Numeric BaseTypes now return fractional part if a scale is set, the return type for numeric values is unboxed from Number class so that existing comparisons and checks keep working, but values are not truncated at nearest integer value.
The codegen class has been updated and some of the messages are re-generated with the new code, with the exception of Hrv* messages, since updating those needs updating the related sample types.
Test cases expected values have been adjusted to keep into account the fractional part of some fields.
Garmin: Fix HRV value and summary types
- Make workout summary persisting idempotent
- Do not delete any data from the database during re-processing, since
the entire process is idempotent now
- Improve feedback during re-processing using toasts
- Prevent re-processing from being started multiple times in parallel
Test regression introduced by the refactor in 34378a4a1
The function is not used a lot, and it's currently misleading alongside
getAllActivitySamples, so it could eventually be removed and the logic
simplified.
Push the legacy values as overrides to all subclasses, ensuring that new
devices start with the expected correct behavior.
Overrides can be removed from the subclasses if devices are confirmed to
work without them / not rely on the erroneous behavior.
The previous attempt to send all zeroes (in 7fa5cd1be5) didn't yield actionable progress, hence we try sending back what the watch sent to us.
Blindly implemented based on the legacy vivomoveHR code, not tested against real devices.
Add a Field definition for GPS coordinates and remove the corresponding method from GarminUtils.
Add a new message COURSE and some fields to other known messages.
Also centralize some utility methods in GpxParser and GpxTrack, adapting ZeppOsGpxRouteFile.
Be aware that the capability used to identify the supported watches might be the wrong one.
Our implementation of scale and offset was backwards: we were adding offset and then dividing by scale when decoding fields, but the publicly available protocol description dictates otherwise ( http://web.archive.org/web/20240519102659/https://developer.garmin.com/fit/protocol/#scaleoffset ): "the binary quantity is divided by the scale factor and then the offset is subtracted".
For this reason the sign of GARMIN_TIME_EPOCH in Timestamp field definition must be flipped as well.
