Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to walk the line between location accuracy and power efficiency?
    text
    copied!<p>I am working on an app that requires to work in foreground and background and send location data. I haven't written code yet and just familiarized myself with how CoreLocation works to determine which approach to follow. From the reading I did so far, I gather that:</p> <ol> <li><p>With startMonitoringSignificantLocationChanges </p> <ul> <li>the GPS is never activated </li> <li>it only calls didUpdateLocations (or didUpdateToLocation for ios&lt;6) when a change of radio tower is detected </li> <li>the desiredAccuracy and distanceFilter properties are both ignored</li> </ul></li> <li><p>With startUpdatingLocation</p> <ul> <li>the battery drain is higher</li> <li>didUpdateLocations is called whenever some hardware from the phone has some data to provide. And because there are multiple hardware components that can be used for location (GPS, radio, wifi), there is no guarantee when or how often didUpdateLocations is called, or whether a new reading will be more accurate than the previous one even</li> <li>the first number(s) are usually bad because they do not rely on the GPS</li> <li>there is no sure way of knowing whether we have the best location we will ever get: it is just a matter of picking among all locations received the one with the best accuracy in the given time window available </li> </ul></li> </ol> <p>I don't see however much discussion or documentation about any intermediate route. What if I want to be power-conscious but get reasonably accurate data when a user has moved significantly? It seems that a possible compromise approach is to:</p> <ul> <li>turn on startMonitoringSignificantLocationChanges</li> <li>switch to using startUpdatingLocation when didUpdateLocations is called</li> <li>wait for a short while to give a chance to the GPS to get some good readings and select the one with best accuracy </li> <li>switch back to using startMonitoringSignificantLocationChanges and so on...</li> </ul> <p>As far as I know, this approach will work the same in foreground and background and will provide some compromise between the two standard approaches supported by Apple.</p> <p>Questions:<br> - Is my understanding correct and my "compromise" approach sound?<br> - Has anyone used that approach successfully?<br> - What are the caveats to look for with that approach?<br> - Is there a better compromise approach out there?</p> <p>PS: I imagine that I could later refine the approach to take into account the estimated travel speed so that I don't constantly use the GPS when the person is traveling.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload