With such a long and promising title, this series of posts better be a good one – you’ll be the judge of it. However, the real reason for this long title is rather simple. All these “big” words simply represent different aspects of the execution model. There are a few things that you need to know if you want to maximize your user’s experience. This post explains the Windows Phone (WP) application execution model by taking you step-by-step through the different aspects of launching, running, and closing a Silverlight application. Note that for XNA games the terms and ideas remain the same with some minor implementation differences. In following posts we’ll cover deactivation, reactivation, and how launchers and choosers work with tombstoning.
With the latest Beta release of the Windows Phone developer tools, applications running on WP employ an updated execution model. Now, when your application is removed from the phone foreground (a different application occupies the phone foreground like incoming phone call, or the lock screen being activated), it is actually being terminated (more on this later). In earlier version of the WP tools, you could get into all kinds of strange scenarios if you went from one application to another. That is because in the previous version of the tools, the WP operating system didn’t terminate your application, it “parked” it. However that led to some issues regarding launching a new instance of your application vs. navigating back to the instance on the back stack. Adding to the confusion, the events and API were less than perfect. I guess that is one of the reasons we have technical previews—to test and fix such “issues.”
A Few Ground Rules
Just to make sure we are all on the same page, by now you probably already know that the WP operating system doesn’t allow any 3rd party applications to run in the background. To be more specific, there can be only one application running in the foreground at any given time, and if your application is not running in the foreground, it means that your application is NOT RUNNING. The main reasons for not allowing 3rd party applications to run in the background are to preserve battery life (see Push Notification post) and to ensure a responsive and consistent user experience.
All WP devices feature a hardware Back button. This button allows the user to navigate back in a given application and even between applications. This is a rather cool feature, mainly because unlike other phones, you can navigate from your application to the browser or to another application, and then press Back to seamlessly return to your application. This yields a much more consistent user experience across different applications, whether they are 3rd party applications or part of the phone’s built-in application suite. This also implies that WP operating system is maintaining a journal of you navigation actions to support the Back button functionality. This is also known as the back-stack.
The Basics – Launching, Running, and Closing Applications
It is time to jump into the Windows Phone execution model, and the best way to do this is to start looking at some code. Simply start a new Windows Phone application and look at the auto-generated code of a new WP Silverlight application template, and you will find four new methods in the App.xaml.cs file that are directly related to the execution model:
Application_Launching
Application_Activated
Application_Deactivated
Application_Closing
As a side note, all these events (the functions are the event handlers) are members of the PhoneApplicationService class in the Microsoft.Phone.Shell namespace.
I think the names of these methods are rather self-explanatory, but just to be on the safe side, let’s review them. We’ll address the Activated and Deactivated methods later; for now, let’s focus on the simple events: Launching and Closing. I’ve added a single line of code to each method:
Util is a simple helper class that we’ll use to help us with debugging. The text in each method changes according to the event but you get the idea. I log the time of each event in order to prove a point later when we talk about Activated and Deactivated events.
Running the application in its current state yields the expected result. Upon launching your application the “Launching” method is called. As expected, after that event, your application runs. Press the Back button (not the Windows button) and your application terminates and the “Closing” event is raised, as you can see in the following image (copy of the output window from Visual Studio).
As we said, by pressing the hardware Back button, the navigation model allows the user to “step back,” or navigate backwards through the application pages, and even across applications. However once you reach to the application’s first page (the first page, and its first instance) pressing the Back button raises the Closing event and terminates your application. You can see that from the above image, where it clearly states that the “program” exited. If you are following this post while coding in Visual Studio you will also note that the emulator exits your application and returns to the Start window.
Understanding Activated and Deactivated Events and Tombstone
So far so good, I mean there is nothing new here. However, let’s try the following trick. From Visual Studio, start your application in debug mode (so we can see the traces). As expected, your application starts and you should see the Application Launching trace in the log. Now, instead of pressing the Back button (which if you do, will terminate your application), press the Windows button (the middle button).
You should notice the following:
The emulator returned to the Start screen and your application doesn’t occupy the phone’s foreground, which means it is no longer running!
The debugging session in Visual Studio was terminated. This means that Visual Studio is not debugging your application, which makes sense since the application is no longer running.
Note: At the end, your application gets terminated. That is super easy to see in the Visual Studio Output window, as the last line in the Output windows states, “The program ‘[220921918] taskhost.exe: Managed’ has exited with code 0 (0x0).” No worries, this is by design. However, unlike our previous example, this time the event that followed the Launching event is “Deactivated,” and NOT Closing. But in both cases your application gets terminated (at the end). So what is going here? What is the difference between Closing and Deactivated and more important, why?
Application Closing is simply the outcome of the user pressing the hardware Back button enough times to navigate backwards through the pages of your application, past the application’s first page. Currently, this is the ONLY way for a user to exit your application. Once your application is closed, its process is terminated, and the operating system removes any trace of that application from its memory (RAM).
Application Deactivated occurs when a different application takes control of the foreground – for example, an incoming phone call, launching a chooser, or the user pressing the Windows button. In both cases, your application will be deactivated (not closed). Before we step into the subtleties of the Deactivated event, let’s make sure we all understand that upon Deactivation, your application gets terminated (at the end).It’s that simple; your code can’t run in the background, therefore your application gets terminated. However, unlike an application that is closed, a deactivated application gets tombstoned. Don’t get confused, a tombstoned application’s process still gets terminated. But unlike a closed application, where the WP operating system removes any trace of the application, when an application is deactivated, the WP operating system stores a record (a tombstone) of the application’s state. Basically, the WP operating system keeps a tombstone of the application that becomes part of the phone’s application back-stack, which is a journal that enables the use of the hardware Back button to enhance navigation functionality.
There are several ways in which applications can become tombstoned. An application will be tombstoned and deactivated if:
The user presses the Windows button (as you just did)
The device timeout causes the lock screen to be engaged (again, a different application takes control of the foreground)
The user invokes a Launcher or a Chooser – which we will cover later
In any of these cases, the running application will be deactivated, the Deactivated event is raised, and your application gets terminated shortly afterwards.
At this point in the application life cycle (while your application is tombstoned), a few things can happen. The user might return to a tombstoned application. This can happen if the user completes the chooser or launcher activity and returns to the application, or if the user presses the Back button enough times to return to the tombstoned application. Regardless of how users return to the tombstone application, the application will be reactivated (raising the Activated event) and magically show the last page viewed by the user before the deactivation.
You don’t believe me, let’s try it together. I’ve added a second page to the basic WP Silverlight application, and added a trace to both constructor pages. Next, I added a button to the first page that navigates to the second page.
In Visual Studio, start debugging your application and click the button to navigate to the second page. From the second page, press the Windows button. As expected, your application is deactivated and then terminated, as you can see from the following screen capture of the Visual Studio Output window.
Note the sequence of the trace (and the corresponding time-code). First your application launches, then the main page constructor is called, and after pressing the button on page one, the application navigates to the second page (DetailsPage), after which you press the Windows button raising the Deactivated event, which indicates that your application is tombstoned.
In the next post you’ll learn about returning to a tombstoned application and managing your state between tombstoning.
