Using the VisualStateManager with the Model-View-Viewmodel (MVVM) pattern in WPF or Silverlight

The visual state manager is a powerful addition to WPF 4.0 that facilitates handling state visuals for WPF and Silverlight controls. For example, a button control could have the states “Pressed”, “Normal”, “Disabled”, etc., and have different looks for each of those states, with transitions between them. If you’re unfamiliar with the Visual State Manager, check out the Visual State Manager Overview, or ScottGu’s post.

The Visual State Manager is already a part of Silverlight 2, and will be in WPF 4.0. You can, however, use it already if you download the official WPF Toolkit.

Now, as nice as the VisualStateManager (VSM) is, anyone who has tried to use it with the Model-View-Viewmodel (MVVM) or Model-View-Presenter (MVP) will have run into some issues. The big showstopper is that to change states using the VSM, you have to pass the view as an argument:

VisualStateManager.GoToState(View, stateName, true);

If you’re using the MVP pattern, this is okay, since your presenter will likely be aware of the view. For example, if you’re using Caliburn (which, by the way, is an awesome framework for MVP or MVVM), you can do something like this:

private object View { get; set; }
public override void ViewLoaded(object view, object context)
{
	View = view;
	base.ViewLoaded(view, context);
}

private void ChangeStateTo(string stateName)
{
	Application.Current.Dispatcher.Invoke((System.Action) (delegate()
	{
		VisualStateManager.GoToState((Control)View, stateName, true);
	}), null);
}

This works just fine. But if you’re using MVVM this isn’t really a solution, since the viewmodel should not have to know about the view. Also, ideally you’d like to bind your visual state to a property on the presenter/viewmodel. Unit testing states will also be difficult like this.

The solution lies in WPF’s attached properties (ooh, don’t we just love those?). We’ll create a helper class with a VisualState depencency property, and in the PropertyChangedCallback method for that property we’ll pass the sender (which will be our view) and the new property value (which will be the name of the state) to the VisualStateManager:

public class StateManager : DependencyObject
{
	public static string GetVisualStateProperty(DependencyObject obj)
	{
		return (string)obj.GetValue(VisualStatePropertyProperty);
	}

	public static void SetVisualStateProperty(DependencyObject obj, string value)
	{
		obj.SetValue(VisualStatePropertyProperty, value);
	}

	public static readonly DependencyProperty VisualStatePropertyProperty =
		DependencyProperty.RegisterAttached(
		"VisualStateProperty",
		typeof(string),
		typeof(StateManager),
		new PropertyMetadata((s, e) =>
		{
		var propertyName = (string)e.NewValue;
		var ctrl = s as Control;
		if (ctrl == null)
			throw new InvalidOperationException("This attached property only supports types derived from Control.");
		System.Windows.VisualStateManager.GoToState(ctrl, (string)e.NewValue, true);
	}));
}

Now in XAML we can bind the VisualStateName string property on our viewmodel to our new helper class:

<UserControl x:Class="MyApp.SomeView"
//namespaces omitted for brevity
MyApp:StateManager.VisualStateProperty="{Binding VisualStateName}">

And that’s it! Our helper class will switch states on the view for us. The viewmodel no longer has to be aware of the view, and unit testing states becomes a lot easier.