How to avoid saving and restoring navigation history

Feb 17, 2014 at 4:41 AM

is there a way to avoid saving and restoring navigation history when the app suspends and resumes?
When my app resumes, I would like always to start from the main page, as it does when launching for the first time.

Is it possible?
Feb 19, 2014 at 5:04 PM

Based on my understanding, you would want to clear the navigation history after Suspending in order to start then again like the first time.

Therefore, in order to clear the navigation history and load from the Main Page you can use the ClearHistory() method declared in FrameNavigationService.cs and call to it before processing the Suspending command. This way, you would suspend the App without any Navigation history registered.

One way of doing this would be to change the OnSuspending() command handler in the MVVMAppBase implementation from the Prism for Windows Runtime library as follows:
private async void OnSuspending(object sender, SuspendingEventArgs e)
     NavigationService.Navigate("MainPage", null);
     IsSuspending = true;
     { ...
Please notice that Suspending the App saves its state but the App remains open and freezed in background. That would be the reason why a Navigate() call is required in order to go to the Main Page after clearing the history. Otherwise, the App would resume on the current Page where it was Suspended with an inconsistent state as you already erased the navigation history.
In addition, I would like to add that those 2 lines were added at the begginning of the OnSuspending() method because the IsSuspending boolean conditions Navigation so it would not appear any consistency while saving Suspend information.

This solution would behave equally with Suspending and Suspending and Shutdown commands.

I hope this helped you,

Gabriel Ostrowsky.
Feb 23, 2014 at 9:55 AM

I'll try your solution.

Instead, If I want to save and restore state when app suspends and resumes, I have to annotate viewmodel properties with RestorableState attribute, as written in the documentation. Also, if I remember well, I have to register types involved in serialization overriding OnRegisterKnownTypesForSerialization.

In LOB applications, viewmodels can be very complex and typically we want to save the entire viewmodel when the app suspends and restore it when app resumes.

What about automatically save and restore the entire viewmodel without having to annotate properties with RestorableState attribute?
I think it would be great if Prism framework manages suspension automatically so developers don't have to worry about it and test each app page for suspension.

What do you think?
Feb 27, 2014 at 4:51 PM

The requirements that you described for properly saving the App state would be correct. And based on my understanding, Prism would not be able to know how each ViewModel would be expected to save its state as this behavior would depend on the App features.

In addition, it may exists autocalculated properties or some private ones that would not be expected to save its state because they would get their corresponding value when interacting with some other elements.

If you would like to save the state of all ViewModel's properties, you could also modify the ViewModel class or create your custom one in order to not validate the properties list having the RestorableStateAtrribute defined, on the FillStateDictionary() and RestoreViewModel() methods. Therefore, those methods would iterate through all ViewModel's properties without having to declare the RestorableStateAttribute atrribute on each of them.

Anyway, if you would think that the automatic save and restore should be provided by Prism without the need of using RestorableState attributes you could create an item in the Issues section of this site so the P&P Team would look into your feedback.


Gabriel Ostrowsky.