Activation and deactivation best practices for Windows Phone 8

[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]

Windows Phone applications are potentially terminated when the user navigates away from them. For an overview of the lifecycle of applications, see App activation and deactivation for Windows Phone 8.

This topic highlights some best practices for handling execution model events.

Best Practices

• Ensure that when your application is launched by the user from Start or the installed applications list, the user is taken to a consistent launch experience. It should be evident to the user that they are experiencing a new application instance.

  When the user launches a new instance of your application, it is acceptable to present the user with some information about a previous instance, for example, a list of recently opened documents, but the user should not feel like they are continuing a previous session.

• Ensure that when your application is activated by the user returning to a previously running application, the user is taken to an experience that is consistent with the one that was shown when the application was deactivated. It should not be evident to the user that the application was terminated and restarted.

• Some Windows Phone features provide a mechanism for the user to launch the application in a way that passes contextual information to the launched application. For example, ShellToast, Reminder, and ShellTile all expose a NavigationUri parameter on which query strings can be passed, and the MediaHistoryItem class has a PlayerContext property that can pass contextual information. The application should display content appropriate to the context when launched using one of these mechanisms.

• Use the State property of the PhoneApplicationService class to store transient application state in the Deactivated event handler and to retrieve application state in the Activated handler.

• Use the State property of the PhoneApplicationPage class to store transient page state in the OnNavigatedFrom event handler and to retrieve page state in the OnNavigatedTo event handler.

• After an application has been tombstoned, the user may not return to the application. For this reason, you should save persistent state to isolated storage both in the Deactivated event handler and in the Closing event handler. To avoid duplicating code, you may want to create a single method that saves persistent data to isolated storage and call the same method from both event handlers.

• Applications must complete all of the application event handlers, such as Activated and Deactivated, and the page navigation methods, such as OnNavigatedTo and OnNavigatedFrom in less than 10 seconds. If an application takes longer than 10 seconds to complete any of these events, the application is terminated.

• If an application relies on data from isolated storage, you should not load this data in the Launching event handler or in the Activated event handler. Disk operations can take several seconds and these events are called before the application is loaded and active, so accessing isolated storage in these handlers results in a long wait time while the application loads. Instead, you should load data from isolated storage asynchronously, after the application has loaded.

  It may be necessary to write data to isolated storage in the Deactivated and Closing event handlers, but due to the 10-second maximum time for these event handlers to complete, we recommend that your application save incrementally while it runs to minimize the amount of data that must be saved during these events.

• If your app is terminated by the operating system while it is not in the foreground, the Closing event will not be raised. Your app can rely on receiving the Deactivated event, but not Closing. For this reason, you should perform all essential cleanup and state maintenance tasks in the Deactivated event handler.

• Your app can’t rely on the Exit event being raised when your app exits. You should handle app cleanup in the Deactivated event.

• Applications can be preserved in a dormant state and then returned to a running state without being tombstoned. Make sure that you do not destroy the in-memory state of your application when it is deactivated.

• Invoking a Launcher or Chooser will always deactivate your application and may cause your application to be tombstoned. To ensure that your application receives the result of the Chooser task when your application is reactivated, the Chooser object must be declared with a global scope within the PhoneApplicationPage class and you must initialize the Chooser and assign the Completed event delegate in the PhoneApplicationPage constructor.

• Handlers for the PhoneApplicationService events are stubbed out in the default Windows Phone application project template included with Windows Phone SDK. They can be found in the App.xaml.cs file.

• An instance of the PhoneApplicationService class is provided by the default Windows Phone application project template. Access the State dictionary of this class from your application using the following code.

  private void Application_Deactivated(object sender, DeactivatedEventArgs e)
  {
      PhoneApplicationService.Current.State["key"] = "value";
  }
  

• Any data that you store in the State dictionary must be serializable, either directly or by using data contracts. For more information, see Using Data Contracts.

Execution Model Considerations for Individual Phone Features