Windows Phone Tutorial

Windows Phone 7: Application Life Cycle

Tombstoning, page state, dormant and tombstoned states — how the Windows Phone execution model keeps apps feeling multitasked.

Given that "there can be only one" application running at a time, creating multitasking on mobile devices presents real challenges. Multiple pathways exist for users to enter and exit software. Navigation can span across multiple apps, and users may return to previous applications via the back button stack. Various events impact program lifecycle — some actions suspend software while others terminate it definitively.

For example, an incoming call interrupts a game, halting it temporarily. When the call ends, the user expects to resume from where they left off rather than restart from the beginning.

Windows Phone's execution model provides a complete cycle for managing application state, designed to deliver fast and responsive experiences. Key terminology:

  1. Tombstoning — The OS deactivates apps when users trigger close events or higher-priority services (like incoming calls) request to start. The operating system saves the app's state when it's deactivated, to be used when the user restarts the application.

  2. Page State — The current visual state of a single page. If you have a page that contains controls for user input, and the user navigates away from your application and then returns, they expect all controls to have the same values as when they left. Managed via the OnNavigatedTo and OnNavigatedFrom methods.

  3. Application State — Data used by multiple pages in an application, e.g. structured data obtained from a web service. Managed using the PhoneApplicationService class.

  4. Persistent Data — Information stored in isolated storage and maintained across application sessions. Application settings are an example.

  5. Transient State — Data used during application initialization, stored in state dictionaries provided by PhoneApplicationService. Tombstoned applications restore this data upon reactivation.

The Life Cycle

Execution Model Diagram for Windows Phone 7.5

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. The application should appear new, not as a continuation. Execute minimal code; defer resource-intensive tasks like file and network operations to background threads after loading.

Running

After launching, the application runs until users navigate away or backward past the first page. The lock screen also exits this state unless idle detection is disabled. Windows Phone applications should not provide a mechanism for the user to quit or exit.

The OnNavigatedFrom Method

Called when users navigate away from a page — through normal navigation or application deactivation. 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. Exception: backward navigation doesn't require state saving as the page will be recreated. Use the NavigationMode property to detect backward navigation.

The Deactivated Event

Raised when users navigate forward away from the application, press Start, or launch another app. Also triggered when launching Choosers.

In the handler for the Deactivated event, your application should save any application state so it can be restored later. Use the State object (a dictionary) for this purpose. If the application is tombstoned and then reactivated, this state dictionary will be populated with the data you saved in Deactivated.

Applications may terminate after deactivation, losing the state dictionary. Therefore, you should also store any unsaved state that should persist across application instances to isolated storage during the Deactivated event.

Dormant

After deactivation, the OS attempts to place the application in dormant state: all of the application's threads are stopped and no processing takes place, but the application remains intact in memory. Reactivation requires no state recreation since it's preserved.

When new applications launch requiring more memory, the OS tombstones dormant applications to free resources.

Tombstoned

A terminated application with preserved navigation state and state dictionaries. The device maintains tombstoning information for up to five applications at a time. Upon user return, the application relaunches and can restore state from preserved data.

The Activated Event

Called when users return to dormant or tombstoned applications. Check the IsApplicationInstancePreserved property: true indicates dormancy (state automatically preserved), false indicates tombstoning (restore from the state dictionary).

Applications should not perform resource-intensive tasks such as loading from isolated storage or a network resource during the Activated event handler because it increases the time it takes for the application to resume. Execute these operations on background threads.

The OnNavigatedTo Method

Called when the user navigates to a page — including first launch, page-to-page navigation, and relaunch after dormancy or tombstoning. Check whether the page is a new instance; if not, skip restoration. For new instances with state dictionary data, restore the page's UI state.

The Closing Event

The Closing event is raised when the user navigates backwards past the first page of an application. The application terminates without state saving. Use this handler to preserve data across instances.

Important constraint: there is a limit of 10 seconds for applications to complete all application and page navigation events. Exceed this and the application terminates. Save persistent state throughout the application lifetime to avoid large file I/O operations during closing.

See also: Windows Phone: Handling the Lifecycle at Two Levels.