Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Periodic foreground location tracking on Android

I am in the process of creating a custom Phonegap plugin for Android that monitors location both when the app is in the foreground and when it is backgrounded. Google documentation on using the FusedLocationProviderAPI is remarkably clear. The process I have worked out thus far is as follows

  • Ensure that the API is available

    GoogleApiAvailability api = GoogleApiAvailability.getInstance();
    int code = api.isGooglePlayServicesAvailable(ctxt);
    return (code == ConnectionResult.SUCCESS); 
    
  • Define a LocationListener with assigned callbacks to handle the results retured by the requestLocationUpdates method.

  • Create a LocationRequest

Here is where things become slightly unclear

  1. setInterval - the interval at which the app wants location updates
  2. setFastestInterval - the interval at which it will consume updates if available.
  3. setSmallestDistance & setPriorty - clear enough
  4. setNumUpdates - how this works is not clear to me. Reading between the lines I am assuming that if I use setInterval(60000) and setNumUpdates(1000) the system will keep sending back location updates for the next 6000 minutes or until such time as the app is backgrounded/shutdown or I/the user cancels location updates.

But then this begs the question - what does the app need to do to be a good citizen. I am assuming that would have to be something like this

  • Record the PendingResult being returned by the requestLocationUpdates call.
  • Detect when the onPause event occurs
  • call PendingResultt.cancel() prior to letting the app go to the background

I'd be much obliged if someone could comment on the correctness of this workflow.

A related issue - The documentation for PendingResult states

It is the responsibility of the caller or callback receiver to release any resources associated with the returned result.

It is not clear to me what resources they are talking about here. The LocationListener.onLocationChanged event returns a Location object which I assume will be garbage collected when it goes out of scope. Presumably the PendingResult being returned by requestLocationUpdates should be canceled and then set to null when the app goes to the background. Is there anything else one needs to do by way of releasing resources?


A few hours later

I created two versions of my test app

  • App 1:Sets up the LocationRequest with setNumUpdates(10000). Pops up toasts on location change in the form App 1:Location is...
  • App 2:Sets up the LocationRequest with setNumUpdates(1). Pops up toasts on location change in the form App 2`:Location is...

I had the two apps running simultaneously and simulated position changes with the help of a really neat little app called FakeGPS. Both App1 and App2 provided me with an update when I did my first fake location change. However, all subsequent location changes were reported only by App 1.

By inference then setNumUpdates provides a mechanism for polling for updates periodically. What is slightly confusing is that the updates continue even after the app is backgrounded - though I assume that this is largely because it is at the mercy of the OS which will kill it when it deems fit.

However, all of the above is based on empirical testing. I find surprisingly little on the setNumUpdates setting.

like image 218
DroidOS Avatar asked Nov 09 '22 15:11

DroidOS


1 Answers

To your question, Is update continue even if app is in background: Ans: What ever be the case setNumUpdates is 1 or x, when your app is in background and is still registered to update, you will get the updates, unless the OS has killed your app, for memory. The only difference that setNumUpdates does is, as you said correctly, if its set to 1, it will give only one update, unless you has reregistered again. Link has sufficient definition for setNumUpdates https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.html#public-methods

like image 198
Ashish Rawat Avatar answered Nov 15 '22 04:11

Ashish Rawat