2. 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 2).
FIGURE 2 Application life cycle.
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.
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.
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.
- A launcher or a chooser is shown.
- The user selects a toast notification, which launches another application.
