I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my last post in this series I discussed working with the push notifications. In the last post in this series I’ll look at location services.

Architecture

Let’s begin with an overview of the location services architecture as implemented on Windows Phone. The location services architecture consists of three layers:

The first layer consists of hardware in the Windows Phone device. This includes the GPS receiver, Wi-Fi, and the cellular radio. All of which function as publishers of location data, each having its own level of accuracy and power consumption.

On top of the hardware sits the native code layer. This layer talks directly with the available sources of location data and decides which sources to use for location based on data availability as well as the performance and accuracy requirements of your application. This layer also talks to a Microsoft-hosted web service to look up location-related information from a database.

It’s important to note that your applications do not directly interact with this native code layer. Instead, they use a managed interface, exposed through an API in the System.Device assembly that ships with the Windows Phone Developer Tools.

It is through this API that your applications start and stop the location service, set the level of accuracy they need, and receive location data as it bubbles up for the hardware to the native code layer then through the managed interface.

Core Classes

Let’s now look at some of the core classes you’ll need to get acquainted with in order to work with location information on windows phone.

When working with the location information, there are three classes you need to be aware of.

The first two reside in the System.Device.Location namespace. The first and most important class to understand is the GeoCoordinate class. This class is constantly used when working with location data. An instance of this class represents a specific geographic location as defined by latitude and longitude.

The GeoCoordinateWatcher class is the class we use in our application to obtain geo coordinates, or location data. The Position property reflects the device’s current location and you can handle the position changed event to perform actions when the device’s location has changed.

After you get your location data you’ll probably want to do something more with it than display coordinates. Chances are you’ll want to visualize it in some way. The last class we’ll talk about, the Map class, enables you to do exactly that. This class resides in the Microsoft.Phone.Controls.Maps namespace which is in the Microsoft.Phone.Controls.Maps assembly and can be leveraged to use Bing maps in your application. This control is nearly identical to the Silverlight version of the Bing maps control. You can draw pushpins and routes on the map, zoom in and out, etc.

Considerations

When working with location data there are two key considerations you should keep in mind.

1. Be very conscientious when deciding on which source to use for your location data. You should take into account the accuracy, power, and speed requirements of your application. If you need a high level of accuracy then you should go with GPS. However, GPS consumes more power than the other sources so make sure you only turn it on when needed. If you’re looking for speed, or a lower level of accuracy will suffice, then cellular is a better option.
2. Allow your users to opt-in/out of consuming location data. Given the potential performance impacts of using location services as well exposing their current location, users should be able to turn the feature on or off.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle
• Windows Phone Essentials #2 – Navigation Model
• Windows Phone Essentials #3 – Application Bar
• Windows Phone Essentials #4 – Isolated Storage
• Windows Phone Essentials #5 – Launchers
• Windows Phone Essentials #6 – Choosers
• Windows Phone Essentials #7 – Accelerometer
• Windows Phone Essentials #8 – Gestures
• Windows Phone Essentials #9 – Location Services

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my last post in this series I discussed working with the gestures. In this post I’ll look at push notifications.

What & Why

Let’s start by addressing what push notifications are and why you should use them.

To get an understanding of what push notifications are let’s get an understanding of windows mobile development up until this point in time.

For illustrative purposes, let’s use the above picture of some people pulling on a rope.

• The people pulling on the rope represent your application.
• The object they are pulling against, more than likely another team of people, represent a web service you have that serves data to your application.
• The rope represents the data your application needs.

There are a couple of difficulties with this common approach of pulling data from a web service.

First, your application has to figure out a schedule of when to pull data from the service. If there is an important update that needs to get to your application, the service has no way of notifying the app. It could be that the critical notification doesn’t get pulled by the application until it is no longer relevant due to a time lag.

Second, and this is a key factor with mobile apps, every time you request data from the web service the cell radio, or wi-fi connection will have to be activated. Frequently polling will result in a degradation of battery life. You certainly don’t want to be the creator of an application that gets a reputation for killing a phone’s batter.

Let’s contrast the polling model with the push model used by push notifications.

For illustrative purposes, let’s use this nice picture of a grandfather pushing his grandchild.

In this illustration, the grandfather represents your web service, and the grandchild represents your application. Unlike the polling scenario, your application doesn’t have to do anything to get notifications. Instead the web service is able to send the notifications directly to your application.

This solves the issues we talked about with the polling model in that we no longer have to worry about potential latency due to the application’s polling schedule, and we will have better battery life on the device as we no longer have to constantly activate the cell radio or wi-fi connection to poll for data.

Architecture

Now that we know what push notifications are, let’s dive into the architecture.

There are a number of moving pieces you have to work with when using push notifications.

The first of course is your application. The second is the Microsoft Push Notification service. This is a service hosted by Microsoft and available for you to consume freely for your Windows phone applications. This service provides you with a dedicated and persistent channel to use to send information and updates to a windows phone application from a web service.

Here’s how you conceptually use push notification:

1. The first thing you have to do when using push notifications is to establish this channel by requesting a Uri from the Microsoft Push Notification Service.
2. Once you have the Uri from the push notification service you need to share it with something, that something is a web service that you create. Once the service is created, you’ll send the uri for your phone’s dedicated communication channel to the web service. You now have the infrastructure in place to send push notifications to your windows phone application.
3. When you send a notification from your web service, it will actually be routed to the Microsoft push notification service.
4. From there, the notification will get sent to the application.
5. Your web service will receive a response code indicating whether or not the message was delivered.

It’s important to keep in mind that the push notification service does not provide you with end-to-end confirmation that your message was delivered from your web service to the windows phone application. The response will tell you if the device is connected or disconnected and whether or not your message was queued for delivery. However, you’re service will not be informed as to the success of the delivery.

Notification Types

With an understanding of the underlying architecture in place, let’s look at the different types of notifications available to us and how we can use them.

Toast

The first type of notifications are we’ll take a look at are toast notifications. Toast notifications are system-wide notifications that do not disrupt the user workflow or require intervention to resolve.  Let’s say you’re using the search application. If you were to receive a toast notification, it would display at the top of the screen for ten seconds before disappearing. If the toast notification is tapped, the application that sent the toast notification will launch. The notification can be dismissed with a simple flick of the finger.

Two text elements of a toast notification can be updated:

• The title is a bolded string that displays immediately after the application icon.
• The sub-title is a non-bolded string that displays below the title.

The result looks something like this:

Tile

The second type of notification we’ll look at is the tile notification. Every application has a tile, or image, that is displayed if the user pins the application to the Start screen. This tile can be updated with a push notification.

There are three elements of the Tile can be updated:

• The tile’s background image can be a local resource or a remote resource.
• The tile’s title, which is a string of text can be updated as well. It must fit a single line of text and should not be wider than the actual tile.
• The count property which is simply an integer value from 1 to 99. If there is not count value it will not display.

This allows you to do something like in the image below:

Raw

The final push notification that you can utilize is the raw notification. If you don’t want to update the Tile or send a toast message, you can instead send raw information to your application. If your application is not currently running, the raw notification is discarded on the Microsoft Push Notification Service and is not delivered to the device. The payload of a raw notification has a maximum size of 1 KB.

Considerations

Before wrapping up this post I want to call out a few considerations you’ll want to keep in mind when using push notifications in your windows phone applications.

If you’re going to use push notifications in your application, you should consider enabling the user to opt into and out of the notifications. In fact, if you use toast notifications you are required to ask the user if he or she wants to receive the notifications, and you must allow the user to turn off the toast notifications if they so desire.

Ask yourself if the data your sending from your service to windows phone contains personally identifiable information. If it does you should rethink your strategy as you really shouldn’t be sending this type of information through push notifications.

Finally, each device has a 15 channel limit when it comes to push notifications. If the user already has 15 apps installed that are using push notification channels, when your application attempts to register a push notification channel, it will encounter an exception. Be prepared to handle this scenario in your applications.

That’s it for push notifications. I’ll wrap this series up with a look at location services.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle
• Windows Phone Essentials #2 – Navigation Model
• Windows Phone Essentials #3 – Application Bar
• Windows Phone Essentials #4 – Isolated Storage
• Windows Phone Essentials #5 – Launchers
• Windows Phone Essentials #6 – Choosers
• Windows Phone Essentials #7 – Accelerometer
• Windows Phone Essentials #8 – Gestures

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my last post in this series I discussed working with the accelerometer. In this post I’ll look at gestures.

What are gestures? Well, gestures are the means by which a user interacts with a windows phone, and consequently, your applications. Users can use one or multiple fingers to perform actions like scrolling, flicking, pinching to zoom in and out, etc.

Working with Gestures in Silverlight

When it comes to working with gestures on Windows phone, you have two frameworks at your disposal. The first is Silverlight. Silverlight enables your apps to process touch inputs, or gestures, by using the eventing system. Specifically events related to manipulation. By handling these events, you can move and scale elements in your user interface in response to touch events.

When working with gestures in Silverlight on Windows Phone, there are several key classes and events you’ll need to know about.

The ManipulationDelta class gives you access to transformation data that is part of a manipulation. For example, you can get data about the linear motion of the manipulation via the translation property.

The ManipulationVelocities class gives you information regarding how fast a manipulation has occurred. Whereas the ManipulationDelta class can tell you about the linear motion of a manipulation, the ManipulationVelocities class will tell you about the speed of that motion.

When working with gestures, you’ll also need to be aware three events that can be fired from any object that inherits from the UIElement class. In the case of Windows Phone these objects would be the pages and controls that compose your application.

• The ManipulationStarted event is fired when, as you would expect, a manipulation is invoked by the user.
• The ManipulationDelta event is fired any time during the manipulation when something has changed (i.e. an object is being dragged across the screen).
• The ManipulationCompleted event is fired, when, once again as you would expect, the manipulation is done.

Working with Gestures in XNA

The second framework you can use for working with gestures is XNA. XNA differs from Silverlight in that it is truly more of a gesture system as opposed to an event based processing model. The result is comprehensive framework that can make it easy to work with gestures as opposed to trying to deal with gestures in an event based model.

To be clear, you can use XNA touch support in your Silverlight apps and vice-versa. For the sake of this module we will look at how to use both of these frameworks in the context of Silverlight applications.

In order to effectively work with the gesture framework provided by XNA, there are number of items in the Micorosft.Xna.Framwork.Input.Touch namespace you need to become familiar with.

The first is the TouchPanel class. This class enables your applications to get data from the physical touch panel that is part of the device. Of particular interest to us is the ReadGesture method as this is how can determine what type of gesture the user has made.

Next up we have the TouchPanelCapabilities structure. This class lets us know if the physical touch panel on the device is actually connected, as well as the maximum number of touch points exposed by the panel.

The TouchLocation structure gives our applications information about a specific touch location. For example, the state property exposes when a location is pressed or released.

When dealing with multi-touch gestures, the GestureSample structure is important to understand as it gives us access to data from multi-touch gestures that occur over a span of time.

Finally, and in my opinion most useful from a Silverlight perspective, is the GestureType enumeration. This enumeration which is exposed as the GestureType property on the GestureSample structure, tells us what type of gesture a user has made. We can know if a user has tapped or double-tapped the screen, dragged their finger across the screen horizontally or vertically, pinched the screen to zoom-in or out, etc.

Next up in this series, working with push notifications.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle
• Windows Phone Essentials #2 – Navigation Model
• Windows Phone Essentials #3 – Application Bar
• Windows Phone Essentials #4 – Isolated Storage
• Windows Phone Essentials #5 – Launchers
• Windows Phone Essentials #6 – Choosers
• Windows Phone Essentials #7 – Accelerometer

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my last post in this series I discussed Choosers. In this post I’ll look at the Accelerometer.

So, what is an accelerometer? Simply, put, it’s a sensor that is part of the device’s hardware that provides data about device movement that can you can use in your applications. An easy way to understand this in terms of Windows Phone, is to think about a windows phone page that supports both portrait and landscape mode. When you move the phone from portrait view to landscape view, the page automatically changes rotation for the new view. This is accomplished via the accelerometer.

When working with the accelerometer, there are two core classes you need to be aware of, as well as one enumeration. All of which reside in the Microsoft.Devices.Sensor namespace.

The first class is the Accelerometer class. This class gives your application access to the device’s accelerometer.

The next class is the AccelerometerReadingEventArgs class. When handling the accelerometer’s reading changed event, you can use this class to get information about the acceleration that has occurred. Specifically you can get access to the acceleration that has occurred in the x, y, and z direction in terms of gravitational units.

Finally, you should also be familiar with the SensorState enumeration. This enumeration contains values for the current state of the device’s accelerometer. There are a number of potential values, including whether or not the sensor is ready, if it can’t obtain data, if the application doesn’t have permission to access it, etc. This is exposed via the accelerometer’s state property.

Next up in this series we’ll look at the different ways you can support gestures in your Windows Phone applications.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle
• Windows Phone Essentials #2 – Navigation Model
• Windows Phone Essentials #3 – Application Bar
• Windows Phone Essentials #4 – Isolated Storage
• Windows Phone Essentials #5 – Launchers
• Windows Phone Essentials #6 – Choosers

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my last post in this series I discussed Launchers. In this post I’ll look at a feature called Choosers.

Much like launchers, chooser give applications the ability to launch one of the built-in, or native, Windows Phone applications. However, unlike launchers, choosers can return data from the built-in application to the calling application. Let’s say you’re building a photo editing application. You can use a chooser to launch the built-in photo picker application to allow the user to select which photo they want to edit. Once the user selects a photo, a stream representing the photo gets returned to the calling application which it can then use for whatever purpose you may have in mind.

Similarly to launchers, you can break choosers them out into three groups of functionality.

The first set has to do with pictures

• CameraCaptureTask allows you to take a picture using the phone’s camera.
• PhotoChooserTask allows you to select a picture that already exists on the phone.

The second set revolves around email addresses

• SaveEmailAddressTask allows you to save an email address to the phone’s contact list.
• EmailAddressChooserTask allows you to choose an email address from the phone’s contact list.

The last group deals with phone numbers

• SavePhoneNumberTask allows you to save a phone number to the phone’s contact list.
• PhoneNumberChooserTask allows you to choose a phone number from the phone’s contact

As with launchers, there are some behavioral differences you need to be aware when working with choosers in the emulator.

In the case of choosers, the only difference is with the CameraCaptureTask. Since the emulator does not have a camera, a default image is returned to your application.

Using a chooser in your Windows Phone application is a five step process:

1. Create an instance of the task type for the Launcher.
2. Identify the callback method to run after the user completes the task.
3. Set any required and optional properties of the task object.
4. Call the Show method of the task object.
5. Implement the completed event handler to capture data and status after the user completes the task.

For detailed “How-To’s” of using specific choosers, you should check out this page on MSDN.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle
• Windows Phone Essentials #2 – Navigation Model
• Windows Phone Essentials #3 – Application Bar
• Windows Phone Essentials #4 – Isolated Storage
• Windows Phone Essentials #5 – Launchers

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my last post in this series I discussed Isolated Storage. In this post I’ll look at a feature called “Launchers”.

Let’s start by defining what a launcher is. In short , a launcher enable you to launch one of the built-in, or native, Windows Phone applications. An example of a launcher would be launching the phone application to place a call to a given number. The calling application can provide the phone application with a phone number and a display name. When the Phone application is displayed, the user can choose whether or not to actually initiate the call. When the user closes the Phone application, the calling application is typically activated again.

When working with launchers, you can break them out into three groups of functionality.

The first set has to do with communication

• EmailComposeTask
• PhoneCallTask
• SmsComposeTask

The next group of launchers has to do with the marketplace

• MarketplaceHubTask
• MarketplaceSearchTask
• MarketplaceDetailTask
• MarketplaceReviewTask

The last group of launchers includes some miscellaneous tasks:

• MediaPlayerLauncher
• WebBrowserTask
• SearchTask

Since you’ll be spending a fair amount of time testing your applications with the emulator there are some key behavioral differences between how some launchers act in the emulator and on an actual device that you need to be aware of. The diagram below indicates which launchers behave differently in the emulator.

• Since you can’t set up an email account in the emulator, the EmailComposeTask is not functional.
• Placed phone calls always connect, but since the emulator uses fake GSM and has a false SIM card the connection is a simulated one.
• Similar to phone calls, SMS message are always sent successfully in the emulator environment.
• Since you can’t link your emulator to a Windows Live account when you launch the MarketplaceReviewTask an error is displayed as the marketplace requires a windows live id to complete the operation.
• When using the MediaPlayerLauncer task in the emulator music can be played, but video will not be rendered.

Using a launcher in your Windows Phone application is a three step process:

1. Instantiate a task type for the launcher.
2. Set any require and optional properties of the instantiated task.
3. Call the Show method of the task object.

For detailed “How-To’s” of using specific launchers, you should check out this page on MSDN.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle
• Windows Phone Essentials #2 – Navigation Model
• Windows Phone Essentials #3 – Application Bar
• Windows Phone Essentials #4 – Isolated Storage

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my last post in this series I discussed the Windows Phone Application Bar. In this post I’ll take a look at Isolated Storage.

Architecture

Isolated storage allows Windows Phone applications to create and maintain device based storage. Now, before we get into the details of the isolated storage API’s let’s take a minute get an understanding of how isolated storage is implemented architecturally on Windows Phone.

At the foundation of isolated storage is the physical file system residing on the disk of the hardware. At the very top is the space where our applications resides.

Sitting between our applications and the physical file system is a virtual file system. This is isolated storage. It gives us an abstraction for working with files and folders without having to be dependent on the physical disk. The advantage here is that if Microsoft changes the OS and how the physical file system is implemented, we don’t need to worry about our applications breaking as were only dependent on the abstraction, not the implementation.

To get a better understanding of how our applications interact with interact with the virtualized file system, let’s say we have three applications (A, B, and C). Each application will have its own root in the virtualized store. Which it can then use to create and access files and folders. Now, you may be tempted to think, that, since you have all of these virtual roots, you can have an app that access the virtual stores of other applications This is not permitted. An application can only access its own store.

Key Classes

When working with isolated storage, there are three classes you need to be familiar with. All of which reside in the System.IO.IsolatedStorage namespace The first class is the IsolatedStorageFile class. This class represents a virtualized file system, that can contain directories and files for use by your application. You can use this class to determine how much space is available for use by isolated storage as well for creating and iterating folders and files in the virtualized space. The next class is the IsolatedStorageSettings class. This gives a quick way to store user specific data in isolated storage via in key-value pairs. Examples of such data might be whether or not to let the application run under the lock screen, whether or not to enable push notifications, etc. The last class is the IsolatedStorageFileStream class. You can leverage this class to work with a single file in isolated storage. In a typically stream fashion, this class gives you the ability to read and write data to a file, with the exception being that the file, in this case, is stored in the virtualized environment of isolated storage.

Strategies

Now that you know the mechanics of working with isolated storage, I’ll spend the remainder of this post looking at when and where it is appropriate to use.

When working with isolated storage it’s important to know when it’s appropriate to both persist data to and load data from this virtualized store as there is latency when performing reads and write with isolated storage. You may be tempted to use the Application_Launching and Application_Activated methods that are part of the generated App class to load data from isolated storage when your application first starts up or is activated after being tombstoned. Similarly, you may be tempted to use the Application_Deactivated and Application_Closing methods that are part of the generated App class to save to isolated storage before your application is closed or tombstoned. However, if you’re going to do this there are some timing restrictions you need to be aware of and make sure your application doesn’t violate:

1. When your application launches, it must render the first screen within 5 seconds.
2. The application must be responsive to user input with 20 seconds regardless of if the application is launching for first time or being activated after being tombstoned.
3. When the application is being activated or deactivated the event handlers must complete their actions within 10 seconds.

Failure to meet these requirements will result in your application failing certification requirements and not be accepted into the marketplace. I bring these timing restrictions up because loading/saving data from/to isolated storage can be time intensive. The best approach to take is to either load data either on page-by-page (as opposed to overall application) basis or on a background thread. Similarly, with regards to saving data, a good approach is save data at points in time throughout the usage of your application as opposed to waiting until the user is done with the application before saving.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle
• Windows Phone Essentials #2 – Navigation Model
• Windows Phone Essentials #3 – Application Bar

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my last post in this series I discussed the Windows Phone navigation model. In this post I’ll take a look at the Windows Phone Application Bar.

What is the Application Bar?

Let’s start by answering the question, “What is the Application Bar?”

The ApplicationBar is a built in toolbar for your Windows phone applications. It’s displayed as a row of icon buttons along the bottom of the phone’s screen. The goal is that the buttons are to provide users with quick access to your application’s most common tasks – for example, save, edit, and delete.

In addition to the row of buttons, you can also expose additional actions to the Application Bar by text-based menu items. These items are displayed in a list that slides up from below icon buttons when the ellipsis to the right of the buttons or the empty space to the left of the buttons is pressed. It’s not hierarchical, in that the menu item list is not considered to be a submenu of any of the icon. Instead, the menu items are used for application actions that are less frequently used and for actions that are difficult to convey with an icon and therefore require a textual representation – for example, maybe you want the use to be able to adjust the space between the lines in text they may be entering. The animations used by the application bar for displaying and hiding menu items is built in.

One other thing to note is that the Application Bar automatically adjusts when the phone changes orientation. When the phone is rotated from portrait orientation to landscape orientation, the Icon Buttons are displayed vertically in a bar on the side of the screen.

It is important to know that the ApplicationBar is not a Silverlight control. Which means you can’t perform some of the common control features, such as databinding, when working with the Application Bar in xaml. This happens implications for localization which I’ll touch on a little later.

Why Should You Use It?

Now that you have an idea, you may be asking yourself, “OK, but why should I use it?”

While you could create your own toolbar and menuing system, one of the goals of the Windows Phone platform is provide a consistent user experience across ALL applications on the device. The application bar enables you to do just that while also providing the necessary animations and rotation support so you don’t have to do a lot of heavy lifting.

Considerations

When it comes to using the application bar there are some things you need to take into consideration before implementation. These considerations can be grouped into three main categories

1. General – considerations that apply to the Application Bar as a whole
• Color – Unless you have a very compelling reason for NOT DOING SO, you should use the default system theme colors for the Application Bar. Using custom colors for the can affect display quality of the button icons, and can cause unusual visual effects in menu animations.
• Opacity – You can be very granular when controlling the opacity of the application bar, but it is recommended that you only use opacity values of 0, .5, and 1. Using values other than these may result in less than desirable affects in terms of display quality.
• Navigation – You should not use an icon button or a menu item for navigates backward in your application’s page stack. All Windows Phones are required to have a dedicated hardware Back button. Providing your own mechanism for navigating back is unnecessary and could result in confusion, providing a less than desirable user experience.
2. Buttons – considerations that apply to the icon buttons
• Color – When it comes to icon buttons, the image used for the icon should have a white foreground on a transparent background. This will enable the application bar to colorize the icon according to the user’s currently selected theme. Using images that deviate from this guidance, specifically colored icons, can result in poor and unpredictable display quality .
• No Circle – When you see sample applications, or applications running on your actual device that make use of the application bar, you’ll notice that each icon button has a circle around the icon. This circle is drawn by the application bar and should not be included in your image.
• Size – The image should be 48 by 48 pixels in size, with the white foreground image fitting in a 26 by 26 pixel area square in the center of the image. This will ensure that it does not overlap with the circle that is drawn by the application bar.
• Meaning – Most importantly, make sure you choose images that have a clear meaning to the users of your application. You’ll also want to ensure that if your application is supporting multiple cultures that you choose images that convey the appropriate meaning in a given culture.
3. Menus – considerations that apply to menu items
• Number of items – You’ll want to try not to have more than five items in your menu. If you have more than five items the user will have to scroll, which will lessen the user experience.
• Casing – Regardless of the casing you specify for your menu items, it will be converted to all lower case at run time. This is done to provide a consistent user experience across the device and platform as a whole.
• Length – Finally, you’ll want to make sure that the text is not so long that it will run off the screen. Typically, if you keep your text limited to between 14 and 20 characters you should be ok.

Localization

There’s one additional consideration I want to touch on when it comes to the Application Bar, and that is localization Localization is the process in which you translate your application’s UI (i.e. textblocks, messages, etc.) to make it suitable for another region. In a typically xaml based (i.e. WPF or Silverlight application) you would accomplish this by using databinding in your xaml to bind to a resource file that contains the appropriate translations. However, as I mentioned, earlier, the application bar is not a Silverlight control, and as a result, cannot participate in data-binding. As a result, in order to localize the application bar, you’ll need to construct it in code as opposed to xaml.

That’s it for the Windows Phone Application Bar. Next up we’ll look at how to work with isolated storage.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle
• Windows Phone Essentials #2 – Navigation Model

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.

In my first post in this series I discussed the Windows Phone application lifecycle. In this post I’ll take a look at the Windows Phone navigation model.

Key Classes

Let’s start by taking a look at some of the key classes involved with the Windows Phone navigation model.

When it comes to working with the Windows Phone navigation model, there are six classes you need to be familiar with.

The first two classes reside in the System.Windows.Navigation namespace, and if you’ve worked with Silverlight navigation applications in the past, they should be familiar to you. The first class is the NavigationService class. As with the Silverlight implementation, this class provides the various methods, properties, and events required to support navigation within your Windows Phone applications. The next class is the NavigationContext class. This class represents the state of navigation operations. Of particular importance is the QueryString property as this enables you to pass data between pages in your Windows Phone applications.

The next two classes you’ll need to familiarize yourself with are in the Microsoft.Phone.Controls namespace. In Silverlight navigation applications you may have used the Frame class. Similar to the Silverlight Frame implementation, the PhoneApplicationFrame class is nothing more than a control that supports navigating to and from pages. Whereas the Frame class in Silverlight supports navigation to Page objects, the PhoneApplicationFrame class in Windows Phone supports navigation to PhoneApplicationPage objects. The PhoneAppliationPage class simply encapsulates navigable content.

The last two classes reside in the Microsoft.Phone.Shell namespace, and, while they are not directly involved with navigation, they are important to be aware of as they are available for use by pages in your application. First is the SystemTray. The SystemTray or “Status Bar” (as sometimes referred to in the documentation) provides the user with system-level status information, such as how much battery power is left, whether or not the device is connected to a Wi-Fi network, etc. Last is the ApplicationBar. The ApplicationBar provides a common place where the user can access the most common tasks in your application, such as save, edit, etc., via buttons or a single level menu.

Let’s get a better understanding of how some of these key classes come together in the Windows Phone user interface. First we have the PhoneApplicationFrame, which you can think of as the container of your application. For Windows Phone applications, one one frame is available to the application. If you drill into the code that gets generated by Visual Studio in the App.xaml.cs file that is added to your application, you’ll see a property called RootFrame…

…which gets set to a new instance of the PhoneApplicationFrame class when the application is launched or reactivated. The RootVisual for the application, which is a UIElement, is then set to the RootFrame.

When looking at the PhoneApplicationFrame for an application, you can be break it up into three regions:

The first reserved region is for the SystemTray. This is where the user will see the strength of their cell connection, whether or not the device is connected to a Bluetooth device, etc. You can toggle the visibility of the SystemTray on a page-by-page basis.

The second reserved region is the ApplicationBar. This is where users can access the most common features in your application. You can have up to four buttons on the menu bar as well as menu items that can be displayed when the ApplicationBar is expanded for some less common features of your application. Your are not required to use the ApplicationBar in your applications, and you can have page specific implementations of the ApplicationBar within your application.

The last region, and the one you will be primarily concerned is the content region. This is where your pages are rendered.

Performing Navigation

So, how do we actually perform navigation in a Windows Phone application. Well, there are a couple of different ways you can do it. If you want to perform navigation directly from your UI, you can add a HyperlinkButton control and set its NavigateUri property to the page you want to navigate to like this:

If you want to perform navigation in the code-behind file for your PhoneApplicationPage, you can use the NavigationService property of the PhoneApplicationPage, and call the Navigate method, using the appropriate Uri like this:

Pages vs. Screens

OK, now that we have an understanding of the core classes involved with navigation in Windows Phone applications, lets examine the concepts of pages and screens. Understanding the differences of pages and screens is important when designing the logical flow of your applications. Lets use a simple application to help understand the difference. Lets say we have an application that enables us to view a list of recipes, view the details of a specific recipe, as well as search for recipes. Here’s what the structure, when implemented, may look like:

I’ll first want to display something to distract the user while my application loads book data as the data may be coming from isolated storage or a web service. This is the splash screen. Once the data is loaded I’ll want to display the list of recipes. From there, the user can do one of two things:

1. The user can view the details of a specific recipe
2. The user can search for a recipe

After a search is performed, the user can either:

1. View the details for a recipe displayed in the search results or
2. Go back to the list of recipes

Simple enough, right?

At this point, you’re probably asking yourself, “OK, so what’s the difference between pages and screens?” Well to answer that question, we need to talk about what happens when the user presses the hardware back button that is standard on every Windows Phone device. When the user clicks the hardware back button within your application, the application will navigate to the last PhoneApplicationPage entry in the navigation history for the application. If there is no entry, the application will exit.

Lets look at a scenario from our app where the user performs multiple searches, looks at the details for several recipes, and goes back to the main recipe list. If each of these functions corresponded to a page we would end up with a navigation history that looks like this:

What is of importance to us is the number of entries we have in our navigation history for the recipe search. However, if we really think about it, we need to ask ourselves if the Recipe Search functionality should be a part of our navigation history. After all, recipe search doesn’t contain any persistent state (unless we were implementing a mechanism to save searches, but that’s outside of our current scope). This gets us to the fundamental difference between pages and screens.

Pages contain persistent state, whereas screens do not

Our navigation history should only contain pages, not screens.

So, if we take another look at the structure of our application, we can now identify which items should be pages, items we want in our navigation history, and which items should be screens and not part of our navigation history or “back stack”:

Since our recipe list and recipe details items contains persistent state, we can label them as pages. These will be implementations of the PhoneApplicationPage class. Because our splash and recipe search items don’t contain persistent state, we can label them as screens. These will have different implementations:

• The splash screen will be nothing more than static jpeg
• The recipe search screen will be implemented as a pop up

By clearly defining which items in our application are pages and which items are pages, we also create a more manageable and user friendly navigation history.

A history which only contains items with persistent state, which, more often than not is what the user is really concerned with.

That’s it for the Windows Phone navigation model. Next up we’ll take a deeper look at the ApplicationBar.

Previous posts in this series

• Windows Phone Essentials #1 – Application Lifecycle

I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as weel.

I’m starting off with what I believe the most important thing for aspiring Windows Phone developers to understand, the application lifecycle. If you’re coming from a traditional Windows development background (i.e. WPF/Windows Forms) and have no mobile development experience, it’s important for you to understand an application’s execution model on Windows Phone as it is different from what you’ve experienced in the past.

Key Terms

Before we get into the application lifecycle, I want to identify and define five key terms that you’ll need to know. You may think you already know what these terms mean, but I want to ensure we’re on the same page.

Persistent Data - This should be pretty easy to grasp and already familiar to you, but just to clarify, persistent data refers to data that needs to be maintained across sessions of an application. An example of persistent data is settings specified by a user.

Transient Data – Transient data is a concept that should be familiar to you, although you might not call it transient data per se. Transient data refers to data that is associated with a particular session of an application. An example of transient data is information a user is entering into a form.

Page State – Page state refers to how a page looks, or its visual state. This includes text in a textbox, whether or not a menu is expanded or collapsed, etc.

Application State – Application state refers to data associated with an application that is not associated with a specific page. If you’ve used the Model-View-ViewModel pattern, also know as MVVM, you may have created some type of service class to handle messaging between view models in order to maintain a separation of concerns. This service class is associated with the application and not any one page within the application.

Tombstoning – The last, and probably most important, term you’ll need to know is tombstoning. Tombstoning is the term used to refer to the process used by the phone’s OS to deactivate the current application while preserving information about it’s state (i.e. transient data, page state, and application state). This process help users and developers deal with the current lack of multitasking on the phone by providing the ability to navigate “back” to an application and have the application’s state restored to the state it was in when the user left.

Key Classes

Besides terminology, there are a couple of key classes you need to be familiar with in order to understand the lifecycle of a Windows Phone application.

[YourNamespace].App

The first is the App class that gets generated when you create a new Windows Phone Application project in Visual Studio. As you’ll see when you examine the class in your project, it inherits the System.Windows.Application class. It’s the class that provides the entry point for your application. If you’ve worked with WPF and/or Silverlight you’ve already seen this in action. However, before you go off and start coding like might want to, I do want to call out a subtle difference between the Silverlight implementation and the Windows Phone implementation of the System.Windows.Application class.

If you’ve worked with this class in Silverlight, you more than likely have handled the Startup event and examined the StartupEventArgs.InitParams property to do some type of initialization. For example, you may pass in a username or some type of permission list from your ASP.NET web app to your Silverlight application to determine what the user can and can’t do.

While you can certainly handle this event and access the InitParams of the StartupEventArgs in a Windows Phone application, there is currently no way to pass parameters into the application.

PhoneApplicationService

The other class you need to familiarize yourself with is the PhoneApplicationService class that resides in the Microsoft.Phone.Shell namespace. Through its properties and events, this class gives you access to different facets of the lifetime of your application.

Application Lifecycle

Now that we have an understanding of the two key classes involved with the lifecycle of a Windows Phone application, let’s take a look at the actual lifecycle through the various events and methods associated with the classes. Below is a simple diagram of the lifecycle.

Launch

When an application is first launched the constructor of the App class is called. If you take a look at the constructor that gets generated, you’ll see that there’s some event wiring, in the case of debugging there’s some profiling tools that are enabled, and there’s the typical Silverlight call to InitializationComponent().

There’s also a call to a generated method named InitializePhoneApplication(). If you take a look at the method you’ll see that it’s one of those “generated” methods that you really shouldn’t touch. All it does is create a RootFrame for your application while the splash screen is displayed. This RootFrame will eventually become the RootVisual for your application.

Shortly after the InitializePhoneApplication() is called the Launching event of the PhoneApplicationService is raised.

You’ll notice that in your App class an event handler was generated for this event. A quick word of caution here, I advise you NOT to load content from the web or isolated storage in this event handler as it will slow down your application’s start up, and could cause a time out.

After the Launching event is handled, navigation occurs to the RootFrame element that was created as part of the InitializePhoneApplication() method. After the navigation occurs the Navigated event gets fired which is handled by the CompleteInitializePhoneApplication() method. This is another one of those “generated” methods that you should only touch at your own peril. If you take a look at you’ll see that it simply makes the RootFrame the RootVisual for the application, which means your page will then be displayed. At this point your application is considered to be running.

Closed

From a lifecycle perspective, one of two things can happen next. Your application can be closed. For example, if the user press the hardware back button, your application will be closed. When this occurs the Closing event is fired by the PhoneApplicationService class and is handled by the generated Application_Closing method in your App class. You’ll want to make sure to save any PERSISTENT data, that is data that needs to be maintained across sessions of the application in the method before the application completely closes.

Deactivated

Alternatively, your application can be deactivated. Deactivation can be caused by several actions, including the lock screen engaging, the user pressing the home or search hardware buttons, or a launcher or chooser is invoked, for example, the phone’s web browser is launched.

When an application is deactivated, the Deactivated event of the PhoneApplicationService class is fired and handled by the generated Application_Deactivated method in your App class. As with the Application_Closing method, you’ll want to save any TRANSIENT data, data associated with the current session, before the application deactivated completely. However, unlike when an application closes, when an application deactivated, it only has 10 seconds to get through the Application_Deactivated event handler. Failure to complete deactivation in 10 seconds will prevent your application from being tombstoned and cause it to be terminated altogether.

Reactivated

If your application is successfully tombstoned, there’s an additional part of its lifecycle that could occur, reactivation The path that follows during reactivation is similar to when the application was initially launched.

I hope this helps you on your path to becoming a Windows Phone developer. If you want more information on the application lifecycle and execution model for Windows Phone applications you should read this article on MSDN: http://msdn.microsoft.com/en-us/library/ff817008(v=vs.92). It’s full of good information and links to “How To” articles.

Next up in this series I’ll discuss the Windows Phone navigation model.