Archive

Posts Tagged ‘Corelocation’

Initial GPS fix always incorrect : Corelocation, CLLocationManager

June 28, 2011 7 comments

The Problem:

You use CLLocationManager.StartUpdatingLocation( ) to get an initial fix on the user’s location in your code. But you notice that the location is always wrong and way-off.

Analysis:

Take a look at Apple’s own documentation of CLLocationManager here : (link to documentation)

Because it can take several seconds to return an initial location, the location manager typically delivers the previously cached location data immediately and then delivers more up-to-date location data as it becomes available. Therefore it is always a good idea to check the timestamp of any location object before taking any actions. If both location services are enabled simultaneously, they deliver events using the same set of delegate methods.

Basically, IOS returns you previously cached information. This could also mean that if you used Corelocation in San Francisco today and then used the app in Dallas next, it will still report your location in San Francisco.

Solution:

In my code below, I have used two ways of making sure I have the correct location. One is to make sure horizontalAccuracy is < 100 meters and the next is the location timestamp is < 15 seconds ago. If it falls under any of these two conditions, the location is probably wrong and can be discarded. In this case I just wait for IOS to give me a fresher more accurate location fix.

Point to be noted here is that because of this, be prepared to wait for upto 10 seconds depending on how accurate the location info you want to get. More accurate = more delay especially after a cold start. Chances are, if you are not writing a GPS turn-by-turn navigation app, you don’t need pin-point location info. So, play around with it and relax the accuracy as much as possible depending on what fits your app’s scenario.

– (void) locationManager:(CLLocationManager*) manager didUpdateToLocation:(CLLocation*)newLocation fromLocation:(CLLocation*)oldLocation
{
@try
{
if(newLocation.horizontalAccuracy > 100)
{
NSLog(@”Ignoring GPS location more than 100 meters inaccurate :%f”, newLocation.horizontalAccuracy);
return;
}

NSDate* eventDate = newLocation.timestamp;
NSTimeInterval howRecent = [eventDate timeIntervalSinceNow];
if (abs(howRecent) < 15.0)
{
NSLog(@”Ignoring GPS location more than 15 seconds old(cached) :%d”, abs(howRecent));
return;
}

[myLM stopUpdatingLocation];
}
@catch (NSException* ex)
{
[self debugMessage:ex.reason withTitle:@”Uncaught Error in didUpdateToLocation()”];
}
}

My app is sucking battery life out of my iPhone – Corelocation

May 10, 2011 2 comments

Lot of times people point out that they think that Loqlyhttp://bit.ly/e5u4j might be sucking out their battery life because it uses their iPhone’s GPS all the time. Unfortunately, Apple hasn’t done a good job of indicating what the small purple arrow at the top means.

Apple’s official documentation says this about conserving the user’s battery life :

“In iOS 4.0 and later, you can use the significant-change location service to receive location events. This service offers a significant power savings and provides accuracy that is good enough for most applications. It uses the device’s cellular radio to determine the user’s location and report changes in that location, allowing the system to manage power usage much more aggressively than it could otherwise. This service is also capable of waking up an application that is currently suspended or not running in order to deliver new location data. “

Loqly uses the same API which delivers us your location based on cell tower triangulation. i.e We don’t even use your GPS except the first time you download and run our application. The purple arrow just means that an application has accessed your location recently. Which is what Loqly is doing. We don’t keep checking your location. We just tell your IOS device to let us know when you have traveled more than 1/2 mile from your current location. And we leave it to IOS to use cell towers and tell us if you change your location.

Bottomline for developers :

In summary, if as a developer if you want to be conscientious and conserve the user’s battery life, use the significant location changes API “[CLLocationManger startMonitoringSignificantLocationChanges]” instead of [“CLLocationManager startUpdatingLocation]”

Of course, to get the initial “fix” you will HAVE to use CLLocationManager startUpdatingLocation but once you get the location, immediately call stopUpdatingLocation and switch to startMonitoringSignificantLocationChanges.

If you have anything to add to this article or don’t agree with me, kindly leave a comment below.

EDIT: 07/12/2011 – IOS5 beta 3 has some changes specific to location services. Check this out – Basically you will see a gray arrow now if an app has accessed your location in last 24 hours and a purple arrow if it is actively accessing your location.

EDIT: 09/07/2011 – The information in this article is accurate and can be confirmed by Apple’s official docs. But due to the low awareness of the general user, we were still getting constant feedback from users that the arrow should not be there when they close the app. So, we chose to turn off the arrow by simply powering off location services by calling “CLLocationManager::StopUpdatingLocation”. As a result of this the arrow simply stays off all the time even when you are actively using the app. What all you have to do to keep your users Happy 😦