- Live sensor data reading is toggled using the "Set music info" in the debug activity.
- The readings are ONLY logged at the moment
- The miband increments a "counter" (two bytes) at every reading, but it may be that more readings are sent with the same counter value. This is already addressed.
- The name of the axes is general (axis1, 2 and 3) because we still don't know which is which
- It could be that the axes depend on the wear location (especially wearing as a necklace means that the miband rests in a vertical position, while wearing on the wrist means it rests in a horizontal position). NB: It could be that we get RAW data, hence not dependent on the wear location.
- Since the miband may be inserted in two directions in its strap, I guess this also has to be taken into account
- the battery impact of reading this data in unknown
- 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.
- use just one data set, because multiple data sets is not supported
by MPAndroidChart (the way we need it)
Now there is hardly any space between the bars anymore
Also:
- allow scaling x and y axis independently via pinch gesture
- set fixed y max value (1.0) so that the display is stable and
independent of the actual available data
- (at least temporarily) display y labels
Daniele Gobbetti