Try to reduce time taken to get a trackable online

[lawrence-forooghian]

I noticed that on a stationary device, or on a simulator set to simulate a static location, the first trackable added would come online almost immediately, but subsequent ones would not come online or sometimes would come online after a long delay.

This is because a trackable will not come online until, after the trackable is added, we receive a location update from LocationService. The frequency of location updates from PassiveLocationManager is determined by that of CLLocationManager, which usually only emits location updates when the device has moved a sufficient distance (where “sufficient” is determined by the publisher’s resolution policy).

So, we provide a mechanism for the publisher to request a location update from CLLocationManager independently of the device’s motion, and we request a location update when any trackable (except for the first) is added.

It’s probably worth also explaining how Android behaves in this scenario and why. My notes here are based on the codebase at commit ably/ably-asset-tracking-android@3a0d833.

There are two different things that happen in the Android asset tracking SDK, either of which has the side effect of causing the publisher to receive a location update when a new trackable is added:

1. The publisher calls DefaultMapbox.changeResolution, which in turn ends up removing and re-adding all of (Google SDK) FusedLocationProviderClient’s location observers (via its requestLocationUpdates method). The documentation for FusedLocationProviderClient.requestLocationUpdates) implies that observers will always receive a location update after this method is called (although it might be an old location).

2. (Only in the case where the added trackable is set as the active trackable – i.e. when it is added using .track and not .add)

   The publisher calls DefaultMapbox.clearRoute, which calls (Mapbox SDK) MapboxNavigation.setNavigationRoutes. Through some process that I haven’t looked into, this ends up calling (Mapbox SDK) MapboxTripSession.kt’s navigatorObserver’s onStatus, which makes an explicit call to updateLocationMatcherResult, which emits a location update.

I think that the solution I’ve implemented for iOS turns Android side effect 1 into an explicit behaviour.

Closes #425.

[KacperKluka]

Overall I like the idea and it's great that you've spotted and fixed it 🙇 I just have a few questions about the stopping and starting of location updates 😉

[KacperKluka]

I wonder how this affects the Mapbox SDK 🤔

1. Have you checked whether this doesn't break things like location history recording?
2. Will there be a big delay in location updates between the "stop" and "start" operations?
3. Additionally, do we know what happens when you stop and start location updates? Will it consume a lot of resources to do that?

[lawrence-forooghian]

These are all good questions, I'll look into it and get back to you 🙂

[lawrence-forooghian]

I've added a script for analysing the logs from the publisher example app, to find out if the frequencies of location updates and recorded locations is affected. My brief investigation using the iOS simulator suggests that they are not. However, I want to test on a device too, and for that we'll probably need to add the ability to log to a file. Once I've done that and gathered some results from a device, I'll post my findings here in detail.

As for resources (which I'm mainly taking to mean battery life), I do not know what the impact would be. I could have a think about how to investigate it, but I don't have any ideas off the top of my head.

[ikbalkaya]

The code looks good to me. Like Kacper I also would be interested to know whether stopping / starting location service might have side effects on other areas

[lawrence-forooghian]

Thanks for the review, @ikbalkaya. I've just posted a reply to Kacper's questions, about the current state of my findings: #481 (comment)