… or “How my app dies and comes back to life to read its own tombstone”
I’m working on code related to tombstoning my Windows Phone app. I’m slowly discovering that the Microsoft designers were not thinking much about app developers when they designed their tombstoning feature.
When not dealing with tombstoned app code, a page (using Silverlight) has a certain flow through the code based on the activity:
- Navigating forward to a page: Constructor is called for the page followed by a call to OnNavigatedTo().
- Navigating backward to a page: A call to is made to OnNavigatedTo().
- A page being shown after tombstoning: A call is made to OnNavigatedTo().
What we see is that the code for a page doesn’t get a call that it is being restored from the tombstone state. If we look closer at the data when OnNavigatedTo() is called, we will see that the navigation mode is “Back” when navigating back from a child page and is “Back” when coming back from the tombstone state.
It is absurd for the mode to be “Back” when being reactivated because, for this app, it is not coming back from anything it went to. It was just dead and the page is now new. “New” happens to be the navigation mode when the page is navigated to from an earlier page.
The trick is to then detect that a page is technically new but that the navigation mode is “wrong” when it says the code is coming “back” to it. This is simply a matter of detecting that the constructor for the page object was called before the OnNavigatedTo() function which indicates that the page content is being generated from scratch. Checking the navigation mode for “Back” will then indicate that the previous state needs to be restored.
Microsoft could have just set the navigation mode to “Reactivate” or something similar to avoid every single programming writing the exact same code to determine this.
I’m also trying to deal with the OnNavigatedFrom() function. How to handle this is not so obvious. The navigation mode will be “New” when navigating to another page and will be “Back” when going back and theoretically abandoning this page. The mode is also “New” when going to a page in another app or the home screen. In all of the “new” cases, the state should be saved because we might come back here after reactivation and also from a child page after hitting the back button. Maybe the state should always be saved when this page is “new” in case we ever come “back” here after reactivation. There is no way to anticipate reactivation.
Another Interesting Issue
I find it annoying that a Dictionary can have this added to it and can have things changed in it but that there is no single function to do whichever is appropriate without throwing an exception at me. If I want to add something to a dictionary but also overwrite it if it is already there, I need four lines of code:
if( DictionaryThing.ContainsKey( "thekey" ) ) DictionaryThing["thekey"] = newvalue; else DictionaryThing.Add( "thekey", value );
I’m fairly new to C# so maybe every single programmer is not writing this same code every time they are in this situation. The whole point of a library is to provide programmers with code so that they don’t have to all write the same thing over and over.
I’ll have to look closer at the Dictionary class.