Why having a single success/error callback block is better than having separate ones

gistfile1.md

Suppose you have a network method that only uses a single block callback

typedef void (^Handler)(BOOL success, id response, NSError *error);

- (void)makeRequestWithHandler:(Handler)handler;

But you have to make this request dozens of times, and you want to reuse the same failure handler in most cases? Easy, just have a factory function that returns a block:

typedef void (^SuccessHandler)(id response);
typedef void (^ErrorHandler)(NSError *error);

Handler makeHandler(SuccessHandler successBlock, ErrorHandler errorBlock)
{
    return ^(BOOL success, id response, NSError *error)
    {
        if (success)
        {
            if (successBlock) successBlock(response);
        }
        else
        {
            if (errorBlock) errorBlock(error);
        }
    }
}

Now you can elegantly call your singler-handler function with seperate success/failure handlers whenever you feel like it:

[[MyNetworkClass sharedInstance] makeRequestWithHandler:makeHandler(^(id response) {

    //success code
    
}, ^(NSError *error) {

   //error code

})];

This also means that if you have a generic error handler, you can just change the error condition in your makeHandler function to:

if (errorBlock) errorBlock(error); else //generic error handling behaviour

And then to use this fallback, just call your network method as follows:

[[MyNetworkClass sharedInstance] makeRequestWithHandler:makeHandler(^(id response) {

    //success code
    
}, NULL)];

And this makeHandler method could even be built into the network library, with various standard implementations for your convenience.

So having a single callback gives you huge flexibility. Having seprate success/failure handlers built into the network method interface would force you to always specify two parameters; there's no easy way to make an equivalent factory function that takes a single handler block and splits it into two.

Disclaimer: I've not run any of the code above, and have no idea if it actually works.

My simple sanitiser method:

-(void)loadJSONFromURL:(NSURL *)url completion:( void(^)( NSDictionary *jsonDictionary, NSError *error ))completionBlock
{
    NSParameterAssert( url && completionBlock );

    NSURLRequest *request = [ NSURLRequest requestWithURL:url ];

    AFHTTPRequestOperation *operation = [[[ AFHTTPRequestOperation alloc ] initWithRequest:request ] autorelease ];

    operation.responseSerializer = [ AFJSONResponseSerializer serializer ];

    [ operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject)
     {
         completionBlock( responseObject, nil );

     } failure:^(AFHTTPRequestOperation *operation, NSError *error)
     {
         completionBlock( nil, error );
     }];

    [ operation start ];
}

I am using the same approach Nigel.

What about just doing:

[operation setCompletionBlock:^{
    self.error;
    self.responseObject;
}];

// note, use weak

OR

dispatch_block_t myRealHandler = ^{
    NSLog(@"Request succeeded or failed.");
}

[operation setCompletionBlockWithSuccess:(void ( ^ ) ( AFHTTPRequestOperation *operation , id responseObject )) {
    myRealHandler();
} failure:(void ( ^ ) ( AFHTTPRequestOperation *operation , NSError *error )) {
    myRealHandler();
}];

@kylef I think the goal is to not repeat code (DRY principle). You are doing the same thing, on both handlers (success and failure)

@kylef those solutions take advantage of the fact that AFNetworking's request operation is a leaky abstraction of NSOperation. My gist makes no reference to AFNetworking. Another network library that didn't use NSOperation but still used the two-handler approach wouldn't neccesarily allow that solution.

Also, If I'm making a lot of requests, having to do that isn't very DRY. I could wrap all the request methods of the library with new methods that take a single handler of course, but if users have to do that, it rather defeats the point of designing a nice API in the first place.

I encourage you all to look at ReactiveCocoa. All of the above approaches are effectively identical, a matter of taste. RAC is much more generally applicable across your entire program and by standardizing callback mechanisms to its design you can see rewards across your stack—eliminate that darn state!

@bvanderveen The problem with ReactiveCocoa, is that you perfectly ok to use on your own stuff. In many places it's just plain impossible. The time it would take to new comers to understand: 1) Your app architecture 2) Work effectively with ReactiveCocoa 3) The company actually accepts the use of it.