(e.g. when switching to another day for which no samples are
available, the chart now becomes empty instead of displaying the
samples from the last day with data.
This avoids a lot of problems because java
- does not know unsigned values
- jvm and dalvic do not internally support byte and short
- sqlite does not know them either
Currently we get the heart rate when synchronizing activity data
(i.e. not live) and we write it to the activity database so that we
can show a nice graph. The value is currently always 0 though,
because we can't enable recording hr, yet.
The reason being that we filter samples by activity kind
and then calculate the total sleep time using a delta between two
consecutive sample timestamps. But due to filtering of samples, not
all samples are consecutive. Instead of we have "holes" and add those
to your sleep time.
The data in the db is correct though (it always is), it's just the
display in the app that is wrong.
Nice hack: MPAndroidChart supports animating values, but only animating
a new entry, going from zero to its actual value. We want to animate
a single entry changing its value.
Since it's just a single entry, we can let a custom animator do this
(without knowledge of any other entries).
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.
They are now managed by the Activity, because the fragments
may be created and destroyed at any time and hece cannot
synchronize their date-state all the time.
Open issue: moving across the borders (first day with data,
current day)
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.
- model package contains mostly shared interfaces (UI+service), not named GB*
- impl package contains implementations of those interfaces, named GB*
the impl classes should not be used by the service (not completely done)
- the service classes should mostly use classes inside the service and deviceevents
packages (tbd)
Every device now has two packages:
- devices/[device name] for UI related functionality
- service[device name] for lowlevel communication
