I was wondering when is more appropriate to save the view model of the single pages.
I see two possibilities:
- Save the state of each page (it's viewmodel) everytime you navagitefrom it so that it is already saved if the application happens to be terminated and reactivated during the tombstoning process
- In the application deactivated event, go through all the pages that are in the navigation stack and save their state (their viewmodel) and then re-inject it in the application activated event.
Which is the correct way of handling it?
Thx
Simone
Unfortunately the "best" time to save the state will depend on: the application; the complexity of the models used by each page; the interaction that each page supports; and the complexity of models shared between pages (at the app level).
As a general rule I try and have a single model at the application level and persist that on activation/deactivation. The model for a page is a reference to part of the app level model and I only persist page specific information on navigation from/to a page.
Examples of page specific information I persist are: entered but unsaved data; and scroll positions.
I suppose it depends on your needs, but it's unlikely you need to stray from the documentation, which suggests the application deactivated event as the appropriate place to save persistent and transient (state) data, while close should only save persistent.
Execution Model Overview (see the control flow diagram under Activating)
This article also gives a decent explanation with examples of the app lifecycle and tombstoning, differentiating between backing out/closing, deactivating, and tombstoning.
You can't anticipate when a user will change the foreground app between page changes. You can, however, anticipate what will happen when closing or deactivating. Therefore, saving your page state between views seems extraneous.
I can't vote up the previous answer because I don't have sufficient "reputation", but yes any transient state information should be persisted in the Application.Deactivated event and then restored in the Application.Activated event for tombstoning support.
If you need to store anything between application sessions then you could use the Application.Closing event, but depending on what you need to store, you could just store it whenever it changes. Again, depending on what you need to store, you can either restore it in the Application.Launching event, or just read it when you need it.
This is something I have given some thought to as well.
I've generalised my view of it to this.
Save as early as you can.
What this means is, short of any other imperatives, which motivate you to defer your save, do your save at the earliest available opportunity. You might save directly to your main store, or you might save to transient state specifically for handling tombstoning. You might save in the background while the page is open. You might save when the user requests to navigate between pages.
In situations where something unexpected can occur, such as loss of power, an exception requiring the users attention (noting no time for this if being deactivated), saving early offers a bit more dependendability to the user.
Imperatives that might motivate you to defer saving, could include
- Depending on your architecture, it may be inconvenient to implement saving data at a page level.
- Depending on the volume of data to be saved, and the architecture of your isolated storage model, it may detract from performance substantially trying to save at a page or field level.
