objective-c, possible to queue async NSURLRequests

Question

I realize this question sounds contradictory. I have several Async requests going out in an application. The situation is that the first async request is an authentication request, and the rest will use an access token returned by the successful authentication request.

The two obvious solutions would be:

1. run them all synchronous, and risk UI block. (bad choice)
2. run them async, and put request 2-N in the completion handler for the first one. (not practical)

The trouble is that the subsequent requests may be handled anywhere in the project, at anytime. The failure case would be if the 2nd request was called immediately after the 1st authentication request was issued, and before the access token was returned.

My question thus is, is there any way to queue up Async requests, or somehow say not to issue them until the first request returns successfully?

EDIT:

Why (2) is not practical: The first is an authentication request, happening when the app loads. The 2nd+ may occur right away, in which case it is practical, but it also may occur in a completely separate class or any other part of a large application. I can't essentially put the entire application in the completion handler. Other accesses to the API requests may occur in other classes, and at anytime. Even 1-2 days away after many other things have occurred.

SOLUTION:

//pseudo code using semaphore lock on authentication call to block all other calls until it is received

// at start of auth
_semaphore = dispatch_semaphore_create(0)

// at start of api calls
if(_accessToken == nil && ![_apiCall isEqualToString:@"auth]){
    dispatch_semaphore_wait(_semaphore, DISPATCH_TIME_FOREVER);
}

// at end of auth with auth token
dispatch_semaphore_signal([[SFApi Instance] semaphore]);
_accessToken = ...;

Answer 1

In cases like this I always find it easiest to write the code synchronously and get it running on the UI thread first, correctly, just for debugging. Then, move the operations to separate threads and make sure you handle concurrency.

In this case the perfect mechanism for concurrency is a semaphore; the authentication operation clears the semaphore when it is done, and all the other operations are blocking on it. Once authentication is done, floodgates are open.

The relevant functions are dispatch_semaphore_create() and dispatch_semaphore_wait() from the Grand Central Dispatch documentation: https://developer.apple.com/library/ios/documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html#//apple_ref/doc/uid/TP40008079-CH2-SW2

Another excellent solution is to create a queue with a barrier:

A dispatch barrier allows you to create a synchronization point within a concurrent dispatch queue. When it encounters a barrier, a concurrent queue delays the execution of the barrier block (or any further blocks) until all blocks submitted before the barrier finish executing. At that point, the barrier block executes by itself. Upon completion, the queue resumes its normal execution behavior.

Looks like you got it running with a semaphore, nicely done!

Answer 2

You can't really have it both ways-- there's no built-in serialization for the NSURLConnection stuff. However, you are probably already funneling all of your API requests through some common class anyway (presumably you're not making raw network calls willy-nilly all over the app).

You'll need to build the infrastructure inside that class that prevents the execution of the later requests until the first request has completed. This suggests some sort of serial dispatch queue that all requests (including the initial auth step) are funneled through. You could do this via dependent NSOperations, as is suggested elsewhere, but it doesn't need to be that explicit. Wrapping the requests in a common set of entry points will allow you to do this any way you want behind the scenes.

Answer 3

This sounds like a case where you'd want to use NSOperation's dependencies

From apple docs:

Operation Dependencies

Dependencies are a convenient way to execute operations in a specific order. You can add and remove dependencies for an operation using the addDependency: and removeDependency: methods. By default, an operation object that has dependencies is not considered ready until all of its dependent operation objects have finished executing. Once the last dependent operation finishes, however, the operation object becomes ready and able to execute.

note that in order for this to work, you must subclass NSOperation "properly" with respect to KVO-compliance

The NSOperation class is key-value coding (KVC) and key-value observing (KVO) compliant for several of its properties. As needed, you can observe these properties to control other parts of your application.

Answer 4

Use blocks... 2 ways that I do it:

First, a block inside of a block...

    [myCommKit getPlayerInfoWithCallback:^(ReturnCode returnCode, NSDictionary *playerInfo) {
        if (playerInfo) {
            // this won't run until the first one has finished
            [myCommKit adjustSomething: thingToAdjust withCallback:^(ReturnCode returnCode, NSDictionary *successCode) {
                if (successCode) {
                // this won't run until both the first and then the second one finished

                }
            }];
        }
    }];
    // don't be confused.. anything down here will run instantly!!!!

Second way is a method inside of a block

    [myCommKit getPlayerInfoWithCallback:^(ReturnCode returnCode, NSDictionary *playerInfo) {
        if (playerInfo) {
             [self doNextThingAlsoUsingBlocks];
        }
    }];

Either way, any time I do async communication with my server I use blocks. You have to think differently when writing code that communicates with a server. You have to force things to go in the order you want and wait for the return success/fail before doing the next thing. And getting used to blocks is the right way to think about it. It could be 15 seconds between when you start the block and when it gets to the callback and executes the code inside. It could never come back if they're not online or there's a server outage.

Bonus way.. I've also sometimes done things using stages:

        switch (serverCommunicationStage) {
            case FIRST_STAGE:
            {
                 serverCommunicationStage = FIRST_STAGE_WAITING;
                 // either have a block in here or call a method that has a block
                 [ block {
                     // in call back of this async call
                     serverCommunicationStage = SECOND_STAGE;
                 }];
                 break;
            }
            case FIRST_STAGE_WAITING:
            {
                 // this just waits for the first step to complete
                 break;
            }
            case SECOND_STAGE:
            {
                 // either have a block in here or call a method that has a block
                 break;
            }
        }

Then in your draw loop or somewhere keep calling this method. Or set up a timer to call it every 2 seconds or whatever makes sense for your application. Just make sure to manage the stages properly. You don't want to accidentally keep calling the request over and over. So make sure to set the stage to waiting before you enter the block for the server call.

I know this might seem like an older school method. But it works fine.