AFNetworking/AFNetworking — pull request #478 by pnc (2012-08-23 19:49:13+00:00)
Title: Automatically dispatch callbacks to the calling queue

GREETINGS.

This patch changes the default dispatch queue on which AFNetworking calls your success and failure blocks.

Currently, AFNetworking calls you back on the main queue unless you specifically request otherwise using `successCallbackQueue` and `failureCallbackQueue`. This patch changes AFNetworking so it assumes that the queue _calling_ the `setCompletionBlockWithSuccess:failure:` selector is the intended callback queue. Because all paths lead to `setCompletionBlockWithSuccess:failure:`, this patch also changes the behavior of the more commonly-used APIs, such as the lovable `getPath:parameters:success:failure:`.

This allows `AFHTTPRequestOperation`, its subclasses, and the get/post/put/delete/patch methods on `AFHTTPClient`, to be used safely from long-lived background queues, such as an `NSOperation` performing a multi-request action.

In (I posit) 90% of use cases, it will end up dispatching on the main queue anyway, exactly as it worked previously. However, I believe this implementation better fits with what one expects when using blocks. The (beautiful) illusion blocks create for the developer is that code is happening later, but in nearly (or very nearly) the same context. This helps preserve that illusion in the (admittedly rarer) cases where you call AFNetworking from a non-main queue.

I tested this patch in the two example applications, and I've been using it in a private application I'm developing for a client.

I fully expect some discussion (or an outright close!) of this pull request. I also recognize that it may be appropriate to add this same functionality in `AFHTTPClient`'s `enqueueBatchOfHTTPRequestOperations:progressBlock:completionBlock:`. I am totally willing to do this and squash it if people like the spirit of the patch.

P.S. I am a huge fan of AFNetworking and recommend it to anyone who asks.