What I want to do:
I want to have my iPhone to frequently (formally defined later) upload my GPS location to a central server. I want to do this in the most battery efficient way.
Research I'm aware of:
Apple Documentation:
https://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html#//apple_ref/doc/uid/TP40007126
Stack Overflow Links:
Response 1
Response: proof of existence; some other tool can do it
How to reduce iPhone battery consumption while using GPS
Response 2
Response: track only cell tower changes
iPhone GPS - Battery Draining Extremely Fast
iPhone running periodical process in the background - battery optimized way
Question
My question is a bit vague in that my definition of "frequently" is really dependent on what the battery life can tolerate. For example, if the battery can take updates of every 5 minutes, I'd like to do it every five minutes; if the battery could do this every 10 seconds, I'd like to do it every 10 seconds.
I really want to understand
the different ways (change on significant location, timer, background?) continuously uploading GPS locations can be implemented
advantages / disadvantages
approximately how long the battery life can last in each case
This seems like a fairly generic and common problem. Does anyone know of either:
an in depth analysis of the various methods
or if there is a single "optimal" way to do this?
[Moderators: feel free to mark this comment wiki. I'd love to just get lots of different answers + cost benefit analysis of them.]
Have a look at the Apple Documentation Here.
The significant-change location service offers a low-power location service for devices with cellular radios. This service is available only in iOS 4.0 and later and can also wake up an application that is suspended or not running.
It all depends on the use case. If the user will stay at a certain location and all you want to do is to track if he is leaving the country, tracking the significant location changing will be most suitable. However, this will not be precise enough for navigation apps.
One advantage of choosing the "Apple-Algorithm" is that they'll optimize it for you, if battery issues occur. (-:
Related
Some of my users ran into an issue where they couldn't fetch the location using Location Service.
In the screenshots they sent me, i noticed that the battery level was really low, like 2-5%.
My question is, does iOS stop the location service when the device is running out of battery?
Thanks
Enabling Low Power Mode (the one that turns the battery icon yellow) does several things to reduce the battery usage of your device. This probably includes the accuracy and refresh rate of the GPS.
If you're requesting a location with a high level of accuracy, the system might either take too long and timeout or just decide not to fulfill that request since the hit on the battery would be too much.
does iOS stop the location service when the device is running out of battery
It certainly might. The GPS is one of the highest power draws of all the sensors. Turning it off would make a lot sense. See also Apple's own statements about low power mode:
https://support.apple.com/en-us/HT205234
Note that if this is the case, it would hardly be an issue with your app. Your app might use a lot of battery, which could be a problem; but if location services itself is affected, all map/navigation apps would be affected.
I am trying to set up an app that will be able to check people's locations in the background, see if they are at a given location, and send a ping to a server if they are. We do not want to drain the energy of our users, so we are attempting to figure out the best solution.
I've done substantial reading and I have not found very much information on these methods. I'll go through the pros and cons as I understand them right now
startMonitoringForSignificantChanges
Description: Based off of wi-fi and cell tower changes the system wakes up the app.
Docs:
Apps can expect a notification as soon as the device moves 500 meters
or more from its previous notification. It should not expect
notifications more frequently than once every five minutes. If the
device is able to retrieve data from the network, the location manager
is much more likely to deliver notifications in a timely manner.
Pros:
Most battery efficient
Cons:
Dependent on wi-fi/cell tower changes
Can only assume that this will be called every 200m to 2km (if not more in certain areas)
More on accuracy
Thus, inconsistent and imprecise
10-minute start-updating or "n-minute updating":
Description: This basically asks the app for more time, when that extra time is about to expire, it calls [self.locationManager startUpdating], grabs the location and extends the background thread for 10 more minutes.
Pros:
Consistent
Can be as accurate as you want it to be as consistently as you
want it
Cons:
Has to do a call every ten minutes or less to keep the app running in the
background (ie n can't be greater than 10 for the calls)
Questions:
What effect does this have on the battery? Does waking up the GPS and shutting it off hurt the battery more? I couldn't imagine running a brief location check in the background would drain the battery that much... but then again, I don't know what goes into powering up the GPS and getting a usable signal.
startMonitoringForRegion (geo-fencing):
Simply put, your app gets woken up when you enter into a pre-defined region. This is the oddball of them, it is more recent and there is less documentation on it. I can't find a good description on how the "system monitors" the boundary crossing. For all I know it is some really smart algorithm, or they are constantly pinging the GPS which would make it less effective than the other methods for doing this.
Pros:
Simple implementation
Managed by the system so you don't have to invent your own ad hoc geo-fences Only triggers on boundary crossing... no unnecessary data to just throw out in exchange for a battery hit
Thus, should be the best for this sort of thing, accurate, managed by the system
Cons:
People question its effectiveness
Huge conflicts on whether or not it is good for battery life or if it
drains battery life terribly.
How is the system monitoring this!?
Basically, indeterminate behavior.
I guess my question boils down to how does startMonitoringForRegion: compare to these other methods of testing user location in the background when it comes to battery life, consistency, and precision. Has anyone thoroughly tested this? Or used it in their app and gotten at least some feedback? Likely, for my purposes, the trade-off is between geo-fencing and the 10 minute update method. (Also given what Apple has publicly said about iOS7 there will be some background tasks... will this change the calculus for the trade-off between these two methods?) Does anyone have an idea of how these two compare?
Thanks so much! Looking forward to seeing if we can get to the bottom of how to compare these methods.
I've been working on vehicle tracking using GPS for 2 years. Learned a lot the hard way... In my experience startMonitoringForRegion or Geo-fencing depends upon cell change events, didEnter or didExit events doesn't fire up until there is a cell/wifi change event. So it doesn't make any difference w.r.t battery consumption. However it does extra computation which depends on how many regions currently are being monitored. Even Apple's Reminder app doesn't give good results for location based reminders because it uses geo-fencing.
The other approach starting GPS for n minutes after each m-minutes is good option, it should not affect the battery life, if done wisely. What exactly effect the battery is constant GPS activation in high precision mode. Like for instance If you enable GPS with kCLLocationAccuracyBest and distance-filter = 0, you can literally observe battery drainage and soon your device will also start getting hotter.
If I was you, I would go for activating GPS after every 10 minutes for 5 sec with kCLLocationAccuracyBest (or may kCLLocationAccuracyNearestTenMeters to use less battery, if accuracy is not that much important) and distance-filter = 5 (meters). Battery consumption in this case will be unnoticeable. You can play around with similar settings which can address your specific case and finally find out what is best you.
BTW: iPhone uses AGPS, A-GPS additionally uses network resources to locate and use the satellites in poor signal conditions. So, when you do startUpdatingLocation it will also use nearby cell tower information. see http://en.wikipedia.org/wiki/Assisted_GPS
I would like to share the info of my performed testing scenarios and to ask you to share your experience with region monitoring. So, I have registered two opposite regions (A and B) with 5 km radius and 1 km desiredAccuracy, with the 20 km distance between them. However, I haven't received any didEnterRegion/didExitRegion events when traveling from A to B. In my app prototype, I also put two buttons (for testing purposes): one starts significant change and another standard location monitoring. Both prints didUpdateToLocation events on-screen-log.
So, after getting to the center of region B and being very annoyed about the unpredictable functionality, I have enabled significant monitoring. After that, I have received several didUpdateToLocation with horizontalAccuracy of ~8.5 km! Wow, that hurts, because all I want to do is to have a functionality where a user would be notified, that his desired place is somewhere in radius of 5 km from his current location position, and I want to rely on GSM cell triangular location detection method only (for preserving the battery).
So, back to my case. After getting such a big 8 km error, I have enabled standard monitoring with best accuracy (GPS). And bingo, I have received didUpdateToLocation event with horizontal accuracy of 399 m, and only then, I have received didExitRegion from my initial place (region A), and another event with didEnterRegion (B). Another updates from didUpdateToLocation where a little bit more accurate - 50m.
In previous scenarios, I was getting unstable accuracy also. Sometimes there were 4 km horizontalAccuracy, sometimes less. But the main question that is, if we want to preserve the battery (Apple teaches us that in docs) then can we rely only on region monitoring + GSM without using GPS? There's a sample of Apple code with "proper use of region monitoring" (here), however there are some unacceptable things there:
1) They state that sample code works only for iPhone4, though Apple docs state that both region monitoring and significant monitoring are supported on iOS4.0+. Cool, ha?
2) The sample code uses all 3 location methods: significant, standard, region. It uses region monitoring all the time but in addition in uses standard location with best accuracy. When app enters background it stops standard and starts significant change monitoring. When entering foreground then app stops significant and starts standard location. Seems like apple docs are quite vague, it's unclear what penalties (horizontalAccuracy) do we get if we use only region monitoring, or do we have always to use all three methods?
3) Apple docs state that we need to preserve the battery and to use as minimum location services as we need, if we don't need GPS then we should use GSM (for example, 1 - 3 km desired accuracy). But the sample code uses best desired accuracy (GPS) both for region monitoring and standard monitoring (when app is in foreground). I do understand that GPS would solve all my problems with errors and accuracy, but what about using GSM only? After getting 8.5 km horizontalAccuracy in my scenario, I'm not sure is it possible to use region monitoring at all because it's unable to provide at least 5 km acceptable error.
In my experience, the region monitoring is pretty accurate without a significant loss to battery life. I have a use scenario of regions that are only 30-50 meters wide. No issues at all with accuracy. One thing I will say, I have only targeted iPhone 4 devices and up. I will need to implement some of the changes you talk about if I want to support the 3GS models.
When relying purely on -startMonitoringForRegion, your updates automatically trigger on the -didEnter and -didExit events. These are triggered through a combination of location tracking events. Significant changes, cell tower transfers, connection to WiFi, another app requests location, and a few others. The OS handles when the callbacks are triggered from these other shared location events. In my experience, it has been very accurate. But this is only for iPhone 4 and up.
I also used the example app from Apple to get things set up, but there isn't a lot of detail in the documentation about the specifics of the when/where you will get your trigger. You can read up on what Apple provides in the Location Awareness Guide. Hope this helps.
I want to create an (game based) iPhone application which sends your GPS location on a specific time (like 3-5 times a day) to a server. I found an apple page explaining some functionality to run in the background like location, music and VOIP.
I need the GPS to be accurate on the meter.
Can someone help me with a small example?
It really depends on your usage of the location. If you monitor actively, kiss the battery of your user goodbye. Very detailed accuracy, even bigger hit to battery. The backgrounding of location is all or nothing as far as accuracy goes.
Less hit, less accuracy is -startMonitoringForSignificantLocationChange. May not be accurate enough for you.
Better depending on usage, region monitoring. Triggers event on entry or exit of defined region.
You don't have the benefit of accuracy and timed location based events. You can do it, but is going to require a lot more effort on your end.
While this is untested, I am planning an app with a similar need. My solution is that on a significant location change, the app will determine what interval exists between the update timestamp, and when I care to know the users location (5pm for instance). If that's below some threshold, it will go into startUpdatingLocation mode (full power, battery draining, which is why that threshold is important) and then, on each location update, check if that target time has passed. if SO, send the update to your server, and go back to monitoring for significant changes. The catch is that if it still requires some movement to trigger the significant change update...so it isn't a perfectly reliable solution, but it may work depending on how you're using the data
You can't "schedule background work". iOS doesn't allow it.
The solution is to set yourself up for notification on significant change (which is some hit to the battery, but it's not horrible), and then only DO anything with that at occasional intervals.
I'm looking into the new background location service options in the iPhone 4 SDK. It allows an app to run in the background and receive location updates from the device.
There are two methods offered. One is a battery intensive mode that continuously gets location updates. The second recommended method sends the app location updates when there has been a "significant location change".
Does anyone know what a significant location change might be? Is a 30 foot walk considered significant, or is a 10 block walk considered significant? I imagine it also depends on the accuracy of the location mechanism being used at the time.
I've recently done some field testing of the new background location service to get an idea of what constitutes a significant location update, what kind of accuracy to expect for the location hits and our general experiences using it.
The results are detailed in a fairly lengthy blog post:
iPhone Background GPS: Accurate to 500 meters, not enough for foot traffic
As Steve Jobs mentioned in the OS 4 introduction, the low power mode uses cell tower triangulation and does not activate GPS unit. Since the iPhone phone module needs to keep a connection to the cell network anyway, there should be no impact on battery life.
Since the precision of a location fix with cell tower triangulation is anywhere between a few dozen meters (in dense city locations) and a few miles, I think 30 ft is not a significant location change. I don't know the specifics, though (and as mentioned by the commenters, the Apple dev forums are the right place to talk about those).