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!
There is a WWDC video (2012) that will probably help you out. It uses a custom
NSOperationQueueand places the asynchronous blocks insideNSOperationsso 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 videohttps://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..