It occurred to me that onServicesDiscovered() was called multiple times
whenever I connected to my Mi Band 2. Either the band actually sent the
characteristics in multiple chunks or Android itself notified multiple
times.
So we gracefully handle this by
- updating the list of characteristics
- *not* initializing the device again when it *is* already initialized
or at least initializing.
- support for org.bluetooth.characteristic.local_time_information
- support for day of week in 0x2A2B
Unfortunately Mi Band 2 does not support 0x2A0F ;(
Some APIs have become synchronous, it seems, e.g.
connectGatt() -> onConnectionStateChanged() -> discoverServices() -> onServicesDiscovered()
appears to happen synchronously. So connectGatt() will not return before services are discovered!
So now we deal with this situation.
This avoids a lot of problems because java
- does not know unsigned values
- jvm and dalvic do not internally support byte and short
- sqlite does not know them either
Sometimes reconnection lead only to "Connected" state, but not "Initialized".
This probably happened when the device got disconnected earlier and then was
automatically reconnected. The reconnection closed the previous connection,
which caused the dispatch-thread to wake up and think the connection is
actually establish. Then, when the first action is invoked, it would fail
with an NPE because mBluetoothGatt passed to the action is actually null.
- listen to notifications early -- the band then actually tells us that
authentication is required
- check for this after sending user info
- add authentication states to GBDevice
- workaround for event problems in pairing activity (delivered although
already unregistered)
- BtLEQueue now deals with gatt events coming *before* connectGatt()
actually returned (namely the connection event)
The notfification APIs now use NotificationSpec as their only parameter, which
contains all information (required and optional ones).
We no longer have separate methods and actions for SMS/EMAIL/GENERIC anymore.
The type of notification is important now, not how we received them technically.
- the BASE_UUID is shared between all BTLE devices, not miband specific. So are the UUID DESCRIPTORS. Hence these have been moved to AbstractBTLEDeviceSupport
- the gatt-characteristic-property-constants used previously in MiBandNotifyAction are also general, and exposed by the gatt subsystem, hence the specific action has been dropped moving the logic to the NotifyAction class
- the logic for checking the gatt-characteristic-property-constants has been extended also to the ReadAction and WriteAction class, this way we won't try to read (or write) a characteristic that isn't readable (or writeable)
- model package contains mostly shared interfaces (UI+service), not named GB*
- impl package contains implementations of those interfaces, named GB*
the impl classes should not be used by the service (not completely done)
- the service classes should mostly use classes inside the service and deviceevents
packages (tbd)
Every device now has two packages:
- devices/[device name] for UI related functionality
- service[device name] for lowlevel communication
