Design  HTML

Latest News:

Technology:

Execution Model Overview for Windows Phone

Windows Phone

12/15/2010

The Windows Phone execution model governs the life cycle of applications running on a Windows Phone, from when the application is launched until it is terminated.

The execution model is designed to provide end users with a fast, responsive experience at all times. To achieve this, Windows Phone prioritizes the foreground application and, in most circumstances, terminates all background applications. This eliminates the possibility of users getting their device into a state where multiple applications are running in the background, causing the application in the foreground to become sluggish.

In addition to responsiveness, the execution model provides users with a consistent navigation experience between applications. On Windows Phone, users navigate forward by launching applications from the installed applications list or from a tile on Start. Users can also navigate backwards, through the pages of a running application, or through the stack of previously running applications by using the hardware Back button.

To enable seamless navigation by limiting the phone to run one application at a time, Windows Phone activates and deactivates applications dynamically, raising events for applications to respond to when their state changes. By implementing handlers for these events, developers can save and restore application state as their application transitions between active and inactive states. This behavior creates an experience in which it seems to the user like the application continued to run in the background. This topic will explain, in detail, the life cycle of a Windows Phone application and describe the strategies that developers can use to take advantage of the execution model events.

Although the operating system manages the execution of all applications in the same way, handling application interruptions in XNA games requires some special consideration. If you are creating an XNA-based application, you should read this section and also read the document, Tombstoning for Windows Phone 7 Games.

Terminology

This section lists some of the terms that are used to describe the Windows Phone execution model.

Term

Definition

Tombstoning

The procedure in which the operating system terminates an application’s process when the user navigates away from the application. The operating system maintains state information about the application. If the user navigates back to the application, the operating system restarts the application process and passes the state data back to the application.

Page state

The visual state of an application page. This includes such things as the scroll position of a ScrollViewer control and the contents of TextBox controls. Manage page state in the OnNavigatedTo and OnNavigatedFrom event handlers.

Application state

The state of the application that is not associated with a specific page. Application state is managed in the events exposed by the PhoneApplicationService class.

Persistent data

Data that is shared by all instances of an application. Persistent data is saved and loaded from isolated storage. Application settings are an example of persistent data that should be preserved between application executions.

Transient state

Data that describes the state of a single instance of an application. Transient data is stored in the State dictionary provided by the PhoneApplicationService class. A tombstoned application restores its transient state when it is activated. An example of transient state is the data returned by a Web service query. This can be stored when an application is tombstoned to reduce the need to perform the query again if the user quickly returns to the application.
Walkthrough of the Life Cycle of an Application

This section will walk through the entire life cycle of a Windows Phone application, describing the user actions that will cause the state of an application to change, and highlighting the events that developers should handle in their code to create a consistent experience for users. All of the life cycle-related events mentioned in this section are members of the PhoneApplicationService class in the Microsoft.Phone.Shell namespace. The Windows Phone project templates provided with Windows Phone Developer Tools include stubbed out handlers for these events in the project’s App.xaml.cs file.

Launching

A Windows Phone application is considered to be “launched” when it is started by a means other than by the user pressing the Back button to return to a previous application. An application is launched when the user taps the entry for the application in the phone’s installed applications list or the tile for the application on Start. An application can be launched in other ways as well, such as when the user taps a toast notification. Whenever the user launches an application using one of these methods, a new instance of the application is created. When the application is started, the Launching event is raised. Applications should not load state data from Isolated Storage in the handler for this event. Because this event is raised before the application is visible or active, performing time consuming tasks, like accessing Isolated Storage can provide a bad user experience as the application will take a long time to load. Instead, calls to Isolated Storage and network resources should be performed asynchronously after the application has loaded. When an application is launched, applications should not attempt to restore transient state from a previous application instance. When a user launches an application, it should always appear to be a new instance.

Running

After the Launching event is handled, an application starts running. While an application is in this state, it manages its own state as the user navigates through the application’s pages. The only execution model-related task that an application may perform during this state is to incrementally save settings and other persisted data to reduce the amount of data that needs to be saved when the application’s state changes. This is optional, and for applications with a small amount of persisted data, may be unnecessary.

Closing

The application state that follows the running state depends on the actions that the user takes. One possibility is that the user presses the hardware Back button to navigate backwards through the pages of the application, past the application’s first page. When this occurs, the Closing event is raised and the application is terminated. Within the handler for this event, an application should save persistent data to isolated storage. It is not necessary to save transient state data, data related only to the current instance of the application, because the only way for the user to return to the application after it is terminated is to launch it again, and as mentioned in the previous section, applications should appear to be fresh instances when the user launches them.

Deactivating

If an application is running and is subsequently replaced in the foreground by another application or experience, the first application will be deactivated. There are several ways in which this state can be invoked. An application will be deactivated if the user presses the Start button or if the device timeout causes the lock screen to be engaged. An application may also be deactivated when it invokes a Launcher or a Chooser, helper applications that allow the user to perform common tasks such as taking a picture or sending an email. In any of these cases, the running application will be deactivated and the Deactivated event is raised. Unlike an application that is terminated, a deactivated application may become tombstoned. This means that it is no longer running, but the operating system keeps a record of the application and stores a set of state data for the application. It is possible that the user will return to a tombstoned application, at which point it will be reactivated.

In the Deactivated event handler, an application should store information about its current state in the dictionary that is exposed through the State property of the PhoneApplicationService class. The data that is stored in this dictionary is transient state data, or data that will help the application reestablish the state of the application before it was deactivated. Because there is no guarantee that a tombstoned application will ever be reactivated, an application should also save persistent data to isolated storage during this event. All of the actions taken in the deactivated event handler must be completed within ten seconds, or the operating system will terminate the application. This is why applications with large quantities of persisted data may want to save incrementally as the application is running.

It is possible for an application to be deactivated without being tombstoned. For example, if the user presses the Start button and then the Back button in rapid succession. For this reason, it is important not to do anything destructive in the Deactivated event handler. Your application should be able to continue after completing the Deactivated event handler without the Activated handler being called.

Activating

After an application has been deactivated and tombstoned, it is possible that it will never be reactivated. The user could launch the application again from Start, invoking a new instance of the application. 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. It is also possible that the user will return to the application. This could happen if the user presses the Back button until the application is reached. Or, if a Launcher or Chooser was the cause of the deactivation, the user could complete the task or cancel out of it. When the user returns to a tombstoned application, it is reactivated and the Activated event is raised. In this event, an application can read values from the State dictionary in the PhoneApplicationService class to reestablish the state of the application that the user experienced before the application was deactivated. Like the Launching handler, applications should not access network resource or Isolated Storage within this event handler. Doing so will cause the application to launch slowly.

The following diagram illustrates the application life cycle for Windows Phone applications.

Ff817008.5e84773d-ae0d-43b8-a956-ffdac77b2922(en-us,VS.92).png

What Causes an Application To Be Tombstoned?

This section lists all of the actions that can cause an application to be deactivated and tombstoned.

User Actions

The following user actions may cause an application to be deactivated and tombstoned.

  • The user navigates away from your application by pressing the Start button.

  • The user stops interacting with the application and the phone’s lock screen engages. This behavior can be modified. For more information, see Idle Detection for Windows Phone.

Launchers and Choosers That Typically Do Not Cause an Application to be Tombstoned

In order to improve performance around several common user scenarios, the following Launchers and Choosers will typically not cause your application to be tombstoned. However, it is still possible that your application will be tombstoned when using these, so your application should be designed to handle this possibility.

Skip Navigation Links
© 2024 LiquidCreations.MediaCenter