CODEWITHSUNDEEP
iosgrand-central-dispatchcllocationmanagernsthreadnsoperationqueue
AppsDev
AppsDev

Reputation: 12509

CLLocationManager and serial location updates processing

I need to use the standard location service and perform some processing, including some network calls, every location update notified. I need location updates being processed in FIFO order, to keep tracking of the device, and get results as fast as possible. What should be the best way or technique to ensure that locations are processed in order and processing does not overlap (and besides to get a fast response): operation queues, dispatch queues, or threads directly (or even another way, if it exists)? It looks like operation queues and dispatch queues are almost the same, in terms of performance, but dispatch queues seem to be easier to handle, so I don't know what could be the advantages of each one. Regarding threads, I have been discouraged to usually use them, but I don't know if their efficiency over operation/dispatch queues is really noticeable and it is worth to use them.

Thanks in advance

Upvotes: 2

Views: 502

Answers (1)

Rob
Rob

Reputation: 437927

If you don't want stuff to operate concurrently in the background, then you need a serial queue. To create a serial GCD queue:

dispatch_queue_t queue = dispatch_queue_create("com.appsdev.project1", 0);

And each time you want to add something to that queue, it's simply:

dispatch_async(queue, ^{
    // do your background stuff

    dispatch_async(dispatch_get_main_queue(), ^{
        // update the UI
    });
});

If you want to use NSOperationQueue it's practically as easy:

NSOperationQueue *queue = [[NSOperationQueue alloc] init];
queue.maxConcurrentOperationCount = 1;

And to add operations to that serial queue:

[queue addOperationWithBlock:^{
    // do your stuff

    [[NSOperationQueue mainQueue] addOperationWithBlock:^{
        // update the UI
    }];
}];

And in answer to your NSThread question, I don't see any need for that on the basis of what you've described. Certainly there's no perceptible performance issue.

By the way, is the stuff you're adding to your dispatch/operation queue guaranteed to operating synchronously (i.e. you're not doing geocoding or stuff like that which, itself, operates asynchronously, are you?)? If it operates asynchronously, then additional care must be taken.

By the way, if you only care about the most recent location, using operation queues, you also have to opportunity to cancel other operations that have not yet started by calling:

[queue cancelAllOperations];

The operation in progress will complete first (unless you put in code to test to see if it was canceled), but pending operations that have not yet started can easily be canceled before you initiate a new request based upon the latest location. It just depends upon whether you really want all of the location requests processed serially, or whether you just want to finish the one in progress, clear out the others, and queue a new operation based upon the new location. It just depends upon what your app needs, but frequently you only care about the current location. This can ensure that your queue doesn't get too backlogged.

Upvotes: 1

Related Questions