Questions regarding debugging logs and plugin behaviour

[tombotley]

Your Environment

• Plugin version: 4.16.0
• Platform: iOS
• OS version: iOS 17
• Device manufacturer / model: iPhone 12
• React Native version (react-native -v0.73.6):
• Plugin config "Default"

  desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
  distanceFilter: 200,
  preventSuspend: false,
  stopTimeout: 5,

"Active mode"

  desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_NAVIGATION,
  distanceFilter: 25,
  preventSuspend: true,
  stopTimeout: 15,

Please could you help with some questions I have regarding the debugging logs to help me better understand some issues we are facing with our iOS app geolocation tracking.

Please could you explain the meaning and trigger action of the following logs? TSConfig persist -[LocationManager requestLocation] ONESHOT -[TSLocationManager startMonitoringStationaryRegion:radius:] Radius: 200

Further questions: If we are not using the URL/HTTP service feature to send location data to our server (we are instead doing this in the onLocation callback, something we may look to change in the near future) then what could be the reason I am seeing -[TSHttpService finish:error:] Success: 0 in the logs after a location point is received? Is this triggered by our onLocation endpoint call?

Is there a log that should be seen when setConfig is called? I am not seeing anything with verbose logging but can see evidence in other logs that the config has changed when expected such as a change to the distance filter value.

In the following log -[TSLocationManager locationManager:didUpdateLocations:] Enabled: 1 | isMoving: 0 | df: -1.0m | age: 23 ms what does “df: -1.0m” mean?

There is a log recorded during one test as follows -[TSLocationManager locationManager:didUpdateLocations:] Updated distanceFilter, new: 50.000000, old: 25.000000 but we only ever set a distance filter of 25 or 200. What might be causing the change to 50?

Should -[TSLocationManager getCurrentPosition:] only be seen in the logs when WE call the method in our code? When the didUpdateLocations logs that a stale location is received and multiple samples and logged would each of these trigger the onLocation event listener? And would the plugin’s HTTP service include all of them in a batch or omit the stale ones? In the docs when you say that preventSuspend must be used in conjunction with a heartbeatInterval do you mean that preventSuspend only works with a heartbeatInterval or the other way round? (Or both?!)

In our app we have an “active” mode which is a period of time during which we set preventSuspend to true and reduce the distance filter from 200 to 25 metres. When the app is in the background the onLocation callback will determine when this active mode period has ended and call setConfig to change preventSuspend back to false and increase the distance filter back to 200 metres. We have been testing this by starting active mode and going on a journey and not opening the app until after active mode and the journey have ended, the device is stationary and the blue bar location service indicator has disappeared. In some tests this works very well but in others it seems that the config is not at all or only partially changed, the blue bar persists for up to 2 hours and the battery is draining at an increased rate. In these cases, at the point of the setConfig change we tend to see the location points stop entirely (not even getting them at the expected 200m intervals) suggesting something has happened but the 25m active mode distance filter can still be seen in the logs and seemingly preventSuspend is still keeping the service alive. Could it be that setConfig is failing to resolve and would we expect to see either some or none of the settings change in this case? I suspect we will need to move to the HTTP service and using the response from our server to update the config instead.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.