Recommended Design Patterns for Asynchronous Blocks?

Question

I am working on an iOS app that has a highly asynchronous design. There are circumstances where a single, conceptual "operation" may queue many child blocks that will be both executed asynchronously and receive their responses (calls to remote server) asynchronously. Any one of these child blocks could finish execution in an error state. Should an error occur in any child block, any other child blocks should be cancelled, the error state should be percolated up to the parent, and the parent's error-handling block should be executed.

I am wondering what design patterns and other tips that might be recommended for working within an environment like this?

I am aware of GCD's dispatch_group_async and dispatch_group_wait capabilities. It may be a flaw in this app's design, but I have not had good luck with dispatch_group_async because the group does not seem to be "sticky" to child blocks.

Thanks in advance!

Answer 1

There is a WWDC video (2012) that will probably help you out. It uses a custom NSOperationQueue and places the asynchronous blocks inside NSOperationsso you can keep a handle on the blocks and cancel remaining queued blocks.

An idea would be to have the error handling of the child blocks to call a method on the main thread in the class that handles the NSOperationQueue. The class could then cancel the rest appropriately. This way the child block only need to know about their own thread and the main thread. Here is a link to the video

https://developer.apple.com/videos/wwdc/2012/

The video is called "Building Concurrent User Interfaces on iOS". The relevant part is mainly in the second half, but you'll probably want to watch the whole thing as it puts it in context nicely.

EDIT:

If possible, I'd recommend handling the response in an embedded block, which wraps it nicely together, which is what I think you're after..

//Define an NSBlockOperation, and get weak reference to it
NSBlockOperation *blockOp = [[NSBlockOperation alloc]init];
__weak NSBlockOperation *weakBlockOp = blockOp;

//Define the block and add to the NSOperationQueue, when the view controller is popped
//we can call -[NSOperationQueue cancelAllOperations] which will cancel all pending threaded ops
[blockOp addExecutionBlock: ^{

    //Once a block is executing, will need to put manual checks to see if cancel flag has been set otherwise
    //the operation will not be cancelled. The check is rather pointless in this example, but if the
    //block contained multiple lines of long running code it would make sense to do this at safe points
    if (![weakBlockOp isCancelled]) {

        //substitute code in here, possibly use *synchronous* NSURLConnection to get
        //what you need. This code will block the thread until the server response
        //completes. Hence not executing the following block and keeping it on the 
        //queue.  
        __block NSData *temp;
        response = [NSData dataWithContentsOfURL:[NSURL URLWithString:urlString]];

        [operationQueue addOperationWithBlock:^{
            if (error) {
                  dispatch_async(dispatch_get_main_queue(), ^{
                        //Call selector on main thread to handle canceling
                        //Main thread can then use handle on NSOperationQueue
                        //to cancel the rest of the blocks 
                  });
            else {
                 //Continue executing relevant code....      
            }
        }];
    }
}];
[operationQueue addOperation:blockOp];

Answer 2

One pattern that I have come across since posting this question was using a semaphore to change what would be an asynchronous operation into a synchronous operation. This has been pretty useful. This blog post covers the concept in greater detail.

http://www.g8production.com/post/76942348764/wait-for-blocks-execution-using-a-dispatch-semaphore