Mundue Blog
Indie iPhone Development
0
Let’s say you’re making HTTP requests and handling responses as we described last time. Parsing the results is usually pretty easy, but what happens when you have a large blob of data, be it XML or JSON or whatever? Any lengthly processing on the main thread, more than a couple hundred milliseconds, will introduce a noticeable hiccup in the UI. Adding a worker thread would help, but perhaps the easiest method is to use the non-blocking NSOperationQueue. With NSOperationQueue you simply package up the work to be done into an NSOperation instance and add it to the queue.
It’s common for iPhone apps to need to make HTTP requests and receive results in either JSON or XML format. There are several excellent full-featured tools ( ASIHTTPRequest, RestKit, etc.) to help you with this task, but sometimes all you need is NSURLConnection. NSURLConnection is a simple class that provides easy to use high-level asynchronous request/response handling. I’ll describe a simple wrapper I’ve been using to make it easy to handle multiple requests easily.
When using NSURLConnection there are only a couple of things to deal with. Unless you are using the synchronous version (not recommended) you will typically set up an object, such as your application delegate or a view controller, as a delegate to receive the NSURLConnectionDelegate callbacks. The main delegate message you need to handle are connection:didFailWithError:, connection:didReceiveData:, and connectionDidFinishLoading:.
One potential issue you face here is using a single object as delegate for multiple connections. Then your delegate message handlers will become messy as they attempt to determine which response goes with which request, etc. Now instead consider creating a utility class with just two public methods, like this:
@interface myConnectionController : NSObject {
NSMutableData* receivedData;
}
@property (nonatomic, retain) id connectionDelegate;
@property (nonatomic) SEL succeededAction;
@property (nonatomic) SEL failedAction;
- (id)initWithDelegate:(id)delegate selSucceeded:(SEL)succeeded selFailed:(SEL)failed;
- (BOOL)startRequestForURL:(NSURL*)url;
@end
NSMutableData* receivedData;
}
@property (nonatomic, retain) id connectionDelegate;
@property (nonatomic) SEL succeededAction;
@property (nonatomic) SEL failedAction;
- (id)initWithDelegate:(id)delegate selSucceeded:(SEL)succeeded selFailed:(SEL)failed;
- (BOOL)startRequestForURL:(NSURL*)url;
@end
In this sample class receivedData is where the response will be stored, the connectionDelegate refers to what will be the target of the succeededAction and failedAction messages. After all, that’s all I really care about when making this request: success or failure notification. Now your connection controller can be instantiated like this:
id delegate = self;
myConnectionController* connectionController = [[[myConnectionController alloc] initWithDelegate:delegate
selSucceeded:@selector(connectionSucceeded:)
selFailed:@selector(connectionFailed:)] autorelease];
[myConnectionController startRequestForURL:[NSURL URLWithString:@"http://request.org/somequery.php"]];
myConnectionController* connectionController = [[[myConnectionController alloc] initWithDelegate:delegate
selSucceeded:@selector(connectionSucceeded:)
selFailed:@selector(connectionFailed:)] autorelease];
[myConnectionController startRequestForURL:[NSURL URLWithString:@"http://request.org/somequery.php"]];
You also need to implement the callbacks. These will take the response data and parse it, typically, or handle any error conditions. Although the request is handled asynchronously by the URL Loading System, your callbacks are signalled on the main thread, and you may not want to tie it up parsing large chunks of XML or JSON. Next time I’ll write about using NSOperationQueue to do the parsing in a background thread so the UI remains responsive.
- (void)connectionSucceeded:(NSMutableData*)data {
// data contains response, e.g. JSON to be parsed
}
- (void)connectionFailed:(NSError*)error {
// error contains reason for failure
}
// data contains response, e.g. JSON to be parsed
}
- (void)connectionFailed:(NSError*)error {
// error contains reason for failure
}
This is a totally trivial example, but you can see how easy it will be to a) define multiple callback handlers for any given class, and thus allowing for multiple NSURLConnections, and b) subclass myConnectionController for specialized request handling. This is what the default implementation looks like:
@implementation myConnectionController
@synthesize connectionDelegate;
@synthesize succeededAction;
@synthesize failedAction;
- (id)initWithDelegate:(id)delegate selSucceeded:(SEL)succeeded selFailed:(SEL)failed {
if ((self = [super init])) {
self.connectionDelegate = delegate;
self.succeededAction = succeeded;
self.failedAction = failed;
}
return self;
}
-(void)dealloc {
[connectionDelegate release];
[super dealloc];
}
- (BOOL)startRequestForURL:(NSURL*)url {
NSMutableURLRequest* urlRequest = [NSMutableURLRequest requestWithURL:url];
// cache & policy stuff here
[[NSURLCache sharedURLCache] removeAllCachedResponses];
[urlRequest setHTTPMethod:@"POST"];
[urlRequest setHTTPShouldHandleCookies:YES];
NSURLConnection* connectionResponse = [[[NSURLConnection alloc] initWithRequest:urlRequest delegate:self] autorelease];
if (!connectionResponse)
{
// handle error
return NO;
} else {
receivedData = [[NSMutableData data] retain];
}
return YES;
}
@synthesize connectionDelegate;
@synthesize succeededAction;
@synthesize failedAction;
- (id)initWithDelegate:(id)delegate selSucceeded:(SEL)succeeded selFailed:(SEL)failed {
if ((self = [super init])) {
self.connectionDelegate = delegate;
self.succeededAction = succeeded;
self.failedAction = failed;
}
return self;
}
-(void)dealloc {
[connectionDelegate release];
[super dealloc];
}
- (BOOL)startRequestForURL:(NSURL*)url {
NSMutableURLRequest* urlRequest = [NSMutableURLRequest requestWithURL:url];
// cache & policy stuff here
[[NSURLCache sharedURLCache] removeAllCachedResponses];
[urlRequest setHTTPMethod:@"POST"];
[urlRequest setHTTPShouldHandleCookies:YES];
NSURLConnection* connectionResponse = [[[NSURLConnection alloc] initWithRequest:urlRequest delegate:self] autorelease];
if (!connectionResponse)
{
// handle error
return NO;
} else {
receivedData = [[NSMutableData data] retain];
}
return YES;
}
And finally, the standard delegate methods for NSURLConnection are hidden inside the myConnectionController implementation. These should be familiar if you’ve ever used NSURLConnection directly:
- (void)connection:(NSURLConnection*)connection didReceiveResponse:(NSURLResponse*)response {
[receivedData setLength:0];
}
- (void)connection:(NSURLConnection*)connection didReceiveData:(NSData*)data {
[receivedData appendData:data];
}
- (void)connection:(NSURLConnection*)connection didFailWithError:(NSError*)error {
[connectionDelegate performSelector:failedAction withObject:error];
[receivedData release];
}
- (void)connectionDidFinishLoading:(NSURLConnection*)connection {
[connectionDelegate performSelector:succeededAction withObject:receivedData];
[receivedData release];
}
@end
[receivedData setLength:0];
}
- (void)connection:(NSURLConnection*)connection didReceiveData:(NSData*)data {
[receivedData appendData:data];
}
- (void)connection:(NSURLConnection*)connection didFailWithError:(NSError*)error {
[connectionDelegate performSelector:failedAction withObject:error];
[receivedData release];
}
- (void)connectionDidFinishLoading:(NSURLConnection*)connection {
[connectionDelegate performSelector:succeededAction withObject:receivedData];
[receivedData release];
}
@end
That should be enough to get you started. Hopefully you won’t find it too hard to extend this to add the ability to cancel a request, etc.
This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site,RSS feed, or Twitter.
The new shiny is here. At the annual WWDC recently, Apple unveiled three widely-anticipated new products. This year it was all about software, so hardware announcements will have to come later. In the keynote Steve Jobs mentioned OS X Lion, iOS 5, and iCloud. If you’re an iOS or Mac developer these changes will have a huge impact on you in the next few months. I’m not going to go into much detail about the announcements, but you should definitely check out the keynote if you haven’t seen it yet.
I ran into an odd issue the other day and spent a little time getting to the bottom of it. It turns out I wasn’t taking good care of my Xcode project’s library search paths. Here’s what I had to do about it and why you might care. Note this problem has likely been lurking in my project for some months, and may have caused other unintended consequences.
Like pay-to-play or in-app ads, prompting for a rating is controversial in that some developers frown upon it. Free apps tend to have an average 3 star rating. People rarely bother to go back to the App Store to rate an app. There’s always a small minority that will go out of their way to provide negative reviews. So why not solicit positive feedback by providing a reminder to rate the game? In my opinion, there’s nothing overtly annoying or obnoxious about presenting an alert view that can easily be dismissed.
A while back I wrote about adding code to support multiple analytics packages inside your apps. While updating that code for a talk I gave at a recent iPhone developer meetup I published the code on Github, so now it’s a little easier to use. Just download the analytics libraries you want to use and add my wrapper classes to your application. It’s really that easy.
Full details on the new and improved MMTrackingController are on Github. Enjoy!
This a post about using Xcode’s distributed build feature to shorten your development cycles. Many indie developers are constantly seeking a way to shave a few seconds off the edit-build-debug workflow. If you have more than one Mac at your disposal, or even if you work in a small team, you can effectively pool compile resources to speed build times.
The mobile advertising buzz lately is about Apple’s iAd. But iAd isn’t yet available in all countries. If you’re like me and have about half of your users outside of the US you will still need ad services that support the other countries. Using an ad mediation layer service like AdWhirl is still a practical solution, and it fully supports iAd and many other ad networks.
What’s all this fuss about Game Center then? Apple says:
“Experience social gaming on your iPhone. Find friends or use auto-match to play multiplayer games against new opponents. Track achievements and compare high scores.”
Nobody likes an update that worsens performance. And a game that can’t be played as a result of such an update is a Very Bad Thing. Probably all iPhone developers have had to deal with a crash or glitch that required them to scramble and hope that Apple would give them expedited reviews. I know I did recently for reMovem 2, when an update which introduced OpenFeint support crashed on users’ systems, but curiously not on mine. Funny how that slipped through the normal review process. But that’s another story.
Back to top