Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and Few More Things That Are on the Way – Part 2

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.

1. From Visual Studio, start a new debugging session of the simple application we created in the last post.
2. Press the Next button to navigate to the application’s second page.
3. Press the Windows button.
4. The emulator returns to WP Start screen, and in the Visual Studio output window, you should see the following image:

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.

• In the WP emulator, you should see the Start screen, press the Back button (once).
• At this point your emulator screen will go black as if it is waiting for something to happen. Guess what? It is. This is the designed behavior for the current Beta version tools. The screen goes black and the application does not restart as it waits for you to re-attach the debugger so you can continue debugging the application.
• To re-attach the debugger and continue the debug session, switch to Visual Studio and press F5 (or use any other method to start your debugger). The debugger attaches to the correct instance, the emulator continues to activate the application, and the Activated event is raised, as you can see in the following image of the Output window of Visual Studio:

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