Windows Phone 7 Process Life cycle

What was made clear at Mix’10 was that third party apps in Windows Phone 7 wont be able to multi task. The reason provided was that too many apps running in the background may make the app in foreground run slowly. Once an user sees that s/he will definitely say that “Windows Phone 7 Sucks!, It is very slow and sluggish”.

Well what If we say that we will need multi tasking and will use it judiciously? well AFAIK, not Third party app multi tasking will be available in V1 ( Not sure , if MSFT intends to publish an OTA update to add multi tasking later )

With Windows phone 7, what MSFT promised was no  sluggish interfaces and apps that consume various data service and provide all the information you need in one place. And Frankly speaking off, they have done a decent job.

So, No Multi tasking, What does that mean for us developers?

Well in order to answer this question, we need to understand how an app will live on the phone ( the Windows Phone off course )

When the app is Launched:

The app that you , me and many more developers will write will need to be launched from either the start experience or application list. When we do this, (from the programmer’s perspective) , a new instance of our application is created.  Well this does mean that we do get to write event handlers for events such as application launched etc..

However anywhere in the app, when the user presses the Start Button and/or triggers a Launcher or a chooser ( such as ‘”send an SMS” , “send an email”) etc, Your app’s state is saved and your app is put to sleep.

This process is called as “Tombstoning”

Following are the main events that we can use in our app to make our app feel as if it were really running in the background

1. Launching Event

When the app is launched, the Launching Event is fired. we can use this event, (usually an empty method pre written for you in app.xaml.cs) which we can use to instantiate stuff from the isolated storage. For e.g. , say you have an app that depends on some XML files that you need to read when the app launches, this is the event for you!, Write the code in the launching event

2. Closing Event

When the user clicks navigates through the app, a stack of page navigation is maintained. When the user hits the back button, the user is taken to previous screen.

Now when the user keep on hitting back button through the first page of the app. The app gets terminated and the closing event is fired. You can now write some app level data that you wish to persist, to the phone’s isolated storage.

3. Activated Event

Your app can be in the foreground or can be replaced with some app in foreground on some Launcher (such as send an email, call etc..). This is when the app is tombstoned and it also becomes possible that the app might not get activated again. The user can open many such apps,knocking off your app from the application stack ( the back button relies on the application stack to take you to a page in the current app or some page in previous app you had launched.) If the user were to launch the app from the start screen, it would create a new instance of the app

Now it is also possible that the user can reactivate your app by pressing the back button and coming to your app or even after the launcher completes. This is when your app is activated again. The Activated Event is fired when your app is activated after , say you complete a phone call when you were using the app . This is a good place where you can reload data you had stored in persistent store ( such as textbox data ,selected item etc . If you intend to store data entered in textboxes and you want to persist it )

4. Deactivated Event.

If an application is running and is subsequently replaced in the foreground by another application or experience, the first application will be deactivated. There are several ways in which this state can be invoked. An application will be deactivated if the user presses the Start button or if the device timeout causes the lock screen to be engaged. An application will also be deactivated when it invokes a Launcher or a Chooser, helper applications that allow the user to perform common tasks such as taking a picture or sending an email. In any of these cases, the running application will be deactivated and the Deactivated event is raised.

 

// Code to execute when the application is launching (e.g., from Start)

// This code will not execute when the application is reactivated

private void Application_Launching(object sender, LaunchingEventArgs e)
{
  //Get Data from Isolated Storage or a web service etc...
  System.Diagnostics.Debug.WriteLine("In Application_Launching event"+
     "... Nice Place to Initialize your app");
}

// Code to execute when the application is activated (brought to foreground)
// This code will not execute when the application is first launched
private void Application_Activated(object sender, ActivatedEventArgs e)
{
   System.Diagnostics.Debug.WriteLine("And We are back!!");
}

// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
   System.Diagnostics.Debug.WriteLine("Go to sleep...zzz");
}

// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
   System.Diagnostics.Debug.WriteLine("goodbye cruel world.");
}

 

Hope this blog post helps you understand the Windows Phone 7 app lifecycle.

I will try and cover many more details in further posts as and how I discover them

Thanks for your support. I will be back with my next post in a few days