Windows Phone 7: Application Lifecycle
This week's release of Windows Phone 7 has boosted my enthusiasm to develop for the platform. If you're a student you may want to do the same - especially as it's free, for you, thanks to Microsoft's Dreamspark. You can put up to 5 free applications on the Windows Phone Marketplace and start making a name for yourself; at no cost.
What Microsoft are doing with WP7 seems to be great and well thought out. People want responsive, feature rich devices. Developers want to be able to utilise all of the platform, without having to worry about what the user is running. The way running in the background is (or isn't) handled is better than I initially thought. WP7 allows developers to have a near guaranteed set of resources for their application, which allows feature and graphically rich applications to run at full tilt while preserve battery life.
This, however, means as a developer you need to be aware of these interruptions and how you want to handle them in your application. The file that these methods are stored in is App.xaml.cs. Inside this there are 4 methods to utilise, however, first let's take a look at the application life-cycle for WP7. There are a number of states that an application can go through so here's a diagram (click for full size):
A little tricky at first glance, but with a bit of explanation it's fairly simple. The top row is essentially a run-to-exit flow of processes. From the running state it becomes a little more interesting. An application can be deactivated in a number of ways; text message, phone call, user hitting start, user searching. Unless you're lucky enough to partner with Microsoft to allow running in the background, your process is killed. It doesn't run in the background and, unless you've handled it, the transient data on screen is gone too. BUT the screen is saved on the 'Application Back Stack'. So if the user then hits the back button on the phone, they'll return to the last screen they were on in your application.
Beware: There is no guarantee of the user doing this so your application will have lost any volatile data. The dotted line is just to show that it may happen.
It is possible to save this 'transient' data just before your application is tombstoned during the 'Application_Deactivated' event. I'm sure you'll have noticed that some of the stages are red. These stages have fire methods, within App.xaml.cs. If you open the file, and take a look the methods, there are some very useful comments describing when each is fired. Restoring the transient data from a back key press the logic needs to be performed within the 'Application_Activated' event.
To save persistent data you can either save on a user-triggered event or within the 'Application_Closing' method. To load this add your logic to the 'Application_Launching' event.
I recommend getting a feel for these events for yourself so you fully understand them. An easy way to do this is to have a play with a Hello World on the phone, but have something within each event, for example:
What Microsoft are doing with WP7 seems to be great and well thought out. People want responsive, feature rich devices. Developers want to be able to utilise all of the platform, without having to worry about what the user is running. The way running in the background is (or isn't) handled is better than I initially thought. WP7 allows developers to have a near guaranteed set of resources for their application, which allows feature and graphically rich applications to run at full tilt while preserve battery life.
This, however, means as a developer you need to be aware of these interruptions and how you want to handle them in your application. The file that these methods are stored in is App.xaml.cs. Inside this there are 4 methods to utilise, however, first let's take a look at the application life-cycle for WP7. There are a number of states that an application can go through so here's a diagram (click for full size):
A little tricky at first glance, but with a bit of explanation it's fairly simple. The top row is essentially a run-to-exit flow of processes. From the running state it becomes a little more interesting. An application can be deactivated in a number of ways; text message, phone call, user hitting start, user searching. Unless you're lucky enough to partner with Microsoft to allow running in the background, your process is killed. It doesn't run in the background and, unless you've handled it, the transient data on screen is gone too. BUT the screen is saved on the 'Application Back Stack'. So if the user then hits the back button on the phone, they'll return to the last screen they were on in your application.
Beware: There is no guarantee of the user doing this so your application will have lost any volatile data. The dotted line is just to show that it may happen.
It is possible to save this 'transient' data just before your application is tombstoned during the 'Application_Deactivated' event. I'm sure you'll have noticed that some of the stages are red. These stages have fire methods, within App.xaml.cs. If you open the file, and take a look the methods, there are some very useful comments describing when each is fired. Restoring the transient data from a back key press the logic needs to be performed within the 'Application_Activated' event.
To save persistent data you can either save on a user-triggered event or within the 'Application_Closing' method. To load this add your logic to the 'Application_Launching' event.
I recommend getting a feel for these events for yourself so you fully understand them. An easy way to do this is to have a play with a Hello World on the phone, but have something within each event, for example:
Debug.WriteLine("Hello World : Application Launching...");A problem I have found with the emulator is re-activating an application too quickly can cause the emulator to freeze/crash. Just wait to see the threads are terminated before pressing the back button to avoid this.