Windows Phone 7 – Pivot Filtering with Caliburn.Micro

In this blog post I will introduce you to some basic functions of the Caliburn.Micro framework, along sharing the result of a small lab using it with a common Pivot scenario. Filtering.


First, what is Caliburn Micro ? It´s a lightweight MVVM framework, with support for WP7 specific features as TombStoning, Launcher, Choosers,  a PhoneContainer for simple IoC and uses naming conventions for binding and events. This gives you a neat framework to get going with your WP7 app development.

The demo project is based on the WP7 Visual Studio template that comes with Caliburn.Micro. To use the templates  download the latest build and run the power shell script to get your template zip file. Copy it to your template directory.

In the RTW of the Windows Phone 7 developer tools there are now a pivot control. So I set off to try this out, trying to mimic the scenario of the Inbox filtering.


If you look at the Pivot template that comes with the tools you see that the pivot items are populated with there content data. I was interested in trying to be able to provide that data in a another way, and also check if there was an easy way to apply the filtering in a “Lazy” way.


I used the “deafult” MainPageViewModel, this holds the different Pivots that I want to use. So I bind a collection of filters to the Pivot Control.  Caliburn will the display this model with the MainPage.xaml.  The property for the collection on the MainPageViewModel is named Items. Using Caliburns conventions, I could now use binding through naming the Pivot control items.

<controls:Pivot x:Name="Items" Title="Pivot Demo">
For this to work my viewmodel should be registered in the AppBootstapper, using some demo extensions. The bootstrapper is initialized by the App.xaml.
protected override void Configure()
  container = new PhoneContainer();

This will bind my Filter Collection (Items) to the Pivot Control. The control should be populated with a PivotItem for each filter. Inside each PivotItem the collection of data should be shown in a list box. I created a PivotFilter class to hold these properties. The filter collection now contain my PivotFilters. This enables me to bind the PivotFilter.Title to the PivotItem header for each filter. Each PivotFilter also contains a collection of its filtered items, to bind to the ListBox.

    <TextBlock Text="{Binding Title}" />
   <ListBox ItemsSource="{Binding Items}" ItemTemplate="{StaticResource SimpleList}" />

Basic bindings are done. To try out some lazy binding I need to be able to filter data each time a Pivot is changed. I found that the LoadingPivotItem event of the Pivot Control might be handy.   To be able to lazy filter I also need to the PivotFilter when the event is triggered. Using Caliburn I set this up like this:

<controls:Pivot x:Name="Items" Title="Pivot Demo">
    <i:EventTrigger EventName="LoadingPivotItem">
      <cal:ActionMessage MethodName="Filter">
        <cal:Parameter Value="$eventArgs" />

This will call a method on my MainPageViewModel named Filter each time the LoadingPivotItem is triggered. Caliburn also allows me to pass on the original eventargs to my method, so I could reach the item. The cal-functions comes from the CaliBurn framework through;


So now I have a simple foundation, lets refactor and put the PhoneContainer to use.

After refactoring a PivotFilter class for Flagged items looks like this:
public class FlaggedFilter : PivotFilter<MailItem>
  public FlaggedFilter(IDataProvider<MailItem> dataProvider)
            : base(dataProvider, true) {}
  public override string Title
    get { return "Flagged"; }

  protected override Func<MailItem, bool> FilterPredicate
    get { return x => x.Flagged; }
The second constructor parameter is for enabling/disabling lazy filtering. The first filter, that show all items should not lazy filter.
The class PivotFilter<TItem> exposes the Items to bind to the list box. To be able to “rebind” these after applying the filter NotifyPropertyChanged is needed. Caliburn provides a simple class to use here, PropertyChangedBase.
private set
  this.items = value;
  base.NotifyOfPropertyChange(() => this.Items);
All filters are registered in the AppBootstrapper.
container.RegisterSingleton<IDataProvider<MailItem>, DataProvider>();
container.RegisterSingelton<PivotFilter<MailItem>, AllFilter>();
container.RegisterSingelton<PivotFilter<MailItem>, UnreadFilter>();
container.RegisterSingelton<PivotFilter<MailItem>, FlaggedFilter>();

The MainPageViewModel’s Filter method now gets the EventArgs and are able to apply the filter for the selected Pivot Item.

I could now in an easy way filter a List of Items , lazy or not, depending on my scenario. This should not be seen as a sample how to filter, more a sample of using Caliburn Micro in a demo scenario.


When I got the Pivot filtering to work, I started to wonder if it would be easy to add tombstoning support.  Running the app in the emulator, filtered, then pressed the windows button on the “phone” the app is closed and the start screen appears. Pushing the back button “Resumes” the app, but when my app resumes I´m back at “All Items” . Why ? I did´t persist the state of my app when the app was tombstoned, and I didn’t resume it from that state.

Caliburn provides a attribute called SurviveTombstone. This gives you a way to Persist and resurrect the state of your model. This is done by a default implementation of ITombstone. So decorating your model with this attribute along with all properties to persist, will persist it to the phone.state.

If you use some other of Caliburn classes like Screen or Conductor this also gives you hooks for Activation and Deactivation among other things. So I used the Conductor class to keep track of my ActiveItem and Persist my SelectedIndex on tombstoning. More information and sample of Conductor and screen can be found in the WP7 documentation on the Caliburn micro site.

My app now supports  tomstoning in a simple way, though it refilters the ActiveItem on activation.


Download sample

sample code

This Post Has 8 Comments

  1. Rob Eisenberg

    Nice article! One quick comment on the action message. If you wanted, you could use the short syntax for that, like so:

  2. Rob Eisenberg

    Oops looks like it filtered out the interesting part. Maybe this will work

    cal:Message.Attach=”[Event LoadingPivotItem] = [Action Filter($eventArgs)]”>

  3. Math

    Thanks for your piece of code snippet.

  4. Scott Chappel

    I am interested in how you have used he filtering. Is the source available for download? (the link seems broken

  5. Juan Agüí

    Interesting post!
    I’d definitely love to peek at your source code, hopefully you could fix the download link?

Leave a Reply