Yesterday Engadget had an opinion piece on mobile multitasking, once again borrowing my awesome slide on the topic from Mix (hey Michael, where's my royalty cheque? :-) ).
A picture tells a thousand words, and I think this one actually does a pretty good job of explaining what happens on Windows Phone 7 (but then again, maybe I'm biased). If your application is running when the user switches to another application (by using the Start menu, or tapping on a notification, or via some other means) then our assumption as a platform is that the user now wants to focus on the new application, and doesn't want the previous one interrupting their experience by grabbing memory, CPU, network bandwidth, or other resources.
Before we suspend the application, we give it some time (exact time TBD) to prepare to be suspended. In this time, the application can save global state to disk, sign-off from web sites, or perform other clean-up operations. In general this should be relatively simple, because the page-based model of Windows Phone applications facilitates a relatively stateless programming model - much of your application's state can be encoded in page URIs (as query-string data) or as small blobs of state stored and retrieved on each page navigation, just like the web.
After your application has finished pausing, it will be suspended and no further user code will execute. Note that you can still have push notifications coming in from the cloud, so the user can be kept up-to-date via toasts or you can have your tile updated with the latest information from the web.
When your application is suspended, it is not killed immediately. If the user returns to the application "soon" then it can be resumed very quickly and the state saved during pause may not even be necessary. But if the user launches other applications that end up needing a lot of memory, your process will be killed and the memory will be relinquished to the foreground application. This is a key difference between Windows Phone 7 and previous versions of Windows Mobile - the foreground application gets access to virtually all the resources on the phone (memory, CPU, etc.) without having to worry about being starved by background apps that are doing random things at unpredictable times in the background.
If your process was not killed, resume is trivial - you don't need to restore any state from disk, but you may need to re-start device features like accelerometer or location, and you may need to re-connect to any web services. Assuming your process was killed, you can use the previously-saved data from pause to re-create your global state, and the per-page state / query-string data to recreate the page state for each page on the back stack.
The end result of all this is that users can switch back and forth between applications and have the illusion of multi-tasking without the downsides of erratic resource usage. Now there are certain multi-tasking scenarios that this model can't mimic, such as persistent location tracking or background music streaming, but for the vast majority of cases users simply want the ability to either get back to where they were (resume a previous task) or to be notified of updates (via toasts). For these scenarios, we think Windows Phone 7 does a great job.
Nice post Peter ... thanks for the information. One question ... with the CTP, how does the app know when someone paused you? I'm assuming this happens when the user presses the Home button, or maybe other buttons on the phone except for the back button. Is there an event that the app can handle?
Hi Paul, none of this is in the CTP build right now... but you're right in the fact that Start will pause your app, as will any other actions that cause the foreground app to switch (eg, click on a toast)