There is quite a bit written on how to handle tombstoning on a Windows Phone. Most of the guidance is for code-behind developers. Here is an MSDN article (How to: Preserve and Restore Page State for Windows Phone) that shows how to use the Page’s OnNavigatedTo and OnNavigatedFrom methods to preserve and restore page state. This article proposes using an instance variable (_isNewPageInstance) to distinguish between navigating to the page due to dormancy or tombstoning.

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
  // If _isNewPageInstance is true, the page constuctor has been called, so
  // state may need to be restored.
  if (_isNewPageInstance)
  {
    if (_viewModel == null)
    {
      if (State.Count > 0)
      {
        _viewModel = (ViewModel)State["ViewModel"];
      }
      else
      {
        _viewModel = new ViewModel();
      }
    }
    DataContext = _viewModel;
  }
  // Set _isNewPageInstance to false. If the user navigates back to this page
  // and it has remained in memory, this value will continue to be false.
  _isNewPageInstance = false;
}

This works pretty well as long as the data you’re trying to save into the Page State dictionary is serializable.  Generally, I don’t put my view models into page state. Instead, I only put values that the user modifies like textbox values, pivot control selected indexes, etc.
 
The scenario that isn’t clear in this article is when the page is navigated to due to page to page navigation. In this case, if this page is navigated to from another page, the _isNewPageInstance variable will be false but no values will be pulled from State because the Page’s State dictionary gets cleared when navigating away from the page to another page in the app. So even if values were stored into the State dictionary due to deactivation, these values won’t hang around once the user navigates to another page in the app.  This is one big difference between the PhoneApplicationPage.State dictionary and the PhoneApplicationService.Current.State. The PhoneApplicationService.Current.State hangs around during the entire lifetime of the application instance.
 
This leads me to my main point. How do you support tombstoning and fast app switching in view models if you are allergic to code-behind development (M-V-VM zealot) or have view models that are not guaranteed to be serializable?
 
One way to handle this is to pull most of the logic you see in the above OnNavigatedTo method into the view model and invoke it from the Page’s OnNavigatedTo.
 
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    var viewModel = (MyViewModel) this.DataContext;
    viewModel.OnNavigatedTo(e, this.State);
}
 
The view model will then check its own isNewInstance value to determine if the navigation was caused by returning from dormancy. The view model will then check the count of the state dictionary that was passed in. Count of zero means no need to restore from tombstoning.
 
Not bad, but that did still require a bit of code-behind. What if we wanted a cleaner more reusable solution with no code-behind and where each view model didn’t have to do the same new instance and Page state checking? That is the scenario we tackled in our latest Windows Phone development guidance.
 
I won’t go into too much detail here but here are the highlights:
  • We use the PhoneApplicationService.Current.State dictionary to store page state in order to survive tombstoning.
  • We have a base ViewModel class that most of our view models extend.
    • This base ViewModel provides virtual OnPageDeactivation and OnPageResumeFromTombstoning methods that derived view models can simply implement and supply their own preservation and recovery logic, respectively.
    • The base ViewModel then calls OnPageDeactivation and OnPageResumeFromTombstoning at the appropriate times.

Please take a look and give us feedback.