The Windows Phone 7.1 application lifecycle has been designed in a way that it can run multiple applications in the background. Today we will discuss about the Lifecycle of Windows Phone 7 (Mango) apps.
Here we will learn about various states of Windows Phone 7 application life cycle. This is an important chapter of the tutorial series to learn about the execution model before developing any application product. Read to know more about this topic and at the end don't hesitate to leave your feedback or queries if any.
Index - Windows Phone 7 (Mango) Tutorial
There are some terminologies available to describe the Application Lifecycle of a Windows Phone 7. It consists of the following things:
- Running State
- Closed State
- Deactivated State
- Reactivated State
Once a Windows Phone Application starts, that is called as "Launch State". It fires the launching event. Then it enters into the "Running State". While in running mode, it actually executes the program. After that, there is a possibility by the user to close the application, continue running in the foreground or start a different application and push the existing application to the background. While pushing the app to the background, you can set it's state to a dormant state where the app got deactivated and when you come back to the dormant application at a later point of time, it got activated and continue running where it was left at that time.
The below diagram will define the Application Lifecycle of a Windows Phone 7.1 (Mango) application:
Hope the above diagram gave you the basic understanding of the lifecycle. Let us describe each one of those states in depth.
This is the first stage when a new application instance loads into the memory. If you are familiar with Silverlight or WPF, you might know that, when an application launches it loads the App class first and executes. The launching operation executes as mentioned below:
- In Windows Phone 7 application, the constructor of the App class executes first.
- The constructor has two method calls. The first one InitializeComponent() initializes all the controls, then it calls InitializePhoneApplication() method. Inside this method, it creates the frame called "RootFrame" for your application. This RootFrame will become the RootVisual for your app. This allows the splash screen to remain active until the application is ready to render.
- Then it raises the PhoneApplicationService.Launching event just after the initialization of the Phone application, forwards to App.Application_Launching.
- Finally it moves towards Navigation event called App.CompleteInitializePhoneApplication. There it actually sets the root visual to allow the application to render.
You can find the sequence of Application Launch diagram here:
After the launch state, your application enters into running mode. There you can use your application and interact with it. While in running mode, your application may go to two different stage. User may close the application and at that time it will go to Closed state. User may place the currently running application in the background and open another application. In that case, the application will be deactivated.
Once you close your application it goes to the close state. While entering into the close state, it first calls the PhoneApplicationService.Closing event which has been handled by the App.Application_Closing and closes the application. Here is the flow diagram of the closing event:
As I mentioned, if user sends the application to background and open a different application, the first application enters into deactivated mode. While going to this stage, it fires the PhoneApplicationService.Deactivated event and then it handles by the App class. The App.Application_Deactivated event executes before the application completely deactivates from the running stage.
Here is the deactivating flow of any Windows Phone 7 application:
Reactivation is similar to the process when the application was first time launch but it has a little differences than the first initialization. Here is the complete flow of the same:
- App class again initializes and calls the constructor App()
- The App.InitializePhoneApplication() method again called to create the RootFrame once again
- Then instead of calling the PhoneApplicationService.Launching event, it actually calls the event called PhoneApplicationService.Activated.
- This handled by the App.Application_Activated method. During this process it resumes the loading data from the session state.
- Finally it enters into the App.CompleteInitializePhoneApplication and loads the RootVisual from the RootFrame and starts rendering the view.
Here is the complete reactivation process:
Let's just summarize the content discussed here. When you are loading your application for the first time, it enters into the Launch state and once you completely launched, it enters into the Running mode. A user may deactivate the running application or close the application. While the app is in the background or running under the lock screen, it is called as deactivated and when the user closes the app from running state, that is called as Closed state. Once the user closes the application, he can enter into running mode again by launching the application by initializing it completely. If the user wants to reactivate the application, he can open the deactivated app and it enters into the reactivated process and continues running.
This is the Application Lifecycle of a Windows Phone 7 App. Hope, this helped you to understand the application lifecycle. In coming days, I will show this with an example and at that time, it will be more clear for you to understand.
Thanks for your time to read the chapter of the series. Please drop a line below with your valuable feedback about this tutorial series. I am also available in Twitter. You can reach me on Twitter @kunal2383.