Customizing App.xaml.cs
If you are familiar with tombstoning on Windows Phone, you know there are four events in the Windows Phone application lifecycle that can be handled: PhoneApplicationService.Launching, PhoneApplicationService.Closing, PhoneApplicationService.Activated and PhoneApplicationService.Deactivated. The first two are for normal app startup and shutdown, while the latter two are for tombstoning scenarios.
Along with these events are two different property bags that application data can be saved to.
IsolatedStorageSettings.ApplicationSettings is typically used for backing up persistent data that you want available every time the application starts up.
PhoneApplicationService.Current.State is used for transient data that you only want persisted if your Silverlight application gets tombstoned. It is the equivalent of session data in an ASP.NET web application.
In the Launching and Closing event handlers you would typically save to Isolated Storage, while in handlers for Activated and Deactivated you would want to use Current.State. The former coding artifacts are for persistent data while the latter are for transient data.
These categories are imperfect, however. It is possible to go through the Deactivated event but never have Activated called. This occurs if for memory management reasons your application is permanently terminated (a permanent death scenario rather than the temporary death that tombstoning is supposed to trigger). This can also happen, of course, if the user for whatever reason just decides not to return to your app after it gets tombstoned.
Another way to look at this is that your application is permanently terminated without ever invoking the PhoneApplication.Closing event.
In order to handle this common scenario, you must save any persistent data in the Deactivated event as well as the Closing event.
A simple pattern for structuring your code to cover all these possibilities is to make sure the code fragment for saving persistent data is called in both the Dectivated and Closing event handlers. Similarly, the fragment for restoring persistent data should be called in both the Activated and Launching handlers. We do this by taking care of persistent data backup and restores in two new methods: BackupPersistentData and RestorePersistentData. Those who remember the IDisposible pattern in C# will recognize some of the same coding idioms being used here.
The following code goes in App.xaml.cs:
private void BackupPersistentData() { var store = IsolatedStorageSettings.ApplicationSettings; //save persistent data store.Save(); } private void RestorePersistentData() { var store = IsolatedStorageSettings.ApplicationSettings; //restore persistent data } private void Application_Closing(object sender , ClosingEventArgs e) { BackupPersistentData(); } private void Application_Launching(object sender , LaunchingEventArgs e) { RestorePersistentData(); } private void Application_Deactivated(object sender , DeactivatedEventArgs e) { BackupPersistentData(); var store = PhoneApplicationService.Current.State; //save transient data } private void Application_Activated(object sender , ActivatedEventArgs e) { RestorePersistentData(); var store = PhoneApplicationService.Current.State; //restore transient data }
Sticking to this pattern has helped me to avoid a lot of unforeseen mistakes in my own phone apps.