Execution Model Overview for Windows Phone
September 23, 2011
The Windows Phone execution model governs the lifecycle 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 allows only one application to run in the foreground at any given time. The operating system puts an application in a dormant state when it is no longer in the foreground. If the device memory available for the foreground application is insufficient for a good user experience, then the operating system will begin to terminate dormant applications, with the least recently used applications terminated first. A programming framework is provided for applications to manage their state as they are deactivated and reactivated. This helps to create a user experience in which applications appear to the user to maintain a single instance, even when they have been terminated and reactivated.
The execution model also 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 in addition to other means, such as tapping on a toast notification associated with an application. 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. Windows Phone 7.5 adds the ability to switch to a previously running application by pressing and holding the hardware Back button.
This topic provides a detailed explanation of the lifecycle of Windows Phone applications and gives you an overview of the steps needed to develop applications that are responsive and provide a consistent navigation experience. After reading this overview, you can find step-by-step instructions, including sample code, in the following topics.
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.
You should become familiar with the following terms and concepts before reading the rest of this overview.
Application State | Data that is used by multiple pages in an application. An example is structured data obtained from a web service. You may want to provide different views of this data on different pages, but the data can be thought of as belonging to the application as a whole. A common misconception is that all application state data should be stored only when the application exits, but it is often a good idea to save this type of data when the user navigates away from a page. This helps to reduce the amount of state management that must be completed while the application is shutting down. |
Page State | The current visual state of a single application page. If you have a page that contains controls for the user to input data, and the user navigates away from your application and then returns to it, the user expects that all of the controls in the form will have the same values as when they left. An application that manages page state sometimes sets the values of the controls on a page when it is loaded so that the user experience is of a persistent application. When the user launches a new instance of the application, the Page UI State should reflect that it is a new instance and not load the UI state from a previous instance of the application. |
Application Events | There are four primary events used for application state management: Launching, Deactivated, Activated, and Closing. Handlers for these events are included in the Application object that is part of the Visual Studio project templates for Windows Phone applications. You will write code in these event handlers to manage your application state.  Important Note:All of the application events have a limit of 10 seconds for the application to complete the tasks in the event handler. If an application exceeds this limit, it will be immediately terminated. For this reason, you should avoid performing resource-intensive tasks, such as reading from and writing to isolated storage within the handlers for the application events. These tasks should be performed on background threads while the application is running, whenever possible. Saving application data as it changes, throughout the lifetime of the application, reduces the amount of state management you need to perform during the application events. |
Page Events | The PhoneApplicationPage object from which all Windows Phone pages inherit exposes two methods, OnNavigatedTo(NavigationEventArgs) and OnNavigatedFrom(NavigationEventArgs), that your application will override to manage page state. |
Tombstoning | The process in which an application is terminated, but some data about the state of the application and the individual pages within the application is preserved. The data that is saved includes the currently displayed application page and the back stack of pages that had previously been visited in the application. If the user navigates back to a tombstoned application, the application is re-created, and the current page and page history are restored automatically. |
State Dictionaries | Each Windows Phone application and application page provides a Dictionary object in which you can store key/value pairs. These dictionaries are preserved when an application is tombstoned. When an application is activated after being tombstoned, these dictionaries are used to restore application state. Note that all data in these dictionaries must be serializable. |
The following image illustrates the lifecycle of a Windows Phone application. In this diagram, the circles are application states. The rectangles show either application- or page-level events where applications should manage their state.
This section discusses all of the elements of the application lifecycle for Windows Phone applications and highlights the actions that an application should take at each step. This section provides background on what the operating system and user do to trigger the various changes in application state. For a simplified checklist of the events and the actions that your application should perform, see Summary of Execution Model Events and Application Actions.
The Launching Event
The Launching event is raised when a new application instance is launched by the user from the installed applications list or from a Tile on Start in addition to other means, such as tapping on a toast notification associated with an application or selecting an application from the Photos Extras menu. When an application is launched this way, it should appear to the user to be a new instance, not a continuation of a previous instance. To help ensure that your application loads quickly, you should execute as little code as possible in the handler for this event. In particular, avoid resource-intensive tasks like file and network operations. You should perform these tasks on a background thread after your application has loaded for the best user experience.
Running
After being launched, an application is running. It continues to run until the user navigates forward, away from the application, or backwards past the first application page. Windows Phone applications should not provide a mechanism for the user to quit or exit. Applications also leave the Running state when the phone’s lock screen engages unless you have disabled application idle detection. For more information, see Idle Detection for Windows Phone.
The OnNavigatedFrom Method
The OnNavigatedFrom(NavigationEventArgs) method is called whenever the user navigates away from an application page. This can happen as the result of normal page navigation within your application. It also is called when the application is deactivated, which is discussed in the next section. Whenever this method is called, your application should store the page state so that it can be restored if the user returns to the page. The exception to this is backward navigation. The NavigationMode property can be used to determine if the navigation is a backward navigation, in which case there is no need to save state because the page will be re-created the next time it is visited.
In some cases, you may want to save state in the OnNavigatingFrom(NavigatingCancelEventArgs) method as well. In particular, you will need to do this to store the state of a MediaElement control.
The Deactivated Event
The Deactivated event is raised when the user navigates forward, away from your application, by pressing the Start button or by launching another application. The Deactivated event is also raised if your application launches a Chooser. For more information about Choosers, see Launchers and Choosers Overview for Windows Phone. This event is also raised if the device’s lock screen is engaged, unless application idle detection is disabled.
In the handler for the Deactivated event, your application should save any application state so that it could be restored at a later time. Windows Phone applications are provided with the State object, which is a dictionary you can use to store application state. If the application is tombstoned and then reactivated, this state dictionary will be populated with the data you saved in Deactivated. Because this data is present in memory, you can use it to restore state without resource-intensive file operations.
It is possible for an application to be completely terminated after Deactivated is called. When an application is terminated, its state dictionary is not preserved. For this reason, you should also store any unsaved state that should be persisted across application instances to isolated storage during the Deactivated event.
Dormant
When the user navigates forward, away from an application, after the Deactivated event is raised, the operating system will attempt to put the application into a dormant state. In this state, all of the application’s threads are stopped and no processing takes place, but the application remains intact in memory. If the application is reactivated from this state, the application does not need to re-create any state, because it has been preserved.
If new applications are launched after an application has been made dormant, and these applications requires more memory than is available to provide a good user experience, the operating system will begin to tombstone dormant applications to free up memory.
Tombstoned
A tombstoned application has been terminated, but information about its navigation state and state dictionaries populated by the application during Deactivated are preserved. The device will maintain tombstoning information for up to five applications at a time. If an application is tombstoned and the user navigates back to the application, it will be relaunched and the application can use the preserved data to restore state. Otherwise, the application is simply terminated.
The Activated Event
The Activated event is called when the user returns to a dormant or tombstoned application. Applications should check the IsApplicationInstancePreserved property of the event args to determine whether the application is returning from being dormant or tombstoned. If IsApplicationInstancePreserved is true, then the application was dormant and state was automatically preserved by the operating system. If it is false, then the application was tombstoned and the application should use the state dictionary to restore application state. Applications should not perform resource-intensive tasks such as loading from isolated storage or a network resource during the Activated event handler because it increase the time it takes for the application to resume. Instead, these operations should be performed on a background thread after the application has loaded.
The OnNavigatedTo Method
The OnNavigatedTo(NavigationEventArgs) method is called when the user navigates to a page. This includes when the application is first launched, when the user navigates between the pages of the application, and when the application is relaunched after being made dormant or tombstoned. In this method, applications should check to see whether the page is a new instance. If it is not, state does not need to be restored. If the page is a new instance, and there is data in the state dictionary for the page, then the data should be used to restore the state of the page’s UI.
The Closing Event
The Closing event is raised when the user navigates backwards past the first page of an application. In this case, the application is terminated and no state is saved. In the Closing event handler, your application can save data that should persist across instances. There is a limit of 10 seconds for applications to complete all application and page navigation events. If this limit is exceeded, the application is terminated. For this reason, it is a good idea to save persistent state throughout the lifetime of the application and avoid having to do large amounts of file I/O in the Closing event handler.
The following table is a brief summary of the events that occur during the application lifecycle and the actions that applications should take for each event.
Event or method | Application action |
|---|---|
Launching event | Execute very little code. Do not do resource-intensive operations like accessing isolated storage. |
OnNavigatedFrom method | If not a backward navigation, save UI state to State dictionary. |
Deactivated event | Save application state to State in case the application is tombstoned. Also, save persistent state to isolated storage in case the application is terminated. Do not destroy the application state in memory in case the application is made dormant. |
Activated event | Check IsApplicationInstancePreserved. If true, do nothing. If false, use data in State to restore application state. |
OnNavigatedTo method | Check whether the page is a new instance. If not, the state is automatically intact. Otherwise, if there is data in State, use it to restore UI. |
Closing event | Save persistent application data to isolated storage. |
| Caution: |
|---|
The events described in this section give you opportunities to save and restore state as your application enters and leaves the foreground. However, 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. Remember that all application lifecycle events enforce a limit of 10 seconds for an application to complete any tasks. |
