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.
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.
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
Then you can set the properties for this behavior in the properties tab. There you can specify which state to select.
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
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…
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
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.
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.
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
(Sample application contains MVVMHelper a small library I built for MVVM. It contains loads of goodies… have a look and enjoy)