0

I want to update the location every 5 mins till the lifecycle of the application. I know how to update the location. What I want to know is whether the requestForLocation is a blocking call or not.

I can do this in Service class but Service is run on main thread only and also Service can be stopped by the system anytime. I do not want this to happen. The location update should work till the application is in memory. If the application itself is killed then obviously the Service also gets killed.

What should be the approach for implementing this?

sunil
  • 9,541
  • 18
  • 66
  • 88

2 Answers2

2

What I want to know is whether the requestForLocation is a blocking call or not.

There is no method named requestForLocation() or requestForLocationUpdates() in Android. If you mean requestLocationUpdates(), this is not a blocking call.

I do not want this to happen.

Users and the OS have the right to terminate your service whenever they wish. In this case, it's a good thing, because your proposed plan wastes RAM for no benefit.

What should be the approach for implementing this?

Use AlarmManager and a service akin to my LocationPoller, so you can get your location data, do something with it, and shut down until the next period comes around.

Also, please allow your users to configure the polling period, including an option for "do not poll".

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • In the locationpoller example you are setting location updates parameters as 0 and removing the locationlistener once the location is received. Also, the example uses only NETWORK_PROVIDER. I will like to use GPS_PROVIDER whenever available and switch to NETWORK_PROVIDER only when GPS is not available. Rather than using AlarmManager way here, it will be better to use requestLocationUpdates() and specifying 5 minutes for getting next update. – sunil Aug 16 '11 at 13:34
  • 1
    @sunil: "Rather than using AlarmManager way here, it will be better to use requestLocationUpdates() and specifying 5 minutes for getting next update." -- no. First, the time parameter supplied to `requestLocationUpdates()` is a hint, not a rule, and you may get fixes faster than that. Second, this model forces you to try (and fail) to keep a service in memory all the time, keeping GPS on all the time, which will cause your users to abandon you in droves and give you one-star ratings on the Market for cutting their device battery life to a couple of hours. – CommonsWare Aug 16 '11 at 14:45
  • 1
    @sunil: Third, as noted, you cannot successfully keep a service in memory indefinitely, as users and the OS will get rid of you -- and with the GPS on, the OS may do that in as little as a half-hour, due to the aforementioned battery drain. – CommonsWare Aug 16 '11 at 14:46
  • Thanks a lot. I will try to follow what you have suggested. – sunil Sep 06 '11 at 12:20
  • Will the battery be drained even if use only NETWORK_PROVIDER. I guess NETWORK_PROVIDER is appropriate for apps where location info is not that critical. – sunil Sep 06 '11 at 12:22
  • @sunil: `NETWORK_PROVIDER` will use either WiFi hot-spot proximity or cell tower triangulation. While both should use less power than would GPS, I do not have figures handy that would indicate how much power they would consume if used continuously. – CommonsWare Sep 06 '11 at 12:24
0

For some reason this requestLocationUpdates() call is really blocking, at least in the phone brands that I tested. The way to fix it is to use one of its overloads. Please see this answer in another post.

RunRabbitRun
  • 21
  • 3