Using the Application Bar in Windows Phone 7 applications

DZone 's Guide to

Using the Application Bar in Windows Phone 7 applications

· Mobile Zone ·
Free Resource

Triggering application events isn't much of a problem if you know the basics of Silverlight. There are buttons, toggles, all kinds of custom controls and automated event triggers. If you ever thought about implementing a custom list of actions for a user to choose from (e.g. a menu) in a Windows Phone 7 application, you don't have to implement a custom mechanism. Of course, nobody says you can't, but should you?

The public SDK comes with ApplicationBar - an UI unit that can be placed on a page that will let users choose from a set of options. It is an analogy for a menu - a control you are probably very familiar with from desktop systems and smartphones like Blackberry.

Unlike a regular menu control, ApplicationBar can only be used as a single instance per page, therefore you cannot create multiple menus on one page. However you can clearly divide the menu items in icons and text items - there is no difference in the functionality those can offer, the only difference being the appearance.

On a sidenote, an ApplicationBar is tied to a page and not to the application itself. Therefore, you should create separate ApplicationBar instances on different pages.

If I would have to represent the ApplicationBar shown above in XAML, it would look like this:

<shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">
<shell:ApplicationBarIconButton IconUri="/Images/appbar_button1.png" Text="Button 1"/>
<shell:ApplicationBarIconButton IconUri="/Images/appbar_button2.png" Text="Button 2"/>
<shell:ApplicationBarMenuItem Text="MenuItem 1"/>
<shell:ApplicationBarMenuItem Text="MenuItem 2"/>

Actually, this is the sample XAML markup provided in every new Windows Phone 7 application (by default it is commented out). But you can see the clear division - there are ApplicationBarIconButton instances, that are the icons that are shown at all times, and ApplicationBarMenuItem instances that are hidden if you are using the default options.

NOTE: The maximum number of possible ApplicationBarIconButton instances is limited to 4. The maximum number of menu items is limited to 50, but just on a sidenote - the ApplicationBar is really not the place to put more than 4-5 menu items.

If you've used Windows Phone 7, you probably noticed that some applications have a custom color defined for the background of the ApplicationBar. One good example would be the Twitter app. This is done by defining the BackgroundColor property:

<shell:ApplicationBar IsVisible="True" BackgroundColor="Green" IsMenuEnabled="True">

Of course, since white doesn't combine with every possible background color, you are also able to customize the foreground:

<shell:ApplicationBar IsVisible="True" BackgroundColor="Green" ForegroundColor="Blue" IsMenuEnabled="True">

As you can see, the border lines of the icon circles also change color. But it is important to note that depending on the icon, the circles might not be visible. Speaking of which, I would highly recommend looking here for some high-quality icons for the ApplicationBar that are bundled by default with the SDK:

C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.0\Icons

But of cours, that is not a requirement.

Both icon buttons and menu items can be tied to regular event handlers, just like any UI control - specifically, to the Click event handler:

<shell:ApplicationBarIconButton IconUri="ApplicationIcon.png" Text="Button 1" Click="ApplicationBarIconButton_Click"/>

Since there are situations when you don't need the menu, you can disable or enable it dinamically bychanging the IsMenuEnabled option.

It's interesting how the ApplicationBar buttons and menu items can be accesed from the code-behind. You can set the name for every one of them, however, try doing this:

myButtonName.IsEnabled = false;

And the moment you trigger this line, you will get a NullReferenceException.The problem is that in fact, both icon buttons and menu items aren't identified by their name, and this is clearly visible in Reflector. If you disassemble ApplicationBarIconButton, you should see this:

public class ApplicationBarIconButton : IApplicationBarIconButton, IApplicationBarMenuItem
// Fields
private EventHandler<BoolEventArgs> Changed;
private EventHandler Click;
private bool mEnabled;
private Uri mIconUri;
private string mText;

// Events
internal event EventHandler<BoolEventArgs> Changed;
public event EventHandler Click;

// Methods
public ApplicationBarIconButton();
public ApplicationBarIconButton(Uri iconUri);
internal void ClickEvent();
internal void UpdateOrRevert(object original, object field);

// Properties
public Uri IconUri { get; set; }
public bool IsEnabled { get; set; }
public string Text { get; set; }

A regular Button control (using this as an example) that follows this derivation sequence:

ButtonBase -> ContentControl -> Control -> FrameworkElement

The FrameworkElement class provides a NameProperty dependency property, IApplicationBarIconButton and IApplicationBarMenuItem do not provide an implementation for such, and neither does the fundamental class.

What you have to do here is reference menu and button objects by their index:

((ApplicationBarIconButton)ApplicationBar.Buttons[0]).IsEnabled = false;

Same applied to menu items:

((ApplicationBarMenuItem)ApplicationBar.MenuItems[0]).IsEnabled = false;

Just make sure that you are passing a correct index to avoid exceptions. Even if you add items to the ApplicationBar present in your page via code-behind, you will still have to access them via an index reference.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}