Select a language to translate this page!
Powered by Microsoft® Translator
In the previous post, you learned about the basics of the Windows Phone execution model. You saw three out of four events. We covered Application Launching, Application Closing, and Application Deactivated. Now it is time to cover the last event, Application Activated. If you want to follow the code shown in this post , you can download the code for the code sample.
How to resume the debugging session of a tombstoned application – Handling the Activated Event?
Remember my promise about the Back button functionality? I'm finally going to come through. However, please read through all 7 of these steps and the following Note before actually trying this yourself.
As you can see, we started a new instance, and therefore the application launching event was raised. Next the application's first page was called (by default) and therefore you see the MainPage trace. When you pressed the Next button, your application navigated to the second page, as you can see from the DetailsPage trace. And finally, when you pressed the Windows key your application was deactivated, again as shown by the trace. The emulator shows the Start screen
Note: Do not close the emulator or make any code change, or else you will start a new instance of your “updated” application, and we don’t want that to happen.
Note: There is a time limit for this process to be successful, as the emulator terminates the application if it takes longer than 10 seconds to reload. Therefore you need to be quick. Also, you should NOT place any breaking points in the Activated event, as Visual Studio will break at the right place, but if you spend too long debugging your code, the emulator thinks that there is something wrong with your application and will terminate it (even if Visual Studio debug session is still active). According to the guidance, your application UI should load within 10 seconds, and since the Activated event is handled before your main page constructor, no UI is shown if you debug and step into the Activated event.
Now that you know what to expect, go ahead and reactivate your application to bring it back to life from its tombstone state by following the steps described above. You will notice that Visual Studio starts a “new session” (because the first instance of the application was terminated). But this time the first trace line is Activated and not Launching, after the Activated event, the next line of debug output shows the DetailsPage CTOR and not the application default first page, MainPage. And if you look at the emulator you will see that your application returned to the correct page, which is the last page you viewed in your application (the second page) before pressing the Windows button.
So there you go, you just experienced firsthand how your application gets tombstoned and then is resurrected.
Note that when your application returns from its tombstone state, it is a new instance of your application, and even so, you will not see the launching event, and therefore you don’t see the Launching trace in the Output window. The Launching and Activated events are mutually exclusive. You should never see both events in the same run of your application’s instance.
A few important things to remember
Launching, Deactivated, Activated, and Closing events are all application level events. They will always get called (unless you remove them from the code – which you MUST NOT DO). If there is any generic workload that your application needs to handle, like loading data from disk or saving data to disk, these events are the right tools for that work (we’ll get to that later).
As you just saw, the application can return from its tombstone state to any one your application’s pages, and therefore you can’t guarantee that one page will load before the other.
The most important thing to remember about tombstoning is that the user may opt NOT to return to your application, and therefore your application may not be reactivated. The user could launch the application again from the Start page (instead of via the Back button), thereby invoking a new instance of the application – Launching event Vs. Activated. Or, the user could launch several other applications, knocking the tombstoned application off of the back of the application stack where it cannot be reached with the Back button. In such a cases, you need to save any data that you wish to restore at a later time. It is completely up to you and your responsibility as a developer to handle the saving and retrieving of data in your application. And that is the subject of our next post. But for now review the following diagram, from the Windows Phone documentation; it should help you understand the relationship between the different events.
By now, you should understand the meaning and functionality of Windows Phone application lifecycle events – Launching, Deactivated, Closing, and Activated. But that is only the beginning as there are additional topics to cover in order to fully understand the execution model and how make the most of it in your application. In the next post, you will learn how to save your page state into a temporary store and when and where in the application to save and load such data.
You can download the code for the sample shown in this blog.
Windows Phone 7 Training Kit for Developers includes a full lab dedicated to the Windows Phone Application Lifecycle.
MSDN documentation includes a topic - Execution Model Overview for Windows Phone
Blog edited by Barbara E. Alban
Thank you for this. Your explanation is crystal clear. Looking forward to the next post on how to save the page state.
Brilliant thanks! Sorry for jumping the gun in the Part 1 comments :)
Is it possible to extend the timeout that the emulator waits for VS to reconnect? Unfortunately, my laptop doesn't support hardware assisted virtualization and so more often than not, the emulator disconnects before the app has even started, never mind after tombstoning.
Crystal clear was the first thing that came to mind for me too. Excellent tutorial!
I think it is more useful to all.
I prefer my friends to read this blog and obtain gain from it.
They also impressed by this site's blog.
Really a excellent site.
<a href="http://www.dirtcheaplaptop.com">Laptop Deals</a>
I do not understand why by pressing the back button the application will be closed and not just tombstoned.
I prefer a consistency by always tombstoning, managing the Closing Event only when the phone is going out of memory, rather than just handle at first just because the user pressed the back button.
I am thinking about this scenario:
1) user open the application from start screen
2) user insert some data
3) user press back to return to the start screen *instead of pressing start*
4) user relaunch the application
5) the inserted data is lost
If I compare the downloadable example code, with the suggestions in the picture above: shouldn't the page state be stored in the PhoneApplicationPage.State (which the picuture says) instead of the PhoneApplicationService.Current.State (which the downloadable code does) ?
Is there a difference in performance or persistence properties ? I assume both are transient ?