Life Cycle Events
,The Microsoft.Phone.Shell.PhoneApplicationService exposes four life cycle related CLR events, which provide an application with the opportunity to save or load state (see Figure 3.2).
Launching Event
When a user selects an application from the App List screen, or from a tile on the Start Experience, or when the application is being debugged, the application moves from the stopped state, to the running state. This represents a cold start. Use the Launching event to restore any persistent state from isolated storage that is not page specific. This event occurs after the App class is instantiated, but before the main page of an application is created.
Note
The Windows Phone Certification Requirements state that an application must render the first screen within 5 seconds after launch and activation, and be fully responsive within 20 seconds. A splash screen can be used to offset startup delay. Later in this chapter you see how to create a splash screen for an application.
The Launching and Activated events are mutually exclusive. That is, exactly one of these two events occurs when the application is being started. Likewise, the Deactivated and Closing events are also mutually exclusive; only one of these events occurs when the application is exiting.
Subscribing to Life Cycle Events Using the PhoneApplicationService
The PhoneApplicationService allows your app to be notified of the various life cycle events. The PhoneApplicationService is, by default, initialized in XAML by the application’s App instance, as shown in the following example:
<Application.ApplicationLifetimeObjects>
<!--Required object that handles lifetime events for the application-->
<shell:PhoneApplicationService
Launching="Application_Launching" Closing="Application_Closing"
Activated="Application_Activated" Deactivated="Application_Deactivated"/>
</Application.ApplicationLifetimeObjects>
The PhoneApplicationService is a singleton class, which exposes an instance of the class via a static property called Current. Code to handle the Launching, Closing, Activated, and Deactivated events can be placed in the App class, for which handlers are created when a new project is created, or directly in code by using the Current property of the PhoneApplicationService.
Note
Subscription to the PhoneApplicationService.Activated event must occur via the App class. If subscription to the event occurs in a UI element, the handler is not called. This is because the PhoneApplicationService itself subscribes to the System.Windows.Application.Current’s Startup event. When the application raises the Startup event, the PhoneApplicationService notifies the operating system that it is ready to receive execution model events (that is, Launching, Closing, Activated, and Deactivated). This causes the PhoneApplicationService.Activated event (or the Launched event in the case of a non-tombstoned application) to occur almost immediately. Therefore, subscription to the event after this point has no effect. Moreover, event subscription is lost when an application is tombstoned; the application has, after all, terminated at that point. Thus, subscription to the Activated or Launching events from, for example, the MainPage constructor, occurs after the event has already been raised.
There may be times when it is tempting to promote certain kinds of transient state to persistent state. When launching your app, however, the user should feel like he is not resuming your app, but rather that it is indeed a new instance, a clean slate.
Persistent state is stored in isolated storage, while transient state is stored in the PhoneApplicationService.State dictionary, which is an IDictionary<string, object> that is maintained while the application is tombstoned. The dictionary is abandoned when the application moves from the tombstoned state to the not running state.
Deactivation Event and Tombstoning
On entering the running state, an application must contend with being interrupted. Each interruption causes the PhoneApplicationService.Deactivated event to be raised. The app is then placed in a dormant state, where it remains in memory but its threads are suspended.
If an app is reactivated after being in the dormant state, there is no need for your app to restore its transient state, reducing its load time.
Detecting whether an app is returning from a dormant state can be achieved within the PhoneApplicationService.Activated event handler using the IsApplicationInstancePreserved property of the ActivatedEventArgs, as shown in the following excerpt:
void Application_Activated(object sender, ActivatedEventArgs e)
{
if (e.IsApplicationInstancePreserved)
{
/* Application was placed in the dormant state. */
}
else
{
/* Application state should be restored manually. */
}
}
When the device’s memory usage reaches a minimum threshold, the operating system may decide to tombstone your app.
Note
When an application is tombstoned, it is terminated.
When tombstoned, the operating system is aware that the application may be reactivated. If an application moves from being tombstoned back to the running state, it will be from a cold start, and all objects must be instantiated and persistent and transient state needs to be restored. The only differences between the tombstoned state and the closed state are that when tombstoned, the operating system retains the transient state dictionary for the app along with an identifier for the app, so that if activated, chooser and launcher events can be resubscribed. Launchers and choosers perform common tasks, such as sending email. You learn more about choosers and launchers in Chapter 14, “Leveraging Built-In Apps via Launchers and Choosers.”
An application is deactivated when it is no longer the foreground application. The following is a list of causes for deactivation:
The user presses the start button.
The phone’s lock screen is engaged without having enabled running under the lock screen. Enabling your app to run under the lock screen is discussed in the section “Running Under the Lock Screen” later in the chapter.
A launcher or a chooser is shown.
The user selects a toast notification, which launches another application.