One of the nicest features in the Windows Phone (WP7 or WP8) is fast app switching (FAS), using which a user can very easily switch between currently running apps and without losing their last running states. So it seems like multitasking experience to the user. But in Windows, the movement you navigate away from the currently running application, its code execution is stopped even though it was running on the asynchronous thread and again started when you launch the application. Hence, though Windows Phone does support background execution of Tasks and the FAS system seems to be multitasking, but in actual it is not a multitasking. It only give multitasking like experience. Because in Windows the application does not continue to execute code while it is not in the foreground. The important thing is to know what happens technically when you navigate away from the app and again launch the app. This post describes how to enable fast app resume for Windows Phone 8 apps and what happens when FAS occurs.
On Windows Phone, when a user navigates away from an application, the application is suspended and its state is preserved in memory. If a user returns to the application by pressing the Back button or by using the Task Switcher, the app instance resumes. Because the app was preserved in the memory, the app quickly resumes in the same state it was when a user navigated away and it is the same thing the user expects. This process is called Fast App Switching (FAS) and the above condition where the app’s state is preserved in the memory is called Dormant state. The big advantage with FAS is that your application does not need to restore state from storage, which can save a lot of time, not show the Resuming screen, and so on. But there might also be a condition where your phone is running on low memory (RAM). In this condition Windows OS put some dormant apps in Tombstoned state i.e. the saved instance of your app is deleted. While creating the Windows app you have to consider both this situations along with your app’s resuming experience to user, and code accordingly. While considering the user expectations, Windows recommend that you should check the time gap between navigating away from app to its relaunch, and if it is less than 30 seconds then you should launch the saved sate of the app but if it is greater than 30 seconds then you should launch new instance of the app. Even though Windows recommend above relaunch checks, you should decide what suits your app best according to the app’s basic requirements.
Achieving FAS only considering the Dormant state is very easy than considering both dormant as well as tombstoned state. Either the app is resuming from dormant state or from tombstone state, it will fire the Application_Activated event, which you can handle in App.xaml.cs. In the ActivatedEventArgs object passed to the Application_Activated event has a new property: IsApplicationInstancePreserved. If it is true, you should skip the restoration of state since it was already done for you by adding the ActivationPolicy attribute to the DefaultTask element in WMAppManifest.xml and set the value to “Resume” as shown below:
<tasks> <defaultTask Name="_default" NavigationPage="MainPage.xaml" ActivationPolicy="Resume"/> </tasks>
As discussed above, you have no choice about whether your application goes to the tombstone state or the dormant state, so be prepared for both. For tombstoned state you must use memory which is independent of the app’s lifecycle. There are two ways that you can store app’s state data when your app is being deactivated and restore it when your app is reactivated. The first way is to use persistent storage. This includes isolated storage and a local database. Another way is using the State dictionary of the PhoneApplicationService which is a temporary storage location that persists only as long as your app is tombstoned, but is much quicker to access than persistent storage. Using these two storage types correctly will have a big impact on the user experience and load time of your app.
If IsApplicationInstancePreserved property is false, you are coming back from being tombstoned. In Application_Activated event, check isolated storage or State dictionary for containing app’s data. If there is no data present in app’s Sate, initialize all UI controls to their default values. Without forgetting save the necessary data to State dictionary or isolated storage in the Application_Deactivated event as below:
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
PhoneApplicationService.Current.State["Key"] = "Value";
// Also save other necessary data to application State dictionary.
}
If this data is available in app’s State, execute the code for tombstoning i.e. extract values of UI controls from State dictionary or isolated storage and initiate the UI controls with these values.
private void Application_Activated(object sender, ActivatedEventArgs e)
{
if (e.IsApplicationInstancePreserved)
{
// Initiate Ui controls with old saved data. ApplicationDataObject=PhoneApplicationService.Current.State["ApplicationDataObject"]
}
else
{
//Application launching first time. Initiate UI controls with default values.
}
}
To test your tombstone code, go to your project’s properties and look on the Debug tab, and you will see a setting that lets you make sure the application always goes to the tombstone state when deactivated.