What we will learn in this Article ?
- Windows Phone terminology
- Application Life Cycle
- Fast Application Switching
- Managing Page State
Windows Phone Terminologies
Application State
Application sate is application level Data. This Data may be returned by the service and being displayed in different view. For example a list of students being retuned by a service and on Page1 only students names are being displayed whereas on Page2 student names and age are being displayed. So Application State is a data returned by service and being displayed differently on different pages of the application.
Page State
It is common scenario that user fill some value on page and navigate from that page. On returning to the same page user expects persisted value on the page. Page state is visual persisted state of the page. For example on a page there is one text box and one check box. User has entered some value in text box and checked the check box. Value entered in the textbox and checked checkbox creates Page state of the page.
Tombstoning
It is process to persist data after application is terminated. Data can be persisted of an individual page or data can be persisted of state of whole application. When again user navigates back then application gets recreated and all the data persisted gets restored.
State Dictionary
Dictionary objects are used to store key/value pair. Dictionary in Windows phone is used to restore the Application state. At time of Tombstoning Dictionary gets preserved.
Application Life Cycle
Application life cycle of Windows Phone application says about different state of the application from launching to closing. User launches an application and application goes to running state. Due to launching of other application or on pressing of hardware start or search button application goes to dormant or tombstone state. Again on the launching of application, app gets activated from either dormant or tombstone state. Application can be closed by pressing of hardware back button.
Block diagram on Application Life Cycle events
Different events are as below. All events are written in App.Xaml.CS
Application Launching
Application Activated
Application Deactivated
Application Closing
As a developer it is must to have understanding of sequence of events get executed in Windows Phone application life cycle
Fast Application Switching
Windows Phone 7.5 operating system provides improved fast application switching over Windows Phone 7 operating system. Before we go into details of how FAS is better in Mango, let us first understand what is FAS?
Imagine application “A” is running and user launches a new application “B”. On pressing hardware back button user can return back to application “A”. If application “A” gets activated without “resuming “ screen then it can be termed as “ Fast Application Switching “
In Windows Phone 7.5 version FAS is improved over Windows Phone 7 with introduction of new state in application life cycle called “Dormant state”. Whereas in Windows Phone 7.0 version there was no Dormant state and on deactivation application directly goes to Tombstone state.
In Windows Phone 7 flow of application was as below,
- User deactivates application by pressing hardware start or search button
- Application goes to tombstone state
- Windows Phone 7 operating system saves information about application Navigation state and State Dictionary
- Operating system terminates application thread and processes.
- User again activates application by pressing hardware back button.
- Operating system creates application thread and process.
- Operating system restores memory state by retrieving saved value of Navigation state and state dictionary.
Due to above steps in Windows Phone 7 operating system user gets feeling that application was running in background and got resumed from there. However this is not true and operating system again creates application process and restores memory state. Creation of application process and restoration of application memory states take time and cause to slower application switching.
In Windows Phone 7.5 flow of application is as below,
- User deactivates application by pressing hardware start or search button
- Application goes to dormant state
- Windows Phone 7.5 operating system preserve instance of the application
- User again activates application by pressing hardware back button.
- Operating system restores preserve instance and re activate application
- If operating system runs low on the memory, it pushes application from dormant state to tombstone state.
- If application is reactivating from tombstone state then it follows the same cycle as of Windows Phone 7 operation system.
Now you understand significant of dormant state for Fast Application switch. With introduction of dormant state in application life cycle, operating system preserve instance of the application in memory unless it is forced to release due to low memory. So at the time of application reactivation as a developer you need to check whether to restore the application or not? If application is reactivating from dormant state then there should not be restoration.
On Application Activated event you can check whether application is reactivating from dormant or tombstone state as below,
private void Application_Activated(object sender, ActivatedEventArgs e)
{
if (e.IsApplicationInstancePreserved)
{
// No need to restore the application.
// Application is reactivating from dormant state
}
else
{
// Need to restore the application.
// Application is reactivating from tombstone state
// Read state dictionary and Navigation state to restore memory state
}
}
An Application gets closed by pressing hardware back button. And in that case application neither goes to dormant state or tombstone state. If there are multiple pages in application then user navigates between pages using hardware back button. However if on start page of application user press hardware back button then operating system will close the application. While closing application Application_Closing() events gets executed.
Maintaining Page State
Page state deals with transient data whereas Application State deals with Persistent Data.
Page state deals with preserving data binding of the user interface of the page. If application is reactivating from dormant state then there is no need of preserving the state of the page or in simple words data of the controls on page explicitly. However if application is reactivating from tombstone state then page data need to be preserved and restore explicitly.
To demonstrate how Page State works? I have designed page as below,
Let us put some control on the phone application page.
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
<TextBox x:Name="txtValue" Height="100" Margin="12,37,58,470" />
<CheckBox x:Name="chkValue" Height="100" Margin="251,144,0,364"
HorizontalAlignment="Left" Width="134" />
<Slider x:Name="sldValue" Value="30"
Height="100" Margin="28,383,58,124" />
</Grid>
There are three controls on the page. After tombstone, we need to preserve and restore value of these controls. Now we need to create properties for each control. We need to call NotifyPropertyChanged event in the setter of property to notify when value changed at the control. Control value would be bind with two ways binding with these properties. Eventually Data class will be as below,
using System.Runtime.Serialization;
using System.ComponentModel;
namespace RestorePageState
{
[DataContract]
public class Data : INotifyPropertyChanged
{
private string textValue;
private bool chckValue;
private double sliderValue;
public string TextValue
{
get
{
return textValue;
}
set
{
textValue = value;
NotifyPropertyChanged("TextValue");
}
}
public bool ChckValue
{
get
{
return chckValue;
}
set
{
chckValue = value;
NotifyPropertyChanged("ChckValue");
}
}
public double SliderValue
{
get
{
return sliderValue;
}
set
{
sliderValue = value;
NotifyPropertyChanged("SliderValue");
}
}
public event PropertyChangedEventHandler PropertyChanged;
private void NotifyPropertyChanged(string propertyName)
{
if (null != PropertyChanged)
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
}
With Data Class in place we need to preserve state of the page. There are two checks to perform before preserving page state. First check to be done, whether application is reactivating from dormant state. If so then there is no need of restoring the state. To save the state of the page OnNavigatedFrom method instance of the Data need to be saved in the State dictionary as below,
protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)
{
if (e.NavigationMode != System.Windows.Navigation.NavigationMode.Back)
{
State["Data"] = dataToBindControls;
}
}
In above code dataToBindControls is object of Data bind to the controls on the page. To restore the page OnNavigatedTo method state count need to checked as below.
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
if (isNewInstanceofPage)
{
if (dataToBindControls == null)
{
if (State.Count > 0)
{
dataToBindControls = (Data)State["Data"];
}
else
{
dataToBindControls = new Data();
}
}
DataContext = dataToBindControls;
}
isNewInstanceofPage = false;
}
}
Essentially there are three tasks we are performing in above function
- Checking if it is new instance of the page.
- If yes then checking if value of data control [object of data class ] is null
- If null then reading from the state else creating new instance of that.
Full source code behind to preserve page is as below,
using Microsoft.Phone.Controls;
namespace RestorePageState
{
public partial class MainPage : PhoneApplicationPage
{
Data dataToBindControls;
bool isNewInstanceofPage;
public MainPage()
{
InitializeComponent();
isNewInstanceofPage = true;
}
protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)
{
if (e.NavigationMode != System.Windows.Navigation.NavigationMode.Back)
{
State["Data"] = dataToBindControls;
}
}
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
if (isNewInstanceofPage)
{
if (dataToBindControls == null)
{
if (State.Count > 0)
{
dataToBindControls = (Data)State["Data"];
}
else
{
dataToBindControls = new Data();
}
}
DataContext = dataToBindControls;
}
isNewInstanceofPage = false;
}
}
}
Last but not least data need to be bind to controls as below,
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
<TextBox x:Name="txtValue" Height="100" Margin="12,37,58,470"
Text="{Binding TextValue,Mode=TwoWay}"/>
<CheckBox x:Name="chkValue" Height="100" Margin="251,144,0,364"
HorizontalAlignment="Left" Width="134"
IsChecked="{Binding ChckValue,Mode=TwoWay}"/>
<Slider x:Name="sldValue"
Height="100" Margin="28,383,58,124"
Value="{Binding SliderValue,Mode=TwoWay}"/>
</Grid>
In this way a page state can be preserved. Before debugging last step we need to perform is enable Tombstone upon deactivation while debugging in the properties page. There may be other approach to preserve state as below,
- Creating extension method for page class
- Create helper class and call method of the class to save control’s data.
I will conclude with supporting above approach of Page State restore and retrieve for better encapsulation. Since each page is handling their own state so it is easy to separate the concern for pages individually.
