digidem / comapeo-mobile

The next version of Mapeo mobile
GNU General Public License v3.0
5 stars 1 forks source link

Tracks/ Give permission then remove via device settings - Crash #848

Closed ximenabb closed 1 week ago

ximenabb commented 1 week ago

https://www.notion.so/digidem/Tracks-Give-permission-then-remove-via-device-settings-Crash-13e1b08162d580db9f75c08250ba66ba

ErikSin commented 1 week ago

I think this issue is semi-unavoidable. If we turn off permissions mid track, the system has to shut down the location services. So hypothetically someone could turn off the permissions, move several KM and then turn the permission back on. The track would then connect the last point from before location was turned off to the newest point when location was turned on (in a straight line) which would not be an accurate track as there is no way of knowing if the user actually went in a straight line.

Hypothetically we could show 2 different tracks (or what would look like a broken track) but it does add complexity to the code/user experience. If we are say "pausing a track", we are assuming the the user is going to turn location permission back on (like you did in your example). But what happens if they don't, at what point does a paused track just become a normal singular track?

The point I am trying to make is that turning off location permission should cause the tracks to stop (even if the permission is eventually turned back on).

The problem is, in order to handle this we need a way for CoMapeo to know when permission service has been turned off. Since the location is being recorded while CoMapeo is closed or in the background, we techincally are not running any of the CoMapeo Code. So we cant just simply notify the app that location services as been turned off (because the app could be closed so none of our code is actually running). We could check if the permission services has been turned on every time the app comes back into the foreground. And if the permission have been turned off then we call cancelTracking() and createTrack(). BUT this could lead to an inaccuarate track as the user could have turned off the location service, done a bunch of movement, and then turned on location service (same problem as above).

So we need a way of knowing when permissions services has been turned off, which is not trivial. AND I think this is related to what is causing the entire app to crash. This has not been tested so take this with a grain of salt but I THINK the app is crashing because we are trying to collect the location, but the location is undefined because location services is turned off. Usually when there is an error we can catch the error (and open the error modal). But because our code is not running (because the app is closed so its just the location being stored by the app), we can't simple wrap a try/catch and catch the error. So when the app starts again, the location tracking has thrown an uncaught error and CoMapeo simply shows the uncaught error, which blocks the rest of the app from loading.

I think what we should do first is confirm my theory above, that the crash is happening because the error is not able to be caught. Then we obviously need to deal with that error...but lets try to do that together once we are sure why the app is crashing...