You might now be wondering if you have been following my post is that..
When do you save a page state?
Assumming our application has a page state that it needs to maintain let’s look at when to save and restore it. First let’s consider when to page state from the OnNavigatedFrom method the purpose of saving page state is to able to restore visual state should deactivation occurs, therefore we want to save page state whenever the page is either navigated away from or being deactivated.
If navigating back however, so if the user hits the back button page state should not be saved from user’s perspective, the implicit agreement is that by pressing the back button the user is leaving the current page and if the user returns to it he expects a fresh instance of the page. And that’s the way how the navigation system works. Pressing the back button either navigates back from the history of stack or exits the applications. In both cases, the current page will get removed from the stack and the page instance is destroyed. So the next time is navigatedTo a new instance is created. There are code we can detect whether the user is navigating back by taking the navigationMode property of the OnNavigatedFrom methods navigation events args parameter, the navigation mode enumeration indicates the direction of the current navigation operation. So if the value is back so we can skip saving page state, otherwise we should go ahead and save it since that means the user is navigating forward and there’s a chance that he will be returning to the page at a later stage.
We can use the state dictionary of the PhoneApplicationService class to persist page state to memory the dictionary will be persisted across deactivation even if the application is tombstoned at a later stage so that we can later retrieve it on reactivation.
When to restore a page state?
First we need to understand in which cases a new instance of a page is constructed when navigating to it. A page is instantiated when reach through forward navigation or the page is the application’s main page when the application is first launch. In the following graph, the yellow arrow indicates when an instance of a page is created so again, backward navigation does not result into a new instance of the page being constructed.
Now when navigating back to the page after the application is being deactivated the page may, or may not be a new instance depending whether the application is tombstoned or not. Most of the times the application will just be put in dormant state, so as we’ve seen this made the application preserve intact in memory. And so when the user returns to the page, the same instance is revived. If on the other hand, at some point later the application is later tombstoned then when the user returns a new instance of a page is created on activation since the application is reconstructed a new one. So page state needs to be restored when the page is a new instance and state was previously saved in the previous dictionary. That’s the only case when returning the page from tombstone mode.
In your applications you can define a simple flag to test whether a current page is a new instance or not, which helps in deciding whether page states should be restored. Know that if you have an existing applications that target Windows Phone 7 typically no change would be necessary when regards to page state, since returning from dormant state scenarios which is new in mango is handled in the same way as the returning back from another page scenario which already exist in Phone 7.