When Windows Phone 7 was first shown to developers, there was a fair amount of concern about the lack of multitasking in the operating system; after all, multitasking is considered one of Android's big features. (It is important to note, though, that iOS was quite successful without multitasking.) One of the big problems with Android is applications that sit in the background consuming resources when the user thinks that they have exited the application. The way Windows Phone 7 handles this is with a concept called tombstoning.
When a user does something that would put the app in the background on a multitasking OS (such as pushing the Start button on the phone), the app is not merely dumped out of memory, it also has the option of doing a last-moment save of state. When the user re-launches the application (or returns to it via the Back button), the application is still loaded from scratch, but it is also sent a notification that it is "returning from the grave" as opposed to being cold loaded. With this notification, applications can then re-load their state and give the appearance of multitasking.
For example, the game Fruit Ninja resumes from an exit and puts the user right back in the game with it paused, as if nothing happened. Other games and applications do not bother to do this at all, or they offer the choice to return to their previous state (like Microsoft Word does when it crashes and offers to recover the document that you were working on). The difference between being started from fresh and resuming is that the former creates a Launching event, while the latter fires an Activated event. Tombstoning fires the Deactivated event. MSDN has a walkthough of the full application lifecycle model.
Options for handling the events
Once you know what events you need to handle, what should you do with them? You have some options. The simplest approach is to do nothing, and for many applications, that is just fine; for other applications, though, that does not provide the best experience.
The next step up is to save a "bookmark" of the work the user was doing, and when they return, go to that "bookmark" in the application and load the data fresh. For example, a Web browser application might save the URL the user was viewing and reload that page when returning from the grave. This is an especially attractive option for applications that get their data over the network. The downside is that the user has to wait for the application to reload its data.
The next step up is to cache the data, and many applications that retrieve network data cache it anyways. You would simply need to ensure that your data is retained throughout sessions.
Another option is to serialize the view model to be saved, so instead of loading data individually, you merely restore the view model. If your application works well in this scenario, it is a very attractive option because it is easy to code up and fast for the user. A number of people I know like this option.
Options when you're saving data
When you save your data, you have two good choices: IsolatedStorageSettings.ApplicationSettings or PhoneApplicationService.Current.State. IsolatedStorageSettings.ApplicationSettings is permanent storage, which means that your application needs to maintain it to ensure that its usage does not get out of control. PhoneApplicationService.Current.State gets wiped out when the application is fully shut down and exited; as a result, you don't need to do anything to make sure that it gets cleaned out. The downside is that you lose the option of restoring the data on a fresh application launch as well. If you need to, you can also save your data as a file in IsolatedStorageSettings.
The tombstoning mechanism is not a replacement for multitasking (which is on its way for Windows Phone 7), but it can be used to provide an excellent user experience that is nearly indistinguishable from multitasking in many cases, with relatively little effort on your part.
Justin James is the Lead Architect for Conigent.