The title of this post sounds a little weird but is actually quite fundamental to how you develop for Windows Phone. Most training content/courses for Windows Phone seem to focus unnecessarily on the application wide events of launching, closing, activating and deactivating. These are useful to get an understanding of what tombstoning is and why it happens. However, in most cases what’s more important is knowing and understanding the page methods which you can override to intercept the page lifecycle, namely OnNavigatedTo and OnNavigatedFrom. These methods always occur as a pair and as such make a useful point at which to save and restore page data.
Let’s assume we now know that we are going to save and restore information in the OnNavigatedFrom and OnNavigatedTo. The next question is what data are we going to load and where to load it from. So now we need to look at different scenarios:
First time arriving at a page
The only thing you should rely on absolutely is the navigation uri for the page (look at the navigationeventargs). This should tell you all the information you need in order to load the data for the page. It might include a product id, a serialized object or some other identifier of the data you want to load.
Using the information from the navigation uri you then need to load the data for the page. This might come from:
– an in-memory application wide store (eg repository model)
– loaded from cached data on disk
– retrieve data from a service
Notice that these are in order of increasing latency. To make your applications appear more responsive you need to think about how you can cache content in memory and/or disk before calling out to a service
Leaving a page
When you leave a page there are two options:
– Forward navigation to some other page and/or application – in this case you need to cache the current data for the page in the State dictionary for the page. When the user comes back to the page, you should retrieve the information from the State dictionary and use it to populate the page. The advantage of the State dictionary is that it automatically handles Tombstoning for you!
– Backward navigation – in this case it’s up to you as to whether you cache the data or not. Caching the data has the advantage that if the use goes to that page again, the data can be loaded very quickly (eg browsing to the same news article again). You can’t use the built in page State dictionary for this because each time you navigate to a page, it will get an new State dictionary, so you’ll have to come up with your own caching mechanism.
Returning to a page
This is similar to arriving at a page, with the only exception that you need to look in the State dictionary first.
The important take away from this post is that looking up data should be a progressive action: start with the page State dictionary; then to an application wide in-memory cache; next look to disk; then call to a service.