public static class ObservableCollectionExtensions
{
 public static void AddRange<T>(this ObservableCollection<T> observableCollection, IEnumerable<T> elements)
 {
  foreach (var element in elements) observableCollection.Add(element);
 }

 public static ObservableCollection<T> Create<T>(IEnumerable<T> elements)
 {
  var observableCollection = new ObservableCollection<T>();
  observableCollection.AddRange(elements);
  return observableCollection;
 }
}

In my sokoban implementation i have a cellview which exists out of 6 canvasses but only two of them (one for the cell type and one for the piece type) are visible at any given point in time. I have implemented this with 6 properties CanvasXVisible (with X being Player, Box, Wall, Goal, Floor and Cell) in my ViewModel but a State Machine / Manager may help clarify how the visibility of the canvasses are related. Here are the 2 visual state groups and their states that i would need for the CellView:

As you can see there is quite a lof of XAML involved to make the correct canvas visible:

 <Storyboard>
  <ObjectAnimationUsingKeyFrames BeginTime="00:00:00"  Duration="00:00:00.0010000" 
   Storyboard.TargetName="Space"  Storyboard.TargetProperty="(UIElement.Visibility)">
    <DiscreteObjectKeyFrame KeyTime="00:00:00">
     <DiscreteObjectKeyFrame.Value>
      <Visibility>Visible</Visibility>
     </DiscreteObjectKeyFrame.Value>
    </DiscreteObjectKeyFrame>
   </ObjectAnimationUsingKeyFrames>
  </Storyboard>
</VisualState>

For a simple modification to the Visibility property this seems like overkill but in many situations you will want to change more than this one property.

With the aid of the behaviors that come with Blend i can quickly add a couple of radio buttons, toss in some gotostate actions and end up with an interactive application:

 <i:Interaction.Triggers>
  <i:EventTrigger EventName="Checked">
   <ic:GoToStateAction StateName="Wall1"/>
  </i:EventTrigger>
 </i:Interaction.Triggers>
</RadioButton>

Feel free to try it yourself by changing the radio buttons:

Conclusion: All in all it is relatively easy to create interactive applications using Blend without writing a single line of code. Too bad that the behaviors are in an Expression assembly and don’t come with standard Silverlight. Another attention point is the maintainability of this new style of programming.

class GameViewModel : INotifyPropertyChanged, IListener<BoardChanged>
{
 public event PropertyChangedEventHandler PropertyChanged = delegate { }; 

 public GameViewModel()
 {
  var messageBus = ServiceLocator.MessageBus;
  messageBus.Subscribe<BoardChanged>(this);
 }

 void IListener<BoardChanged>.Handle(BoardChanged message)
 {
  PropertyChanged("Board");
 }
}

 <Grid.Resources>
  <DataTemplate x:Key="CellTemplate">
   <views:CellView />
  </DataTemplate>
 </Grid.Resources>
 <ItemsControl 
   ItemTemplate="{StaticResource CellTemplate}" 
   ItemsSource="{Binding Cells}" />
</Grid>

Because each CellViewModel needs to know which cell they manage i used the following dirty hack:

public CellView() 
{
 Loaded += CellView_Loaded; 
}

void CellView_Loaded(object sender, RoutedEventArgs e) 
{
 DataContext = new CellViewModel(DataContext);
}

Later on that day i realised there was a much cleaner solution: Let the BoardViewModel expose a collection of ViewModels.CellViewModel instead of Model.Cell. What a relief that i don’t have to use the Loaded event hack

Passive View doesn’t work (well) with smart views so i decided to give M-V-VM another because i really wanted to leverage WPF’s rich support for databinding.

The key difference between M-V-VM and Passive View is, imho, the fact that the ViewModel is unaware of the View unlike Passive View where the Presenter knows about the (simple) View.

When we test a Presenter i notice that we end up writing interaction based tests (assertions on a mocked view) and when we test a ViewModel we end up writing state-based tests instead.

For each layer i simply copied the XAML from Expression Design into my Cell.xaml file. Apparently all the layers are interpreted as a Canvas and the layer name determines their x:Name which makes it pretty easy to make the correct canvasses visible. With a simple ScaleTransform i can ensure that the canvasses are sized correctly.

Here is the updated version of Sokoban:

• Allow users to copy text from the UI (Or was the UX argument an excuse for playing with new toys?)
• MSTEST (I know that Silverlight Unit Test Framework exists.)
• Triggers (including data triggers)
• Typed data templates
• Uniform XAML (WPF: <Style TargetType={x:Type local:Foo}/> vs Silverlight: <Style TargetType={local:Foo}/>)
• Uniform validation API (eg: Data Annotations has three flavors)
• XAML with less namespaces (doesn’t really matter if you’re a designer only type)
• Support for Desktop (‘regular’) .NET assemblies. As long as Desktop .NET assemblies are not supported, tools that automate the process of generating a ‘shadow’ .Silverlight project (eg: Prism has for each project a silverlight project that, ignoring the different assembly references, exists out of file references to the orginal project).
• UniformGrid

Note: This list is not exhaustive and may change in the future.

I also dislike the fact that Blend adds values for Width and Height to each element by default. This requires me to hit that ‘auto’ square in the properties window for each element. What a waste of time