Evolution of my asynchronous networking code

In 2010 I used synchronous NSURLConnection‘s, completely blocking the UI (time pressure). In early 2010, I was working on a pre-existing app the did use asynchronous connections, but would block the Back button of a UIViewController until all completed. This was something the product managers really wanted fixed.

My solution used concurrent NSOperations (of which I’d had some prior experience). Using the “cancel” feature of operations, it was possible to stop all background operations when the user clicked the Back button and cleanup. It turns out there are many “corner” cases in the design—for instance, the user cancels before a queued operation has started running. Since the app also showed a spinner when the operations were running, the feature had to let the controller discover how many operations remained, in particular if all operations were complete.

Thus, in late winter, 2011, I had coded this feature into a UIViewController subclass, it was working pretty well, and I took what I’d learned and created an open source testbed for concurrent NSOperations on github, Concurrent_NSOperations, supporting both Mac and iOS targets.

This project allowed me to really flesh out the logic – the UI lets you choose the sequence of events (e.g., cancel before operations starts), and it let me catch and deal with many edge cases.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s