Synchronous network calls blocking other calls on startup

Question

I have an App which does hundreds of different network calls (HTTP GET requests) to a REST service. The calls are done from every single page of the app and there are much of them. But there is the requirement that two requests have to be done (on startup or awake) before any other network requests happens. The result of these two requests is some config data which is needed before all other following requests. (this requirement has many reason)

I have one central method for all GET requests. It uses AFNetworking and (of course) asynchronous handlers:

func GET(path: String, var parameters: Dictionary<String, String>? = nil) -> Future<AnyObject!> {
    let promise = Promise<AnyObject!>()

    manager.GET(path, parameters: parameters, success: { (task: NSURLSessionDataTask!, response: AnyObject!) -> Void in
        // some processing...
        promise.success(response)

    }) { (task: NSURLSessionDataTask!, error: NSError!) -> Void in
        // some failure handling...
        promise.failure(error)
    }

    return promise.future
}

The problem now is - how to do this first two calls and block all other calls until those two succeed? The obvious solution would be a semaphore which blocks the thread (not main!) until those two calls arrive successfully but if possible I want to avoid this solution. (because of deadlocks, race conditions, how to do error handling, etc... the usual suspects)

So is there any better solution for this?

The synchronous order basically has to be:

1. 1st call
2. wait for successful response of 1st call
3. 2nd call
4. wait or successful response of 2nd call
5. allow all other calls (async) in any order

I can not do this logic on the upper layers of the app because the GET requests could come from every part of the app, so I would need to rewrite everthing. I want to do it centrally on this single GET request.

Maybe this is also possible with the Promise/Future pattern I already use, any hints are welcome.

Thanks.

Answer 1

There are a couple of approaches to tackle this class of problem:

• You can use GCD (as shown in the answer you linked to) using semaphores or dispatch groups.
• You can use asynchronous NSOperation custom subclass in conjunction with NSOperationQueue.
• Or you can use promises.

But I'd generally suggest you pick one of these three, but don't try to introduce dispatch/operation queue patterns with your existing futures/promises code. People will suggest dispatch/operation queue approaches simply because this is how one generally solves this type of problem (using futures is not gained popular acceptance yet, and there are competing promises/futures libraries out there). But promises/futures is designed to solve precisely this problem, and if you're using that, just stick with it.

On the specifics of the dispatch/operation approaches, I could explain why I don't like the GCD approach and try to convince you to use the NSOperationQueue approach, but that's moot if you're using promises/futures.

The challenge here, though, is that you appear to be using an old version of Thomvis/BrightFutures. The current version takes two types for the generic. So my code below probably won't work for you. But I'll offer it up as as suggestion, as it may be illustrative.

For example, let's imagine that you had a loginURL (the first request), and some second request that you wanted to perform after that, but then had an array urls that you wanted to run concurrently with respect to each other, but only after the first two requests were done. Using 3.2.2 of BrightFutures, it might look like:

GET(loginURL).flatMap { responseObject -> Future<AnyObject!, NSError> in
    return self.GET(secondRequestURL)
}.flatMap { responseObject -> Future<Int, NSError> in
    return urls.map { self.GET($0) }.fold(0) { sum, _ in sum + 1 }
}.onSuccess { count in
    print("\(count) concurrent requests completed successfully")
}.onFailure { error in
    print("not successful: \(error)")
}

Judging from your code snippet, you must be using an old version of BrightFutures, so the above probably won't work as written, but hopefully this illustrates the basic idea. Use the capabilities of BrightFutures to manage these asynchronous tasks and control which are done sequentially and which are done concurrently.