I am of two minds when it comes to multitasking support on mobile devices, much like the 2 approaches taken to date by iOS, Android and QNX. The 2 approaches take different philosophies, being a trade-off between application flexibility and power management. Both have their merits and both have their pitfalls.
The iOS approach is to make most apps go into what is essentially a sleep state when they aren’t in the foreground being used. Apps can request special permission to continue to run and process data, but only if they are using one of a specific set of services (networking, location services or music/audio playback). Otherwise, when an app is told it is being put into the background, it is given a short period of time to wrap up whatever it is doing, save state if appropriate and prepare to snooze. An app can request more time, if it finds the default isn’t sufficient, but it may not be allowed more time. Apps are told when they wake up, so that they can restore their state and start running again.
In Android (and I believe in QNX, I haven’t used it yet), an app is basically always running. It just doesn’t have a UI visible to the user. This is basically the same approach as any current desktop operating system. An app is still notified when it is being put into the background or when it comes back to the foreground, so that it can at least stop updating the UI and can notify the user using different mechanisms when in the background. But an app, once running, continues to run while it is in the background.
The iOS approach is taken to preserve battery life. Unlike most notebooks and netbooks, smartphones and tablets have very, very limited battery capacity. Having an multiple apps running continuously can make it difficult for the OS to manage CPU power consumption, since it may not be able to scale back the CPU speed to preserve battery life. By putting apps to sleep that don’t require certain services, it gives more control to the operating system in terms of how it manages power.
The downsides, though, are that it makes writing applications a bit more complex, and makes it harder to provide certain types of services in an app if it doesn’t really need network, location services or audio playback (and doesn’t want to cheat by claiming it needs them when they really don’t). Basically, going into the background is very similar to the app being shutdown completely. The app does presumably start faster, since the binary and its associated memory are still loaded and ready to go. But some app writers are treating background like shutdown, so bring the app back into the foreground takes about as long as a cold start. It varies from app to app, and in some cases, it assuming “foreground” and “first start” are the same makes things simpler for the app developer, even if it doesn’t make it easier for the user.
The Android approach provides a great deal of power and flexibility, although an app can be terminated by the OS if the resources are needed. That means an app developer can’t assume they will be running continuously once started, because the user or the OS could shut them down. But this, conceptually, isn’t really any different from building an application for Linux or MacOS, since the same thing can happen there. The developer docs do recommend using a Service if you are building an app that requires long-duration processing, but there is nothing stopping a developer from simply doing that in whatever Activity is currently active. However you do it, building for Android for multitasking tends to make the apps a bit simpler, since it is more like running in a normal desktop environment.
The downside, though, is that an app in the background could still require that the CPU run at it’s top level of performance, making it harder to manage battery life (and resulting in users wondering why their battery doesn’t last as long). Some app developers may not be aware that their app requires a lot of CPU, and they inadvertently impair battery life without meaning to do so. Basically, it makes it a lot easier for a developer to hurt battery life without knowing it.
I’m not sure which approach I prefer. On the one hand, forcing developers down a path that favours battery over application flexibility is a bit heavy-handed, and takes away some features that a well-written app could take advantage of. This in turn could provide users with a superior app experience. However, given the potential for a poorly written app to make the user’s overall experience with the device worse, I can see merit it putting limits around developers. The argument against that, in the case of iOS, is that Apple does review apps before approving them for the app store, and adding a review task that would include battery usage when running actively in the background could presumably weed out these ill-behaving apps. They must already do this when an app claims to require background access for network, location or audio playback, so they could extend that to all apps. While I can see the point of the limits, I’m not sure that those couldn’t be enforced with a process (during app review) rather than with technology.
For now, I live with the fact that apps on iOS don’t run in the background unless they need specific services. On Android, it means being careful that CPU utilization is minimized when the app is in the background.