Overview of the Windows Phone 7 Execution Model

Introduction

Not only has Microsoft changed the user interface with the new Windows Phone 7 platform, it has fundamentally redesigned the phone operating system. In this light, it is imperative that developers understand the execution model of the Windows Phone platform so that they develop applications which are responsive to user inputs, and reliable in performance.

What’s New About the Execution Model of the Windows Phone Platform?

Windows Phone prioritizes foreground applications over background applications. As of January 2011, it did not even multi-task so it avoided the state where multiple applications are running causing slowdown in the user experience.

Windows Phone provides consistent navigation experiences across all applications and supported devices. By having a dedicated “Back” button and “Start” button, Microsoft has ensured that users will have zero learning curve when they move across different Windows Phone devices.

The platform ensures dynamic application activation and deactivation as a user switches between applications. Events are raised so that applications can take the necessary steps to preserve and restore context. This ensures a user experience which feels more like an application was restored rather than re-invoked.

Different Stages of the Windows Phone Application Lifecycle

The Windows Phone application has the following stages during its lifecycle:

Launching

An application is considered to be launched when it is invoked from the live tiles via a toast notification, from the phone’s installed application list, or from another application. However, if the application is invoked by clicking on the Back button, it is not considered to be in the “Launching’ state.

In this stage, the “Launching “event is raised. Because this event is raised before UI is rendered, developers should avoid coding any long running activities in the event handler else the application will feel less responsive.

Running

The Running stage is entered after the application exits the Launch stage. In this stage, the only execution-model related task that is permitted is incrementally saving settings and other persisted data. If the application is small this might not be even necessary.

Closing

When the user uses the Back button to navigate past the first page of the application, the closing event is raised. Here it is recommended to save persistent data, such as settings and user data, to isolated storage. There is no merit in saving transient data because once the application is exited, it cannot be restored.

Deactivating

When a running application is replaced by another, the former is said to be deactivated and the deactivated event is raised. The application can be deactivated by a number of actions:

• User presses the Start button
• User phone hits a timeout and the screen locks.
• User invokes a Launcher or Chooser, for example, invoking the camera to take a picture.

In the deactivated event handler, the application should store its current transient state into the static state property of the PhoneApplicationService class and its persistent data to the isolated storage.

Activating

When a user reactivated a deactivated application by clicking the “”Back” button, the application is reactivated and the activated event is fired. In this event handler, the application must restore its state by reading from the state dictionary. Similar to the launching event handler, an application must avoid accessing network resources during this stage, as it will lead to a lesser responsive feeling.

Summary

In this article, we looked at the execution model of the Windows Phone operating system and studied the various events raised at the various stages.