With the Mango update of Windows Phone to Windows Phone 7 many things will be changed. One of them is a better support for mutitasking behaviour of your application. This package consists of new background tasks (a will report about this later) and a new state in the executing model of Windows Phone.
The new state
Until Mango, an Windows Phone app will be tombstoned (=process will be killed), if the user leaves the app with the start menu button and call another application. With Mango Microsoft now introduce a new state for an application: “Dormant”. If there is enough memory left, the Windows Phone OS let the process of your app in memory until a other application process will kick it out. The user can than use the new function “Press and hold the back button for two seconds” to open the Mango fast switch application screen to return to one the dorming apps.
Is it really new?
But this state for your application is not really new. Because today with Windows Phone application development for version 7.0, you have to consider this state also. If you have a long running deactivation process, for example because of serialization, it could be that the user returns quicker back to your application than the deactivation is finished. In that case you have to handle the same behaviour that your old process is still running.
How to handle the revival
To distinguish between a activating of your app after tombstoning or revival you can use the IsApplicationInstancePreserved property of the ActivatedEventArgs in the Activated event of your app in that way:
private void ApplicationActivated(object sender, ActivatedEventArgs e)
{
if (e.IsApplicationInstancePreserved)
{
ApplicationDataStatus = "application instance preserved.";
return;
}
if (PhoneApplicationService.Current.State.ContainsKey("ApplicationDataObject"))
{
ApplicationDataStatus = "data from preserved state.";
ApplicationDataObject = PhoneApplicationService.Current.State["ApplicationDataObject"] as string;
}
}
Because in the case of application revival after the dormant state the constructors of your pages are not run through, you can define a bool variable which indicates in the NavigatedTo-Event if your application was tombstoned or not. It is not a good idea to create a static class with a starting state, which is set during the activating event, because the NavigatedTo of your page could be called earlier than the activated event (in case of long running deactivation, for example).
So best practice is to define a private member IsNewPageInstance, which is set to true within the page constructor.
bool isNewPageInstance = false;
// Constructor
public MainPage()
{
InitializeComponent();
this.isNewPageInstance = true;
}
In the NavigatedTo-Event we know now, if we have to restore our page state:
private void ApplicationActivated(object sender, ActivatedEventArgs e)
{
if (e.IsApplicationInstancePreserved)
{
ApplicationDataStatus = "application instance preserved.";
return;
}
if (PhoneApplicationService.Current.State.ContainsKey("ApplicationDataObject"))
{
ApplicationDataStatus = "data from preserved state.";
ApplicationDataObject = PhoneApplicationService.Current.State["ApplicationDataObject"] as string;
}
}
Testing of Tombstoning with the emulator
Another greeat new feature of the new Mango Windows Phone tools is that you can force the debugger to produce a tombstoning behaviour. The achieve this, you have to check a checkbox in the project properties of the debugging area.
Conclusion
With the new state “dormant” and the fast switching ability of the Windows Phone OS for the Mango version in combination with the new backgound tasks Microsoft give us the tools of trade to emulate a better multitasking appearance. This behaviour is now similiar to other mobile plattforms and still assure a good battery life time. For me, a great step in the right direction.
