Fix: sync iOS `rid` and Android `id` in the `waypoint` payload

[pauloantoniassi]

Currently, even having an int/long ID, the Android app uses tst as a unique key. Meanwhile, iOS added the property rid. This difference causes issues when sending updates (via setWaypoints cmd) between both OS, Android can detect just fine duplicates (as they have the same tst), but the iOS is having a hard time detecting the duplicated object and may add an extra record to the list of regions/waypoints.

When a message without rid arrives to the iOS app, the app creates a rid from the hash of tst+name, but this means the name can not be changed at all. Also, new waypoints are created by the iOS app using random IDs, but this information is lost on the Android app, so updates submitted by the Android for a waypoint created by iOS might not have the same rid (because as the rid is missing, iOS will generate one from the hash, which might not match the random one).

My suggested implementation is to keep the tst as the "main" unique key in the Android app, but adds the rid property as a secondary unique key (maybe a hash from the tst). This way the app can save the rid generated by the iOS app (and send it back for updates) but also Waypoints as a whole will have an ID that is common and stable between OS's.

---

• Tested with: Android 2.5.0-beta1 GMS (GH releases page) / iOS 17.2.5 (App Store)

[pauloantoniassi]

Btw, I'm not an Android developer (I'm a BE dev), but I can try to implement this if it makes sense.

[wir3z]

Fully agree with this concept. iOS using the name as key always breaks when the users decide they want to rename a waypoint.

As a workaround from the hub side, I send a clearWaypoints command before setWaypoints command. This removes all the waypoints on the mobile, and replaces then with "correct" ones.

Only catch is you need to send all waypoints vs update a single one.