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.
- Untested features have to be turned on.
- We will accept data from any source.
- One way, we do not send out replies.
This already works with the minimalistic sports demo from the sdk
This allowed to remove some ugly hacks from pebble code, when encoding a
response in a GBDeviceEventSendBytes and at the same time trying to notify
generic code via another GBDeviceEnvent.
Previously, the DeviceCommunicationService was invoked directly,
via
Intent intent = new Intent(foo, bar);
intent.setExtra(EXTRA_BAZ, baz);
startService(...);
and this was scattered throughout GadgetBridge.
Now there is a "frontend" available, so that you can call
the service more easily, like
GBApplication.deviceService().connect();
For a start, this client interface (DeviceService) actually
implements the same interface (EventHandler) as the receiving side
(DeviceSupport). This may change in the future.
This will also make testing much easier, because we can use
this client interface to invoke the test service as well.