Open Radar

 
When setting an NSOperationQueue on an NSURLConnection via setDelegateQueue to receive the delegate callbacks upon, these methods are never called if the setDelegateQueue and start methods are not called on the main thread, such as when the connection is used in an NSOperation subclass.

Steps to Reproduce:

- Create an NSOperation subclass.
- Create and instantiate a strong NSOperationQueue property in this class.
- Create an NSURLConnection with startsImmediately set to NO.
- Set the queue on the connection via setDelegateQueue.
- Start the connection in the NSOperation start methods.


Expected Results:

The delegate callbacks should be called on this queue.


Actual Results:

The delegate callbacks are never called even if the operation, and thus the connection have started.

The setDelegateQueue method is unusable as per 5.0.1. This method should make using an asynchronous connection in an NSOperation easier but instead we have to use scheduleInRunLoop loosing all the benefits of the delegate queue.

Regression:

This happens consistently, on both simulator and device (tested on a 4S, 3GS, iPad and iPad 2).

Notes:

This works fine on Mac OS X.
This happens in iOS 5.0, 5.0.1 and does not seem to have been fixed yet on 5.1.
Also, it looks like calling setDelegateQueue and start on the main queue works. However, it leads to weird behaviours when more than one such connections are created, such as hanging.

I have attached a sample project for iOS and a sample project for Mac OS X, demonstrating the difference in behaviour between the two platforms.

Download sample code at:
http://ddvl.me/0g160z0t112J0H1d1a0P