Windows Phone

Windows Phone 7 tombstoning explained

Windows Phone 7 developers can use tombstoning to provide an excellent user experience that is very similar to multitasking. Justin James provides more details about the tombstoning concept.

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.

For more details, an MSDN article shows a basic walkthough of using these two objects to store a simple string, and James Ashley demonstrates an approach that allows you to save view models.

Summary

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.

J.Ja

About

Justin James is the Lead Architect for Conigent.

12 comments
mayima
mayima

From what I understood through the ms model is that true multitasking has been introduced, but when background applications begin to consume to much resources the applications are than put into tombstoned state, this only happens if the device reaches a point where background applications begin to affect user experience. Please correct me if I am wrong but to me this sounds like a very smart way of handling backgrounded apps.

peterrogers
peterrogers

Can't say ive used the Windows phone 7 as of yet, but I'll be sure to check this out when I do. I believe my Sister ought one not to long ago, I'll have to have a look.

insuranceman1
insuranceman1

Is multitasking available yet? while I appreciate the helpful guide to tombstoning, i much prefer the background energy efficiency of multi-tasking.

khiatt
khiatt

to be able to have multiple applications running at the same time?

jasondlnd
jasondlnd

No taking up background resources when multitasking!

Justin James
Justin James

Have you worked with WP7's tombstoning before? If so, what strategy did you use to save/load the data? Was it a good approach to handle things, or would you do it differently next time? J.Ja

Justin James
Justin James

I've written an article about just that, too, published a few days ago here on TechRepublic. :) J.Ja

AnsuGisalas
AnsuGisalas

So they have app-scale hibernation instead to create the illusion that the older task is still "alive"... when it's really reanimated.

Justin James
Justin James

When I owned an Android phone, the multitasking was the root cause of a number of really big problems. For example, if you wanted to "clean slate" an app the only way to do it for sure was to reboot the phone. And you'd need to reboot the phone on a periodic basis to clear out the nooks and crannies where apps had loaded but never exited. On WP7, you don't have these kinds of problems. I'm a bit nervous about the "Mango" update that brings true multitasking to WP7, because honestly, I don't want it! The only times I've rebooting my WP7 phone in 3 months are for updates and for an odd bug where the Marketplace would crash (it seems to be fixed now). My wife's never rebooted hers in that same time span, except for updates. I was rebooting my Android phone every few days, and my wife was rebooting hers multiple times a day. J.Ja

Justin James
Justin James

1. Yes, this is true. Many games, for example, have a particularly long startup time (5+ seconds) so it can be annoying. 2. That is definitely a possibility as well, but I think that those applications would need to be working with some pretty big amounts of data for it to be noticable (say, YouTube sticking its buffer in there, or the Web browser putting its cache in there). There seems to be some definite differences between Android users on bit rot and background task hogging. I know users who never see it. I saw it moderately, my wife's phone was nearly useless because of it. I had one phone that worked perfectly until I started one particular application, and then text messages would be delayed. Completely unexplainable but at the same time, I could repeat it time and time again, it was DEFINITELY the application... oh, and the app was a simple game. I have come to the conclusion that it isn't that the Android bit rot is "overblown" or "exaggerated", it is that some users and devices will see it based on the manufacturer's customizations to Android and the applications installed and used, and other users will not. In terms of the background processing scenario, you are right that apps are limited on WP7 without it. They make up for it with push notifications being able to wake up apps, but that is a poor substitute, in my opinion, for a proper background processing piece, because it forces the developer to write a server application and maintain it forever, with no idea of what the payback from app revenue will be. J.Ja

Heshan Perera
Heshan Perera

Reloading an application from scratch, though to a state that the user left it in cannot be expected to be as fast as the response in a multitasking environment. I have the following concerns... 1. It will often be slower than a cold startup due to the extra reads and writes. 2. Many applications storing serialized view model in non-persistent memory could take adversely affect the performance of other applications. I am a heavy Android user myself, and I have not faced the issue of unused applications hogging resources given a fair period after closure. This issue of bit-rotting with regard to Android is over exaggerated in my opinion, thus leading users to believe that the windows remedy of restarting the device frequently makes the OS run much faster than it did. If anything, the problem with Android is the famous fragmentation problem, where the OS is forced to run on a vast range of hardware, some of it being slow enough to make users blame the OS. Though tombstoning may solve the user experience problem to a certain extent, I would never choose it above a truly multitasking environment, as it is very limited where background processing is concerned.

AnsuGisalas
AnsuGisalas

Not without something like Task Manager that lets me kill off the stuff I don't want running. But done the right way, not like those cheap appkiller apps. Don't trust those either.

Editor's Picks