Windows Phone Developer FAQ

There is not an “all-inclusive list”. You should save what is meaningful and useful to your app. The most common examples include:

• SelectedIndex for the pivot (if the page contains a pivot)
• Scrolling position in a ListBox or any other ScrollViewer in the page.
• Zoom levels and other transforms in a map control, picture viewer or any other control that supports manipulation
• Uncommitted text in a TextBox. If the textbox is critical to the app (the tweet text in a Twitter app, for example) consider restoring text selection, caret position, and focus.
• Element that had focus in a page (especially if it is a TextBox, which needs to show SIP

The answer relies on how you prepare a PhoneApplicationPage for tombstoning.   The recipe says:

1. Save your state in OnNavigatedFrom ( )
2. Load your state in OnNavigatedTo ()

Imagine you have a page1, and you navigate to page2. Sequence goes like this:

Page1.OnNavigatedFrom  () // saves state, does work
Page2.OnNavigatedTo () //
Press Back, will trigger
Page2.OnNavigatedFrom () //
Page1.OnNavigatedTo ()  // here is the magic place. We need to know if there was a tombstone since Page1.OnNavigatedFrom() was last called.  Unfortunately, the flag we set earlier does not tell us if there has been a tombstone since this page was created or serialized; that flag only tells us if there was a tombstone recently (but it could have been before or after our page was pushed to the back stack ). 

There are multiple approaches to deal with this.
The obvious one is to

1. Set a flag on your page’s constructor.  If you set a “isnewPage” flag in your constructor, then
2. During OnNavigatedTo you can check if your Page had state; if it does, then this must be a page after a tombstone, since page is being reconstructed but it has state.

Another approach is to assign tokens (or activationIds) to  your pages.

1. If our application  keeps track of activationIds now when a page was constructed, we can assign an activationId to that page.
2. Using yesterday’s flag to detect tombstones, we can detect deactivate->tombstone->activate sequences. When such a sequence happens,  we assign a new activationid to this run of the app. 
3. now, when OnNavigatedTo () happens, we can check if the activationid  assigned by the app to this page (when the page was constructed) matches the activationid of the app.  if they do match, a tombstone has not happened.   if they do not match, then a tombstone must have happened while page was in the back stack.

Either approach works. All I am explaining is that for pages, listening to whether a tombstone happened is not enough.

You are right; currently StartupMode does not convey whether a deactivation lead to a true tombstone (aka process termination).   The StartupMode flag just tells you how the last time the actual process was started happens.

Here is an example on how it is not reliable.

1. Launch process ( mode will be Launch)
2. Show a Chooser (such as PhotoChooserTask) that does not tombstone.
3. Click Back to get back to the app;  StartupMode will still be Launch – arguably this is right since process was not terminated.

Now, try different sequence:

1. Launch process ( mode will be Launched)
2. Press start button to tombstone the application
3. Click Back  — StartupMode will be Activate 
4. Show a Chooser (such as PhotoChooserTask) that does not tombstone.
5. Click Back to get back to the app, StartupMode will now remain as Activate – arguably this is right since process was not terminated; but now the information is useless because you will not know if process was tombstoned or not.

Lesson learned: don’t rely on StartupMode to try to detect if a process was tombstoned.

Yes. Page.State has weird ‘limitations’. I have not seen these documented to exact limits, and I see them be a combination of circumstances, here is what I have observed:

1. If you insert more than > 2 MB of data into PhoneApplicationPage.State, your navigations will see RootFrame.NavigationFailed fire. The NavigationFailedEventArgs will have a weird error about IAccessControl::IsAccessPermitted, and a 0×80040204 Hresult.
2. If you insert smaller chunks of data into PhoneApplicationPage.State, but you have a back stack with enough pages to exceed again the same > 2.5  MB, you will get NavigationFailed again, different error: Unable to obtain the client’s security blanket; the Hresult is 0×80040205

Afaik, there is not much you can do to prevent these. The workaround is not to store this much data in PhoneApplicationPage.State. You can use IsolatedStorage instead. I recommend you serialize these as binary (yes, a little work, but much better performance) if you have a lot of data to save.