Leveraging MEFedMVVM ExportViewModel – MEFedMVVM Part 2

Some content may be out of date. See latest blog on changes made here.

In this post I will explain and show case what you can do with your VieModel by leveraging MEFedMVVM. If you want an introduction to MEFedMVVM please go here.

In order to make your ViewModel discoverable you simple decorate the ViewModel with ExportViewModel and give your view model a name so that the View can import the ViewModel by name. Some thing like this

ViewModel

   1: [ExportViewModel("VM1")]

   2: public class MyViewModel

and the view can look for this view model like this

   1: <UserControl x:Class="MEFedMVVMDemo.Views.UsersScreen"

   2:              xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   3:              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:              xmlns:meffed="http:\\www.codeplex.com\MEFedMVVM"

   5:              meffed:ViewModelLocator.ViewModel="VM1">

The ViewModelLocator.ViewModel will leverage MEF to go get the exported ViewModel and set an instance of that ViewModel as the UserControl’s DataContext. BUT there is more stuff you can do.

 

DesignTime Data

The best way how to have design time data is by having Data Services injected in the ViewModel so that at design time you inject design time services and at runtime you inject the real services. This also allows you to better unit test because you can mock the data services while unit testing.

MEFedMVVM allows you to easily export services so that you can then import these services in the ViewModel. When you are exporting the service you also supply MetaData which is used by MEFedMVVM to decide which service to inject. Let’s do a quick example. Let’s say your ViewModel is using a service that implements IUserService to get a list of user from a database at runtime and you create another implementation of this service for design time that just returns a static list of Users. you would export these services like this

Design time Service

   1: [ExportService(ServiceType.DesignTime, typeof(IUsersService))]

   2: public class DesignTimeUsersService : IUsersService

   3: {

   4:    #region IUsersService Members

   5:  

   6:    public IList<Models.User> GetAllUsers(){}

   7: }

Runtime Service

   1: [ExportService(ServiceType.Runtime, typeof(IUsersService))]

   2: public class UsersService : IUsersService

   3: {

   4:    #region IUsersService Members

   5:  

   6:    public IList<Models.User> GetAllUsers()

   7: }

As you can see all you do is decorate the service with the Export Service attribute and specify if its Runtime or DesignTime. You can also specify ServiceType.Both if you want that service to be injected both at runtime and design time. I will talk more on the Export Service and what you can do with it in my next post. Just to give you a quick insight of what this can do here is a small list

- Have shared services (a service that is shared for all ViewModels)

- Have prioritized Services (have a service priority and MEFedMVVM will pick the appropriate service to be injected)

- Have IContextAware services. These are special UI related services. Basically MEFedMVVM will call InjectContext passing the UI element that requested the ViewModel, so that service can work as a bridge for the ViewModel and the View without any coupling. (This is one of my favorite features)

OK let’s not get side tracked. Were are we?

We have a ViewModel that is an empty class decorated with ExportViewModel and we have two services exported one for runtime and one for design time.

In order to inject the services we need in our ViewModel, we need to state that in the ExportViewModel attribute, like this

   1: [ExportViewModel("VM1", typeof(IUsersService))]

   2: public class TestViewModel {}

This will tell MEFedMVVM to get that service and inject it to the ViewModel. But how can MEFedMVVM inject this in the ViewModel? Well in order to do so your ViewModel must implement an interface called IServiceConsumer. Here is the interface contract.

   1: /// <summary>

   2: /// Defines a service consumer.

   3: /// An entity that has a Service Locator and consumes services

   4: /// </summary>

   5: public interface IServiceConsumer

   6: {

   7:     /// <summary>

   8:     /// Gets the service locator that contains the services 

   9:     /// </summary>

  10:     IServiceLocator ServiceLocator { get; }

  11:     

  12:     /// <summary>

  13:     /// Call to be made when services are injected to the ServiceLocator

  14:     /// </summary>

  15:     void OnServicesInjected();

  16: }

So you will have a ServiceLocator property from where you can get the Services injected from and you need a method called OnServicesInjected which will be called when MEFedMVVM injects the services.

Don’t worry if you do not want to implement the interface yourself we made the heavy lifting for you. You can inherit from BaseViewModel which implements this interface for you. BaseViewModel also implements the INotifyPropertyChanged so you can do PropertyChanged notifications by calling OnPropertyChanged( () => Myproperty); Yes the implementation of INotifyPropertyChanged we used leverages lambdas so that you do not have spelling mistakes when doing property changed notifications :)

Back to service injection…. So our ViewModel is not implementing IServiceConsumer or inheriting BaseViewModel; inside the OnServicesInjected you can get the services and get the data you need. Like this

   1: protected override void OnServicesInjectedOverride()

   2: {

   3:     foreach (var item in GetService<IUsersService>().GetAllUsers())

   4:     {

   5:         if (SelectedUser == null)

   6:             SelectedUser = item;

   7:         users.Add(item);

   8:     }

   9: }

So here I am getting the data from the IUsersService that was injected and adding them in a collection which is bound in the View.

So yea finally my designer can see this in Blend

image

This sounded like a lot of work because I went into details of how everything works. But try it and you’ll see how easy it is to do. If its not easy enough get back to me and I really want to hear your feedback.

What if I do not have a service injected but I still want design time data??

Yes, I agree. There are some ViewModels that do not have a service injected BUT they still want design time data. An example of this… Let’s say you have another ViewModel which renders the SelectedUser which the end user selects from the other ViewModel. This ViewModel does not have a service because the data is coming from either from a Mediator callback or from a Property that is bound to some UI…. How can I have Design time data for this ViewModel?

MEFedMVVM let’s you do this as well. All you need to do is implement the IDesignTimeAware. This is the interface

   1: /// <summary>

   2: /// Interface to be implemented by ViewModels that want to do something when rendering in design time

   3: /// </summary>

   4: public interface IDesignTimeAware

   5: {

   6:     void DesignTimeInitialization();

   7: }

The DesignTimeInitialization method will be called on your ViewModel (ONLY AT DESIGN TIME) and inside there you can do what you want in order to have Design Time Data. Here is an example

   1: [ExportViewModel("VM2", typeof(IMediator), typeof(IVisualStateManager))]

   2: public class SelectedUserViewModel : BaseViewModel, IDesignTimeAware

   3: {

   4:     private User selectedUser;

   5:  

   6:     /// <summary>

   7:     /// Gets or sets the selected user

   8:     /// </summary>

   9:     public User SelectedUser

  10:     {

  11:         get { return selectedUser; }

  12:         set

  13:         {

  14:             selectedUser = value;

  15:             OnPropertyChanged(() => SelectedUser);

  16:         }

  17:     }

  18:  

  19:     protected override void OnServicesInjectedOverride()

  20:     {

  21:         mediator = GetService<IMediator>();

  22:         if (mediator != null)

  23:             mediator.Register(this);

  24:     }

  25:  

  26:     [MediatorMessageSink(MediatorMessages.SelectedUser, ParameterType=typeof(User))]

  27:     public void OnSelectedUserChanged(User selectedUser)

  28:     {

  29:         SelectedUser = selectedUser;

  30:     }

  31:  

  32:  

  33:     #region IDataContextAware Members

  34:  

  35:     public void DesignTimeInitialization()

  36:     {

  37:         SelectedUser = new User

  38:         {

  39:             Name = "Marlon", Surname = "Grech", Age = 24

  40:         };

  41:     }

  42:  

  43:     #endregion

  44: }

This will render like this in Blend

image

What if the DataContext is set because I am in a DataTemplate? How can I get Services injected and some design time data as well?

Very well. Sometimes we have scenarios when you have a DataTemplate that has a UserControl inside. This UserControl will still have a ViewModel set as its DataContext but it must not be set from MEFedMVVM ViewModelLocator.ViewModel attached property since the ContentControl or the ItemsControl should be setting the DataContext.

You can still do this with MEFedMVVM! In the ExportService you can have an additional parameter stating that this ViewModel should be “DataContextAware”. Something like this

   1: [ExportViewModel("UserVM", true, typeof(IMediator))]

   2: public class UserViewModel : BaseViewModel, IDesignTimeAware

   3: {

The second parameter passed set to true is where you specify that this ViewModel needs to be “DataContextAware”.

What is this gonna do?

Well at Runtime it will not create an instance of the ViewModel, instead it will wait until the DataContext is set on the UIElement. When DataContext is set, it will inject the services that you requested in the ExportViewModel.

At DesignTime it will create the ViewModel instance and inject it in the DataContext of the UI element so that you can still design your UI seamlessly.

Conclusion

These are only some of the features that MEFedMVVM has to offer. We are working on expanding more functionality. We are also working hard to test as many scenarios as possible but without your feedback and help we cannot cover all of them.

Please let us know if you encounter any issues so that together we can continue building an awesome and easy to use library, and have loads of fun creating cool WPF and SL applications :)

Download the source

http://mefedmvvm.codeplex.com/

Peace

An introduction to MEFedMVVM – PART 1

Some content may be out of date. See latest blog on changes made here.

Intro

This is a small introduction to MEFedMVVM, a library that I built with the help of some fellow WPF Disciples, Peter O’Hanlon and Glenn Block (aka Mr.MEF). This library will enable you to quickly create ViewModels that consume services and inject these ViewModels in your View’s DataContext. It will also enable you to work better with your fellow friend, “The Designer” by leveraging Design time data and many other UI friendly stuff. With this library you can create WPF/Silverlight applications seamlessly since the API is common for both WPF and Silverlight.

This framework works for SL 4, WPF (.NET4.0 ). And we only support Blend 4 RC or newer. MEFedMVVM does not work in Blend 4 Beta .

MEFedMVVM-Logo2

Goals

- Write code that works for SL and WPF.

- Enable Design time data.

- Enable loosely coupled bridge between View and ViewModel.

- Enable easy ViewModel discovery and injection mechanism.

- Make composition super easy by leveraging MEF capabilities (without coupling your code with MEF).

How do I use this thing?

Ok so these are the first 3 basic steps.

1. Add a reference to MEFedMVVM.WPF/MEFedMVVM.SL (you also have to add a reference to dlls that are located in the Dependencies folder of the Source code if you are not including the library source code in your solution.)

image

2. Add an attribute somewhere in your project to mark the assembly as a “MEFedMVVM” Assembly, [assembly: DesignTimeCatalogAttribute]. This is used so that MEFedMVVM only looks for exported items in the marked assemblies. This makes initialization faster.

Now begins the MEFedMVVM fun….

3. Make your ViewModel discoverable by decorating it with [ExportViewModel(“MyMEFedViewModel”)] and instruct the view to go find that ViewModel by setting an attached property meffed:ViewModelLocator.ViewModel="MyMEFedViewModel"

So the View looks like this

   1: <UserControl x:Class="MEFedMVVMDemo.Views.UsersScreen"


   2:              xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"


   3:              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"


   4:              xmlns:meffed="http:\\www.codeplex.com\MEFedMVVM"


   5:              meffed:ViewModelLocator.ViewModel="MyMEFedViewModel">

and the ViewModel like this

   1: [ExportViewModel("MyMEFedViewModel")]


   2: public class TestViewModel { }

and viola that is it…. You run the project and magically the ViewModel gets injected in the View…

I must say, I cannot take the credit for this magic, it’s all powered by the mighty MEF!

Ok so we injected the ViewModel in the View, but where the hell is the Design time data???

well should I tell you or should I go to sleep ? mmmm…. thinking… still thinking… aa well might as well tell you now that I started right :P

When creating ViewModels usually the data is coming from some service which is injected to the VM via Dependency injection. What MEFedMVVM will do for you is let you expose services and include meta data that gives extra information to the service. MEFedMVVM uses this Meta data to decide which service to give to the VM at runtime and which service to inject at Design time.

This is how you expose services (for runtime)

   1: [ExportService(ServiceType.Runtime, typeof(IUsersService))]


   2: public class UsersService : IUsersService

This is how you expose services (for design time)

   1: [ExportService(ServiceType.DesignTime, typeof(IUsersService))]


   2: public class DesignTimeUsersService : IUsersService

P.S you can also specify ServiceType.Both if you want the same service to be injected at runtime and design time.

Once you make your Services discoverable it’s time to start using them in your ViewModel. In order to do this, you must have your VM implement the IServiceConsumer interface, or if you are lazy like me just inherit from BaseViewModel. You also need to specify which services you want injected by specifying the different types in the ExportViewModel attribute. Something like this

   1: [ExportViewModel("VM1", typeof(IUsersService), typeof(IVisualStateManager), typeof(IDispatcherService))]


   2: public class TestViewModel : BaseViewModel

In the above code I am importing the IUserService, the IVisualStateManager and the IDispatcher service into my view model. These services are injected when MEFedMVVM creates an instance of the ViewModel into a ServiceLocator so you can get them by calling GetService<T>() from the OnServicesInjected method. the code for this looks something like this

   1: protected override void OnServicesInjectedOverride()


   2: {


   3:     var usersService = GetService<IUsersService>();


   4:     var dispatcherService = GetService<IDispatcherService>();


   5: }

You might ask yourself why can’t I just import the services by using a standard [Import] like in normal MEF. Basically when the MEFedMVVM is looking for the correct services it is also doing some extra stuff that I will talk about in following blog posts (but I know you are curious so I’ll give you a hint…. IVisualStateManager for example gets injected with the UIElement that is requesting the ViewModel so that then the ViewModel can execute state without coupling to the VSM)

What comes out of the box?

Out of the box this library supplies a number of things… here is a list of most of the stuff

Common Services

- IMediator (use this to communicate from one ViewModel to another.

- IViewStateManager (User this to invoke VisualStates from the ViewModel)

- IContainerStatus (Provides a loaded event and unloaded event, these are hooked to the loaded and unloaded events of the UIElement that is consuming the ViewModel)

- IDispatcher (Provides a way so that you can call BeginInvoke on the Dispatcher in a loosely coupled way so that you can mock this when doing unit tests)

- and many many many more to come….

- and many more you can create yourself.

Basically this library is still learning how to walk, its still a cute little baby… but the basics are in (so yea its a healthy cute baby)… I will talk more on how you can create your own services that BRIDGE the ViewModel and the View in my next post (yet yea I know, I know, you are curious… Implement IContextAware in your service and you get injected with the View that requested the ViewModel and then you can do what the hell you want :). but don’t tell anyone I told you :P )

Other stuff

DelegateCommand<T> (Used to create commands without having to create a separate class that implements ICommand)

BaseViewModel (Implement INotifyPropertyChanged and you can raise PropertyChanged notifications in a strongly typed manner i.e OnPropertyChanged(() => Users); . BaseViewModel also has some other benifits that I will discuss in my next post)

More stuff coming up … don’t don’t worry … we just built the basics here :)

Conclusion

Why do I think this library has a lot of potential? Well right now there are some things missing but the basics are there and it is really easy to add new stuff now that we have a solid base. There are loads of things that I did not mention in this post since I wanted this post to be just a mini introduction. I will have Part 2,3 n of this post coming up shortly where I will go into more dept of the library and how you can extend it and bend it to your will.

I suggest you download the code from CodePlex and start playing with it. Right now I really need your help and get as much feedback / bug reports as possible … WARNING: Right now I am doing loads of changes to the code so please do not use this in production projects.

I hope you like this new library… just a word of caution when using this library…. it can get really addictive :P myself am suffering this side effect right now … hehe :)

Part 2 here

Part 3 here

Part 4 here

Download source and MEF it up! http://mefedmvvm.codeplex.com/

Working with the WPF VSM in an MVVM friendly manner

Lately I have been working a lot with Silverlight. While working on my first Silverlight project I encountered my first problem… There are no Triggers in SL!!! At first I was frustrated and started hitting my self in the head but hey SL is not that bad… SL has the Visual State Manager aka VSM which is a pretty awesome tool I must say. I still think SL should have Triggers for some tasks such as ControlTemplates and other tasks yet with VSM you can still get some cool stuff done :)

What really strikes me with the VSM is the way it is supported in Blend, and YES designers love VSM! With the VSM they can define states in an easy way (and yes these states transition and the designer has full control on the transitions done). They can navigate easily through states in Blend and even see the transitions being done in Blend there and then.

image

Going back to WPF one thing that is missing in WPF is a way how a designer can define animations that get Triggered when something happens… Or let me re phrase that…. There is no easy way, or better not as easy as the VSM :)

Triggers in WPF can invoke Storyboards yet still it feels like the WPF animation system does not have a nice way to dispatch animations… Enter the VSM for WPF.

Yes, VSM is available for WPF as well, and yes it is supported in Blend (you just have to do a little trick that you can find over here)

I created a sample project that leverages the VSM for its animations and yes its all MVVM (in the sample app you’ll see that I am also using design time data for blend and I also included a mini MVVM Libarary that I use to develop my everyday WPF projects :) ).

 

Let’s Get Started

So let’s start by defining a state in Blend. In order to do so (assuming you followed the instructions to enable the VSM for WPF projects) you need to navigate to the States Tab and create a new state. Once the state is created and selected you’ll see that Blend will go to recording mode (just like it does when you are doing a normal WPF animation). Now you can change any property of any element and the Blend will record that and create the appropriate transitions for it.

image

Ok, now that we have the states defined in Blend what is next? well we need a way how to invoke these states for starters!

The Blend team were so kind to give us a Behavior called GoToStateAction. This behavior will basically invoke a state when an event is raised, for example if you have a button that should dispatch a new state, you simple find the GoToStateAction form the Asset tab and drag it on the button

image

Then you can set the properties for this behavior in the properties tab. There you can specify which state to select.

image

By doing these steps (define a state and use the GoToStateAction to invoke the state) you are already good to go. You can press F5 and you can see that when you click the button you get transitioned from one state to another. (P.S it’s important that you set a default transition time span otherwise you end up with no transition since the default is 0s).

 

This is all cool but what about MVVM ??

I hear you I hear you…. What if I have a ViewModel which needs to invoke a state change ?? Unfortunately this is not so straight forward… BUT of course there is a solution… I extended the GoToStateAction so that it can be hooked up from a ViewModel. Here is my extended version

   1: public class VisualStateManagerInvoker : GoToStateAction

   2: {

   3:     #region CurrentState

   4:  

   5:     /// <summary>

   6:     /// CurrentState Attached Dependency Property

   7:     /// </summary>

   8:     public static readonly DependencyProperty CurrentStateProperty =

   9:         DependencyProperty.RegisterAttached("CurrentState", typeof(string), typeof(VisualStateManagerInvoker),

  10:                                             new PropertyMetadata((string)null,

  11:                                                                  new PropertyChangedCallback(OnCurrentStateChanged)));

  12:  

  13:     /// <summary>

  14:     /// Gets the CurrentState property.  This dependency property 

  15:     /// indicates ....

  16:     /// </summary>

  17:     public static string GetCurrentState(DependencyObject d)

  18:     {

  19:         return (string)d.GetValue(CurrentStateProperty);

  20:     }

  21:  

  22:     /// <summary>

  23:     /// Sets the CurrentState property.  This dependency property 

  24:     /// indicates ....

  25:     /// </summary>

  26:     public static void SetCurrentState(DependencyObject d, string value)

  27:     {

  28:         d.SetValue(CurrentStateProperty, value);

  29:     }

  30:  

  31:     /// <summary>

  32:     /// Handles changes to the CurrentState property.

  33:     /// </summary>

  34:     private static void OnCurrentStateChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

  35:     {

  36:         if (GetGoToStateAction(d) == null)

  37:         {

  38:             var command = new RelayCommand(x => //where x is the state name passed as parameter

  39:             {

  40:                 var stateAction = new VisualStateManagerInvoker();

  41:                 stateAction.Attach(d);

  42:                 stateAction.UseTransitions = GetShouldUseTransition(d);

  43:                 stateAction.StateName = (string)x;

  44:                 stateAction.Invoke(null);

  45:             });

  46:             SetGoToStateAction(d, command);

  47:         }

  48:     }

  49:  

  50:     #endregion

  51:  

  52:     #region GoToStateAction

  53:  

  54:     /// <summary>

  55:     /// GoToStateAction Attached Dependency Property

  56:     /// </summary>

  57:     public static readonly DependencyProperty GoToStateActionProperty =

  58:         DependencyProperty.RegisterAttached("GoToStateAction", typeof(ICommand), typeof(VisualStateManagerInvoker),

  59:                                             new PropertyMetadata((ICommand)null));

  60:  

  61:     /// <summary>

  62:     /// Gets the GoToStateAction property.  This dependency property 

  63:     /// indicates ....

  64:     /// </summary>

  65:     public static ICommand GetGoToStateAction(DependencyObject d)

  66:     {

  67:         return (ICommand)d.GetValue(GoToStateActionProperty);

  68:     }

  69:  

  70:     /// <summary>

  71:     /// Sets the GoToStateAction property.  This dependency property 

  72:     /// indicates ....

  73:     /// </summary>

  74:     public static void SetGoToStateAction(DependencyObject d, ICommand value)

  75:     {

  76:         d.SetValue(GoToStateActionProperty, value);

  77:     }

  78:  

  79:     #endregion

  80:  

  81:     #region ShouldUseTransition

  82:  

  83:     /// <summary>

  84:     /// ShouldUseTransition Attached Dependency Property

  85:     /// </summary>

  86:     public static readonly DependencyProperty ShouldUseTransitionProperty =

  87:         DependencyProperty.RegisterAttached("ShouldUseTransition", typeof(bool), typeof(VisualStateManagerInvoker),

  88:                                             new PropertyMetadata((bool)true));

  89:  

  90:     /// <summary>

  91:     /// Gets the ShouldUseTransition property.  This dependency property 

  92:     /// indicates ....

  93:     /// </summary>

  94:     public static bool GetShouldUseTransition(DependencyObject d)

  95:     {

  96:         return (bool)d.GetValue(ShouldUseTransitionProperty);

  97:     }

  98:  

  99:     /// <summary>

 100:     /// Sets the ShouldUseTransition property.  This dependency property 

 101:     /// indicates ....

 102:     /// </summary>

 103:     public static void SetShouldUseTransition(DependencyObject d, bool value)

 104:     {

 105:         d.SetValue(ShouldUseTransitionProperty, value);

 106:     }

 107:  

 108:     #endregion

 109:  

 110: }

This class contains 2 attached properties CurrentState (which is a string) and a GoToStateAction which is an ICommand (It also has another property ShouldUseTransition which instructs the VSM weather to use transitions or just change the properties for the new state).

The CurrentState property will attach itself to the DepenedencyObject which is being decorated with this property and hook to its VSM (please note that the attach will crawl up the Logical Tree to find the first available VSM). This operation creates an RelayCommand that is set in the GoToStateAction attached property.

Now the interesting part happens. I created a base class for ViewModels that want to invoke states called StateBaseViewModel. Here is the code…

   1: /// <summary>

   2: /// Base view model that has a property for state changes

   3: /// </summary>

   4: public class StateBaseViewModel : BaseViewModel

   5: {

   6:     private string currentState;

   7:  

   8:     /// <summary>

   9:     /// Gets or sets the current state of the ViewModel

  10:     /// </summary>

  11:     public string CurrentState

  12:     {

  13:         get { return currentState; }

  14:         set

  15:         {

  16:             currentState = value;

  17:             RaisePropertyChanged("CurrentState");

  18:         }

  19:     }

  20:  

  21:     /// <summary>

  22:     /// Changes the CurrentState property to the spcified state

  23:     /// </summary>

  24:     public ICommand GoToStateCommand { get; protected set; }

  25:  

  26:  

  27:     /// <summary>

  28:     /// Specify a command to be fired when state changes

  29:     /// </summary>

  30:     public ICommand OnGoToState { get; set; }

  31:  

  32:  

  33:     public StateBaseViewModel()

  34:     {

  35:         GoToStateCommand = new RelayCommand(

  36:             x =>

  37:             {

  38:                 CurrentState = (string)x;

  39:                 if (OnGoToState != null && OnGoToState.CanExecute(CurrentState))

  40:                     OnGoToState.Execute(CurrentState);

  41:             },

  42:             x => !String.IsNullOrEmpty((string)x)

  43:             );

  44:     }

  45: }

This base view model has the same 2 properties of the VisualStateManagerInvoker. We can make these 2 in sync together by using standard TwoWay databinding. By doing so the VisualStateManagerInvoker will feed the View Model with a command that is hooked up to a UI element VSM and when invoked this will ask the VSM for that element to transition to the state passed as parameter.

Here is the binding for this

   1: <local:Checkout  

   2:     mvvmStateManagement:VisualStateManagerInvoker.CurrentState="{Binding CurrentState}"

   3:     mvvmStateManagement:VisualStateManagerInvoker.GoToStateAction="{Binding OnGoToState, Mode=TwoWay}" />

Assuming that the element local:Checkout has a datacontext set to a view model that is inheriting from StateBaseViewModel, you can see how the VisualStateManagerInvoker is feeding this View model a GoToStateAction by simple two way databinding.

Since this command is now ready to be used from our ViewModel we can invoke a state by simple executing the command like so.

   1: CancelCommand = new RelayCommand(x =>

   2:                 {

   3:                     GoToStateCommand.Execute("CancelState");

   4:                 });

This is super awesome isn’t it :)

Another cool thing about this is that you can use this trick so that you can invoke a state from a child to its parent. Lets say that you have a Window that contains a usercontrol (which has a StateBaseViewModel set as its datacontext) and a button. You want the button to show the UserControl. Ok easy Just drag and drop a GoToStateAction behavior and set its state to the state which makes the user control visible. But now lets say you have a button inside the user control and this button needs to invoke a state defined in the Window. The VSM works with namescopes thus you cannot invoke a state that is out of your namescope. BUT with the approach of uses VisualStateManagerInvoker we can do this since we can set the binding in the same XAML line that declares the usercontrol in the Window thus being in the same namescope as the Window :) We can then make a normal command that executes the GoToStateCommand in out StateBaseViewModel (this example is in the sample application to Cancel the check out of the shopping list and to show the thank you message when someone checks out the shopping cart)

Please note that the same code works for Silverlight.

Conclusion

I think that by using VSM one makes the Developer Designer workflow a happier thing. Designers love VSM and I learnt to love it as well. Now that I can invoke states easily from my ViewModel. Besides that since the implementation gets the VSM instance in an attached behavior and then feeds it to the ViewModel via databinding, the ViewModel never touches the VSM thus unit testing is much easier like this.

I found this way of working with the VSM awesome… OK I still need to make it cooler but as it is right now you can just grab the code and start working without any problems…. hope it helps :D

 

Download sample application (P.S Open this in Blend 3 to get maximum pleasure :) )

(Sample application contains MVVMHelper a small library I built for MVVM. It contains loads of goodies… have a look and enjoy)

Service Locator in MVVM

While doing MVVM one of the common problems to solve is to have the ViewModel consume entities that are “replaceable”. Let me give you an example so that you can better understand what I mean by “replaceable“. Let’s say you have a ViewModel that is using a DataAccess entity to get some data from a data store. You want to be able replace the DataAccess entity so that you can mock this entity for unit testing. Besides this you want to also be able to have some sample data while at design time. And not to forget, when at runtime you want the data access to connects to the database or whatever data store you are using.

In order to do solve this problem I use the ServiceLocator pattern. The Service Locator pattern is very simple. You have a RegisterService method where you register the instance of the service you want to provide and a GetService method which you would use to get the service you want.

Here is the signature of both methods

   1: public T GetService<T>()

   2:  

   3: public bool RegisterService<T>(T service)

And here is how to use them in code

   1: //get the data access service

   2: var dataAccess = GetService<IPeopleDataAccess>();

   3:  

   4: //Register the data access service

   5: vm.ServiceLocator.RegisterService<IPeopleDataAccess>(new PeopleDataAccess());

So for example to test the the ViewModel I can write a unit test like this

   1: MainViewModel viewModel = new MainViewModel();

   2: viewModel.ServiceLocator.RegisterService<IPeopleDataAccess>(new PeopleDataAccessMock());

   3:  

   4: Assert.AreEqual(viewModel.People.Count, PeopleDataAccessMock.PeopleCount,

   5:    "Invalid number of People returned");

   6: Assert.AreEqual(viewModel.People[0].Name, PeopleDataAccessMock.FirstPersonName,

   7:    "Invalid item in people list");

   8: Assert.AreEqual(viewModel.People[0].Surname, PeopleDataAccessMock.FirstPersonSurname,

   9:    "Invalid item in people list");

So basically in this unit test I am just creating a mock object and testing that my ViewModel is exposing the data from the data access (which is mocked so the data returned by this data access is known in the test context)

This is all cool but now how can I use this in WPF and MVVM. So the first question that people ask is how do I create the ViewModel and set it as the DataContext. And also who is responsible of assigning the services that the ViewModel will consume. In order to do this I use AttachedBehaviour and the Factory design pattern.

I created a simple attached property that accepts a type of a Factory that is responsible for creating the ViewModel and register whatever services it needs. The attached property is very simple, here is the code for it

   1: public class ViewModelLoader

   2: {

   3:     #region FactoryType

   4:  

   5:     /// <summary>

   6:     /// FactoryType Attached Dependency Property

   7:     /// </summary>

   8:     public static readonly DependencyProperty FactoryTypeProperty =

   9:         DependencyProperty.RegisterAttached("FactoryType", typeof(Type), typeof(ViewModelLoader),

  10:             new FrameworkPropertyMetadata((Type)null,

  11:                 new PropertyChangedCallback(OnFactoryTypeChanged)));

  12:  

  13:     /// <summary>

  14:     /// Gets the FactoryType property.  This dependency property 

  15:     /// indicates ....

  16:     /// </summary>

  17:     public static Type GetFactoryType(DependencyObject d)

  18:     {

  19:         return (Type)d.GetValue(FactoryTypeProperty);

  20:     }

  21:  

  22:     /// <summary>

  23:     /// Sets the FactoryType property.  This dependency property 

  24:     /// indicates ....

  25:     /// </summary>

  26:     public static void SetFactoryType(DependencyObject d, Type value)

  27:     {

  28:         d.SetValue(FactoryTypeProperty, value);

  29:     }

  30:  

  31:     /// <summary>

  32:     /// Handles changes to the FactoryType property.

  33:     /// </summary>

  34:     private static void OnFactoryTypeChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

  35:     {

  36:         FrameworkElement element = (FrameworkElement)d;

  37:         IFactory factory = Activator.CreateInstance( GetFactoryType(d) ) as IFactory;

  38:         if (factory == null)

  39:             throw new InvalidOperationException("You have to specify a type that inherits from IFactory");

  40:         element.DataContext = factory.CreateViewModel(d);

  41:     }

  42:  

  43:     #endregion

  44:  

  45: }

and you can use this in XAML like so

   1: <Window x:Class="ServiceLocatorSample.Main"

   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:     xmlns:vm="clr-namespace:MVVMHelper.Factory;assembly=MVVMHelper"

   5:     xmlns:fac="clr-namespace:ServiceLocatorSample.ViewModels.Factories"

   6:     Title="Main" Height="300" Width="300" vm:ViewModelLoader.FactoryType="{x:Type fac:MainViewModelFactory}">

Usually in the implementation of the factory I would check if the current state is at design time or runtime and accordingly register different services. Something like this

   1: public class MainViewModelFactory : IFactory

   2: {

   3:    public object CreateViewModel(DependencyObject sender)

   4:    {

   5:        var vm = new MainViewModel();

   6:        if (Designer.IsDesignMode)

   7:            vm.ServiceLocator.RegisterService<IPeopleDataAccess>(new DesignTimeData.DesignTimePeopleDataAccess());

   8:        else

   9:            vm.ServiceLocator.RegisterService<IPeopleDataAccess>(new PeopleDataAccess());

  10:        return vm;

  11:    }

  12: }

So with this factory at design time I would get Design time data showing in my designer but as soon as I run the app the actual data access (the real one that connects to the database) gets injected.

That’s it for today. Download the sample project and you will have a better idea of how all this works. Any questions or comments please let me know, I will be more than happy to answer :)

P.S In the sample I have the full MVVMHelper assembly that I use in my everyday work with MVVM so you will also have stuff like Mediator and other things that I will be blogging about very soon :)

Download the sample project

Animations and MVVM

This week I was asked from a colleague of mine, ‘How do I fire a command once a storyboard has completed?’. Do we have to break the MVVM here and write code behind. The answer is simple, HELL NO….

Attached Behavior to the rescue. Basically we can do this task by using an attached property, that will hook up to the Completed event of the storyboard and fire the command for us on the ViewModel. Here’s how to do this

   1: var timeline = d as Timeline;

   2: if (timeline != null && !timeline.IsFrozen)

   3: {

   4:    timeline.Completed += delegate

   5:    {

   6:        ICommand command = GetCommand(d);

   7:        object param = GetCommandParameter(d);

   8:  

   9:        if(command != null && command.CanExecute( param ))

  10:            GetCommand(d).Execute(GetCommandParameter(d));

  11:    };

  12: }

and here is how to use this in XAML

   1: <EventTrigger RoutedEvent="ButtonBase.Click">

   2:     <BeginStoryboard>

   3:         <Storyboard cmds:CommandStoryboard.Command="{Binding Close}" >

   4:             <DoubleAnimation Storyboard.TargetName="border" Storyboard.TargetProperty="Height" 

   5:                          DecelerationRatio="1.0" Duration="0:0:0.5" To="0"/>

   6:         </Storyboard>

   7:     </BeginStoryboard>

   8: </EventTrigger>

In the sample application (that is provided below with this article) shows how to animate some item in an items control and when the animation is completed the Storyboard executes a command that actually removes the item from the binding list.

I also created another simple class so that you can execute a Command from an EventTrigger. This is very handy since sometimes we want to execute a Command on a VM when some arbitrary RoutedEvent is raised. Here is the code for that

   1: public class CommandTimeline : Storyboard

   2: {

   3:     protected override Duration GetNaturalDurationCore(Clock clock)

   4:     {

   5:         return new Duration(TimeSpan.FromTicks(1));

   6:     }

   7:  

   8:     protected override Freezable CreateInstanceCore()

   9:     {

  10:         return new CommandTimeline();

  11:     }

  12: }

and here is how to consume it

   1: <EventTrigger RoutedEvent="FrameworkElement.Loaded">

   2:     <BeginStoryboard>

   3:         <cmds:CommandTimeline cmds:CommandStoryboard.Command="{Binding Test}" />

   4:     </BeginStoryboard>

   5: </EventTrigger>

As you can see this reuses the attached behavior that is used on normal storyboards. The only difference between a Storyboard and a CommandTimeline is that a CommandTimeline returns a Duration of 0 so the Completed event gets raised immediately.

PLEASE NOTE: This can be only used in an event trigger. When this is used with DataTriggers etc you will get an exception saying that the Trigger cannot be sealed. This happens because you cannot hook up to the Completed event of a storyboard in a DataTrigger/Trigger. In order to workaround this I use AttacedRoutedEvents so that I can have EventTriggers executing my commands.

Download the sample app + source code

Sync Multi Select Listbox with ViewModel

Today one of my colleagues at Infusion asked me how he could sync up the selection of a ListBox with his ViewModel. WPF supports already single mode selection via the ICollectionView yet when it comes to MultiSelect there is no out of the box support in WPF.

Attached Properties to the rescue ….. :)

I quickly when in my VS and wrote up a simple Attached property that hooks to the SelectionChanged event of the ListBox and populates a list of selected items to the ViewModel.

This is how the attached property looks like

   1: #region SelectedItems

   2:  

   3: /// <summary>

   4: /// SelectedItems Attached Dependency Property

   5: /// </summary>

   6: public static readonly DependencyProperty SelectedItemsProperty =

   7:     DependencyProperty.RegisterAttached("SelectedItems", typeof(IList), typeof(ListBoxHelper),

   8:         new FrameworkPropertyMetadata((IList)null,

   9:             new PropertyChangedCallback(OnSelectedItemsChanged)));

  10:  

  11: /// <summary>

  12: /// Gets the SelectedItems property.  This dependency property 

  13: /// indicates ....

  14: /// </summary>

  15: public static IList GetSelectedItems(DependencyObject d)

  16: {

  17:     return (IList)d.GetValue(SelectedItemsProperty);

  18: }

  19:  

  20: /// <summary>

  21: /// Sets the SelectedItems property.  This dependency property 

  22: /// indicates ....

  23: /// </summary>

  24: public static void SetSelectedItems(DependencyObject d, IList value)

  25: {

  26:     d.SetValue(SelectedItemsProperty, value);

  27: }

  28:  

  29: /// <summary>

  30: /// Handles changes to the SelectedItems property.

  31: /// </summary>

  32: private static void OnSelectedItemsChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

  33: {

  34:     var listBox = (ListBox)d;

  35:     ReSetSelectedItems(listBox);

  36:     listBox.SelectionChanged += delegate

  37:     {

  38:         ReSetSelectedItems(listBox);

  39:     };

  40: }

  41:  

  42: #endregion

  43:  

  44: private static void ReSetSelectedItems(ListBox listBox)

  45: {

  46:     IList selectedItems = GetSelectedItems(listBox);

  47:     selectedItems.Clear();

  48:     if (listBox.SelectedItems != null)

  49:     {

  50:         foreach (var item in listBox.SelectedItems)

  51:             selectedItems.Add(item);

  52:     }

  53: }

and here is how you would use it in the XAML

   1: <ListBox ItemsSource="{Binding MyData}" Grid.Column="1" local:ListBoxHelper.SelectedItems="{Binding SelectedData}"

   2:                  SelectionMode="Extended"/>

As you can see all you have to set is the List you want to populate in the ViewModel and the rest is taken care of by the Attached Property.

Please Note: This code was implemented quickly without any testing to prove an implementation idea, so please do review it before putting it in production :)

Download the source code

Mediator v2 for MVVM WPF and Silverlight applications

This last 2 weeks, us WPF Disciples have been talking a lot about the Mediator pattern for MVVM applications. Me and Josh Smith revised my previous Mediator implementation and found some problems with it.

Problem: There was a memory leak. Once a Mediator subscribes for one or more messages it would be kept in memory since the Mediator was holding a reference to the ViewModel.
Solution: We could have just exposed an unregister method so that when you call this method the Mediator would release the instance of the ViewModel. But sometimes it is hard to know when a ViewModel is going to die… So we went a step further and created the WeakAction. The WeakAction stores the instance of the ViewModel in a WeakRefence thus the ViewModel can be garbage collected without any problem and once it does get garbage collected the Mediator automatically removes that ViewModel registration from the list.

While we were at it we PIMPED the Mediator API :) We added 2 approaches to subscribe to the Mediator and we also added support for (thanks to David Anson suggestion) strongly typed parameters.

So now the Mediator offers 2 methods of registration, a declarative way of registering and an imperative way as well.

The Declarative approach. (Supported in WPF and Silverlight)

This approach uses attributes so that you can decorate the messages that act as subscribers for messages.Here is an example

   1: /// <summary>

   2: /// Subscribe to Message1

   3: /// </summary>

   4: /// <param name="message">The message to be passed</param>

   5: [MediatorMessageSink(MediatorMessages.Message1, ParameterType = typeof(SomeData))]

   6: public void Test(SomeData data)

   7: {

   8:     MessageBox.Show(data.Text + "\nReceived by: ColleagueA");

   9: }

So you just have to decorate your method with MediatorMessageSink attribute and the Method will get invoked every time a message is broadcasted via the Mediator.

As you can see the Mediator also supports strongly typed parameters. In order to do so you have to specify the ParameterType property on the attribute as shown in the sample code above. You can pass 0 or 1 parameters. If you don’t have any parameters just ignore the ParameterType (since this is an named Property and you can just not set it )

When using the declarative approach you must register the instance of the ViewModel to the Mediator. This is just one line of code in the ViewModel constructor. Here is how you do that

   1: public ColleagueA()

   2: {

   3:     //Register all decorated methods to the Mediator

   4:     Mediator.Register(this);

   5: }

This will inspect all methods of the ViewModel and look for the MediatorMessageSink attribute and register the appropriate methods to the Mediator. If you are going to have a base class for the ViewModels in your project and you can put this in the constructor of your base class. As simple an that.

 

The Imperative approach. (Supported in WPF ONLY)

If you do not want to use the attribute based registration we offer an imperative approach where you specify a method to be registered to a specific message. This implementation is exactly as it was in the old Mediator yet now it supports strongly typed parameters.

Here is how you can use this in your code

   1: public ColleagueC()

   2: {

   3:     //Register a specific delegate to the Mediator

   4:     Mediator.Register(MediatorMessages.Message1,

   5:         (Action<SomeData>)

   6:         delegate(SomeData x) 

   7:         {

   8:             Test = x.Text;

   9:             MessageBox.Show(x.Text + " \nReceived by: ColleagueC"); 

  10:         });

  11: }

This method is supported in WPF only since in Silverlight you cannot call an anonymous method (via reflection). If you try to use this method in Silverlight you will get an InvalidOperationException saying “This method is not supported in Silverlight”.

 

Conclusion

I packaged the Mediator in a class library so that you can go ahead and add a reference and reuse this library in your day to day projects.As always feedback is much appreciated.

Download MediatorLib + Sample application