Windows Phone Essentials #1 – Application Lifecycle

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as weel.

I’m starting off with what I believe the most important thing for aspiring Windows Phone developers to understand, the application lifecycle. If you’re coming from a traditional Windows development background (i.e. WPF/Windows Forms) and have no mobile development experience, it’s important for you to understand an application’s execution model on Windows Phone as it is different from what you’ve experienced in the past.

Key Terms

Before we get into the application lifecycle, I want to identify and define five key terms that you’ll need to know. You may think you already know what these terms mean, but I want to ensure we’re on the same page.

Persistent Data - This should be pretty easy to grasp and already familiar to you, but just to clarify, persistent data refers to data that needs to be maintained across sessions of an application. An example of persistent data is settings specified by a user.

Transient Data – Transient data is a concept that should be familiar to you, although you might not call it transient data per se. Transient data refers to data that is associated with a particular session of an application. An example of transient data is information a user is entering into a form.

Page State – Page state refers to how a page looks, or its visual state. This includes text in a textbox, whether or not a menu is expanded or collapsed, etc.

Application State – Application state refers to data associated with an application that is not associated with a specific page. If you’ve used the Model-View-ViewModel pattern, also know as MVVM, you may have created some type of service class to handle messaging between view models in order to maintain a separation of concerns. This service class is associated with the application and not any one page within the application.

Tombstoning – The last, and probably most important, term you’ll need to know is tombstoning. Tombstoning is the term used to refer to the process used by the phone’s OS to deactivate the current application while preserving information about it’s state (i.e. transient data, page state, and application state). This process help users and developers deal with the current lack of multitasking on the phone by providing the ability to navigate “back” to an application and have the application’s state restored to the state it was in when the user left.

Key Classes

Besides terminology, there are a couple of key classes you need to be familiar with in order to understand the lifecycle of a Windows Phone application.

[YourNamespace].App

The first is the App class that gets generated when you create a new Windows Phone Application project in Visual Studio. As you’ll see when you examine the class in your project, it inherits the System.Windows.Application class. It’s the class that provides the entry point for your application. If you’ve worked with WPF and/or Silverlight you’ve already seen this in action. However, before you go off and start coding like might want to, I do want to call out a subtle difference between the Silverlight implementation and the Windows Phone implementation of the System.Windows.Application class.

If you’ve worked with this class in Silverlight, you more than likely have handled the Startup event and examined the StartupEventArgs.InitParams property to do some type of initialization. For example, you may pass in a username or some type of permission list from your ASP.NET web app to your Silverlight application to determine what the user can and can’t do.

While you can certainly handle this event and access the InitParams of the StartupEventArgs in a Windows Phone application, there is currently no way to pass parameters into the application.

PhoneApplicationService

The other class you need to familiarize yourself with is the PhoneApplicationService class that resides in the Microsoft.Phone.Shell namespace. Through its properties and events, this class gives you access to different facets of the lifetime of your application.

Application Lifecycle

Now that we have an understanding of the two key classes involved with the lifecycle of a Windows Phone application, let’s take a look at the actual lifecycle through the various events and methods associated with the classes. Below is a simple diagram of the lifecycle.

Launch

When an application is first launched the constructor of the App class is called. If you take a look at the constructor that gets generated, you’ll see that there’s some event wiring, in the case of debugging there’s some profiling tools that are enabled, and there’s the typical Silverlight call to InitializationComponent().

There’s also a call to a generated method named InitializePhoneApplication(). If you take a look at the method you’ll see that it’s one of those “generated” methods that you really shouldn’t touch. All it does is create a RootFrame for your application while the splash screen is displayed. This RootFrame will eventually become the RootVisual for your application.

Shortly after the InitializePhoneApplication() is called the Launching event of the PhoneApplicationService is raised.

You’ll notice that in your App class an event handler was generated for this event. A quick word of caution here, I advise you NOT to load content from the web or isolated storage in this event handler as it will slow down your application’s start up, and could cause a time out.

After the Launching event is handled, navigation occurs to the RootFrame element that was created as part of the InitializePhoneApplication() method. After the navigation occurs the Navigated event gets fired which is handled by the CompleteInitializePhoneApplication() method. This is another one of those “generated” methods that you should only touch at your own peril. If you take a look at you’ll see that it simply makes the RootFrame the RootVisual for the application, which means your page will then be displayed. At this point your application is considered to be running.

Closed

From a lifecycle perspective, one of two things can happen next. Your application can be closed. For example, if the user press the hardware back button, your application will be closed. When this occurs the Closing event is fired by the PhoneApplicationService class and is handled by the generated Application_Closing method in your App class. You’ll want to make sure to save any PERSISTENT data, that is data that needs to be maintained across sessions of the application in the method before the application completely closes.

Deactivated

Alternatively, your application can be deactivated. Deactivation can be caused by several actions, including the lock screen engaging, the user pressing the home or search hardware buttons, or a launcher or chooser is invoked, for example, the phone’s web browser is launched.

When an application is deactivated, the Deactivated event of the PhoneApplicationService class is fired and handled by the generated Application_Deactivated method in your App class. As with the Application_Closing method, you’ll want to save any TRANSIENT data, data associated with the current session, before the application deactivated completely. However, unlike when an application closes, when an application deactivated, it only has 10 seconds to get through the Application_Deactivated event handler. Failure to complete deactivation in 10 seconds will prevent your application from being tombstoned and cause it to be terminated altogether.

Reactivated

If your application is successfully tombstoned, there’s an additional part of its lifecycle that could occur, reactivation The path that follows during reactivation is similar to when the application was initially launched.

I hope this helps you on your path to becoming a Windows Phone developer. If you want more information on the application lifecycle and execution model for Windows Phone applications you should read this article on MSDN: http://msdn.microsoft.com/en-us/library/ff817008(v=vs.92). It’s full of good information and links to “How To” articles.

Next up in this series I’ll discuss the Windows Phone navigation model.