PDC09 – Meet the Griffs Code drop

rich — Thu, 19 Nov 2009 18:58:35 +0000

Ian and myself really enjoyed presenting our pre conference session “Getting the most out of Silverlight” and we both hope that you enjoyed the sessions. The slide decks will be posted at some point by the event team and I will update the post when this happens so that you can get copies of the decks.

As promised I have stashed all the final code examples up on my skydrive folder so that you can download and play with the samples. As we ran out of time in the last session what I will do in the next week or so is to record a Camtasia session and capture what I unfortunately did not get time to go over during the session.

I have named the zip files as intuitively as possible so these line up with the title of the session.

What I also wanted to briefly mention is that in the MEF and Ninject demos you will see that I am using Commands from the Silverlight Extensions project on CodePlex. The command pattern that is used here is a standard command pattern common to WPF. In the current release there is no support for Commands so what you will see included in the projects are the Command classes that I need in order to harness the power of Commands.

In a previous life I wrote a post on WPF commands that you may want to take a look at if you are not familiar to the Command pattern used in WPF and how it helps to separate out UI logic into you View Model and helps increase the testability of your code that responds to the behaviours in your application. The refactor that I did here was to remove the click event handler on the button and replace this with a command. There are 3 steps for refactoring out the event handler.

First we need to create a commands.cs file and create a Commands class which will hold all our commands associated with our view model. In essence we are going to be providing a list of possible actions that the View Model can perform in relation to the view. Once we have created the class we need to define our commands that we want which in our demo is called RefreshFeedItems then we need to add in public mechanism so that we can invoke the command from the view so that it can be wired up to a button.


using StandardViewModel.SLExtensions.Input;

public class Commands
{
      private static readonly Command refreshFeeds = new Command(RefreshFeedItems);

      public static Command RefreshFeedItems

      { get { return refreshFeeds; } } }

Now that we have defined the command that we want to fire we need to do the second part which is to wire up the command in the Xaml of the view.

     Input:CommandService.Command=RefreshFeedItems

We can now remove the click handler code behind of the view.

The finally part is to implement the CanExecute and Executed code in the ViewModel, so move into the Constructor of the ViewModel and here wire up the commands.

       Commands.RefreshFeedItems.CanExecute += (sender, args) args.CanExecute = true;
       Commands.RefreshFeedItems.Executed += delegate(object sender, ExecutedEventArgs args)
         {
                        Refresh();
         };

And we are done. Enjoy. One thing to note is that there are other types of commands, RelayCommand and DelegateCommand which are also very cool black belt ninja moves for dealing with separation when building your MVVM apps

MVVM, design time data, and Blendability

rich — Fri, 02 Oct 2009 08:44:15 +0000

With the introduction of design time data support in Blend I thought that I would try and take advantage of using design time data and MVVM. For a while now I have been using Ninject, with a Service Locator Pattern to provide the ability to build WPF and Silverlight apps in an MVVM pattern where I prefer to use a View first mechanism. There are a number of benefits from using this approach, one of the ones that we are good to drill to in this post is around Blendability of the controls that developers create. Prior to me using Ninject I would have a heavy reliance on the DesignerProperties IsInDesignMode call to check to see if the control was being render in Blend, as i would normally have to do something to stop the control from crashing and allow myself and the designer to use Blend in order for us to Style and Template the controls we created.

What we are going to cover here is the journey which i went on when adding support for design time data to my project, I really like it as the refactoring from the standard inbuilt mechanism in Blend to the final output is a nice series of steps that feel good.

The screen shot on the right shows the simple looking UI displaying contextual data in Blend allowing the designer to see how the control will look. I think providing the ability for your application to look exactly the same at design time as at run time is going to mean that you can produce better looking applications quicker as the designer is design the screens in the context of the data.

When first adding the design time data to your project Blend takes over control and this means that you need to use Blend to shape your design time data classes to match your data types used in the system. So if we were building a throw away prototype then I would agree this is the best way forwards, but when you are moving from prototype to production this does not really work. On of the reasons behind the research for this post is around the transition from prototype to production and even from sketch to prototype, once we have sign off from the client on a number of ideas and we want to start to build these out then there is a high potential one will become production quality and because of this its good to have the right architecture in place, so reshaping to MVVM early on will almost certainly cost your client less.

The Xaml below is what i put together to represent the shape of data that was in the mock classes. Blend then hooks this data up to the design time data context for you.

Xaml data for shopping cart

When the design time data shape matches your real data shape you can then go ahead and use the new d:DataContext Dependency Property and bind your design time data to this property.

Xaml Source code for the control

Nothing too tricky there, the new design time data context is the key to making all this happen, it also means that you can bind any sort of data you want to the design time data context to provide contextual data in Blend during design time. It was at this point that i started to think about how we can really bend the design time data features. My initial refactor was not a great result in that I ended up with 2 sets of mock data; one set of data would be used by the designers in Blend; and the second set of data would be used by the unit test, Not nice, management nightmare to ensure that both data sets are keep in sync.

So the goal was to provide design time data which was the same data used by the unit tests, meaning that we only have one data set to maintain and manage, allowing us to leverage the powerful features of design time data in Blend and also keeping our unit tests looking sweet, pleasing both the designers and the developers on the team.

In order to do this I needed to restructure the existing shape of my data classes that I use in my mock service layer classes, first I needed to change the OnCompleted method to be a virtual implementation and also the method which retrieves the data. This simple change means that we can now provide two mock services that can be injected in.

Refactored mock service class with new virtual methods

    using System;
    using System.Collections.ObjectModel;

    public class MockShoppingCartService : IShoppingCartService
    {
        public event GetShoppingCartCompletedHandler GetShoppingCartCompleted;

        public bool LoginToShoppingCart(string username, string password)
        {
            throw new System.NotImplementedException();
        }

        public virtual void RetrieveShoppingCart()
        {
            this.OnGetShoppingCartCompleted(null, MockShoppingCartData.CreateShoppingCartRuntime());
        }

        protected virtual void OnGetShoppingCartCompleted(Exception error, ShoppingCart result)
        {
            if (this.GetShoppingCartCompleted != null)
            {
                this.GetShoppingCartCompleted(new GetShoppingCartCompletedEventArgs(error, result));
            }
        }
    }

The new mock service class which is used specifically for working with Blend

namespace DesignDataSample.Mocks
{
    public class MockShoppingCartServiceDesignData : MockShoppingCartService
    {
        public override void RetrieveShoppingCart()
        {
            this.OnGetShoppingCartCompleted(null, MockShoppingCartData.CreateShoppingCartDesigntime());
        }
    }
}

How we can use ninject to inject the service we want to use, design time data, mock or real.

this.Bind().To().OnlyIf(c => isBrowser);
this.Bind().To().OnlyIf(c => isBlend);
this.Bind().To().OnlyIf(c => isBrowser);
this.Bind().ToSelf();

Xaml code for how we leverage the data context and the new design time data context for providing contextual data.

So I hope that this article has opened your eyes to how useful design time data can be to enhance the Blendability of the controls which you produce both lookless and user. In the majority of cases designers that you are working with really like that they can view the control at deign time how it will appear when running in your application and populated with data. When implementing the MVVM pattern in you application incorporating support for design time data is also possible and provides you with the ultimate Xaml Ninja experience.

You can download the source from my Skydrive.

xaml ninja » Ninject

PDC09 – Meet the Griffs Code drop

MVVM, design time data, and Blendability