Let’s understand the cycle thoroughly.
1. The phone starts with a clean slate. No app is in memory or in dormant state. The user taps a tile and starts Application A .The Application A while going from the Not running state to the Launched state invokes the “launching “event.
2. Now the App is running .Let’s say a call comes .The dialer will come into focus and our app will be shifted to the background. This is called the dormant state. The app is in memory but it’s not working. Suppose, if we have a note taking app, and the user was taking notes and the call comes. After the call, when the user gets back to the app, the unsaved notes will be visible without any special action by the developer.
3. Whenever the app gets deactivated the deactivating event is invoked.
4. So when does it get tombstone? Well Windows Phone currently can have maximum of 6 apps in dormant state. So the moment a seventh app goes to dormant, our app A which was the first to go into dormant state goes into Tombstone state.
5. Tombstones state basically means that your app is no longer taking any system resources .All unsaved data is lost. For example suppose our user was typing a note in the textbox and presses the home key and then goes onto open 6 other applications. First the app will be shifted to dormant and then finally to tombstone.
6. So we don’t need any special code for keeping state during dormancy. But the important part is that we would never know when the app goes from the dormant to the tombstone state. Hence, whenever our app goes to the dormant state, we should think of it as tomb stoning and put data into isolated storage for keeping state.
7. So when the user navigates back to the app by pressing the back key multiple times or long pressing the back key (task manager) .Our app will come to running state from either tombstone state or deactivated state. Both these cases will result in same function to be invoked “Activating”
8. So how do we know whether our app has been brought to life from tombstone or dormancy? That can be done by testing e.IsApplicationInstancePreserved . If it’s coming to life from dormancy, then we do not need to do anything special.
9. There is a third case, the case when our app is dormant, but the user launches your app by tapping on tile. Technically tapping on the tile creates a new instance of your app and that is what is done. The unfortunate case is your existing instance of the app which was in dormant state is silently destroyed. Which means the user loses the unsaved data. The “launching” event is invoked
10. The solution is code redundancy! Well sort of, since in both activating and launching event needs to have some sort of parallel code ,as both would involve getting saved data from local storage .
The recommended practice is to save state data as the data changes. For example, the results of a web request can be saved to disk or the application state dictionary (or both) at the moment it arrives from the network. You should not wait until the Deactivated event occurs to store this data. All application lifecycle events enforce a limit of 10 seconds for an application to complete any tasks.