Updated November 8, 2014 12:08 am - In the first two Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and… Few More Things on the Way posts (part 1, and part 2) you learned about the different application lifecycle events – Launching, Deactivated, Closing, and Activated, and how they differ from one another. Based on that knowledge and this code, we’ll move forward.
Saving the transient state and navigating to the right page
As you will recall, the second page of our simple application includes two textboxes, one for allowing the user to enter a phone number that will be used to save new contact information, and a second textbox for allowing the user to enter an SMS message to be sent. This will become useful when we start playing with Launchers and Choosers in the context of tombstoning applications.
Let’s start by defining the problem. The easiest way is simply to run a small experiment:
- From Visual Studio, start your application.
- Navigate to the second page and enter some text in either or both textboxes.
- Press the Windows button; this will deactivate your application (see part 2 of this series).
- Press Back (once) to return to your application. This will result in a black screen on your emulator.
- Press F5, or use any other method to restart the Visual Studio debugging session to reactivate your application. (Again, if you are missing some context, please read part 2 of this series)
- At this stage, your application should be running and you should see the second page of the application. However, both textboxes are empty… the text that you entered before you deactivated your application is no longer there. It is gone!
From this little experiment you have learned that data entered into your application is not automatically saved when your application deactivates (remember, your application gets terminated). And since reactivating an application really means starting a new instance of the application with some tombstoned information, the page that you land on – in our case page 2, the DetailsPage, is a brand new instance of that page. This indicates that by default all the controls have no data, unless you load data into them.
The most important thing to remember about tombstoned applications is the simple fact that the user may NOT return to your application, and therefore your application may not be reactivated. If you anticipate this happening, you need to save to disk any data that you wish to restore at a later time. It is completely up to you and your responsibility as a developer to handle the saving and retrieving of data in your application
We identified two sets of data types that we want to store (copied from MSDN):
- Persistent data – Data that is shared by all instances of an application. Persistent data is saved and loaded from isolated storage. Application settings are an example of persistent data that should be preserved between application executions.
- Transient data –Data that describes the state of a single instance of an application. Transient data is stored in the State dictionary provided by the PhoneApplicationService class. A tombstoned application restores its transient state when it is activated.
We will address the persistent data and working with isolated storage in a future post. For now, let’s focus on managing the transient data and using the State dictionary.
One of the new classes in the SDK is PhoneApplicationService. The PhoneApplicationService class provides access to various conditions of the application’s lifetime. This includes management of the application’s idle behavior and management of the application’s state when it becomes active or inactive. This class plays a major role in the tombstoning game, since it exposes the Launching, Deactivate, Activated, and Closing events that have the corresponding methods (which you already saw) in the App.xaml.cs file. This class also includes a read-only State property of type IDictionary<string, object>. The importance of this dictionary is that it is persisted on your application’s behalf by the Windows Phone operating system when your application gets tombstoned. When the application reactivates, the objects that placed in the dictionary are returned. You don’t need to save these transient objects to disk as long as you expect your application to return from the tombstoned state. Therefore, if you intend to use the State dictionary, make sure you save only transient data in it– information that you don’t mind losing and that is local to the current application instance. In our example, we’ll save the phone number and SMS text message.
Please note that the objects you store in this dictionary have to be serializable, or else you will get an exception during the deactivating event about the inability of the operating system to sterilize or desterilize your object.
MSDN best practices recommend that you store transient page data in the State dictionary during the OnNavigatedFrom event, and load data during the NavigatedTo event.
I’ve update the application to save the phone number and the SMS message in the Store dictionary, and load it each time the page get navigated to. If a “completely” new instance (indicated by the “Lunching” event) of the application is started, the State dictionary is empty.
Note that with the following changes, the information in page 2 is stored between page navigation. That is when you press the Back button in page 2, the application navigates back to page 1. If you click the “Navigate to next page” from page 1, your application navigates to page 2. The OnNavigateTo (on page 2) event is raised, and with the above code the control will be loaded with data. This is important because if you take a closer look at the trace in the Output windows in Visual Studio you will find that the each time you navigate to page 2, its constructor is executed. This indicates that each time you press the Back button from page 2, that page is destroyed, and therefore each time you navigate back from page 1 to page 2, the page is recreated. To observe this behavior for yourself, simply navigate back and forth between the two pages, and note that the page 2 CTOR is called each time you navigate from page 1 to page 2. If you comment out the OnNavigatedFrom method in your application, and navigate between the two pages, you will see that the information on the second page is not saved.
Now tombstone the application to see for yourself that the phone number and SMS message are being stored, not just between page navigations, but also after leaving the application and returning to it. Simply navigate to page 2, enter a phone number and some text, and press the Windows button to tombstone the application. You should see the deactivated trace and then the application terminated. Press the Back button and don’t forget to press F5 in Visual Studio to restart the debugging session. Your application will return from its tombstoned state and you will see the launching event, and then the DetailsPage (page 2) constructor. Next you will see the OnNavigatedTo trace and, if everything works, you will see the “Found phone number” and “Found Sms Msg” lines in the trace (and in the emulator), as shown in the next image.
All this is nice, and I hope it explains the way things work with tombstoning Windows Phone applications. But, now it is time to step up our game and show some cool things in action.
First, I’ve added a helper Logger class that logs all the traces and displays them in the MainPage (first page) textbox. The goal of the Logger is to prove to you without a doubt that your application gets terminated and that the State dictionary really works. The logger will also allow you to run your application from the emulator, not in debug mode, and still get some information back through the traces shown in the log textbox.
The Logger class includes a very simple (and most probably not that thread-safe) implementation of a Singleton. The main reason this class is a singleton is to show that even a singleton class is removed from memory when your application is terminated, as well as the order of events and the loading of data between the different events. This class has a string member, which is the log, and a DateTime member that saves the creation time of the Logger object. With the Logger class you can add new lines to the log, and get the entire log. This is good for debugging, which is exactly what the Logger is for. Each time you use the Util Class to add a trace, you also add it to the Logger.
Usually a singleton implementation doesn’t have a public constructor. However, you are going to save this class in the State dictionary, which means that the Logger class must be serializable and therefore must have a public default (empty) constructor. Otherwise you will get an exception when trying to deactivate or activate your application.
To “view” the log, I’ve added the OnNavigatedTo method to the MainPage.xaml.cl and loaded text in the log to the logTextBox control on the main page. Therefore each time you navigate to the main page of the application you will see the log file printed. Doing this enables you to view the trace in your application without the need to debug your application in VS (and thanks to Jaime Rodriguez for the tip). Let’s try it.
- First you need to deploy you application to the emulator. You can do this by right clicking on your project in the Visual Studio Solution Explorer panel, or from the Build menu. Simply click Deploy.
- In the emulator, navigate to the applications list by clicking on the white arrow on the top right corner of the phone.
- You should see the applications list, which is rather short. From the applications list pick your application. If you are using the code from this post, the application name is LWP.AppLifeCycle
- The application launches, and you see the trace in the MainPage textbox. You may want to change the phone setting (by clicking the wrench button) to set the zoom level of the emulator to 100%. The text in the log textbox is small to be able to show as much log history as possible without scrolling.
- In the log textbox you should see the trace from creating the application and the constructor of the main page.
- Click the Next Page button.
- On the second page, enter a phone number or some text to the SMS textbox.
- Then deactivate your application simply by clicking the Windows button. In the emulator, you should see the Start screen.
- Click the Back button to return to your application. This will reactivate your application and restore your application to the last page you viewed, that is the second page, and, if all goes well, you should also see the information you entered in step 7.
- On the second page, click the Back button to return to the first page. Take a look at the trace found in the log textbox. You should see something that looks the following image:
In this code, you can see that we are looking for the Logger object in the State dictionary. The object was put into the State dictionary in the deactivated event. Assuming the logger object is found, we are creating a temporary object called logger (note this is not the actual logger object that we are using in the current application). Next we compare the creation time of the Logger from the State to the singleton Logger instance of the “new” application that we just activated. As you can see in the trace, there is a difference in time; the logger from the State dictionary that we saved when we last deactivated the application is older than the new logger. From the code you can see that we can’t really initiate the older logger; its creation time and log are restored and printed to the textbox. So everything between the dashed lines is actually the previous run of the application up to the deactivated event.
The first line after the dashed line is shows the constructor of the second page, as expected, and it shows the “new” application that got reactivated and returned to the second page, from which we had deactivated the application.
Now you have seen all four events in action: Launching, Deactivated, Activated, and Closing. I hope you understand that when your application is not running, it is terminated, and any data you didn’t saved is gone. Then when you are return to the application, with either an Activated event or a Launching event, you get a NEW instance of the application (our little singleton experience proved that).
The State dictionary can save transient data between Deactivated and Activated events and will turn out to be a very useful tool in the next post where we’ll talk about choosers and launchers.