Most of the code is generic, so it could be implemented by other devices.
I dont know what happens if multiple messages arrive in the same notification.
So, this is experimental.
HOWTO:
1) Pair you normal Pebble (not necessary if already done), make sure it was connected once
2) Unpair your LE pebble if already paired
3) Switch on "Always prefer BLE" in Pebble Settings
4) Tap on the + in Control Center to add a new device
5) Pair your Pebble-LE XXXX or Pebble Time LE XXXX inside Gadgetbridge's Device Discovery actibity
Now Gadgetbridge will connect to your LE Pebble when tapping on Pebble XXXX if "Always Prefer BLE" option is enabled.
You can easily switch back to classic LE by turning that option off again
This commit contains the infrastructure needed for the
NotificationHandler to send music state information to the device. That
is, it introduces a call onSetMusicState(MusicStateSpec stateSpec), that
in turn sets up an intent to the service, which will then call the
encodeSetMusicState() function of the device. encodeSetMusicState is
available for pebble only. There are empty stubs for other devices.
- dynamically toggle hr sleep support when preference changes
- check hr support dynaically after device info is available to avoid false error message
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.
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.
