I’m coming out of highly concentrated work (approx 87 hours) on my latest project. It’s an app that allows you to organize a betting pool for the upcoming FIFA World Cup.
The simplest method of communicating with our web-based API we found to be having the server send array or dictionary PLISTs which I could load and parse in a single line of code synchronously. So first I created all the API calls in synchronous blocking mode. When they where working I added a method by the same name prefixed with “async” and would have the blocking code executed on an NSOperationQueue.
If the synchronous method needed zero or one parameter then you can use NSInvocationOperation of calling it and have the queue work it off in the background. In some cases more than one parameter has to be passed. Here an NSInvocation has to constructed with multiple parameters, which I explained previously.
Once the API call is done processing it needs to tell the app about its result. This is done conveniently by sending NSNotifications. And in all the places in the UI where specific notifications should have an effect, you simply subscribe to the notifications by adding an observer for them to the default NSNotificationCenter. NSOperationQueue automatically uses multiple threads and takes care of the autorelease pool. So any operation might either run on the main thread or on a background thread.
Warning: Crash Ahead!
This causes a problem I have only ever seen happen on Simulator, so I’m not sure if it would also happen on the device. Generally you want the NSNotifications to be sent on the main thread as well, especially if they trigger UI activities like dismissing a modal login dialog. I don’t know if Apple will tweak NSNotificationCenter to send on the main thread in the future, but until they do, here’s my drop in solution.