Some companies are switching from Blackberry devices to iOS 4 devices with the advent of multi-tasking on iOS 4.
iOS 4 is not the first mobile OS to support multi-tasking. It’s the last.
The reason it’s the last, is because it’s designers wanted to avoid multi-tasking entirely. They were of the opinion that
fast switching between apps was 95% of what users meant when they said “multi-tasking”. And to really give that
extra touch, developers could write code to save the state of their apps and restore that state when the user started
them up again.
The designers were mostly right. Many users never even noticed the lack of multi-tasking. That is until mobile apps
gained more complex functionality. When that happened, GPS applications stopped working when you took a phone call.
Pandora stopped playing. Skype stopped talking. Your app stopped syncing.
Let’s step back for a moment. Why don’t mobile phones just support traditional multi-tasking? They have in the past.
You can do traditional multi-tasking on a Windows Mobile device and on a Blackberry. But the Android and Google
phones don’t. What’s the problem?
The problem is two-fold: complexity and limited resources. Complexity arises from the fact that you have a much smaller
visual space and simpler UI on a mobile device. Applications tend to take up the entire screen. There’s no easy way
to indicate to the user that multiple applications are running. There’s no easy way to allow them to quit or control
multiple applications. Users expect mobile devices to be simpler, easier and idiot-proof. They don’t want or expect them
to work like little computers.
The second reason is limited resources. Everything that runs on the phone uses CPU time and memory. And
everything that uses CPU uses battery power. If you write your applications perfectly then they will use very little
of both. A well-written application will sleep between requests from the user. It won’t hit the network every few
seconds. It won’t use every last byte of available memory. Unfortunately many apps won’t be well written, or they
will need to hit the network or use every byte of memory to accomplish their tasks.
Given the limited resource problem, the Android developers decided to implement a new approach to multi-tasking.
An Android developer doesn’t just get to leave their program running. They have to decide what, exactly, needs to
run in the background. The answer for most applications is nothing.
The most common form of multi-tasking on the Android (and probably on iOS 4) is simply saving state. The Android OS
provides first-class support in the operating system for application developers to write out the current state of their
applications and load them back in when their app is resumed/restarted.
From the user’s perspective, it looks like the application is multi-tasking. When they switch away from an app and back
again it looks exactly like it did when they left. The note they were writing is still in mid-paragraph, their solitaire hand is
still in mid game. The OS will even try to keep the application in memory, making the switch back even faster.
But if the application you switched to needs more memory, the old app gets booted out. The user won’t notice
except that the switch back takes a little more time.
And that brings us to the less common form of multi-tasking. The ability to actually run in the background.
This is for those apps that want to continue playing music, downloading twitter messages, etc. Android supports
those types of apps by allowing them to register and run services. The entire application doesn’t run in the background,
just a service thread. That background thread doesn’t get to interact with the user, it just gets to service a
network connection, play music, etc. The result is far less memory pressure and, theoretically, less CPU usage.
iOS 4, despite Apple’s hyperbole, works almost exactly like Android. The OS now provides first class support for
saving state like Android does. And for background apps, there are a few extra wrinkles and one major
restriction. iOS 4 provides more “types” of service threads. You can register a music player and it will use the
normal iTunes background music controls. You can register a GPS or VOIP app. Those are explicit types.
The major restriction is that you can’t register a generic type. There’s no type for background network feeds.
So background IM or Twitter isn’t supported.
Apple took this approach so that the OS was the one doing all of the heavy lifting. The hardest code to get right is
the code that services the background functionality. With Apple’s approach, an iOS 4 developer only needs to write
the guts of the service thread. They don’t get to decided when they are called. Apple thinks this covers 99% of the
use cases and uses less resources then the generic Android approach.
That’s why not all of those companies with custom Blackberry or Windows Mobile apps can switch over to an
iPhone. There’s still no generic multi-tasking capability, even in iOS 4. If you have a sales support app that
expects to get live, continuous feeds, you won’t get that in iOS 4. You can get much closer with Android but
Android doesn’t yet have the other enterprise support features that Blackberry and iOS 4 does.
This new approach to multi-tasking in mobile operating systems appears to be the future. Microsoft’s newest mobile
OS looks to use the same mechanism. All modern mobile OS’s now use the service thread approach. The difference is
in what they allow the service threads to do. My expectation is that iOS 4 will open up to allow more “types”,
including a generic network service thread. And Microsoft’s model will probably look more like Android then iOS.
