Users simply turn off location on their devices which means a lot of these apps either don’t work at all or they work in a degraded manner.
why do users do this?
Because fairly or not, they associate a location with battery drain and they think turning off location will help preserve battery .Location is used a lot- we know that.
The relationship between Battery drain and Location
The relationship between battery drain and location in sort of a concrete way.I mentioned with theFuse Location provider you have to essentially tell Fuse location provider what you want. You make a location request, and each does the right thing, and it does the right thing in a battery-efficient way.So, essentially, what this post is going to be, it’s going to about what is a good location request ? How do you tell Fuse location provider what it should do? So, I would say battery can be measured on three points , the discussion can be anchored on this three-point: accuracy, frequency, latency .
It is course how accurate is your location? How fine do you want it to be? The way this works is that you can take the location request that you create and define a priority.There are a bunch of priorities that you can choose from, and depending on what you choose, the Fused location will give you different technologies under the hood and give you what you want.
Request request = new LocationRequest(); request.setPriority(PRIORITY_HIGH_ACCURACY)
The most accurate state-of-the-art is priority high accuracy.This will use GPS if it is available, and everyone will lose and accuracy will win.It is going to give you the most accurate location it knows how to do. This is a good kind of a use case for the foreground , when you have a short-lived activity that’s in the foreground, or something.This is a terrible idea for the background because it is going to be prohibitively expensive in terms of battery .
Related to that is another priority balance power accuracy .This will rarely use GPS but will have GPS matching and will not.I would recommend you writing the location apps to consider this something as a default.It does give you pretty good location without burning out your battery .
The next is “priority low power” and this will be hitting the cell network , not using a lot of Wi-Fi, it will not use GPS. This will give you coarse location .You can’t say I’m a few feet here or there, but you will be able to say I’m in this part of city vs that part of the city.Depending on your use case, this may be all you need in which case you should never request more expensive location updates than this.
The most interesting of all is the “priority no power”
Which is saying give you location updates but not spend any power .How does this bit of magic work? In this case, what you’re saying to Fused location power is don’t calculate any location for me. If another app is computing that, let me know the results .That’s what “priority now power” means and it’s an incredibly good tool to have because it doesn’t cost your app anything .
Again, it is fairly simple to understand what this means.The more frequent your updates, your location consumption, the more expensive.It is for the batter but it is a little bit more than that.Frequency is defined by a
setIntervl() .Location services will try to honor that value.If you say give me location updates every two minutes, it will try to do that.If you do it every 15 seconds, it will try to do that.Generally speaking, apps should pass the largest possible value when using
al() .Especially background apps.Using intervals of a few seconds,15 seconds, 30 seconds, it really is something you should reserve for foreground use cases.Location services will sort of doing what you ask it does.It is up to you to choose wisely.Now, if you say location update
setInterval() for two minutes, there’s caveat there which is that is just a suggestion.Your location updates may be a little slower or a little faster.The way that can happen a little faster is if another app is requesting location at a faster rate, that will be brought to your app as well because this location data is shared between apps.
So for that reason, Android has another method we can call in building our location request called
setFastestInterval(..) .It says give me the location, even if it is coming from another app no faster than what I’m specifying coming from another app no faster than what I’m specifying here.So, here’s a little example.
Request request = new LocationRequest(); request.setInterval(5*60*1000); request.setFasterInterval(60 *1000);
You create a location request object and set its interval to be five minutes.So at this point, every five minutes, your app is going to have location computed for it But if you also
setFasterInterval() , which is, in this case, one minute, any app running out there this is requesting location also, that location will be made available to you but no faster than one minute.This is a pretty good way of not burning the battery yourself.You’re relying on other application to do the work and you get the location kind of freedom that they’re doing it is a passive way of getting location, and it’s a pretty powerful way of conserving battery.
The latency is really about when location services have a location to give you, how quickly do you need it ? How quickly do you want location updates to be given to you?So, remember, we talked about
setInterval() , when you set an interval of 30 seconds or two minutes, that’s what location services will try to use as this interval at which it gives you location.There also a method call
setMaxWaitTime() which is a way of having your location delivered in watches after a few times after it’s been computed.
setInterval() is how often is location computed for you?
setMaxWaitTime() is how often location is delivered to you.
Request request = new LocationRequest(); request.setInterval(5* 60 *100); request.set.setMaxWaitTime(60*60*1000)
Let me make this concrete with an example.Again, we create a location request and set the interval to five minutes.This means low cakes will be computed for every five minutes.if in that time when the location is found and a new location is found, and your app will be woken up, and that location will be given to your app. If you set a max wait time of one hour, something different will happen.Your location will still be computed every 5 minutes but it will be delivered to you in a batch every hour, and you will get 12 location data points, at least in theory in. Instead of being woken up five minutes, your app will be woken up every hour which is dramatically better for battery consumption.Batching is a really, really good thing to use, especially for background case where you don’t want your device to get woken up a lot.
If you’re using geofencing, it’s the set Notification Responsiveness.if you don’t want your geofencing to be immediate, you can have a window to hold off before a geofencing result is given to your app. You can set the responsiveness period to something high, and that is also a very good thing for battery.
new Geofence.Builder() .setRequestId() .setCircularRegion() .setExpirationDuration() .setTransitionTypes() .setNotificationResponsiveness() .build()
This is a classic case of how you build a geofence.you set a circular region, you set when it expires, you set what condition you want, and you build it.But if to that you add a
setNotificationResponsiveness and give it a sufficiently large value.That will make your geofencing all the more battery-efficient.
That’s a bunch of stuff summarise, it is a fairly obvious thing, the more frequent and more accurate your updates and the lower your latency, the more expensive it is for battery. So, in foreground use case, you could have it all – you can be frequent, as accurate as you want, as low latency as you want, but for everything else,you’re going to have to trade off on one of these or more than one of these, and that’s where you get to preserve battery.
Share this post: on Google+