Coordinate callback getting called multiple times for same coordinate on iOS

[TKFRvisionOfficial]

While recording with no movement at all (in this cased achieved through simulator) iOS will not trigger or record the coordinates at all. It only does at the beginning once, but it seems like it triggers the callback multiple times. This lead to one recorded coordinate being stored multiple times. This is clearly visible by the fact that they contain the same timestamp.

[TKFRvisionOfficial]

After a short look into my own codebase it turns out that I am actually getting the timestamp using the CURRENT_TIMESTAMP default of sqlite. This is super weird...

[TKFRvisionOfficial]

So I researched the topic

What went wrong?

After trying the app for the first time on iOS and created my first recording, at a completely stationary location, the slider in the editor didn't work. It complained that it had not enough divisions, which is a variable that it set to the amount of coordinates in the specific recording. This is weird since the RangeSlider requires at least two divisions but every recording under three cords gets deleted.

So how did only one cord end up there?

I map my coordinates to there specific datetime right here:
https://github.com/tlm-solutions/stasi/blob/c7a66ea8112ffa794e2f78b2c91af10c5beacbf1/lib/pages/recording_editor.dart#L77-L80
If there are multiple points with the same DateTime there is going to be a collision.

Points with the same DateTime? Don't we use timestamps?

Well,kinda. Sqlite don't really has a timestamp fields and stores datetimes as a string. Yes, a string. The way we get those is by using CURRENT_TIMESTAMP as a default for the datetime field. A quick SELECT CURRENT_TIMESTAMP; reveals 2023-02-08 19:22:38. You might already get where this is going but this is only precise to a second!

Are we getting a cord this often?

Yes, we are. I've actually set the duration to 800ms.
https://github.com/tlm-solutions/stasi/blob/c7a66ea8112ffa794e2f78b2c91af10c5beacbf1/lib/pages/vehicle_selection.dart#L95
So the real question is: "Why didn't we have this problem on Android?".

Energy economy. Modern version of android only take these values as a suggestion and only update when they feel like it. This helps to save energy because it prevents bad developed apps, that eat up the battery life of your phone really quickly, existing by not allowing bad energy behavior. So android uses the value more as an min between updates instead of an actually update. The scenario of it actually hitting the same second gets pretty rare and when it happens you normally don't notice in our usecase.

Apple takes with one step further by not offering the option to have such a value. The device decides itself when it updates by figuring out if the user actually moved. The only thing a developer can set is the precision of the location which will just shorten the required distance a user has to travel before the update callback is called again.

But if you don't travel at all?

Well this is where things gets weird. Because if you are completely stationary and you activate the location updates iOS will fire the same location three times in rapid succession at the callback function. This leads to the same location being stored multiple times with the same datetime string.