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