|ReleasedLast Release||Mar 2017|
Maintained by Paul Melnikow.
A minimal category which extends AFNetworking to support synchronous requests.
pod 'AFNetworking', '~> 3.0' pod 'AFNetworking-Synchronous/3.x'
#import <AFNetworking.h> #import <AFHTTPSessionManager+Synchronous.h> AFHTTPSessionManager *manager = [AFHTTPSessionManager manager]; NSError *error = nil; NSData *result = [manager syncGET:@"/document/123" parameters:paramDict task:NULL error:&error];
Your synchronous request will never return if it is dispatched on the session manager's completion queue.
You really should not perform a synchronous network request on the main thread on iOS, as it's likely to cause a crash when run outside the debugger. You probably should not on OS X either, as it's likely to cause lags in the UI.
If you must do so, create a separate queue for the completion handlers:
manager.completionQueue = dispatch_queue_create("AFNetworking+Synchronous", NULL);
pod 'AFNetworking', '~> 2.0' pod 'AFNetworking-Synchronous/2.x'
#import <AFNetworking.h> #import <AFHTTPRequestOperationManager+Synchronous.h> AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; NSError *error = nil; NSData *result = [manager syncGET:@"/document/123" parameters:paramDict operation:NULL error:&error];
Currently there is no support for AFHTTPSessionManager.
pod 'AFNetworking', '~> 1.0' pod 'AFNetworking-Synchronous/1.x'
#import <AFNetworking.h> #import <AFHTTPRequestOperationManager+Synchronous.h> AFHTTPClient *client = [[AFHTTPClient alloc] initWithBaseURL:...]; NSError *error = nil; NSData *result = [client synchronouslyGetPath:@"/document/123" parameters:paramDict operation:NULL error:&error];
Before you decide to use this category, consider whether you can adopt an asynchronous design instead. As @mattt wrote, asynchronism a tough thing to get your head around, but it's well worth the mental overhead. Rather than creating methods that fetch and return network data, use blocks or delegate methods to call back with the results when you have them.
Using the asynchronous API has many advantages:
However, in some cases, a synchronous response is better, such as when the document architecture or another framework is handling the multithreading for you, and expects a synchronous result. This code attempts to provide a safe and reliable way to use the framework synchronously.
While it overrides the default success and failure queues to avoid a deadlock, it can't anticipate every possible situation. In particular, you should not set the queue from which you're invoking as the processing queue, which will cause a deadlock.
You shouldn't call these methods from the main thread. On iOS, if your application enters the background while one of these methods is running on the main thread, a deadlock may result and your application could be terminated.
This category is suitable for most of the request operation subclasses built into AFNetworking, which process their response objects synchronously.
If you're using the processingBlock on AFImageRequestOperation, which contains essential processing in the completion handler, or your subclass performs other asynchronous processing in the completion handler, use the version in the using-completion-blocks branch.
All custom subclasses must override
AFHTTPRequestOperation+ResponseObject.h for more information.
This project includes integration tests which use the delightful service
httpbin. To run them, run
pod install inside the
then load the workspace and execute the test action.
This project is licensed under the MIT license.