Trajectories should encode time moving/stayed explicitly about simport-learning-app

[zven]

To properly implement #96 and #102 without any workarounds for the validity check of staypoints, we need to know when tracking was started and stopped. At the moment, it's not possible to distinct between a long stay at one point because the user has not moved from the situation where the tracking was simply stopped (explicitly by user or because app was stopped / has crashed).

[zven]

After looking into the API of the background geolocation plugin, I have identified the following cases:

We can subscribe to start and stop events that area triggered when the user toggles location tracking by hand (the happy path).

The more interesting cases are the not so happy paths:

1. App is closed / killed: In Ionic, we don't seem to have a way of finding out if our app is currently being killed by the OS. Thus, we can not record a stop here. We are only able to detect if the app is put into background and if the background geolocation plugin switches into background mode (and keeps tracking the user).

2. Then, we have another case related to the background geolocation plugin: We have set stopOnTerminate: false. Which means when the tracking runs, the app is closed / killed and then opened again, the background tracking continues (thus the user does not need to start the tracking again by hand). However, this case would be something we would need to detect by hand since no callback is available here.

[zven]

Todos:

• analyse lifecycle of start and stops on Android and iOS
• implement persistence

[zven]

Analysis of location tracking start and stop behaviour:

• we can detect start / stop when manually triggered (start and stop events are fired)
• iOS:
  • start tracking, kill app (swipe away) -> start app again -> previous running state is persisted + no tracking started event -> indicator for marking last known location as stop and / or the latest location as start
• Android:
  • start tracking, stop app (swipe away) -> start app again -> previous running state is persisted -> indicator for marking last known location as stop; issue here: tracking does actually not resume for whatever reason (click on stop button twice and start again, probably related to #97)
  • start tracking, kill app (via "Force stop" in options menu) -> start app again -> running state is false -> need to restart tracking by hand; situation two times start in a row

[zven]

Maybe it could actually suffice to save start events only?