Best architecture for an iOS application that makes many network requests?

Question

I\'m in the process of rethinking my approach to the request architecture of a large app I\'m developing. I\'m currently using ASIHTTPRequest to actually make requests, but

Answer 1

Try out STNetTaskQueue, which can make your request reusable and maintainable.

Answer 2

After having tried several approaches, this is one architecture that is giving me excellent results, is easy to document, understand, maintain and extend:

• I have a single object taking care of network connectivity, let's call it a "network manager". Typically this object is a singleton (created using Matt Gallagher's Cocoa singleton macro).
• Since you use ASIHTTPRequest (which I always do, wonderful API) I add an ASINetworkQueue ivar inside my network manager. I make the network manager the delegate of that queue.
• I create subclasses of ASIHTTPRequest for each kind of network request that my app requires (typically, for each backend REST interaction or SOAP endpoint). This has another benefit (see below for details :)
• Every time one of my controllers requires some data (refresh, viewDidAppear, etc), the network manager creates an instance of the required ASIHTTPRequest subclass, and then adds it to the queue.
• The ASINetworkQueue takes care of bandwidth issues (depending on whether you are on 3G, EDGE or GPRS or Wifi, you have more bandwidth, and you can process more requests, etc). This is done by the queue, which is cool (at least, that's one of the things I understand this queue does, I hope I'm not mistaken :).
• Whenever a request finishes or fails, the network manager is called (remember, the network manager is the queue's delegate).
• The network manager doesn't know squat about what to do with the result of each request; hence, it just calls a method on the request! Remember, requests are subclasses of ASIHTTPRequest, so you can just put the code that manages the result of the request (typically, deserialization of JSON or XML into real objects, triggering other network connections, updating Core Data stores, etc). Putting the code into each separate request subclass, using a polymorphic method with a common name accross request classes, makes it very easy to debug and manage IMHO.
• Finally, I notify the controllers above about interesting events using notifications; using a delegate protocol is not a good idea, because in your app you typically have many controllers talking to your network manager, and then notifications are more flexible (you can have several controllers responding to the same notification, etc).

Anyway, this is how I've been doing it for a while, and frankly it works pretty well. I can extend the system horizontally, adding more ASIHTTPRequest subclasses as I need them, and the core of the network manager stays intact.

Hope it helps!

Answer 3

Here is how I generally do it. I, too, have a singleton object used for making network requests. For requests that have to be made often, I have an NSOperationQueue that accepts AFHTTPRequestOperations (or AFJSONRequestOperations) since I generally use AFNetworking for making requests. For these, there is a completionBlock and failureBlock property that is executed upon success or failure of the request. On my singleton object, I would have a method for initiating a particular network request, and as parameters to that method, I would include a success and failure block which can be passed into the blocks defined in the method. This way, the entire application can make a network request, and the scope of the application at that point is available to the singleton in the block that is passed to the method. For example...(using ARC)

        @implementation NetworkManager

    -(void)makeRequestWithSuccess:(void(^)(void))successBlock failure:(void(^)(NSError *error))failureBlock

    {
        NSURL *url = [NSURL URLWithString:@"some URL"];

        NSURLRequest *request = [NSURLRequest requestWithURL:url];

        AFHTTPRequestOperation *op = [[AFHTTPRequestOperation alloc] initWithRequest:request];

        [op setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
            [responseObject doSomething];

            if (successBlock)
                dispatch_async(dispatch_get_main_queue(), successBlock);

        } failure:^(AFHTTPRequestOperation *operation, NSError *error) {

            if (failureBlock)
                dispatch_async(dispatch_get_main_queue(), ^{
                    failureBlock(error);
                });
        }];

        [self.operationQueue addOperation:op];
    }
@end

And you can always make the success block take whatever parameters you need to pass around.

Answer 4

The fully-loaded project is a good read.