xaml ninja » Xaml

Metro Controls – Jump Viewer

rich — Fri, 30 Sep 2011 18:23:49 +0000

After an amazing week at //Build, I’ve been busy playing with the new controls, which I have to say are fantastic! Ollie and I know the pain first hand when it comes to building a Silverlight TUI (Touch User Interface) it’s not a great story and IMHO the controls are not ready. I may still post my thoughts on this experience, I’ve been holding back as I really don’t want to be dragged into the Silverlight is DEAD! debacle and this post could be taken in this way, however it will give you context around why we are so pleased that there is a new story and that one is awesome. But while I think about posting my experiences of building TUI on slates running Win 7, I’ve been putting together notes on the controls and thought that these may be beneficial to others so my objectives are to walk through some of the new controls and peel the layers like an onion. So, we can then go deep on certain topics.

So without further ado please say a big HELLO! to the Jump Viewer which is currently my favourite control. The interactions are stunning and performance is awesome! Before I start to dig in we should take a look at the finished control. The first screen shot is of the Jump Viewer when it first loads up in its zoomed in state and the second screen shot is taken when we peform an inwards pinch gesture which zooms out and the semantic zoom kicks in replacing the view with higher level details so that we can easily jump to another position in the Grid.

Note:- there are some anti-aliasing issues that happen periodically, not sure why this happens but I will update the post when I know more.

For more background reading on semantic zoom check out the guidelines for semantic zoom and also the sample in the SDK.

What I really like about the Jump Viewer is that it uses composition, allowing you to simply wrap up other controls that you may have used previously in order to deliver an immersive experience when interacting with the visualised data. In order to build a better understanding of the control we need to look at the Xaml. Lets start by concentrating on the JumpView which is the part of the control that is activated when we zoom out.

I have added my notes into the Xaml and hopefully this is a better way of groking the Xaml rather than snippets and dialogue, this way you can copy and paste the Xaml into your app and retain the notes.

Below is an illustration of the above Xaml and how the composite parts fit together.

What is very cool is the new Wrap Grid which provides the ability to change the layout of Jump View in the code above I do this.

In order to change the layout of the grid we can simply change the number of Maximum Rows or Columns, for example changing this property to 1 will change the layout to look more like the standard search control in Metro. Therefore, a quick tweak with how many rows or columns you want means that you can change the experience depending on the content being visualised. I will cover off the Wrap Grid in a future post.

Next we need to look at the content part of the Jump Viewer.



    
    
    
        <--
           Data template used to display the data
        -->

As you can see the Content section of the Jump Viewer comprises another control, in this case a Grid View, which provides the horizontal scrolling experience. A new feature for Metro is the ability to apply a Group Style on both the List and Grid View controls which provide the ability to group the data if your data model supports it. I will go into more detail about Group Styles in a future post. For now what we should understand is that when providing a Group Style we need to ensure that we provide a data template that will visualise the data in the header template and we can change the orientation of the layout by changing the Stack Panel in the Item Container Style from Vertical to Horizontal.

The Grid View also needs a data template for the items and there is also another new layout control called the Variable Sized Wrap Grid which is being used to layout the items in the Grid View. Once again I am loving this new layout and I will talk in more detail about the control in a future post. The most important thing for now is to understand that like the Wrap Grid, we can change the orientation and the Maximum Rows Or Columns properties which effect the layout of the items in the Grid. Sweet!

You may have also noticed that I have commented out the Virtualizing Stack Panel, I had problems when I used this, not sure why this is and when I find out more details I will update the post.

Enjoy!

WP7 Contrib – Bing Service Wrapper Part I – Location

rich — Fri, 24 Jun 2011 14:31:13 +0000

This being the first post about the Wrappers I thought that we should break the ice with the most commonly used service. Location. Out of all of the services this is the simplest to call but also we would suspect the most widely used. When you combine this service with the device location based WP7C bits then you can build your geo location aware app and have it plotting to a map and moving in real-time, or you could be helping your user to find the location of an address.

In the sample for using the location service we tackle both of these scenarios.

So, I am going to jump straight in here and assume that you have either looked at the sample in the Spikes folder of the WP7 Contrib (WP7C) or you have some experience of using the Rest API provided by the Bing Maps endpoint. If you have not done this then I would suggest opening up the sample and taking a quick look at the Location View Model, its pretty straight forwards so you should be back in 10.

First off if you have not already created a project then you need too. If you are using MVVM and some sort of DI library cool, if not no worries. There are two different options provided by the Location Service from the Bing REST API; you can either use the Geo Coordinate Location of the device and pass this to the service in order to give you back a current address; or you can enter a location to find out what Geo Coordinate Location is.

If you are not already using the WP7C components in you app (shame on you J) then you need to add a couple of references in order to get this up and running, these include:-

WP7Contrib.Services
- BingMaps
- BingMaps.Model
- Location

These are the basic bits that you need to get your geo location app up and running. Once we have included those assemblies then we need to define the interfaces we want to use and the data objects that correspond to the location service calls.

First up we need to declare the private fields so let’s go ahead and do that

private readonly IBingMapService bingMapService;
private readonly ILocationService locationService;
private LocationRect boundingRectangle;
private GeoCoordinate currentDeviceGeoCoordinate;
private IDisposable currentLocationObserver;
private RelayCommand selectFindMyCurrentLocationCommand;
private RelayCommand selectFindGeoLocationFromAddressCommand;
private Address address;
private LocationData locationDataByPoint;

Next, we need to create a constructor for our VM. You will notice that not only am I using the ILocationService which is the WP7C’s Rx location component but we are also going to pass in a IBingMapService which is our wrapper that we will use to call the REST services. The other interfaces that I am using here are the navigation service and the logging component from WP7C.

public LocationViewModel(
INavigationService navigationService,
ILocationService locationService,
IBingMapService bingMapService,
ILog log)
: base(navigationService, log)
{
this.locationService = locationService;
this.bingMapService = bingMapService;
this.address = new Address {CountryRegion = "UK", PostalCode = "LE17 5ER"};
}

Currently, and this is consistent across all of our samples we are using Funq as our DI framework of choice, its light and simple which is why it’s great for WP7, we are not bound to Funq in anyway so if you want to use your Favourite DI then you can do so.

With our constructor defined we need to go ahead and do our register and resolve in the bootstrapper.

There is quite a bit of stuff happening in the bootstrapper, mainly because of the fact that we are taking advantage of the different components inside of the WP7C, now you don’t have to use these however if you need things like logging; want to store data; and if you have a design where you are not loading all the VM’s upfront take a look at the Last Message Replay. As this is the first in a series of posts we can deconstruct what is happening here in the future articles I will only reference this section.

The code below setups the Logging bits for us.

this.Container.Register(c => new LoggingService("BingMaps"));
this.Container.Register(c => this.Container.Resolve());
var logManager = this.Container.Resolve();
logManager.Enable();

Here we setup the settings for the app and assign the key that we want to use for bing maps. The registered key in the code is registered to the WP7C so I would advise that you register, it does not take long and the key is generated instantly.

this.Container.Register(c => new SettingsStore(this.Container.Resolve()));
this.Container.Register(c => new Settings("Bing Key"));
var serialisationAssemblies = new List { this.GetType().Assembly };

Setup the cache provider and initialise it.

this.Container.Register(c => new  IsolatedStorageCacheProvider("BingMaps", serialisationAssemblies,  c.Resolve()));
var cache = this.Container.Resolve();
System.Threading.ThreadPool.QueueUserWorkItem(state => cache.PreemptiveInitialise());

Setup the last replay messenger.

this.Container.Register(c => new LastMessageReplayMessenger());

Setup the WP7C Navigation Service.

this.Container.Register(

c => new ApplicationFrameNavigationService(((App)Application.Current).RootFrame));

Setup the WP7C Network service

this.Container.Register(c => new NetworkMonitor(5000));

Setup the WP7C Storage service.

var assemblies = new List { this.GetType().Assembly, typeof(BaseModel).Assembly };
this.Container.Register(c => new StorageService(assemblies, c.Resolve()));

As we are using the Resource Client from WP7C we also need to add this setup code into our bootstrapper.

this.Container.Register(c => new UrlEncoder());
this.Container.Register(c => new ResourceClientFactory(c.Resolve()));

The final part is that we need to wire in the IBingMapService which needs to be resolved using some of the interfaces that we registered earlier.

this.Container.Register(c => new BingMapService(
c.Resolve(),
c.Resolve(),
c.Resolve(),
c.Resolve(),
c.Resolve()));

Ok, so we nearly have, all of the underlying plumbing done what we need to do next is to setup the VM locator. If you need more details on this please refer to the sample code. Once you have the VM locator updated we can go ahead and bind our Data Context up to the VM using the service locator pattern in Xaml.

As I mentioned at the start of this article, the UI’s are more about form and function, so our intentions are purely to visualise all the different types of data coming back from the service. So, for this we went with simple UI controls to make sure that the data being returned from our request is correct.

Now, that we have the plumbing in place, and some simple UI that displays the responses, our next step is to make our requests out to the Bing Services. This code is going to live in the VM.

The first thing on our list to implement is that we need to make our app location aware, everything you need to do this is already baked in the WP7C, it just requires a simple bit of Rx to get it wired in. In order to do this we need to leverage the ILocation Service that we injected into the VM as this will find out what our current location is.

private GeoCoordinate currentDeviceGeoCoordinate;
private IDisposable currentLocationObserver;
private void ExecuteSelectFindMyCurrentLocationCommand()
{
try
{
this.currentLocationObserver =
this.locationService.Location()
.ObserveOnDispatcher()
.Subscribe(geoCoordinate =>
{
this.CurrentDeviceGeoCoordinate = geoCoordinate;
this.SearchForLocation(this.BuildLocationSearchForPoint());
});
}
catch (Exception exn)
{
MessageBox.Show(string.Format("Failed! Message - '{0}", exn.Message), "Location Search",                MessageBoxButton.OK);
}}

Notice in the subscribe how we are assigning a value to the VM’s Current Device Geo Coordinate Property which is bound up in the view; also note that we are then doing a Search for a geo location and passing into this method the result from the Build Location Search For Point. We decided that in order for us to wrap up all the services and provide a common API from which users can use the services we would adopt a factory style pattern. So, what’s going on in the Build method? Well here we are calling out to the factory and asking it to create what we need in order to query the Bing services for dealing with the request.

private ILocationSearchPointCriterion BuildLocationSearchForPoint()
{
return CriterionFactory.CreateLocationSearchForPoint(this.CurrentDeviceGeoCoordinate);
}

And that is all you need to add location awareness to your app, I hope that you agree with me that this is rather straight forwards. Next up we need to build out the search for location method, which is going to use the Bing wrapper service from the WP7C to search for a location. If you have looked over the code you will see that we have 2 overloaded methods, one which deals with Geo Location and the other which deals with addresses.

private void SearchForLocation(ILocationSearchPointCriterion criterion)
{
this.bingMapService.SearchForLocationUsingPoint(criterion)
.ObserveOnDispatcher()
.Subscribe(this.ProcessSearchLocationByPointResponse,
FailedSearch,
CompletedSearch);
}

And for completeness I have included the code for the address mechanism below.

private void SearchForLocation(ILocationSearchAddressCriterion criterion)
{
this.bingMapService.SearchForLocationUsingAddress(criterion)
.ObserveOnDispatcher()
.Subscribe(this.ProcessSearchLocationByAddressResponse,
FailedSearch,
CompletedSearch);
}

Note that there are a couple of differences between the overloads; first the interface type that we are passing into our method for locations we always need to use the ILocationSearchPointCriterion and for addresses we need to use the ILocationSearchAddressCriterion; and the other difference is that we use a different method to deal with the response that we get sent from the Bing Services.

private void ProcessSearchLocationByPointResponse(LocationSearchResult result)
{
if (result == null)
{
return;
}
if (result.Locations.Count != 0)
this.LocationDataByPoint = result.Locations[0];
}

In order to successfully process the data and then work on this data the WP7C provides you with the data transformation classes that you need and does all the map and wrap code so that you don’t have to. In the code above this is illustrated by our use of the LocationDataByPoint property which uses the Location Data class from the WP7C, we are using databinding in the view and wiring up to this property from the VM .

So, just to recap what we have covered are a couple of things here; first we made our app Geo Location aware by using the WP7C Rx location service; which was then wired up to the Bing Services Wrapper and we used this to provide an address of the device’s current location; and for completeness we provide a way for the user to enter details of an address and the app responds with a Geo Location that corresponds to the address.

Admittedly we are doing some simple tasks here however its super important that we put in the ground work so that you can gain a deep understanding of how the wrappers work. We would really like to hear your feedback, if you have built an app using the Bing services we would also be interested in talking to you about your sceanrios.

In the next post I will dig into using the Route Service.

Ollie has some deep dive blog posts planned which are based around the patterns that he is using along with some gems of information around using Rx with these more traditional patterns so watch out for those.

Enjoy!

WP7Contrib – Page Transitions and Navigation Service

rich — Mon, 21 Mar 2011 15:33:27 +0000

I finally got around to updating the page transistions in wp7 contrib last week, its something that has been on my list for awhile. For a complete sample project check out the sample in the spikes folder where you can also find lots of other samples illustrating other tennants of the contrib.

The transitions used in the WP7C are based around the great work of Kevin Marshall who originally created the transitions, we like them becuase they are lighter on memory usage and slightly faster when compared to the page transitions found in the WP7 toolkit. Now that is not too say I dislike the transitions in the toolkit, I actually really like them mainly because we have the ability to define these transitions in Xaml and hopefully there will be some future design-time support in Blend where we could run these transitions. Xaml support for the transitions is definately on the vNext list for the WP7C as we believe its important for designers to able to change, apply and understand the different transitions that are available.

When comparing implementation details, the toolkit uses a custom Frame called a Transition Frame; and WP7C does this at a page level all the pages in your app have to sub class the Animated Base Page. Other differences include; the toolkit uses a Render Transform and WP7C uses Composite Transform; the WP7C uses the XamlReader.Load to setup the storyboards, however the toolkit has specific loose Xaml files that contain the storyboards.

So the new page transitions includes the different Rotate permutations for your page transitions, I also added in some new slide and fade transitions. You can play with these and all the other different transitions by downloading the sample app.

The other thing that I decided to add into the app was a very simple implementation of the WP7C navigation service. Page transitions and navigation are interconnected, when you navigate to a page you want to execute a transition between the current page and the new page, this is approapiate when going forwards or backwards. Normally we would wire up the WP7C Navigation Service in the bootstrapper of our app and use a DI framework to new this up. In order to keep everything super simple I am using the interface and manually newing up an instance, also note that I am not using a View Model this is simply to show the flexibility of the WP7C Navigation Service.

private WP7Contrib.Services.Navigation.INavigationService navigationService;

public MainPage()
{
        InitializeComponent();

       AnimationContext = LayoutRoot;
       this.navigationService = new WP7Contrib.Services.Navigation.ApplicationFrameNavigationService(
                                   ((App)Application.Current).RootFrame);
}

Notice how we grab the RootFrame and pass this in to the constructor of the WP7C Navigation Service the same code can be used in a bootstrapper. When using the WP7C transitions there is no requirement for us to change the base class of the frame in the App’s Initalize Phone App handler like we would do when using the toolkit.

private void InitializePhoneApplication()
{
    if (this.phoneApplicationInitialized)
    {
        return;
    }

    // Create the frame but don't set it as RootVisual yet; this allows the splash
    // screen to remain active until the application is ready to render.
    this.RootFrame = new TransitionFrame();
    this.RootFrame.Navigated += this.CompleteInitializePhoneApplication;

    // Handle navigation failures
    this.RootFrame.NavigationFailed += RootFrame_NavigationFailed;

    // Ensure we don't initialize again
    this.phoneApplicationInitialized = true;
}

Instead we need to hang all our pages from the Animated Base Page, pay close attention to; the constructor where we assign the Animated Context of our base page to the LayoutRoot of our page; and the overridden Get Animation where we are deciding which transitions to fire based on the Animation Type.

namespace PageTransition
{
    using System;

    using WP7Contrib.View.Transitions.Animation;

    public partial class Slide : AnimatedBasePage
    {
        public Slide()
        {
            InitializeComponent();

            AnimationContext = LayoutRoot;
        }

        protected override AnimatorHelperBase GetAnimation(AnimationType animationType, Uri toOrFrom)
        {
            if (animationType == AnimationType.NavigateForwardOut)
            {
                return new SlideLeftFadeOutAnimator { RootElement = LayoutRoot };
            }

            if (animationType == AnimationType.NavigateBackwardOut)
            {
                return new SlideRightFadeOutAnimator { RootElement = LayoutRoot };
            }

            if (animationType == AnimationType.NavigateForwardIn)
            {
                return new SlideLeftFadeInAnimator { RootElement = LayoutRoot };
            }

            return new SlideRightFadeInAnimator { RootElement = this.LayoutRoot };};
        }
    }
}

For completeness I have covered off the different permutations of Navigating forward or backward. The implemented page transitions have a corresponding Animator which makes it straightforward to implement the type of animation that you require. And that is everything you need in order to get page transitions working in your app. Once you have implemented the transitions you want then its a fairly simple task of using the WP7C Navigation Service to navigate to a page in your app.

private void OnSelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (AnimationList.SelectedIndex != -1)
    {
        switch (AnimationList.SelectedIndex)
        {
            case 0:
                this.navigationService.Navigate(new Uri("/View/Turnstile.xaml", UriKind.Relative));
                break;

            case 1:
                this.navigationService.Navigate(new Uri("/View/TurnstileFeather.xaml", UriKind.Relative));
                break;

            case 2:
                this.navigationService.Navigate(new Uri("/View/Continuum.xaml", UriKind.Relative));
                break;

            case 3:
                //slide right
                this.navigationService.Navigate(new Uri("/View/SlideRight.xaml", UriKind.Relative));
                break;

        }
    }
}

And we are done!

Couple of things to watch out for when implementing the page transitions

Make sure that you have the correct base url in you WMAppManifest.xml.
It should look something like this
```
      
    
```
Even if you have a sub folder which contains your Views
If you have already overriden the OnBackKeyPress handler remember to call the base implementation

If you have created transitions and happy to share or have ideas for ones you would like to see then please contact me.

WP7 Contrib – the last messenger

rich — Thu, 27 Jan 2011 17:43:42 +0000

As you may already be aware the WP7C uses MVVM Light as its preferred MVVM framework. Laurent has a great implementation of a Mediator style pattern that he has aptly name the Messenger. What I really like about this is the simplicity when it comes to implementing the baked in messages and how you can extend the IMessenger interface that Laurent has included in MVVM Light. In general these generic messages cater for the majority of problems. However, there is a case that is not particularly well catered for. What follows is focused on WP7 however, this messenger component could be recompiled under your favourite SL build and used in your MVVM Light application today.

Before we start to roll you are going to make sure you have all the bits installed

WP7 Dev tools ISO download thanks JaimeR

MVVM Light Toolkit

WP7 Contrib

Now if you are using some sort of DI component, at the moment my favourite is funq (Ninject will always have a place in my heart) you may have found yourself in a situation where by you want to pass data from one VM to another, however the VM you want to pass the data to has not yet been created. There are various ways around this like not using DI and newing up all your VM during start-up so that this is no longer an issue. But, remember we are running under WP7 and performance is never going to be what it’s like in the browser. We also want to take advantage of DI and all the goodness that it brings to the party.

Which came first, the chicken or the egg ??

An inherent problem with using Silverlight navigation and DI and having your VM’s lazily loaded. When you navigate to a page its not until this moment in time that your VM is constructed, therefore we hit this timing problem where the VM that is loaded up and trying to send a message to a VM which has yet to be loaded. What we first started out with was an implementation that was not so polished in that we would have a Register and Send Message being defined in the VM making the call; a Register Message defined in the receiving VM; and a callback Message in the receiving VM.

The way in which this works would be something like :-

VM SearchPeople Registers for Message CurrentlySelectedPerson
In response to an interaction in the View (i.e. selecting an item in a list box). The associated VM SearchPeople Sends Message CurrentlySelectedPerson from within a INPC Property
In response to an interaction in the View (i.e. tapping an item in a list box). The associated VM SearchPeople ‘s RelayCommand navigates to a new page Person Details
VM Person Details is constructed by our DI framework
VM Person Details constructor Registers for the Message CurrentlySelectedPerson
VM Person Details constructor fires a CallBack for the MessageCurrentlySelectedPerson
VM SearchPeople received the Message CurrentlySelectedPerson
VM SearchPeople Send the Message CurrentlySelectedPerson
VM PersonDetails received the Message CurrentlySelectedPerson

This mechanism has to deal with the timing issue of the second VM not being loaded before the message is sent from the first, we end up in a situation where the first message never works and the subsequent messages always work. Therefore, by providing a callback in the second and sending the message from here to the first VM we solve the problem, but its not as elegant as it could be. The main issue here is that we are forced to send our messages twice due to the fact that our recipient VM has yet to be created and we need to give it a poke.

What becomes apparent is that the callback mechanism is not built for this type of work and we need a more structured and direct messaging mechanism. I had a chat with Ollie and he came up with a great messaging implementation. The rest of this post is concerned with how to use this Replay Messenger in your app, Ollie has a great post coming where he is going to go into more detailed post on the implementation details.

Laurent has provided an interface called IMessenger which provides developers with the ability to extend the and create our own Messages, nice… Let’s make a start on building out a simple implementation. If you have all the bits installed lets make a start. First off what is this app we are going to build, well is a simple app which has some sort of people list and we can select a person from the list and navigate to a more detailed page. Not the most exciting of apps but I want to keep the context fairly striaght forward so that we can concentrate on the problem and the solution rather than being distracted by other stuff. Saying that you are going too meet some other interface from WP7Contrib, ILogManager, ILog and INavigation Service. Over on the right you can see an screen shot showing the strcuture of the sample which can be found in the Spikes dir of the WP7Contrib.

My intentions below are not to walk you through every step we have some planned detailed posts and maybe even some screencasts to illustrate this points, therefore I am assumming that you know about the message classes availavble to you in MVVM Light Messaging and I am also assuming that you understand how to uses a DI framework.

Over on the right there is a screen grab of the solution if you want to fire this up then you can find it in the Spikes dir of the WP7Contrib. I have a model class called Person this is going to hold our data;2 pages main page and child page; 2 corresponding View Models main VM and child VM; in messages I have a base message and something called the Selected Person Message; a custom Base VM for WP7 which subclasses the MVVM Light VM Base; and finally I have a BootStrapper for my DI bits.

So first off what we need to do is take a look at the Selected Person Message as this is the message which is a wrapper for our data that we want to pass from the Main VM to the Child VM.

namespace ReplayLastMessageMessenger.ViewModel.Messages
{
    using System;

    using ReplayLastMessageMessenger.Model;

    /// 
    /// The currently selected search result message.
    /// 
    public class SelectedPersonMessage : BaseMessage
    {
        #region Constants and Fields

        /// 
        /// The person.
        /// 
        private readonly Person person;

        #endregion

        #region Constructors and Destructors

        /// 
        /// Initializes a new instance of the  class.
        /// 
        /// 
        /// The person.
        /// 
        public SelectedPersonMessage(Person person)
        {
            this.person = person;
        }

        /// 
        /// Initializes a new instance of the  class.
        /// 
        /// 
        /// The exception.
        /// 
        public SelectedPersonMessage(Exception exception)
        {
            this.Exception = exception;
        }

        #endregion

        #region Properties

        /// 
        /// Gets person.
        /// 
        public Person Person
        {
            get
            {
                return this.person;
            }
        }

        #endregion
    }
}

The code above is boiler plate making the implementation clean and repeatable, the code above is the message that we use for passing Property data between our VM’s.

That’s the message built.

Remember, what we have in our view is a list of items, and in our case a list of people and when you select an item from the list we navigate from this page to a details page, and we do this by sending a message that contains the data of the currently selected item from the list.

/// 
/// Gets or sets CurrentlySelectedPerson.
/// 
public Person CurrentlySelectedPerson
{
    get
    {
        return this.currentlySelectedPerson;
    }

    set
    {
        this.SetPropertyAndNotify(ref this.currentlySelectedPerson, value, "CurrentlySelectedPerson");
        this.NavigationService.Navigate(new Uri("/View/ChildPage.xaml", UriKind.Relative));
        this.MessengerInstance.Send(new SelectedPersonMessage(this.currentlySelectedPerson));
    }
}

Note, in the above code the Messenger is only responsible for sending message, its the Navigation Service that is responsible for the navigation from the list page to the details page and the details page displays the details of the data item selected from the list, therefore the Child VM will need to know the currently selected person. I will cover off the Navigation Service interface in a future post.

In order to do this we need to inject the IMessenger into each VM from our bootstrapper. I am using funq for this so the code below is specific to funq however it’s the same drill register your wire ups with the container and then resolve them to an interface, This will provide a way of firing Registering and Sending those Currently Selected Person messages.

public class BootStrapper : IDisposable
{
    #region Constants and Fields

    /// 
    /// The disposed.
    /// 
    private bool disposed;

    #endregion

    #region Constructors and Destructors

    /// 
    /// Initializes a new instance of the  class.
    /// 
    public BootStrapper()
    {
        this.Container = new Container();

        this.ConfigureContainer();
    }

    #endregion

    #region Properties

    /// 
    /// Gets Container.
    /// 
    public Container Container { get; private set; }

    #endregion

    #region Implemented Interfaces

    #region IDisposable

    /// 
    /// The dispose.
    /// 
    public void Dispose()
    {
        if (this.Container != null)
        {
            this.Container.Dispose();
            this.Container = null;
        }
    }

    #endregion

    #endregion

    #region Methods

    /// 
    /// The configure container.
    /// 
    private void ConfigureContainer()
    {
        this.Container.Register(c => new LoggingService());

        this.Container.Register(c => this.Container.Resolve());

        this.Container.Register(c => new LastMessageReplayMessenger());

        this.Container.Register(
            c => new ApplicationFrameNavigationService(((App)Application.Current).RootFrame));

        this.Container.Register(
            c => new MainViewModel(c.Resolve(), c.Resolve(), c.Resolve()));

        this.Container.Register(
            c => new ChildViewModel(c.Resolve(), c.Resolve(), c.Resolve()));
    }

    #endregion
}

There are a couple of interfaces here that I am injecting into my VM’s these include the Navigation Service, the log manager and the log all of which we will talk about in future posts.

Again, Laurent has done a great job by providing a property in the View Model Base called Messenger Instance which returns the instance of the messenger we injected in our bootstrapper, nice. There is a small nugget here as well to help with performance, as the registration of the message does not need to happen on the UI thread we can wrap this up like so.

The Main VM looks like this.

public MainViewModel(INavigationService navigationService, IMessenger messenger, ILog log)
    : base(navigationService, messenger, log)
{
    ThreadPool.QueueUserWorkItem(state =>
    {
        // messaging
        this.MessengerInstance.Register>(
            this, message => message.Execute(this.CurrentlySelectedPerson));
    });
}

Now in the constructor of the Child VM its far sweeter code instead of the crufty callback and force a message in order to get the data we simply register for the replay message we are interested in, and provide a method to deal with the received message.

public ChildViewModel(INavigationService navigationService, IMessenger messenger, ILog log)
    : base(navigationService, messenger, log)
{
    ThreadPool.QueueUserWorkItem(state =>
    {
        this.MessengerInstance.Register(this, this.OnReceiveMessage);
    });
}

The Xaml in the Main View looks like this.

The Xaml in the Child View looks like this.

Just to recap our steps were :-

Define the Message which wraps up the data
Add the IMessenger interface as a parameter in the VM constructor
Register the IMessenger interface with the Last Message Replay Messenger
In the originator register the type of message data you’re interested in with the Notification Message Action
In the VM which is interested in the message register for the Message defined in step 1
Provide a method that deals with the received messages and setups up the data context of the View

You can find out more information on the WP7Contrib and find out what people are saying on twitter #WP7Contrib.

As i mentioned at the start if you are already using MVVM Light today then you can take advantage of the Last Replay Message. Ollie is going to follow up with a more detail post on the implementation details.

WP7 Contrib – Customising the DateTime Picker

rich — Sun, 23 Jan 2011 18:45:44 +0000

As you may already be aware there are two controls in the WP7 toolkit that provide the standard interactions and UI for selecting time and a date. Personally these are 2 of my favourite controls mainly due to the transitions and simple UI. However….. What happens when we are building an application that needs you to enter credit card details ? Or you only want a subset of the provided controls i,e, a Month and a Year ? Unfortunately at the moment AFAIK there is no way of doing this with the provided controls, its just not possible using Xaml either via the Style or the Template. We need to dig in a little deeper and find out what controls are actually powering these pickers. Well you don’t have to go too far before you find something called the Looping Selector control, the control provides an Item Template so that we can if we want add our own Data Template if so desired.

So why would you want to do this ? Well for us we need to provide an experience where the user of the app is prompted to enter in their credit card details. It seems only sensible to use the standard UI metaphor for picking a Date or a Time on WP7. As I found out this is just not possible and a level of customisation is required in order to achieve the interactions that we want along with the right experience.

This problem can be divided into two main pieces; data we will need to provided some subclassed data sources for day, month and year; UI we need to change the looping selectors visibility and do some work around hooking up the controls with data.

In the WP7 Contrib View project you can locate the DateTime Picker folder where the data sources are defined to support the picker. The main thing that we here is to reuse the same data source classes that are defined in the toolkit however we have changed the accessor to be public so that we can seem where we are using the control. The code below is here for completion and your viewing pleasure.

The Day DataSource

namespace WP7Contrib.View.Controls.DateTimePicker
{
    using System;

    public class DayDataSource : DataSource
    {
        // Methods
        /// 
        /// Gets the relative to.
        /// 
        /// The relative date.
        /// The delta.
        /// 
        protected override DateTime? GetRelativeTo(DateTime relativeDate, int delta)
        {
            int num = DateTime.DaysInMonth(relativeDate.Year, relativeDate.Month);
            return new DateTime(relativeDate.Year, relativeDate.Month, ((((num + relativeDate.Day) - 1) + delta) % num) + 1);
        }
    }
}

The Month DataSource

namespace WP7Contrib.View.Controls.DateTimePicker
{
    using System;

    public class MonthDataSource : DataSource
    {
        // Methods
        /// 
        /// Gets the relative to.
        /// 
        /// The relative date.
        /// The delta.
        /// 
        protected override DateTime? GetRelativeTo(DateTime relativeDate, int delta)
        {
            int num = 12;
            int month = ((((num + relativeDate.Month) - 1) + delta) % num) + 1;
            return new DateTime(relativeDate.Year, month, Math.Min(relativeDate.Day, DateTime.DaysInMonth(relativeDate.Year, month)));
        }
    }
}

The Year DataSource

namespace WP7Contrib.View.Controls.DateTimePicker
{
    using System;

    public class YearDataSource : DataSource
    {
        // Methods
        /// 
        /// Gets the relative to.
        /// 
        /// The relative date.
        /// The delta.
        /// 
        protected override DateTime? GetRelativeTo(DateTime relativeDate, int delta)
        {
            if ((0x641 == relativeDate.Year) || (0xbb8 == relativeDate.Year))
            {
                return null;
            }
            int year = relativeDate.Year + delta;
            return new DateTime(year, relativeDate.Month, Math.Min(relativeDate.Day, DateTime.DaysInMonth(year, relativeDate.Month)));
        }
    }
}

Now that we have redefined these datasources we want to use in our customised implementation the next part is to take a look at the guts of the Xaml that is being used to compose the Picker as we mentioned earlier on there is the LoopingSelector that can be found in the Primitives namespace. This control is rather nice and does what it says on the tin, by providing a gambling machine style interaction. If you take a look at the Xaml defined in the DateTimePicker.xaml this is essentially what we need, so again this is pretty much a copy and paste job. I created a new user control called MonthYearPicker.xaml and stuffed the Xaml in here. The only changes that we need to make in the Xaml is to change the visibility of the looping selector that you don’t want to present to the user, in my case this was the day. Now we could do some more sophisticated stuff here, like provide an attached Dependency Property to control the visibility of the selector this is on the list so watch this space, but if you can think of any others shout.

The final piece of the puzzle is the wire up, you maybe thinking why can’t you remove the looping selectors that you don’t want ? Well I thought that same thing, however its does not seem possible as the LoopingSelector wants 3 parts to be initialised; a Primary Part / Selector; a Secondary Part / Selector; and a Tertiary Part / Selector. Therefore we have to define all of the selectors in the Xaml. Now that we have that worked out we need to bring over some of the methods from the codebehind the picker from the toolkit.

Initialisation code

public MonthYearPicker()
        {
            this.InitializeComponent();
            this.PrimarySelector.DataSource = new YearDataSource();
            this.SecondarySelector.DataSource = new MonthDataSource();
            this.TertiarySelector.DataSource = new DayDataSource();

            ((DataSource)this.PrimarySelector.DataSource).AltSelectionChanged += this.HandleAltDataSourceSelectionChanged;
            ((DataSource)this.SecondarySelector.DataSource).AltSelectionChanged += this.HandleAltDataSourceSelectionChanged;
            ((DataSource)this.TertiarySelector.DataSource).AltSelectionChanged += this.HandleAltDataSourceSelectionChanged;

            this.InitializeDateTimePickerPage(this.PrimarySelector, this.SecondarySelector, this.TertiarySelector);
        }

Composition of the parts for the picker

        /// 
        /// Gets a sequence of LoopingSelector parts ordered according to culture string for date/time formatting.
        /// 
        /// 
        /// LoopingSelectors ordered by culture-specific priority.
        /// 
        protected override IEnumerable GetSelectorsOrderedByCulturePattern()
        {
            return GetSelectorsOrderedByCulturePattern(CultureInfo.CurrentCulture.DateTimeFormat.ShortDatePattern.ToUpperInvariant(), new char[] { 'Y', 'M', 'D' }, new LoopingSelector[] { this.PrimarySelector, this.SecondarySelector, this.TertiarySelector });
        }

Handles the alt data source selection changed.

        /// 
        /// Handles the alt data source selection changed.
        /// 
        /// The sender.
        /// The  instance containing the event data.
        private void HandleAltDataSourceSelectionChanged(object sender, SelectionChangedEventArgs e)
        {
            DataSource source = (DataSource)sender;
            if (source is YearDataSource)
            {
                // Set the year part of the value
                this.PrimarySelector.DataSource.SelectedItem = source.SelectedItem;
                if (source.SelectedItem != null && this.Value.HasValue)
                {
                    this.Value = new DateTime(
                        ((DateTimeWrapper)source.SelectedItem).DateTime.Year, this.Value.Value.Month, 1);
                }
            }
            else if (source is MonthDataSource)
            {
                // Set the month part of the value
                this.SecondarySelector.DataSource.SelectedItem = source.SelectedItem;
                if (source.SelectedItem != null && this.Value.HasValue)
                {
                    // Get the last day of the month
                    this.Value = new DateTime(
                        this.Value.Value.Year, ((DateTimeWrapper)source.SelectedItem).DateTime.Month, 1);
                }
            }
            else if (source is DayDataSource)
            {
                // We don't care about the day
                this.TertiarySelector.DataSource.SelectedItem = source.SelectedItem;
            }
        }

And there we have it DateTime Picker control which you can customised to show the selector that you want to show under different experiences. Our main job has been to refactored some of the code in the toolkit in order to access it from outside and also the changes to the xaml, nothing too taxing. I am pretty certain that this same approach could be used on the Time Picker, I have not tried this however there does not appear to be any particular reasons why this would not be possible.

As always interested in your thoughts and feedback…

What this space for more about the WP7Contrib soon to hit the shelves at a Codeplex near you….

You can download the code from here on Codeplex and take a look at spikes where you can find this sample and others or you can get it from here

The cleansing process

rich — Wed, 13 Oct 2010 11:32:04 +0000

I spend a large proportion of my time collaborating with UI designers and UI interaction designers where we work closely together to produce interactive UI’s for customers. As someone who is a novice when it comes to Adobe Illustrator and Photoshop I am very reliant on the import functionality in Blend. In this post I want to talk about a simple process that we have adopted to help with bringing those assets from AI and PS in our Xaml based projects.

Before the import features in Blend appeared we used the cool plug-in from Mike Swanson which would allow us to convert vector art work in Xaml. This was incredibility useful and mean that we reduce the time it took to convert these assets into Xaml and then modifying the Xaml in Kaxaml or in Blend. The process worked for us and we continued down this path until the import features in Blend improved and are now at a state where we can easily use the import functionality in Blend to convert these assets even easier.

But, that is not where the story ends, if you have tried out the import process on complex AI or PS visuals then you will have found that when Blend performs the import it positions each layer into a Canvas and will also import any images into the project as well. All in all this is cool however not so much when you have an existing project where you are happy with the code architecture and the folder structure of your application. And, this is what I want to dig into in this post is how to use the import functionality to your advantage.

Where do we start, ok so lets imagine that you have a project which you have setup or a developer on the team has created, its nicely structured and potentially uses MVVM or even a MVVM framework like MVVM Light. We also have a bunch of great looking designs that we need to convert into Xaml assets. We have a couple of options available at this point; we can import directly into the main solution or we can create a separate project a scratch project where we can import into. Admittedly at first I started out by importing directly into the main solution however this became a headache as the solution becomes polluted, by this I mean that when we do the import Blend will create a new folder in our project to hold the images that are referenced in the AI file however we are more than likely have an images folder in the project where all our images live. And for me this is where the management headache begins as we have to work out which images we want to keep and the ones we want to remove, and we also have to then move these images to the right folder and change the references to these images from the Xaml. All in all not too difficult when we break them down but on a large import this can become rather sticky very quickly.

Because of these issues what I have found is that importing into a scratch project is a smoother process for creating your Xaml assets and managing what images you want to keep. So the process goes something like this.

Create a scratch project and setup the folder structure for your Resource Dictionaries and images to mirror the same structure in the main project. Then import you AI or PS file into this project.

Next start to clean up your imported Xaml, the majority of the time you will want to ungroup the visual elements from their containing canvas as the visual elements will have been relatively positioned to mirror the layout defined in AI or PS. You will also find that the designer will have used a number of different layers to create the final appearance of an element. For example the designer may have used 4 different layers in order to create the colour of an element. In these cases my approach is to use the colour picker in Blend to find out what the colour is of the topmost layer, create this colour as a resource in your Resource Dictionary and then remove all the underlying layers until your left with the topmost then apply your newly created colour resource so that the visual element looks like the original. We could leave the visual elements as is however there are performance issues that we may encounter when doing this, in that if you have a list and you are planning on using this visual a number of times then those hidden layers are going to be present in the visual tree which means that the framework will render these and will have an impact on the performance of the application.

Other items to look out for are drop shadows on elements, when performing the import the drop shadows will be translated in a png images. In the majority of cases removing these images and replacing them with a drop shadow effect is the best mechanism, however there are some cases where the png works better. These situations are related to interaction design and occur when you are either; animating the visual elements on screen from one position to another; or you animating the drop shadow effect itself; in these circumstances then leaving the png is desirable and you may also consider using the EnableGPUAcceleration param at the plugin level along with setting the Bitmap Caching mode on your Xaml element.

By this stage you should now have cleansed your import and are ready to start styling and templating the imported visual elements into controls. There are two options available to you at this stage and they are related to your experience and confidence around the templating of the controls.

The first option is to group up the different visual layers that you want to make into the control, the majority of the time grouping them into a Grid or a Canvas will work for you. From here you can then right click on the layout panel that you created and select “Make into Control” option where you can select from the popup dialog the control that you want to create a style for. From here you can start to assign the visual elements to the parts associated with that template.

The second option is to drag onto the art board the control that you want to style and template and size the control to be the same as the visual elements. Right click on the control and select the “Create a Copy” sub menu option located under “Edit Template” option. This will then provide you with a default template which you can then start to modify so that it takes on the appearance of the visual.

The first option works well if you have intermit knowledge of the template you are creating, it can also work well when you know that you are creating styles and templates for controls which are of a fixed height and width. However, if this is not the case then the second option is a preferred route.

The styles, templates, colour and brush resources that you are using need to be added into the correct Resource Dictionaries. By following this approach you can then pick up the visual elements and merge them into your main solution along with the modifications to the Resource Dictionaries and moving any images that you are using into your images folder.

I hope this insight helps both designers who are creating assets using Adobe products to think about some best practices on how you construct your designs and for the Blend folks this should help with cleaning up the imported Xaml.

As always please let me know your thoughts and also what you have found works best for you.

PathListBox Adventures – radial layout

rich — Mon, 29 Mar 2010 11:13:45 +0000

The PathListBox ROCKS, if you have not heard of this control before then checkout Christians blog for more details and also his session at mix 10. The PathListBox solves some of the tricky issues related to creating custom panels for a ListBox or ItemsControl. Previously when we need custom layout of visual elements inside of these controls we would typically create a custom Panel and crank C# code and some positioning logic to layout the elements as we needed. However, with the introduction of the PathListBox we nolonger have to resort to building a panel and thus lowers the barrier to entry for designers who want to create custom layouts without having to be reliant on a developer to build the panel.

To get going with the PathListBox I wanted to create an simple Silverlight app which pulled back some results from digg, this is something which I have done in the past to illustrate the basics of MVVM in my session from PDC. While on the topic of MVVM its great to see that we now have an MVVM template inside of Blend that we can use. In this post I am not going to talk about the MVVM templates as I have only started out with them and so to give a comparison would not be justifiable at this stage, but I will posting an article when I have it straighten out in my head.

So for this first adventure I created a new MVVM Silverlight application and added a Model and a Service folder. As we already have the code for the digg service and the model created I copied these classes and moved them into their respective folders in the project. Open up the VM that has been added into the project and we can see that it implements INPC. The other thing to notice is that the constructor in parameter less, which is unlike my VM’s where I would normally inject an interface. So for the purposes of this example i am going to new up the interface inside of the constructor.

Ok so there are 3 steps that we need to perform in order to recreate the radial panel visual layout that is illustrated above. First we need to create our path on the design surface and then add the PathListBox to the design surface and associate the path with the PathListBox. As with a regular ItemsControl or ListBox we need to bind it to a list of items which in this case is our collection of FeedItems. Blend 4 Beta does quite alot of work for free, you will notice it has created the DataTemplate, ItemContainerStyle and ItemPanelTemplate which is rather nice. So here we start our 3 Steps and each step is associated with the templates and style.

First select the DataTemplate of the PathListBox either from the crumb bar or from right clicking in the objects panel. What we need to do here is add a ChangePropertyAction which fires when we LeftMouseButtonDown on to the DataTemplate so that we can set a flag on the data bound object so that it gets removed from the current list and added to second list. Once we have added this we need to change the RotateTransform on the StackPanel to 90.

Navigate back to the PathListBox and this time we want to edit the orientation on the items on the path so that they are OrientToPath and check the Wrap Items checkbox.

The second step is to move into our ItemContainerStyle for the PathListBox and change the VSM states so that we have a nice transition for the items when they are loaded and unloaded. With the release of Blend 4 Beta a new set of states have been added to the ListBoxItem. PathListBoxItem subclasses ListBoxItem and so we have the ability to modify the transitions for the BeforeLoaded and AfterLoaded states. For these I

simply changed the Opacity on the root element so that we can have a simple fade in type transition. Next we need to change the length of the transition in this case to 0.3 seconds, and change the easing function to your desired choice. The other changes I made here was to enable the Fluid Layout and turned on the design time layout transitions so that you can see your transitions during design time. Navigate back to the PathListBox.

The final piece to the puzzle is to change the ItemPanelTemplate. Edit the template either via the assets panel or the crumb bar. Here we are looking to add the FluidMoveBehavior on to our PathPanel which will be responsible for providing the animation effect for moving items between the two PathListBox’s.

The important things to note here include; we have selected the Children option from the AppliesTo dropdown as we want this particular FluidMoveBehavior to effect all the items in the ListBox; I changed the duration and also the easing functions that I wanted to use; I also selected the DataContext option from the Tag dropdown as I want to capture the data object associated with the item that is being animated. Navigate back to the PathListBox……

And we are done.

3 simple steps for you to add a radial panel layout into your project.

Change the data template so that it can handle a user interaction
Change the ItemContainerStyle BeforeLoaded and AfterLoaded States
Change the ItemPanelTemplate by adding in the FluidMoveBehavior

We also used ChangePropertyAction to manipulate the data in our collections exposed by the VM, and we used the FluidMoveBehavior to animate selected items from one PathListBox to another. The ability to do this without having to write any C# is a great step forwards, it does have some consequences but the advantages from my prospective outweigh the disadvantages.

The next thing that I want to do is animate each individual PathListBoxItem depending on where they are on the Path associated with the PathListBox.

All the code for this example you can find on my SkyDrive Folder.

Its a POC don’t worry about the data…

rich — Thu, 11 Mar 2010 13:37:43 +0000

In the last post my aim was to start a conversation around the advantages of building a visual data model.

But this is a POC ? Why would you do this?

Well its an interesting question and I am sure that there are folks out there who like to build prototypes and POC’s in this way, but based on my experience this usually ends up taking longer as you find yourself adding a workaround to the existing workarounds resulting in friction between what you want to do and the limitations of the framework. So the approach that I prefer to use is to take some time out at the start of the process and deconstruct the visual designs and build out a data model to represent what information needs to be presented. We can then go off and create the simple factory classes to build these data structures and take full advantage of the features supported by the framework. In essence we are using the same techniques that we would use for a production quality application but slimming down a journey through the application using more appropriate patterns.

This simple process is not time consuming, helps clear up any potential misunderstanding of how the application will react based on certain interactions, and it means that when deconstructing the visual designs its easy to figure out what type of control you can use in order to build the visual and if the control you are thinking about using will support the interactions required. The additional bonus here is that if you want to go a step further then you easily wire in a simple MVVM pattern, again this is something that I do however its not an essential step.

What I also like about this approach is that POC’s are usually built in a short timeframe and are thus open to change on a regular basis and we need to have an approach which reduces churn. By having a good data model you can limit the pain when things change as you can easily change the data object to suit and then a simple change to the Xaml. The opposite of this can result in lots of conditional logic which becomes prone to bugs and also limiting the application to potentially just a clickable mockup.

The other benefit which results in this approach is the level of reusability that I can pull from the POC and move into the production application. By having taken the time to produce a data structure that is usable this means that I can potentially reuse all the existing data templates, data bindings, styles, templates and certain custom controls. Again from my experience this level of reusability is normally higher than when we push forwards with a more static and tightly coupled approach.

To put this into a better context, a number of Surface applications that I have been involved in recently have required a ScatterView with ScatterView Items as these control provide those all important gestures for NUI interactions out of the box. Cool, but we are faced with the options either; create a known number of items and potentially recreate the same style but with different hardwired data; or create a single data template and style and take advantage of the data bind features. This can easily be achieved by data binding to the DP’s provided by the ScatterView Item that controls its placement, its easy to maintain and manage when those known changes happen. It also provides us with the flexibility to extend certain aspects rapidly without getting freaked out by the amount of conditional logic being added to the app.

My approach here is a simple one, create a base class for all your data controlled visuals which allow you to provide point data information so that when the objects are created you can initialise them where they need to be placed on screen. You can also add into here some more properties such as Orientation and data bind your data object property to the Orientation DP. Properties such as CanScale etc I would manipulate in a Style for the ScatterView Item, however there is no reason why you could not add them into the base. My reasons for the using a Style is so that when I am working with the designer I can easily make changes to the Style when we are both using Blend, it also allows me to share the work with designers visually, this for me is essential, personally I am more of a visual guy I prefer to see something rather than read textual content a visual helps paint the picture in a more accurate way with less room for individual perceptions of a textual instruction or description.

This simple approach provides; the ability to place visual elements exactly where the designer wants them;animations can be built in order to animate these visual elements on and off screen, interrogating the strongly typed data types means that we can apply the required styles on demand; reduces the complexity of app by taking advantage of data binding.

Just to break this down a little further, with the Tag Heuer implementation, I created a bunch of data objects for the locations around the world, London, Los Angeles, Cape Town, Sydney etc; all of which subclass the same base called Location. Location, Travel and Watches, the three different states of the app all subclass a class providing the positioning logic which intern subclasses an abstract base implementing INPC. I then have a data templates for each of the locations that we need to visualise, London, Los Angeles, Cape Town, Sydney etc. The data templates deal nicely with presenting our data, however there is a problem with layout as some of the aforementioned locations need to be positioned from left to right and some need to be positioned from right to left. To achieve this visual effect I used a different style
one for left to right and a second for right to left and wired these into the data template. I could have written c# to flip the visual tree however in this instance it was more effective to rebuild the styles in Blend it also has the advantage that I can show the designer in Blend the visual created and make any additional tweaks required.

I used the same technique for the F1 GP races and the watches area all of which have strongly typed data objects to encapsulate the visual information providing me with the advantages mentioned above to create and adapt quickly with the changes to the visual designs, it also allows me to take advantage of OO when it comes to adding additional properties to the base classes which will have a ripple effect down the object hierarchy.

In your next POC or prototype in WPF I hope that you will feel confident enough to try out this technique and reap the benefits that are at your disposal. Unfortunately the current version of Silverlight does not support implicit data templates, which in my humble opinion is a fundamental missing part of the Silverlight framework. Hopefully we will see this in a future release.

In the next post I am going to dig into how I built the watches section of the application and also dive into how interactions with the watch chrome and its content were created.

JC Decaux and Tag Heuer Surface Application deployed to Heathrow T5

rich — Thu, 25 Feb 2010 15:13:37 +0000

This is really the start of a number of posts that I have been meaning to put together for a while now. These are centred around how to rapidly build prototypes. It’s a technique that I use on a regular basis both for WPF and for Silverlight. In order for me to get across how effective this is it seems only right to provide context of how you can also take advantage of this technique.

More about that later, for this particular implementation I partnered with Splendid in order to produce an interactive experience for travellers at London Heathrow T5 lounges. The brief was to help raise brand awareness of the new Tag Heuer watches available and take advantage of the collaborate aspects provided by Surface.

The Tag Heuer Surface application has three main areas of functionality, all driven by the concept of time.

Travel Guide: The application displays the current time at your departure destination, displayed on a Tag Heuer watch display with moving hands. Using a stylized world map passengers can choose popular destinations and explore local time, travel duration and view local landmarks.

Sports Finder: Tag Heuer have a number of sports stars as ambassadors, we chose Lewis Hamilton as the trial location was the UK. Passengers can explore the world find the next Grand Prix including a countdown and images of last years race.

Watch Explorer: A Tag Heuer Application wouldn’t be quite right without the ability to explore their classic watch collection, passengers can use gesture to explore high-res images of the men’s and women’s collections with the ability to sign-up for an email on your favourite watch. The email contains details of the watch and your nearest location to purchase.

For a UX developer there are some really rather cool interactions used in each of the areas. I am going to try and give a higher level overview of these areas below and then jump into the detail in separate posts. The first of these are interactions present in each of the different functional pillars of the experience illustrated above and were designed so that visual elements could be placed into specific areas, animation of these items on and off screen and designed in such away that data bound objects provided the visual positioning information. The solution I used here was a combination of strongly typed data templates with model objects that contained the required coordinates of where to be positioned on screen and styles to create the required interactions.

When deconstructing the visual design I knew that the ScatterView Control would do the job nicely and having the coordinates in the model meant that we can take full advantage of data binding as each ScatterView Item has a centre and orientation DP which can be used to achieve this layout. Using a different ScatterViewItem Style provided the ability to choose different interactions and visuals based on which area of functionality is in use. Note there are 2 styles for the map points; a style for map points which are right aligned and a style for those which are left aligned. Using the strongly typed data templates and the use of data binding provides a clean and easy to achieve solution that provided the required interactions. The application was aware of its state and by changing the data based on state the usage of the strongly typed data templates come into their own as these state changes are triggered resulting in the new visuals to be displayed all done using data and data bindings in the Xaml.

For the travel section animated clocks were used and the TimeZoneInfo class provided the ability to calculate the time in different time zones. Here I used a dispatch timer that was ticking away and then updating the value of the data object. Each of the different time zones were associated data objects of the current location using data binding and INPC meant that we can change the time in the data object and this will trigger the animations used to rotate the hands on the watch.

The watch section has cool interaction where there is a 2 level zoom mechanism, I broke this one down to be a ScatterViewItem which wraps a ScatterView. This allowed for an interaction which meant the user could use a pinch gesture in increase the size of the outer ring and then a second pinch gesture can be used to manipulate the watch being displayed. What I like about this interaction design is that it allows the user to easy move and collaborate with other users interested in seeing the detailing of the watch. More importantly this also meant that I could take full advantage of data binding and strongly typed data templates.

As you may have noticed there is an underlying theme happening here, data and Xaml. For me WPF is really all about your data, get the data structure right that needs to be presented on screen and we can take full advantage of the framework and reduce the amount of C# code we write to a minimum.

links

The Moodie Report http://www.moodiereport.com/document.php?c_id=1113&doc_id=23335

Resource Dictionaries

rich — Tue, 23 Feb 2010 11:46:08 +0000

In this post I thought that it would be interesting to share some of my thoughts that I have been having recently around Resource Dictionaries (RD) and how they are structured. It is very easy to just put everything into your generic.Xaml or even into your app.Xaml files and let the designer run away with implementing their designs, but this is not too say that its the best way to roll.

From a developer prospective these files can become large very quickly and the result is a complete management headache when it comes to maintaining the styles, control and data templates. Its is also rather easy to allow this to happen as its in the Xaml and its what the designer produces, in effect its someone else’s responsibility. What is rather interesting and confusing at the same time is that Blend actually works very well when it comes to dealing with resources that are all in one file and it provides the designer with an easy way manage styles and templates. The other interesting thing about RD is that its actually at the heart of the Designer and Developer collaboration, its one of the areas where these two worlds collide. Therefore one of the ways in which we can help improve the workflow is to have a better understanding of RD and create some guidelines on how to best go about structuring them.

Unfortunately, even though RD are one of the core parts that make up the presentation layer there is very little information on best practices on how we should be doing this and why its important to get it right in order from which to have a good platform to move off from. Structuring RD in the wrong way can have rather serious performance problems.

There is a great article on the WPF Disciples pages providing very good advice on how to structure your RD and naming conventions, but I want to attempt to take it a little further. There are a number of different scenarios that I have come across and I am sure that there will be more along the way. These include; a POC application where this is built quickly and iteratively and requires a compelling UI but there is a high potential the application will not make it into production; themeable applications where a number of different themes can be applied to change the look and feel; and also applications that leverage 3rd party controls which have their own and sometimes rather interesting ways of how they are styled and templated. Each scenario is different but can be solved in the same way by using well structured RD to produce a clean, performant and easy to maintain application.

Ok, so how can we achieve a better structuring of the RD, help improve collaboration and provide a basic pattern and best practices in order to satisfy the different scenarios outlined above ?

Putting your RD in a separate project is the first thing to do, there are a number of advantages in doing this; but primarily this is about separation of concerns to help with workflow; and it helps to provide a blue print of a theme that can be reused over time.

In addition to the guidelines put forwards from the WPF list I am also going to add some more into the mix.

Suggested WPF Disciples Resources :-

BrushResources – solid brushes, linear gradient brushes and drawing brushes

ConverterResources – allows us to reference any of the converters by merging our resource dictionary with this file, rather than re-declaring our converters every time.

ImageResources – as above, allows us to declare an ImageSource once and reference it from anywhere.

TextResources -styles applied to textual elements (Hyperlinks, TextBlocks, etc.)

Additional Resources:-

Colours – for simple colours used as a swash for branding of clients colour palette.

DataTemplates – holds all the Data Templates used in the application.

Storyboards – holds all the Storyboard animations.

VectorGraphics – holds all the vectors graphics

CustomControls – holds styles and templates for those custom lookless controls

CommonControls- holds styles and templates for those common controls

Now the above list is not an exhaustive one and there is a high potential that this may change in the future but for now these provide a good platform from which to start. There are a number of ways in which you can slice and dice the RD used in your application some of which I will talk about shortly, but in general its best to think about the RD as a whole. The reason for this is that its best to see the Xaml assets as what constitutes your design and interaction of the UI that you are projecting onto the view for the user to experience. Therefore a change in the template or style means a complete new design. By thinking about them in a more holistic view as a the sum of all parts.

Therefore by splitting up the styles, templates etc into different high level RD categories provides the capabilities for the designers to work in an independent way and not have the constraints of working in the same project as the developers. The majority of times you will want to split out the RD into a separate project, and provide an area where they can create and design controls and elements. It also means that as they are working in a separate project they are completely separated from the developers but they are both working in the same solution.

What are those other views of RD that I mentioned earlier. Another potential way of looking at splitting up the RD is to break out the control templates and styles and place those into separate files. This will provide the ability to change the colours, font types etc and leave the control templates alone, which is great for those situations where you want to restyle the application and want to retain the layout of the controls. However, there are some problems with this approach; making significant changes to the style of controls will almost certainly mean that you will have to change the layout of the control, or building a custom control to handle the different styles; support in Blend for this type of structure is sub optimal in that it becomes more difficult to navigate and manage the styles and templates.

So why is it important to structure the RD in this way ? Why can they live all in the same Generic.Xaml file ? Is it the developer or the designer who owns the files ? How does this make my application more themeable ?

So those are a few of the questions which I have been asked about recently from both designers and developers, and they are all good questions and ones which i have also been thinking about hence my solution attempts to tackle these questions and provide a simpler implementation of how to use RD in your app.

One of the main problems with coming up with a good structure is the lack of guidance that is actually out there, plenty of high level information around some structure and naming conventions but no real information on the details. Rather frustratingly although we have gone head first into solving and building frameworks that address MVVM and come up with some notable solutions. It does feels like we have neglected an important area of the presentation layer.

What is rather interesting is how differently developers and designers perceive RD and this comes out in how they implement them in the app.

Developer : As a developer it is a natural and in the interest of best practices to split out each individual control so that each control is sat in its own RD.

Designer: As a designer its natural to think of all the controls at a higher level so that at set of individual controls contribute to the overall design of the app.

So as you can see neither side is right or wrong its their interpretation of RD which differs and this is natural as the different roles have different views and priorities on what is required to build the User Experience. What is interesting as well is that these opinions are skewed by the tools that they use and how they interpret and solve problems. The developer is very much focused on detail and implementation, mean while the designer is more interested in the higher level and the total experience of their design.

Therefore a combination of both these views seems to feel right where we split up the RD into a higher level categorisation with good naming conventions. This approach meets both parties needs and is Blendable allowing the designer to work in an environment which has a reduced reliance on the developer world and vice versa.

So I am hoping this that has made you think a little more about RD. In the next post I am going to talk more about how to implement the RD in your application and drill into the performance issues related to implementing RD and some sample code to help with guidance.