Prevent duplicate notifications with a dedicated data structure (not reusing
the anti-burst one) #1062, #657
Pebble: Forward the actions attached to notifications (not only reply)
inspired by the work of dnastase #705
(This is called "Activity" in Gadgetbridge, since we have that on the Bip, we should probably rename that to Workout also for consistency with the menus)
The issue here is the following:
- we used intents in the generic BleProfile classes to notify about the results of e.g. certain read requests
- we used to send these results asynchronously via LocalBroadcastManager.sendBroadcast(), which always used the main thread for sending
- however, we noticed that reconnecting to devices sometimes failed because the results arrived too late and the next action in the BLE queue lacked the necessary information
- the fix was to use LocalBroadcastManager.setBroadcastSync(), so that the results arrive in time
- this unfortunately meant that they were not sent in the main thread anymore, and especially, this would send all pending intents that were previously queued via sendBroadcast() also in the "wrong" thread (in order to keep the order of events)
The fix is to use a custom IntentListener callback interface for synchronous notifications of ble profile results
*without* also causing other, previously queued intents to be sent.
Fixes#1218
NOTE:
- Needs latest firmware
- Setting to Japanese or Korean leads to empty menus on the device. When
reconnecting you, will get a sceen which telling you to update. I highly
suspect it requires flashing Mili_wuhan.ft.kj (kj=korean,japanese)
Play/pause and skip to previous/next song work. The currently playing song
name is shown on the Cor. The track length and progress are now shown as
we don't know how to send these yet.
- Rename MiBand2Service to HuamiService
- Move preferences around (Mi Band 2 has its own device specific settings now)
- Fix Cor menu items not syncing immediately in settings
- Try to support settings menu items on Mi Band 3 (buggy, disabled code for now)
