Application state is not related to a particular page, we handle the life cycle events launching, deactivated, activated, and closing to perform state saving and restoring operations. These events are raised by the operating system. These are still the same and unchanged. Event handlers are stabbed out by default.
Going back to the Life Cycle Graph that I posted earlier. Remember that the deactivated event is raised before the application goes into Dormant state so this is our last chance to save application data to the phone application services state dictionary which will persist data across deactivation just like it’s Page State counterpart.
Now if and when the application gets reactivated like the user hits the back button, the activated event is raised early on before any page is constructed and so before any pages OnNavigatedTo is called. This is where we get to restore global application state before we handle any page level state.
It’s important to remember that the activated event will be raised on activation whether the application is returning from tombstone or dormant mode.
Here again, if the application was merely put to sleep in dormant mode it was never tombstoned no state restoration is necessary, since the application’s memory image is preserved. And we can test for that with
ApplicationEventArgs.IsApplicationInstancePreserve flag of Deactivated Args parameter that’s passed in to the activated event handler. As the name of property implies, a true value indicates that the application was frozen and preserve in memory and not tombstoned. Finally, in the closing event handler we can save our application’s persistent data if any to permanent storage before the application closes for good.