- 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)
Due to a bug in DeviceCommunicationService.isConnected(), devices using the
INITIALIZED state only worked when they had useAutoConnect set to true (Mi Band)
Now setting devices to INITIALIZED state to allow any action send to
DeviceCommunicationService is mandatory. As an exception only
REQUEST_VERSIONINFO will be also be allowed for CONNECTED state.
This also fixes a problem when notifications came in on the Pebble with 3.x
FW before we actually knew it was FW 3.x (INITZALIZED state on the Pebble
now implies that we know the FW version)
It's still very much possible to leak the descriptor (when an exception occurs
somewhere in between or anything else goes wrong). So maybe the whole thing
should be redesigned to be independent of files.
- 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
There are some inconsistencies across ROMs: some need the mimetype filter to be present in order to match the file extension, other refuse to do so if the filter is present. Current strategy is to satisfy both requirements by duplicating the filter element.
At the moment the progress bar code is not useful because the FW preparation is almost instantly done, and is the BT transfer that takes time.
The transfer happens when the getQueue method is called, and there is no progress info that I can find.
- add some device and db independent model interfaces for activity samples
- use these model interfaces where possible
- chart activity does not do device dependent rendering anymore and uses
normalized values for all devices
- initial interface for daily summaries
This way on android 5 the status of the connection is shown also on the lockscreen even if the user chose to hide sensible content of the notifications.
java.lang.NullPointerException: Attempt to write to field 'int nodomain.freeyourgadget.gadgetbridge.miband.MiBandSupport$ActivityStruct.activityDataHolderProgress' on a null object reference
at nodomain.freeyourgadget.gadgetbridge.miband.MiBandSupport.flushActivityDataHolder(MiBandSupport.java:748)
at nodomain.freeyourgadget.gadgetbridge.miband.MiBandSupport.handleActivityNotif(MiBandSupport.java:689)
at nodomain.freeyourgadget.gadgetbridge.miband.MiBandSupport.onCharacteristicChanged(MiBandSupport.java:583)
at nodomain.freeyourgadget.gadgetbridge.btle.BtLEQueue$2.onCharacteristicChanged(BtLEQueue.java:369)
This release seems to be working quite well with respect to the firmware upgrading itself. The user facing part needs more work.
In order to update the firmware one has to:
- open a file ending with .fw
- switch from the firmware upgrade activity to the main one
- connect to the miband
- return to the firmware upgrade activity
- press the "install" button (that became active when the device connection was established)
Caveats:
There are almost no check wrt. the integrity of the firmware files.
Known issue: scrolling a zoomed-in chart interferes with swiping to the
next/previous chart (so far there's just one, but...)
Workaround: Swipe down and then left or right in one go, this will let
you scroll the zoomed chart
- the day of week are evenly spread across the screen in the alarms detail activity
- the alarms are stored in a single shared preference (as a set) NB: you'll have to reset your alarms if you used a previous version (and also manually clean the shared preferences, but this is not needed)
- the list of alarms gets correctly updated after editing a specific alarm
- the actionbar back button saves the alarm status, the device back button doesn't. I'm not sure if it's a bug or a feature :)
The code basically works, but there a lot of things to fix / improve.
* The alarms are stored to and read from the Shared Preferences, but there is no persistence within the app (basically they are read and stored at every access)
* The alarm list is not updated when coming back from the alarm detail view (probably related to the point above), but the actual alarm is
* The alarms preference names is sometimes built by concatenating strings, which is not really safe
* There is no check in the alarm constructor whether the stored string is a valid alarm representation
* Even though only 3 alarms can be stored on the device, we could have more in the app and let the user choose which to sync
* In the alarm detail view XML some material* drawables are used, it's possible that these break on android version < 5
* ...
- one fragment per chart screen
- common chart code should move to fragment baseclass and the host
Activity (ChartsActivity)
Currently it's not used, change ControlCenter to invoke ChartsActivity
instead of SleepChartActivity to test it.
WIP for #79
Configurable for sms, k9, incoming calls, pebble messages, generic
notifications.
Color is unfortunately not configurable so far, see #37Closes#29
Currently provided profiles are
- staccato
- short
- medium
- long
- waterdrop
- ring
- alarm clock
When enabled it forces to use 3.x notifications on FW 3.x (2.x notifcations on FW 2.x)
When disabled 2.x notification on FW 2.x and 1.x notifications on FW 2.x are used (which is recommended)
This allows Pebble Time users to do further tests.
- display the recorded level of deep sleep rather than a constant
(I hope this works for morpheuz, too!?)
- give light sleep a minimum value, because it's sometimes 0 for Mi Band
on the UUID_CHARACTERISTIC_BATTERY characteristic.
This is a first try at addressing #71
Please note that this will probably not work at this point, but it's
worth a try. To make it work probably we have to tell the device to
send updates, and we don't know how to do it.
