Database Reference
In-Depth Information
to live with constraints imposed by the needs of lesser devices. In a perfect world, try
to design your protocols to allow for both chunky and chatty requests, and let the client
decide how much data they want to consume at once.
First Things First: Getting a Connection
I'm going to make a general assumption for the body of this chapter, which is that
whatever you are talking to, you're doing it via HTTP (or HTTPS). If you're doing
something custom using sockets, the 1990s are calling and they would like their archi-
tecture back. In all seriousness, though, almost all client-server mobile work these days
is done using HTTP for transport.
†
The iOS SDK comes with a perfectly adequate HTTP implementation, found in the
CFNetwork framework. But anyone who uses it is a masochist, because it makes you
do so much of the work yourself. Until recently, I would have recommended using the
ASIHttpRequest package. ASI stands for All Seeing Interactive (or “eye”), by the way,
so if you happen to be an Illuminati conspiracist, this may not be the software for you.
Why did I like this package so much?
It is licensed under the über-flexible BSD license, so you can do pretty much anything
you want with it, and it provides a lot of the messy housekeeping code that HTTP
requests tend to involve. Specifically, it will automatically handle:
Easy access to request and response headers
Authentication support
Cookie support
GZIP payload support
Background request handling in iOS 4 and later
Persistent connections
Synchronous and asynchronous requests
(And more!)
However, after the early access version of this topic was released, I learned that
ASIHttpRequest is in danger of becoming an orphan project. This is especially dis-
turbing, because it means it may never be converted over to ARC, among other things.
It would be more disturbing if it were the only game in town; until recently, it was,
because the system-provided alternative,
NSURLConnection
, didn't support asynchro-
nous requests. Being able to choose synchronous and asynchronous requests is criti-
cally important. Almost all of the time, you want to use asynchronous requests, even
if the request
seems
synchronous. For example, a login may seem synchronous. After
all, you can't really do anything further until the request completes. But in reality, if
you do a real synchronous HTTP request, everything locks up (including activity
† Yes, I know, technically HTTP is the Application Layer, according to the OSI model. My apologies to pedantic
taxonomists.
