I need to get GPS location updates every minute (battery life isn't a problem as the device(s) will be charged within the vehicles). It's a company delivery app, with vehicle tracking, used in conjunction with Google maps, to track journeys for delivery planners etc.
I've used both AlarmManager and LocationManager.requestLocationUpdates() with a listener. The later seems a bit ropey and going by the documentation, it may or may not give a location. But I've seen that even though the minTime is set to 1 minute and distance is 0/1, I'm still only seeing updates once or twice per 5 min period.
private void startGeoLocationSender()
{
LocationManager locationManager = (LocationManager)getSystemService(Context.LOCATION_SERVICE);
LocationListener locationListener = new GeoLocationListener(this);
// MINIMUM TIME TO REQUEST , MIN DISTANCE TO REQUEST, LISTENER
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,
AppSettings.COLLECTOR_PROC_1_MINS,
AppSettings.COLLECTOR_DISTANCE_1_M, locationListener);
}
So, is it worth me just going back to an AlarmManager and forcing an update manually for it to be reliable? Or is there another method, which is 100% reliable given a specific update time? What is better suited to my requirement?
PS. I'm very aware of the other '000s of topics on the subject, but I've never seen such a Good Vs Evil trend. Some folk swear by location listeners, and others only AlarmManagers.
I am not sure of a better way, so I would recommend AlarmManager.
If you use only LocationListener you can't ensure that will receive update in interval time needed.
I really think that the best option is the AlarmManager or a Scheluder Service with a trigger to your LocationListener.
Related
I'm building an app that should be able to report the users exact location. There is only a need for a single location, i.e. I don't need to track the device continuously.
I want the location to be as accurate as possible, and it's okay to wait a short while for the location to be determined (max 1-2 minutes).
I've been looking at FusedLocationProviderClient.getLastLocation(), but since I want the location to be as accurate and updated as possible it doesn't fit my needs.
So I started looking at using FusedLocationProviderClient.requestLocationUpdates() instead, and it seems like a better choice.
But I'm not sure how to best configure my LocationRequest to get as good accuracy as possible. For instance, would it be better to use setNumUpdates() so that I only receive a single update and use that as my location, or should I receive multiple updates in hopes of getting better accuracy (GPS locking to more satellites for example)? I'm thinking that if I use the second approach, I could look at the value of getAccuracy() from each location update and only keep the one with the highest accuracy. The downside is that if the device is moving and I keep receiving updates for a minute or so, the first location could have the highest accuracy, but since it's a minute old it's not accurate any more.
As stated above, I need just a single highly accurate location and it's okay for the app to wait 1-2 minutes for it if needed. What would be the best approach in this kind of scenario?
First, make sure the accurate location is turned on. look at Settings.Secure.LOCATION_MODE_HIGH_ACCURACY It has a noticeable advantage over only using GPS. Then listen for the location for a while and calculate the result you get to find out the best location. You can also detect if the user is moving if the number differs a lot or by using Activity Recognition API. It shouldn't be very hard to write this calculate function to get the best result.
I'm not sure about this but I really don't think waiting more than a few seconds gives you an advantage. to be sure you can simply alter this time and watch the result.
You might want to use LocationManager. In my experience FusedLocation will indeed appear to lock faster but may not be as accurate overall, or at least for a while. I have an app that also requires pretty accurate coordinates. My default is to use a LocationManager based approach but users can switch to a FusedLocation provider if they want faster locking (like when indoors).
This is a good overview https://developer.android.com/guide/topics/location/strategies
For the provider when requesting updates I'd use LocationManager.GPS_PROVIDER. It will take longer to lock since it will wait for satellites and not use Wifi or other towers. But you said that's OK. Something along these lines
LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE);
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, YourLocationListener);
Once you start getting location updates via your listener's onLocationChanged() you can start to inspect the location for accuracy, movement from last location change, etc. to try and evaluate if the GPS receiver is still settling in on a location. Once you are satisfied with the quality of the fix you can stop receiving location updates (locationManager.removeUpdates(YourLocationListener)) and then run your logic that needs the location. The link I provided has good info about this too.
Android programming is a brand new thing to me, i've been playing with android's location and i have a same issue, im going to send a periodic location updates to a server in background and i'm using the AlarmManager/LocationManager approach, set an alarmManager with a defined Interval then when the alarmReceiver is triggered it will get device's current location (using locationManager) and send it to the server on its onReceive method. i found out this FusedLocation as a great replacement as LocationManager give me an additional job to get the best location provider. is it possible to perform sending location updates in background periodically using fusedLocation api without an alarmManager? if so, how can i do that? thanks in advance!
Per the LocationRequest documentation:
In between these two extremes is a very common use-case, where applications definitely want to receive updates at a specified interval, and can receive them faster when available, but still want a low power impact. These applications should consider PRIORITY_BALANCED_POWER_ACCURACY combined with a faster setFastestInterval(long) (such as 1 minute) and a slower setInterval(long) (such as 60 minutes). They will only be assigned power blame for the interval set by setInterval(long), but can still receive locations triggered by other applications at a rate up to setFastestInterval(long). This style of request is appropriate for many location aware applications, including background usage. Do be careful to also throttle setFastestInterval(long) if you perform heavy-weight work after receiving an update - such as using the network.
This allows you to guarantee you'll get location updates based on the interval you set with setInterval(long), giving you the equivalent behavior to a periodic alarm, but if other apps request location information, you may get location information as often as your setFastestInterval(long) - you can set your fastest interval to your interval if you just want location updates at a set interval.
I am developing an android application wherein I need the user location updates pretty frequently. Say 2 times a minute.
Earlier I had been using Google Play Service's "Fused location service" but the location updates were not received as requested.
The location updates got stuck for sometime, the interval between updates jumped to 10min or so.Sometimes even if I put my priority to "PRIORITY_HIGH_ACCURACY" the same happened.
I then went back to the old "Location Manager" and when I used the "NETWORK_PROVIDER", I noticed that the location updates got stuck due to this provider. Also the GPS does not get activated immediately, it takes some time. I am trying to build my custom fused location provider. How can I efficiently switch between providers, without getting lags on location updates.
I want to know what are the best practices for getting location updates regularly, all the time, be it either NW, GPS or both. Like it should work for an application where location updates getting stuck cannot be afforded.
Battery drain is not an issue for me right now.I am aware of all the supporting docs that Google provides regarding location access.
Any help would be much appreciated.
Thankyou !
FusedLocationProvider really is the best option for obtaining locations at the moment, because it uses a lot more than just GPS or Network data to obtain location fixes. I have experienced issues regarding intervals being missed as well, but ultimately this is something down to luck depending on availability of GPS, Network, etc. etc.
My favourite usage of FusedLocationProvider so far is in conjunction with the AlarmManager class: Basically, the idea is to start location tracking at intervals specified by the Alarm Manager (this can be set to every 30 seconds such as in your case). Once the interval is hit, the location provider is to obtain a location fix as soon as possible (so in the setInterval method or whatever it's called, the parameter is a 0). This way, you can avoid having to wait another 30 seconds for a new location, instead having the location tracker attempt to provide a location as soon as possible after the interval specified by the Alarm Manager is hit.
By the way, when making custom location tracking wrappers, be careful of using the .getLastKnownLocation() method as it only uses cached locations - you could end up sending the same location to the user every 30 seconds.
Good luck!
Porting our location based game to Android.
We rely on updating user location when the app is in the background. What's the best way to accomplish this on the Android side while mitigating battery impact?
We don't need high-frequency updates, even 20 minute cadence is acceptable.
Thanks for any help
You will need to create a Background Service in order to accomplish what you want.
Inside that Background Service you will need to use LocationManager and request for Location Updates.
The function that request for Location Updates takes parameters for the fixes intervals as shown below:
public void requestLocationUpdates (String provider, long minTime, float minDistance, LocationListener listener)
you will use the minTime parameter to choose the interval between the fixes:
minTime : the minimum time interval for notifications, in milliseconds. This field is only used as a hint to conserve power, and actual time between location updates may be greater or lesser than this value.
i'm working on app, which must get latitude and longitude. in my case requestLocationUpdates (String provider, long minTime, float minDistance, LocationListener listener) is not in option. why? because i must get location just when user do something that location is needed (let's say he hits button). and i need location exactly on the time, when button is hit. in requestLocationUpdates, we can set minTime-if i set this let's say on 30000 the location at the "button hit time" won't be as good as i want. of the same reason minDistance is also not as good as i want. if i understant function requestLocationUpdates correct-when minTime and minDistance are set to 0, location is updating all the time. please correct me if i'm wrong. app is for company that i'm working at and that app will be used through the day and night. so if app will check for location updates all the time, battery would be often empty. thst's why i need location just at the time, that button is hit. i found requestSingleUpdate function. but i can't use it in eclipse =( like it doesn't exists.
is there some other way to do this or am i missing something?
The requestSingleLocation method new for API level 9. If you are targeting an earlier API level, this method will not be available to you.
One of the problems with obtaining location information is that it can take time to get a fix. This is more of a problem with the GPS location provider than the network provider. If you are only using the network provider, then there may not much of a delay with getting the location information when the user clicks the button (I say this knowing nothing about what your app does with the data, or what type of user experience you are trying to provide).
Something else you can try is the PASSIVE_PROVIDER. It allows you to get location updates that were requested from other apps. This will mean that you have to request the ACCESS_FINE_LOCATION permission however. You may also need to leave something running to receive the location updates (likely a service or a BroadCastReceiver). The BroadcastReceiver approach should not use that much additional battery life since it only runs when the Intent is received along with the PASSIVE_PROVIDER only getting locations when some other app requested them anyways.
The other sticky point with the PASSIVE_PROVIDER is that you should eventually call removeUpdates. Where and when to call this really depends on how your app is structured and how you handle the user exiting the app.
You can use getLastKnownLocation method, but it can be out-of-date. requestLocationUpdates is asynchronous because gps needs to "warm-up" to find new location.
requestSingleUpdate method is available since api level 9, but you can implements it's using requestLocationUpdates and disabling updates after first callback to LocationListener.