Question

I have been working with a few applications that deal with NSURLConnections. While researching best practices I have noticed a lot of examples online showing how to use NSOperation and NSOperationQueue to deal with this.

I have also noticed on stackoverflow a few examples that show initializing the connection as synchronous and asynchronous using the class methods of NSURLConnection: sendAsynchronousRequest and sendSynchronousRequest.

Currently I am doing my initialization as follows:

[[NSURLConnection alloc] initWithRequest:request delegate:self];

While doing this I have monitored the main thread and the calls to the delegate methods:

connectionDidFinishLoading, connectionDidReceiveResponse, connectionDidReceiveData and connectionDidFailWithError

Everything I have read in Apples documentation and my tests prove to me that this is asynchronous by default behavior.

I would like to know from more experienced Objective C programmers when the other options would be used for either a best practice, or just be more correct than what I see as the most simplistic way to get async behavior?

This is my first question I have posted on here, if more information is needed please ask.

Answer 1

The method you list are the traditional means of asynchronous transfer and an app that uses them will be efficient in processor (and hence power) use.

The sendAsynchronousRequest method is a relatively new addition, arriving in iOS 5. In terms of best practice there’s little other than style to differentiate between it and the data delegate methods other than that a request created with the latter can be cancelled and a request created with the former can’t. However the tidiness and hence the readability and greater improbability of bugs of the block-based sendAsynchronousRequest arguably give it an edge if you know you’re not going to want to cancel your connections.

As a matter of best practice, sendSynchronousRequest should always be avoided. If you use it on the main thread then you’ll block the user interface. If you use it on any other thread or queue that you’ve created for a more general purpose then you’ll block that. If you create a special queue or thread for it, or post it to an NSOperationQueue then you’ll get no real advantages over a normal asynchronous post and your app will be less power efficient per Apple’s standard WWDC comments.

References to sendSynchronousRequest are probably remnants of pre-iOS 5 patterns. Anywhere you see a sendSynchronousRequest, a sendAsynchronousRequest could be implemented just as easily and so as to perform more efficiently. I’d guess it was included originally because sometimes you’re adapting code that needs to flow in a straight line and because there were no blocks and hence no ‘essentially a straight line’ way to implement an asynchronous call. I really can’t think of any good reason to use it now.