Question

I am running into a very strange situation with an app I have that uses CLLocationManager to get the user’s current location. I am using a wrapper class that is very similar to Apple’s CLLocationManager example code. It starts looking for location, and it waits until it is given a location that meets some criteria (timestamp age, accuracy). All works well when I am in a very GPS-accessible area.

Now the issue. When I am in my office, on a WiFi connection, where the GPS signal is seemingly lousy, I open my app and it can never find a suitable location. I exit out of my app, open Foursquare, and it finds places near me almost immediately, leading me to assume that it has found my location. I exit Foursquare, and reopen my app to find that it finds my location almost instantly.

Can anyone shed some light on what might be happening here? I can post some code if folks think that would be helpful, but this is more a general question about how other apps can positively or negatively affect the functionality of CLLocationManager. Ideally, I’d love to know what exactly Foursquare is doing to get a location so quickly, and how that might cause my app to suddenly start getting one as well.

EDIT: It seems like based on the answer below, people have experienced cross-app cacheing, which is fine. However, it doesn’t explain why Foursquare gets a location and my app only gets it after using Foursquare. Below is my CLLocationManager code, hopefully someone can find some smoking gun:

- (void) lazyInit {
    if (!self.locationManager) {
        self.locationManager = [[CLLocationManager alloc] init];
        self.locationManager.delegate = self;
        self.locationManager.desiredAccuracy = kCLLocationAccuracyHundredMeters;
        self.reverseGeocoder = [[WPGeocodingService alloc] initWithDelegate:self];
        self.locationAndPlacemark = NO;
    }
}

- (void) getCurrentLocation {
    [self lazyInit];
    self.recentLocation = nil;
    [self performSelector:@selector(timeoutLocationFetch) withObject:nil afterDelay:kLocationFetchTimeout];
    [self.locationManager startUpdatingLocation];
}

- (void)locationManager:(CLLocationManager *)manager didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation *)oldLocation {
    NSLog(@"LocationService:update: <%f,%f> Accuracy: %f", newLocation.coordinate.latitude, newLocation.coordinate.longitude,
          newLocation.horizontalAccuracy);

    // test the age of the location measurement to determine if the measurement is cached
    // in most cases you will not want to rely on cached measurements
    NSTimeInterval locationAge = -[newLocation.timestamp timeIntervalSinceNow];
    if (locationAge > 5.0) return;

    // test that the horizontal accuracy does not indicate an invalid measurement
    if (newLocation.horizontalAccuracy < 0) return;

    // test the measurement to see if it is more accurate than the previous measurement
    if (self.recentLocation == nil || self.recentLocation.horizontalAccuracy > newLocation.horizontalAccuracy) {
        // store the location as the "best effort"
        self.recentLocation = newLocation;
        // test the measurement to see if it meets the desired accuracy
        //
        // IMPORTANT!!! kCLLocationAccuracyBest should not be used for comparison with location coordinate or altitidue 
        // accuracy because it is a negative value. Instead, compare against some predetermined "real" measure of 
        // acceptable accuracy, or depend on the timeout to stop updating. This sample depends on the timeout.
        //
        if (newLocation.horizontalAccuracy <= self.locationManager.desiredAccuracy) {
            // we have a measurement that meets our requirements, so we can stop updating the location
            // 
            // IMPORTANT!!! Minimize power usage by stopping the location manager as soon as possible.
            //
            [self.locationManager stopUpdatingLocation];
            // we can also cancel our previous performSelector:withObject:afterDelay: - it's no longer necessary
            [NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(timeoutLocationFetch) object:nil];

            if ([self.delegate respondsToSelector:@selector(locationService:didReceiveLocation:)]) {
                [self.delegate locationService:self didReceiveLocation:self.recentLocation];
            }
        }
    }    
}

- (void)locationManager:(CLLocationManager *)manager  didFailWithError:(NSError *)error {
    NSLog(@"LocationService:error: %@", [error description]);
    if ([error code] != kCLErrorLocationUnknown) {
        [self.locationManager stopUpdatingLocation];
        if ([self.delegate respondsToSelector:@selector(locationService:didFailWithError:)]) {
            [self.delegate locationService:self didFailWithError:error];
        }
    }
}

- (void) timeoutLocationFetch {
    NSLog(@"LocationService:timeout");
    [self.locationManager stopUpdatingLocation];
    if (self.recentLocation && [self.delegate respondsToSelector:@selector(locationService:didReceiveLocation:)]) {
        if ([self.delegate respondsToSelector:@selector(locationService:didReceiveLocation:)]) {
            [self.delegate locationService:self didReceiveLocation:self.recentLocation];
        }
    } else {
        NSError* error = [NSError errorWithDomain:@"Location Error" code:0 userInfo:
                          [NSDictionary dictionaryWithObject:@"The application could not determine your location." forKey:NSLocalizedDescriptionKey]];
        if ([self.delegate respondsToSelector:@selector(locationService:didFailWithError:)]) {
            [self.delegate locationService:self didFailWithError:error];
        }
    }
}

Answer 1

Why are you using

self.locationManager.desiredAccuracy = kCLLocationAccuracyHundredMeters

and not kCLLocationAccuracyBest? Of course, without comparing the horizontal accuracy with this, as you noticed yourself, negative constant – but some reasonable other value (say 100.0m) instead. Have you tried whether it makes a difference?

The desired accuracy controls how much effort is put into the position acquisition (for the higher values, GPS is not even turned on, as you can check with Xcode/Instruments/EnergyDiagnostics). Less effort results in both less accuracy and/or more time to get a position. Doesn’t that sound reasonable?

From my own observations: When asking iOS for a position with a certain desired precision, the result can be anything: Less accurate (i.e. in a building with poor GPS reception), as accurate as desired, or in fact more accurate than needed (another application or another CLlocationManager object of the same application might simultaneously ask the hardware for a higher accuracy – then all other applications inherit the better values without additional effort).

In addition to the above, it might make a difference whether you iOS device is accessing the internet, because it is an assisted GPS receiver. Maybe there is some kind of side effect with some assisting data being downloaded, if the device happens to be online because of some other internet activity. This last thought is pure speculation, though.

One more thing:
If I haven’t overlooked it in your code, then you have not defined a distance filter. Try something like

self.locationManager.distanceFilter = kCLDistanceFilterNone;

to ensure you get as many updates as possible.