On Mac OS 10.7 and iOS 5.0, a very handy method has been added to
Using a URL connection in an
NSOperation subclass has always been quite tedious because of the fact that one has to run a runloop for as long as the delegate callbacks have to happen.
As suggested by Marcus Zarra in this StackOverflow answer, this has usually been achieved by calling
CFRunLoopRun() when calling the start: method on
CFRunLoopStop(CFRunLoopGetCurrent()) when the connection finishes loading or fails.
So, by creating an
NSOperationQueue in your
NSOperation subclass and scheduling the delegate callbacks into this queue, we do not need to run the current runloop for the length of the operation and consume a thread. In a nutshell, this is very handy and a much cleaner way to achieve this!
Here comes the problem: even though everything works perfectly fine on Lion, when performing the very same thing on iOS, the delegate callbacks are never called. It looks like the connection has to be started (and the delegate queue set) on the main queue for the delegate callbacks to happen. This obviously defeats the point of using it within an
NSOperation subclass given that since Snow Leopard (and iOS 4.0) the
start method of
NSOperation will likely not be called on the main thread.
For this reason, in my opinion, the
setDelegateQueue: method is unusable as per iOS 5.0 and should be avoided until Apple fixes this problem.
I have filed a bug at rdar://10529053 and you should dupe it if you observe the same behavior as I do.
I have created a small sample project to demonstrate the bug that I have attached to the radar. Feel free to run it on your side and see for yourself. You can download it from here.
Interested in working with me on amazing products used by millions of people? My team at Dropbox is hiring, get in touch!