In developing a Windows Phone application, we can select one of the two options, which are Silverlight and XNA. Silverlight for Windows Phone is similar to Silverlight 3 that has been released for web developments. Here are some important points regarding Silverlight in Windows Phone:
- Uses the same base class library
- Has been modified for performance
- Integrated with the hardware
- Integrated with the operating system
- Specific API for the device (accelerometer, GPS, etc.)
- Uses out-of-browser model
In the template provided for application development using Silverlight platform, there are five types of project we can choose, depending on what we need:
Windows Phone Application, which provides an empty page with no control at all S Windows Phone List Application, which provides a sample scenario for master-detail data application
Windows Phone Panorama Application, which provides a sample usage of panorama navigation in an application
Windows Phone Pivot Application, which provides a sample usage of pivot navigation in an application
Windows Phone Class Library, to build components that can be reused in other projects By default, a project will consist of these files:
|
Item |
Description |
|
App.xaml/App.xaml.cs |
The application’s entry point which initializes resources and layouts of the application |
|
MainPage.xaml/MainPage.xaml.cs |
Defines a page with interface in the application |
|
Background.png |
A graphic file which shows as the application’s icon in the applications list. This icon can be replaced |
|
SplashScreenImage.jpg |
A graphic file that is displayed when application is launched. Splash screen is designed to give fast response to users while the application’s initial page loads |
|
Properties\AppManifest.xml |
Manifest file for application package generation purposes |
|
Properties\AssemblyInfo.cs |
Assembly file that contains information regarding the name and version of metadata attached to the assembly that is generated |
|
Properties\WMAppManifest.xml |
Manifest file with specific metadata regarding Windows Phone application that defines icon name, initial page, etc. |
Another point to consider is that applications using Silverlight in Windows Phone fully apply navigation techniques in Silverlight 3. Using frame container, navigation can naturally be easy to handle, and the navigation to go back is integrated to the button on the hardware. No need to override the method :).
Application Life Cycle
Model execution on a Windows Phone has a complete cycle, from when the application is launched until it is deactivated. This execution model is designed to provide a fast, responsive experience at all times. This causes the Windows Phone to only be able to run one application at a time. This is to prevent the device from being slow or unresponsive due to the existence of background applications.
Several terminologies we should get familiar with in order to understand the aspects of execution model on Windows Phone application
|
Term |
Description |
|
Tombstoning |
A procedure in which the operating system deactivates the application process as users exits the application. Operating system preserves any information about the application’s state. When the application is re-launched, the operating system restarts the process and sends the last known state from before the application was turned off |
|
Page State |
A state regarding the application page. It includes scroll positions or text field contents. Modifications to this state is done by overriding OnNavigatedTo or OnNavigatedFrom methods |
|
Application State |
An application’s condition in which there are no specific associations to any page. This condition can be modified using PhoneApplicationService class |
|
Persistent Data |
Data shared by application. This data is stored and retrieved from isolated storage. Application setting is one example of persistent data |
|
Transient State |
Transient data are those related to an instance of the application. Transient data is stored in state dictionary provided by PhoneApplicationService. An application in tombstoned state will return to transient condition when application is reactivated. An example of transient state is web service query |
Now let us move on to a short journey about application lifecycle in Windows Phone.
• Launching
A Windows Phone application is launched when it is called either because the user pressed the Back button to said application, selected from application list, or from tiles in the main screen. Regardless of the way it is called, an instance of the application will be created, and as the application starts running, Launching event is started. The application preferably should not retrieve any data from isolated storage. Since the event is generated before the application is active or displayed, doing tasks that consume time, such as accessing isolated storage, may cause unwanted user experience because it slows down the application’s launch time. Accessing isolated storage, or calling network related actions, should be done asynchronously when application has been loaded. It is also not advisable for the application to call transient state from its previous instance. When an application is launched, it should look like an entirely new instance.
• Running
After launching event is handled, the application will start running. In this condition, the application defines its conditions when the user, for example, navigates his way through the application’s pages. The only activity that can happen is application incrementally stores data or settings in order to reduce the amount of data to be stored as the application’s state changes. For applications using small amount of data, this becomes ignorable.
• Closing
A sample scenario that starts closing event is when the user presses the device’s Back button on a n application’s initial page. Application has to store persistent data into isolated storage. It is not necessary to store transient data, or data related only to one instance of application, because the only way for a user to return to application after it is deactivated is by re-launching the application, and as stated above, it will be an entirely new instance.
• Deactivating
When a running application is replaced by another, the previous one will be deactivated. There are several scenarios as to how this event is started. One is by pressing the Start button or due to timeout when the main screen is locked. An application can also be deactivated by the invocation of a Launcher or Chooser—default applications that enables users to do common tasks on a mobile device, such as taking pictures or sending emails. In those cases, the running application will start Deactivated event and enter deactivating condition. Unlike when it is closed, an application that launches Deactivating event will enter tombstoned condition. This means that the application is no longer running, but the operating system records the application’s conditions and stores several data related to it. It is very likely for users to return to the application, and when this happens, the application enters reactivated condition.
In event Deactivated condition, an application should store information regarding the current conditions using State property on PhoneApplicationService. Data stored into the dictionary are transient data which will restore the application to its condition before it is deactivated. Since there is no guarantee that applications that enter tombstoned condition will be reactivated, applications should also store data into isolated storage. The whole actions has to be finished within 10 seconds, otherwise the operating system will not terminate the application. For this reason, an application that uses large amount of data is advised to store its data incrementally while the application is running.
This is the list of actions that will cause an application to enter tombstoned condition:
• WebBrowserTask
• MarketplaceDetailTask
• MarketplaceHubTask
• SaveEmailAdressTask
• SavePhoneNumberTask
• SearchTask
• SmsComposeTask
The following actions will not automatically cause application to enter tombstoned condition, and thus should be handled:
• PhotoChooserTask
• CameraCaptureTask
• MediaPlayerLauncer
• EmailAdrdressChooserTask
• PhoneNumberChooserTask
• Activating
After an application is deactivated and enters tombstoned condition, it is very likely to be reactivated. Applications can be invoked as a new application instance from Start. Users may also start application from another application, causing the tombstoned application to never be launched again. When Launcher or Chooser is the cause of deactivation, users can finish tasks related to the plug-in then return to the application’s tombstoned condition. When this happens, application will be reactivated or Activated event will be called. Application should load data stored in PhoneApplicationService dictionary to restore last known condition of the application. Similar to the handling of Launching event, application should not access resources from network or isolated storage to avoid slowing the process down.
This knowledge regarding execution model is absolutely necessary in order to preserve consistency and provide a consistent user experience. Microsoft team has issued the best practice guide regarding execution models in Windows Phone applications, as can be seen here. The following image elaborates the application’s workflow for better understanding.
Security
Security has become a certain issue in Windows Phone application development. This aspect directly affects developers in building the application. There are several built-in features provided in Windows Phone, and these affect what we should do and how we should code. If our application sends or receives sensitive information through the internet we also have to secure the data. In this case Silverlight for Windows Phone provides several classes that can be used.
Silverlight for Windows Phone is designed with several built-in features to support security aspects. Windows Phone applications run in limited environment, Sandbox, thus limiting their access to filesystem or other application files like any other .NET applications. This assures that applications will not affect operating system or certain features in the device, such as camera or email. From the development point of view, this means that developers only need to know how to call tasks related to the operating system or those features through managed-code, because they cannot directly invoke the features. And this is where Launchers and Choosers come in. Since applications may not access filesystem whilst several scenarios require data storage, Silverlight provides isolated storage, in which we can store data. It is isolated because an application may only access its own isolated storage. This very much simplifies codes regarding to data storage in our application.
The feature mentioned above is already provided, and we only have to learn how to use it. On the other side, Silverlight for Windows Phone also provides some tools for your application’s security. Sending sensitive data through internet is one scenario where we want to secure the data. For this purpose, there are a number of namespace that can be applied:
• System.Security.Principal gives information regarding user management and role management
• System.Security.Permissions exposes features on access to certain resources
• System.Security.Cryptography provides encryption and hash functions: AES, SHA1, SHA256, and HMAC
