Back in August 2009, Shufflegazine featured an article talking about what makes a good iPhone app. The article has a good discussion about what apps are popular and why, and ultimately concludes that a good app has to be simple, intuitive, responsive, and give users a compelling reason to use it.
Unfortunately, there’s no recipe for how to write a simple, intuitive and compelling app. Our best bet for getting our hands on that recipe is probably this guy, but until he makes that announcement, handling these points is left as an exercise for the reader.
Writing a responsive app, however, is much easier.
A good working definition for a “responsive” app is one that responds to user input quickly and doesn’t hang without telling the user what’s going on. The rule of thumb here is that GUIs should respond to input in no more than 1 second, so the bar is set pretty high, especially for web-enabled apps. This article describes the most common reason GUIs get unresponsive and what to do about it.
How Do These Newfangled GUIs Work, Again?
Cocoa Touch’s GUI (like most GUIs) is built on an “event + event loop” architecture. User interactions like taps and keypresses are translated to events, and these events are then processed one-by-one in the imaginatively named event loop:
Simplified Event Flow in a Cocoa App
As long as each event gets processed quickly, the GUI stays nice and zippy. But because events are processed serially, one event can back up the whole gravy train. If one event takes five second to process, then the GUI will be completely unresponsive for those five seconds until the event loop can start processing new events again.
But what if you have some GUI resources that take five seconds to load? We can’t load them all at app initialization time because we don’t always know what resources we’ll need when the app is starting up, especially for things like profile pictures. Also, the iPhone is an embedded platform, so memory for preloading is in short supply, anyway. How, then, can we appease the event loop tiki gods? The answer, young grasshopper, is to load such resources asynchronously, and then update the GUI when they’re done loading.
Responsiveness Test Bench
To illustrate these ideas, I’ve made a simple iPhone app that loads an image resource for display in an iPhone app GUI three different ways.
The Responsiveness Tester. The people responsible for the appearance of this iPhone app have been sacked.
Each method loads and displays the same image, but does the loading differently to demonstrate the effect each approach has on GUI responsiveness. The source code for this app is attached to this article if you’d like to play along at home.
When the user chooses a loading technique by tapping its table row, a corresponding method is called to illustrate that loading technique. These methods are called directly from the UITableViewDelegate tableView:didSelectRowAtIndexPath: method, which runs in the event loop, so all this code runs directly in the GUI thread.
First, let’s have a look at the code from the load-from-file example:
- (void)showSynchFileDemoWithTitle:(NSString *)title {
UIImage *image;
image = [UIImage imageNamed:@"apple-logo.png"];
EagerViewController *view=[[EagerViewController alloc]
initWithNibName:@"EagerViewController" bundle:nil title:title image:image];
[self.navigationController pushViewController:view animated:YES];
[view release];
}
The code looks like it sounds, right? We load the image from disk, use it to create a new UIViewController, push that UIViewController onto our UINavigationController, and then release the UIViewController back into the wild. This is exactly why synchronous loading is so popular: it’s ridiculously simple. And since we’re just loading a small image from a file, the GUI is still zippy, so synchronous loading is actually fine here.
Now let’s look at loading that same image from a synchronous web request instead of a file:
- (void)showSynchWebDemoWithTitle:(NSString *)title {
UIImage *image;
NSURLRequest *request=[NSURLRequest requestWithURL:[NSURL
URLWithString:IMAGEURL]];
NSURLResponse *response=nil;
NSError *error=nil;
NSData *content=[NSURLConnection sendSynchronousRequest:request
returningResponse:&response error:&error];
if(content == nil)
image = [UIImage imageNamed:@"big-red-x.png"];
else
image = [UIImage imageWithData:content];
EagerViewController *view=[[EagerViewController alloc]
initWithNibName:@"EagerViewController" bundle:nil title:title image:image];
[self.navigationController pushViewController:view animated:YES];
[view release];
}
The code is slightly more complicated, but still not too bad. We set up a web request for the image, wait for it to download, build an image with the contents of that request if it succeeded or load a default image if it failed, and then build our UIViewController from that image. Still nice and easy, but how does it perform?
The problem with synchronous web loading. Hang much?
Turns out, not so well. After the user taps “Synchronous from Web,” the app just kind of sits there for a few seconds before it shows the next view. Why? The synchronous web request loading the image in the event loop takes a while to complete, which blocks the event loop and hangs the GUI. This kind of code is surprisingly common despite the hangs it causes. Unless you’re willing to tick off your customers, which is usually considered harmful, synchronous web loading in the event loop is right out.
So what’s the asynchronous web loading equivalent look like? Behold, ye mortals, and despair…
From RootViewController.m:
- (void)showAsynchWebDemoWithTitle:(NSString *)title {
LazyViewController *view=[[LazyViewController alloc]
initWithNibNamed:@"LazyViewController" bundle:nil title:title
imageURL:[NSURL URLWithString:IMAGEURL]];
[self.navigationController pushViewController:view animated:YES];
[view release];
}
From LazyViewController.m:
- (id)initWithNibNamed:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil title:(NSString *)title imageURL:(NSURL *)imageURL {
if(self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) {
self.navigationItem.title = title;
if(imageURL != nil) {
self.getlogo = [AtomicAsynchronousWebRequest requestWithURL:imageURL
andDelegate:self];
}
}
return self;
}
- (void)updateLogoWithImage:(UIImage *)image {
[self.logo stopLoadingWithActiveView:[[[UIImageView alloc] initWithImage:image]
autorelease]];
}
- (void) atomicAsynchronousWebRequest:(AtomicAsynchronousWebRequest *)request didFailWithError:(NSError *)error {
if(request == self.getlogo) {
[self updateLogoWithImage:[UIImage imageNamed:@"big-red-x.png"]];
self.getlogo = nil;
}
else {
// We have no idea which request this is. Just log it and move on.
NSLog(@"Failed unrecognized HTTP request: %@", request);
}
}
- (void)atomicAsynchronousWebRequest:(AtomicAsynchronousWebRequest *)request didSucceedWithResponse:(NSURLResponse *)response andContent:(NSData *)content {
if(request == self.getlogo) {
[self updateLogoWithImage:[UIImage imageWithData:content]];
self.getlogo = nil;
}
else {
// We have no idea which request this is. Just log it and move on.
NSLog(@"Succeeded unrecognized HTTP request: %@", request);
}
}
Oh… that’s all? Well, I guess that’s not so bad. We pass the URL for our image to the UIViewController initializer, and the UIViewController then starts an asynchronous web request for the image and updates the logo view with an image when the web request either succeeds or fails. (Observant readers will notice some custom methods above. Hang tight, we’ll talk about those in a minute.) What does all this trouble buy us?
Nice and Zippy. Asynchronous Loading FTW!
A wonderfully responsive app, that’s what. The transition from the first view to the second view is instantaneous; the second view shows its spinner until the web request completes or fails, and then the logo is updated with a new image. Why is this UI so snappy? Because all long-running operations are performed outside the message loop, so nothing hangs the GUI thread. Lazy loading for slow resources is clearly the way to go.
And if you think about it, this approach is good not only because it runs faster, but also because it’s more modular. The UIViewController being created knows what it’s displaying; it should probably be loading its resources too, especially if that loading is complex, in case that UIViewController needs to be reused elsewhere in the app.
So… sweet. A twofer.
Being Lazy About Being Lazy
If asynchronous loading is what we need to be doing — and it is – then how can we make it easy? It turns out that asynchronous loading is easier in Objective-C than it is in many other languages.
In Java, for example, asynchronous loading requires you to mess with callbacks and Threads, SwingWorkers, or ExecutorServices, which feels like jumping through a bunch of flaming hoops while wearing a newspaper tutu. In Objective-C, though, web requests are baked into the API and already have asynchronous callback functionality, which means that asynchronous loading can be had essentially for free, especially if we do a little customization of our own.
The app uses two custom classes. I’ll discuss them here just in case the classes themselves or what they do is useful to other developers. Both classes are in the attached source if you want to put your eyes on them, or use them for your own nefarious purpose.
AtomicAsynchronousWebRequest
The iPhone SDK’s generalized web request API is NSURLConnection, and you can find a good primer on how to use it here. The NSURLConnection exposes way more features than most apps need, though, like hooks for reacting to redirects and chunked input, which makes it more difficult to use than it needs to be. AtomicAsynchronousWebRequest is a thin wrapper around NSURLConnection that lets developers perform the most common web tasks (namely atomic GETs and POSTs) asynchronously by implementing a dead-simple 2-method protocol.
DelayedLoadView
While the iPhone has a nice “spinner” GUI element (UIActivityIndicatorView) that’s handy for telling the user something is loading, it has no explicit API for populating GUI views lazily. DelayedLoadView is essentially a “container” view that shows a spinner until it’s updated with its “real” content view, which makes handling activity indicators and lazy content really easy, especially for GUIs built-in Interface Builder.
Gotchas
A couple gotchas have been glossed over in the interest of keeping things at least a little brief. Now that we’re past the good stuff, I’ll mention a few of them here, just in case you want to get creative on your own:
- All GUI updates must happen on the GUI thread. Cocoa Touch GUI elements, like GUI elements in most toolkits, are not thread-safe. So, if you need to interact with a GUI element, you need to do it from the main thread. If you’re not making your own threads, you probably don’t need to worry about this. If you are, you may need to make use of
NSObject’s performSelectorOnMainThread:withObject:waitUntilDone: or similar.
- Remember that
UIViewController IBOutlets are not initialized after super’s initializer completes. Instead, the UIViewController must be set to appear before IBOutlets are properly connected. This means that failure conditions can’t really be handled inside a UIViewController initializer, so any custom load code you write needs to take that into account. If you want an example of how to work around this issue, check how AtomicAsynchronousWebRequest calls its failure method from its initializer roundabouts using a performSelector call.
UIActivityIndicatorViews are kind of confusing. You probably want to set hidesWhenStopped to YES. That way, startAnimating and stopAnimating will do what you expect them to. If you don’t see a spinner and you expect to, make sure your UIActivityIndicatorView isn’t hidden. If you see a spinner but it’s not spinning, you need to call startAnimating.- Not all long-running operations have asynchronous callbacks baked in. Web requests do, which is very handy, but if you need to do some other kind of loading you’ll have to get creative. If you’re only going to load things now and then, using
performSelectorInBackground:withObject: is probably just fine. If you’re going to be doing a lot of loading, though, you won’t want to create a new background thread each time you load something, so you’ll probably want to create a custom NSRunLoop and kick off your loading with performSelector:onThread:withObject:waitUntilDone:. You can synch up the GUI when loading’s done with a simple performSelectorOnMainThread:withObject:waitUntilDone:.
Conclusion
You’re now an expert on how to build responsive network-enabled GUIs! Or at least you know more than you did.
It’s worth mentioning that even though the article focused on loading images, the very same principles can be applied to executing web service calls, loading web pages, or any other task that requires time to complete.
I now expect all apps to have responsive GUIs, even if they’re loading resources from the web. You’ve been warned. I’ve got my eye on you, iPhone developers.
Stay QWERTY, my friends.
I’ve written an 
and finishing up his stripes with some magic shiny tape I was on the hunt for legs. He’s not a large suitcase, just the right size, medium. He needed legs that matched his style and size. I hunted and hunted for something inexpensive and suitable. What did I end up using? The base from my very own best friend of a laptop table from Ikea, Dave. Height adjustable, tiltable and so so birdlike, I loved the idea in my mind. With a little cleaning, some paint and a simple transplant of hardware he was born. Without any further explanation, let me introduce Blue Footed Bobby.
Gary Coleman, Shannon Price’s husband who became famous with the series “Arnold” has been hospitalized in Utah and is in critical condition, according to a hospital spokeswoman.
