- 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 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
* ...
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
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.
- supports zooming an panning
- displays labels for all x-values (= time of day)
- fix deep vs. light sleep constants
- increase activity data buffer size for Mi Band
A device now has a busy flag (set during synchronization). While busy,
no other communication with the device shall occur (TODO)
Refactors the non-bluetooth actions a bit #45
Next step: make use of the busy state in ControlCenter (show
a busy cursor) and in BluetoothCommunicationService (to not call other
operations while busy)
* no more ByteBuffer, but a fixed size byte array that gets flushed everytime it's needed
* log of activity data to a separate file (no DB integration yet)
* the size of the buffer must be a multiple of 3 (1 minute of data = 3 bytes) and 20 (the normal size of the chunks we get from the device)
* better logging and more comments in code
To close#29, we need to have a bit more configuration options than
just the number of vibrations. E.g.
- duration
- pause
- LED flashing (again, number of flashes, duration and pause, but also
the colour and maybe which LEDs)
Also implements reboot-functionality for Mi Band.
For a start, use android-logger as backend. Needs a better configuration
but no time right now.
For file-logging we will use logback as slf4j-implementation.
Daniele Gobbetti