... and log them if data comes in from a known id.
Also request open sessions on connect.
And last but not least hex dump data which might be from Health (the tags that I never see on Aplite but always on Basalt)
Created a new device-independent class ActivityUser to hold the data
Moved the constants from the miband constant class to the ActivityUser class
Removed the miband-specific in favor of common-prefixed preferences (with upgrade support for legacy values)
Changed the way the gender is stored to an integer value
Removed the hardcoded default values for user data in favor of static fields of the ActivityUser class
- You should also set reconnect attempts to 0 in preferences when using this.
- It also works when you set flight mode on the pebble, then wait for about 5 minutes and turn BT back on
- Pebble FW 2.x support ist completely untested.
This watchface is used as example: https://github.com/ygalanter/PebStyle because it doesn't initiate a connection like others do.
At the moment this is more a proof of concept^W^W^Wdirty hack then anything else.
NOTE:
Total allowed bytes for all replies = 512 - (reply count - 1)
TODO:
- check with Firmware 2.9.1
- remove last reply that exceeds the 512 bytes limit completly (else it will be partly truncated)
- put random id/phone number pair into limited lookup list (last 16 sms messages) when sms arrives
- lookup the phone number when replying from the a device
THIS STILL DOES NOT DO ANYTHING USEFUL
- parse the reply string in PebbleProtocol
- put replies into GBDeviceEvents
- display a toast in AbstractDeviceSupport, containing the reply
THIS STILL DOES NOT DO ANYTHING USEFUL
- Implement the PebbleProtocol side (2.x and 3.x)
- Add Preferences for canned replies
This can be tested by enabling untested features in Pebble Settings
It lets you see and select the replies set up in "Canned Repies" on the Pebble
You will get a "NOT IMPLENTED" message on your Pebble.
THIS DOES NOT ACTUALLY DO ANYTHING USEFUL YET.
NOTES:
- YOU SHOULD NOT TRY THIS YET ;)
- This was only tested with the unoffical japansese language pack
- Problably needs proper crc calculation (I just hardcoded the one for the japanese language pack)
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.
danielegobbetti