Networking using NSURLConnection

The basics of networking using NSURLConnection, part of Apple’s Foundation framework.

What I’m not going to cover:

How to determine if a connection is available before trying a request. (Hint: Don’t.)

How to retry an operation when a connection becomes available. (Hint: Reachability.)

How to abstract this without losing anything important, and bring it all under control. (Hint: Use AFNetworking.)

All of these are topics I’ll write about in future articles. But today, just the basics!

Also, this code will assuming you’re using Automatic Reference Counting. Because you ought to be.

For any HTTP operation, you’re going to use NSURLConnection. It’s not safe to use synchronously from the main thread. This will cause the main thread to stop responding to user-level events, and iOS will quit your application. It behaves exactly as if your application crashed.

On Mac OS X, the system will not quit your application, though your application will become unresponsive and look like it’s frozen. So on Mac OS X, you should follow the same pattern of avoiding synchronous network requests on the main thread of your application.

That leaves three options:

Asynchronous networking on the main thread.

Synchronous networking on another thread.

Asynchronous networking on another thread.

Under normal circumstances, you don’t need to run networking operations on a different thread. There’s very few problems that require moving to another thread.

Using asynchronous operation will cause the networking itself to run in the background. You can consider this a dedicated thread by Apple. Your delegate methods will be called in the correct sequence on the main thread to catch up with networking as iOS determines it is appropriate.

Clear the contents NSMutableData instance in connection:didReceiveResponse:. (You may receive multiple connection:didReceiveResponse: events as the request is redirected, but you should only use data from the last one.)

Append the data you receive from didReceiveData to the NSMutableData. Don’t try to process it immediately; you will usually receive multiple connection:didReceiveData: events for a single transfer.

In connectionDidFinishLoading:, your data is complete. Here, you can do something with it.

The idea here is that your start (or restart) accumulating data in connection:didReceiveResponse:, append data in your connection:didReceiveData:, and actually do something with the data in connection:connectionDidFinishLoading:.

Processing the data shouldn’t really be done on the main thread, either. You can start another thread, but it’s easier to just dispatch_async to a queue that isn’t running on the main thread.

It is possible to run an NSURLConnection on another thread, of course. That thread will need to be using a run loop to receive the delegate events from networking. But unless there’s some reason you need a separate thread, using asynchronous networking is Apple’s solution to this.

Using NSURLConnection requires a class member to accumulate data as its transferred. That means that if you’re going to have multiple simultaneous transfers, you’ll need something more complicated. Probably a wrapper class to drive NSURLConnection, and keep each response separate. By the time you’ve written this wrapper class, you’ve probably written a naive version of AFHTTPRequestOperation, a part of AFNetworking.

But we’ll get to AFNetworking in a future post.

Assuming you only have a single transfer going on at once, your code should look a bit like this: