SilverlightShow: Silverlight Community

WinRT Business Apps with Prism: Client Side Validation

editorial@silverlightshow.net (Brian Noyes ) — Tue, 11 Jun 2013 11:54:00 GMT

Download the source code for this article

This is part 5 in the series WinRT Business Apps with Prism.

Introduction

In this article, I am going to show you how to use the client side validation mechanisms of Prism for Windows Runtime. One challenge you face when you sit down to write a business application with WinRT is that you will probably have a fair amount of data entry in a business application. But then you will quickly discover that unlike WPF and Silverlight, which had great support for input validation through features in the Bindings and controls, WinRT has none. Sure you can write logic that detects when a property changes, evaluate some rules, and then maybe pop a message dialog in the user’s face if they input some bad data. But you will be spinning the code and the patterns for doing that all by yourself. And you won’t have any native support at the input control level for detecting and showing validation.

Don't miss

All SilverlightShow Ebooks

Because this is a primary business app scenario, the Prism team wanted to give you something more to work with. So one of the core features of Prism for Windows Runtime is a set of classes to help you do validation when the user inputs data. These classes evaluate validation rules when properties on a model or view model object change, store the error messages associated with any violated rules in the object so that you can data bind to them and display errors, and some example behaviors to make visual modifications to the bound controls when they have a validation error.

So let’s get started seeing how to use those capabilities and looking at the classes that support this in Prism.

Step 1: Add some data entry fields

The starting point for this article’s code is the completed code from Part 3 in this series. In that app, we had a little bit of data input with the selection of products and entry of a quantity, but I need a few more free form entries from a user to demonstrate input validation with a more common scenarios. So I added a Customer model type and some fields at the bottom of the Add Sales page to allow you to input customer information associated with the current order being displayed on that page. Below you can see the visual result and the XAML for those fields as a starting point.

   1: <Grid Grid.Row="3">

   2:     <Grid.ColumnDefinitions>

   3:         <ColumnDefinition Width="Auto" />

   4:         <ColumnDefinition Width="Auto" />

   5:         <ColumnDefinition Width="*" />

   6:     Grid.ColumnDefinitions>

   7:     <Grid.RowDefinitions>

   8:         <RowDefinition Height="Auto" />

   9:         <RowDefinition Height="Auto" />

  10:         <RowDefinition Height="Auto" />

  11:         <RowDefinition Height="Auto" />

  12:         <RowDefinition Height="Auto" />

  13:         <RowDefinition Height="Auto" />

  14:         <RowDefinition Height="Auto" />

  15:     Grid.RowDefinitions>

  16:     <TextBlock Grid.Row="0"

  17:                Grid.Column="0"

  18:                Text="Name"

  19:                Style="{StaticResource SubheaderTextStyle}"

  20:                Margin="5" />

  21:     <TextBox Grid.Row="0"

  22:              Grid.Column="1"

  23:              Text="{Binding Customer.Name, Mode=TwoWay}"

  24:              Margin="5"

  25:              Width="500"

  26:              HorizontalAlignment="Left"/>

  27:     <TextBlock Grid.Row="1"

  28:                Grid.Column="0"

  29:                Text="Phone"

  30:                Style="{StaticResource SubheaderTextStyle}"

  31:                Margin="5" />

  32:     <TextBox Grid.Row="1"

  33:              Grid.Column="1"

  34:              Text="{Binding Customer.Phone, Mode=TwoWay}"

  35:              Margin="5"

  36:              Width="500"

  37:              HorizontalAlignment="Left"/>

  38:     <TextBlock Grid.Row="2"

  39:                Grid.Column="0"

  40:                Text="Address"

  41:                Style="{StaticResource SubheaderTextStyle}"

  42:                Margin="5" />

  43:     <TextBox Grid.Row="2"

  44:              Grid.Column="1"

  45:              Text="{Binding Customer.Address, Mode=TwoWay}"

  46:              Margin="5"

  47:              Width="500"

  48:              HorizontalAlignment="Left" />

  49:     <TextBlock Grid.Row="3"

  50:                Grid.Column="0"

  51:                Text="City"

  52:                Style="{StaticResource SubheaderTextStyle}"

  53:                Margin="5" />

  54:     <TextBox Grid.Row="3"

  55:              Grid.Column="1"

  56:              Text="{Binding Customer.City, Mode=TwoWay}"

  57:              Margin="5"

  58:              Width="500"

  59:              HorizontalAlignment="Left" />

  60:     <TextBlock Grid.Row="4"

  61:                Grid.Column="0"

  62:                Text="State"

  63:                Style="{StaticResource SubheaderTextStyle}"

  64:                Margin="5" />

  65:     <TextBox Grid.Row="4"

  66:              Grid.Column="1"

  67:              Text="{Binding Customer.State, Mode=TwoWay}"

  68:              Margin="5"

  69:              Width="500"

  70:              HorizontalAlignment="Left" />

  71:     <TextBlock Grid.Row="5"

  72:                Grid.Column="0"

  73:                Text="Zip Code"

  74:                Style="{StaticResource SubheaderTextStyle}"

  75:                Margin="5" />

  76:     <TextBox Grid.Row="5"

  77:              Grid.Column="1"

  78:              Text="{Binding Customer.Zip, Mode=TwoWay}"

  79:              Margin="5"

  80:              Width="500"

  81:              HorizontalAlignment="Left" />

  82:     <Button Grid.Row="6"

  83:             Grid.Column="1"

  84:             Content="Submit Order"

  85:             Command="{Binding SubmitOrderCommand}"

  86:             FontSize="20" />

  87: Grid>

Step 2: Add a Customer Model object

Now we need a model object that those fields will bind to. And we want to express some validation rules on that object for those fields. In Prism, we chose to support the most ubiquitous and built-in way to express validation rules – DataAnnotations. If you haven’t been exposed to these, it is a set of attributes in the System.ComponentModel.DataAnnotations namespace and some supporting classes to evaluate them that let you declaratively express validation rules on properties of your model objects. DataAnnotations are automatically evaluated by a number of different parts of the .NET Framework, including ASP.NET model binding, Entity Framework, and WCF RIA Services.

Because WinRT does not automatically evaluate those attribute-based rules, we need some infrastructure code to do that for us. Also, once the rules are evaluated, we need to store the resulting errors in a way that can be easily used to display them to the user. This leads us to use the ValidatableBindableBase class from Prism as our Customer base class to provide that support, which I will drill into shortly.

The resulting Customer class definition ends up looking like this:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.ComponentModel.DataAnnotations;

   4: using System.Linq;

   5: using Microsoft.Practices.Prism.StoreApps;

6:

   7: namespace HelloPrismForWinRT.Models

   8: {

   9:     public class Customer : ValidatableBindableBase

  10:     {

  11:         private string _Name;

  12:         private string _Phone;

  13:         private string _Address;

  14:         private string _City;

  15:         private string _State;

  16:         private string _Zip;

17:

  18:         [Required]

  19:         public string Name

  20:         {

  21:             get { return _Name; }

  22:             set { SetProperty(ref _Name, value); }

  23:         }

24:

  25:         [RegularExpression(@"^\D?(\d{3})\D?\D?(\d{3})\D?(\d{4})$",

  26:             ErrorMessage="Please enter a 10 digit phone number")]

  27:         public string Phone

  28:         {

  29:             get { return _Phone; }

  30:             set { SetProperty(ref _Phone, value); }

  31:         }

32:

  33:         public string Address

  34:         {

  35:             get { return _Address; }

  36:             set { SetProperty(ref _Address, value); }

  37:         }

38:

  39:         public string City

  40:         {

  41:             get { return _City; }

  42:             set { SetProperty(ref _City, value); }

  43:         }

44:

  45:         [StringLength(2)]

  46:         public string State

  47:         {

  48:             get { return _State; }

  49:             set { SetProperty(ref _State, value); }

  50:         }

51:

  52:         public string Zip

  53:         {

  54:             get { return _Zip; }

  55:             set { SetProperty(ref _Zip, value); }

  56:         }

  57:     }

  58: }

You can see the use of the Required, RegularExpression, and StringLength attributes on the Name, Phone, and State properties, respectively. In addition there is a Range attribute for numeric ranges, and then the power hook – a CustomValidation attribute that you can point to your own method to do any kind of complex custom validation that you need to.

The ValidatableBindableBase class from Prism provides several things for your class. The first is that it inherits from BindableBase itself, which encapsulates the implementation of INotifyPropertyChanged so that your object can participate correctly in data binding when properties change behind the scenes. BindableBase provides some helper methods that let you write more compact property setters like those shown in the Customer class listing where the set block just needs to call SetProperty(), passing a reference to the member variable to be set and the new value that is being set on the property. That method encapsulates checking to see if the value is the same that it was before, in which case it does nothing, or if it is different, it sets the member variable and raises the property changed event.

ValidatableBindableBase also encapsulates an instance of a class called BindableValidator. This is the brains of the validation system, in that it has a method called ValidateProperty that can be called for an object it is attached to and it will reflect on that property, find the DataAnnotation attributes, evaluate them, and put any errors for that property into a dictionary of Errors it maintains that keeps a list of errors per property (where the property name is the key in the dictionary and the value is the list of error strings). It also exposes an indexer so that you can simply index into the BindableValidator with a property name and it will return the list of error strings associated with that property.

ValidatableBindableBase exposes the underlying indexer from the BindableValidator so that it can be used in data binding, along with a GetAllErrors method if you want to display a validation summary to the user for all errors on a given object. It also overrides the SetProperty method from BindableBase so it can use that as a trigger point for calling ValidateProperty when a property is changing. And of course if you know your WinRT data binding, you know that will happen when there is a focus change off a field that is being edited.

Step 3: Expose the Customer for data binding

I added a Customer property to the AddSalesPageViewModel, but since that will be associated with the current order that is being managed by the OrderRepository, the view model simply gets the Customer out of the repository:

   1: public Customer Customer

   2: {

   3:     get { return _OrderRepository.Customer; }

   4: }

Then the Repository just initializes a Customer on construction associated with the current order. Obviously in a real application there would need to be a way to clear out the current data associated with an order when it is completed or canceled to allow other orders to be placed, but this sample is not covering that use case.

   1: public interface IOrderRepository

   2: {

   3:     void AddToOrder(Product product, int quantity);

   4:     ObservableCollection CurrentOrderItems { get; }

   5:     Customer Customer { get; set; }

   6: }

7:

   8: public class OrderRepository : IOrderRepository

   9: {

  10:     ...

  11:     public Customer Customer { get; set; }

12:

  13:     public OrderRepository(ISessionStateService stateService)

  14:     {

  15:         Customer = new Customer();

  16:         ...

  17:     }

  18:     ...

  19: }

Step 4: Display validation errors to the user

Next to each one of the input fields that have rules associated with them, I added a TextBlock to display the errors for the bound property. That TextBlock needs to be bound to the errors collection associated with that property. Since the bound object is the Customer, and it has an indexer exposed from the ValidatableBindableBase to get to those errors, what that looks like is this:

   1: <TextBlock Grid.Row="0"

   2:            Grid.Column="2"

   3:            Style="{StaticResource ErrorStyle}"

   4:            Text="{Binding Customer.Errors[Name],

   5:                   Converter={StaticResource FirstErrorConverter}}" />

So the Text property is bound to Customer.Errors[Name], which returns the collection of errors strings that result from evaluating the rules associated with the Name property. However, since that returns a collection of strings, we need a converter that will turn that into a simple string to set the Text property. I pulled in a converter from the AdventureWorks Shopper sample application that comes with Prism, which just pulls the first error out of the collection if there are any:

   1: public sealed class FirstErrorConverter : IValueConverter

   2: {

   3:     public object Convert(object value, Type targetType,

   4:         object parameter, string language)

   5:     {

   6:         ICollection<string> errors = value as ICollection<string>;

   7:         return errors != null && errors.Count > 0 ? errors.ElementAt(0) : null;

   8:     }

9:

  10:     public object ConvertBack(object value, Type targetType,

  11:         object parameter, string language)

  12:     {

  13:         throw new NotImplementedException();

  14:     }

  15: }

The ErrorStyle that is being set simply sets the Foreground color Red and the FontSize to 20.

Step 5: Highlight the control when it has a validation error

Another thing most validation mechanisms do that you may want to support as well is to highlight the control itself in some way when it has a validation error. For example, both WPF and Silverlight put a red box around the control when the Binding sees that there are validation errors.

Because there is no built in support for that in WinRT, you have to do a little extra work. The best way to implement some code that supplements the behavior of an existing control that you do not own the code for is with a behavior. In WinRT, attached behaviors (based off of attached properties) are the way to go until we have first class support for Blend Behaviors in WinRT.

The Prism sample code has a couple of these already implemented for you. For this article, I pulled the HighlightOnErrors behavior class out of the Prism Validation QuickStart that is designed to work with a TextBox and apply a style to it when there are errors to change it’s appearance. That class looks like this:

   1: public static class HighlightOnErrors

   2: {

   3:     public static DependencyProperty PropertyErrorsProperty =

   4:         DependencyProperty.RegisterAttached("PropertyErrors",

   5:         typeof(ReadOnlyCollection<string>), typeof(HighlightOnErrors),

   6:         new PropertyMetadata(BindableValidator.EmptyErrorsCollection, OnPropertyErrorsChanged));

7:

   8:     public static ReadOnlyCollection<string> GetPropertyErrors(DependencyObject obj)

   9:     {

  10:         if (obj == null) { return null; }

  11:         return (ReadOnlyCollection<string>)obj.GetValue(PropertyErrorsProperty);

  12:     }

13:

  14:     public static void SetPropertyErrors(DependencyObject obj,

  15:        ReadOnlyCollection<string> value)

  16:     {

  17:         if (obj == null) { return; }

  18:         obj.SetValue(PropertyErrorsProperty, value);

  19:     }

20:

  21:     private static void OnPropertyErrorsChanged(DependencyObject d,

  22:         DependencyPropertyChangedEventArgs args)

  23:     {

  24:         if (args == null || args.NewValue == null) { return; }

25:

  26:         TextBox textBox = (TextBox)d;

  27:         var propertyErrors = (ReadOnlyCollection<string>)args.NewValue;

28:

  29:         Style textBoxStyle = (propertyErrors.Count() > 0) ?

  30:             (Style)Application.Current.Resources["HighlightTextStyle"] : null;

31:

  32:         textBox.Style = textBoxStyle;

  33:     }

  34: }

You can see that it declares an attached property called PropertyErrors. It is designed so you can set that property through a binding to the errors collection for a property. When the errors collection changes, it will re-evaluate its logic and set a style on the control if there are errors in the errors collection. It is hard wired to expect an application scoped resource named

So all we need to do is attach that to the TextBoxes that have rules on them with the PropertyErrors bound the to Errors collection for the same property the Text property is bound to and we are good to go:

   1: <TextBox Grid.Row="0"

   2:          Grid.Column="1"

   3:          Text="{Binding Customer.Name, Mode=TwoWay}"

   4:          Margin="5"

   5:          Width="500"

   6:          HorizontalAlignment="Left"

   7:          beh:HighlightOnErrors.PropertyErrors="{Binding Customer.Errors[Name]}" />

Now with that in place on the Name, Phone, and State field, and errors introduced on those fields, we have a display like so:

Step 6: Validate all properties on submit

A final thing you probably want to do is make sure all errors are checked when the user tries to submit, because the validation errors do not display until the user has tried to change the field (by design) and you may have some other required fields there. Plus you probably want to prevent calling the back end or trying to persist the changes if they are invalid.

To do that I have a DelegateCommand bound to the SubmitOrder button with the following command handler:

   1: private void OnSubmit()

   2: {

   3:     // You can trigger all properties to evaluate their rules

   4:     Customer.ValidateProperties();

   5:     // May want to get all errors for a validation summary display:

   6:     var allErrors = Customer.GetAllErrors().Values.SelectMany(c => c).ToList();

   7:     // You can check for any validation errors by checking the count of all errors

   8:     if (allErrors.Count == 0)

   9:     {

  10:         // Go ahead and persist

  11:     }

  12: }

You can see that the ValidateProperties() method will trigger validation across all properties on the object. Once that is done, the errors collection for each property will be populated. You can collect all errors across all properties with the GetAllErrors method and can flatten that dictionary into a list with LINQ.

Summary

In this article I have shown you how to use the validation features of Prism to support rich input validation with minimal effort. You saw that all you need to do is first have your model objects inherit from ValidatableBindableBase and have your property set blocks call SetProperty on the base. Next you add DataAnnotation attribute based rules to the properties on your object. You can then data bind to that object normally, and whenever you set a property, the data annotations rules for that property will be evaluated. To display the error strings, you can bind through the Errors indexer exposed from the base class, passing in the property that you want to get the errors for. And to display errors on the control itself, you can use a behavior to adorn that control based on the presence of errors in the same indexer.

About the Author

Brian Noyes is CTO of Solliance (www.solliance.net), a software development company offering Architecture as a Service, end-to-end product development, technology consulting and training. Brian is a Microsoft Regional Director and MVP, Pluralsight author, and speaker at conferences worldwide. Brian worked directly on the Prism team with Microsoft patterns & practices, and has a Pluralsight course that covers Prism for Windows Runtime end-to-end titled Building Windows Store Business Apps with Prism. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on Twitter @briannoyes.

WinRT Business Apps with Prism: PubSubEvents

editorial@silverlightshow.net (Brian Noyes ) — Tue, 21 May 2013 14:01:00 GMT

Download the source code for this article

This is part 4 in the series WinRT Business Apps with Prism.

Introduction

In this article, I am going to cover the loosely coupled communication mechanism from the newly released Prism for Windows Runtime, called PubSubEvents. This communication mechanism is also known as EventAggregator because it is based on the design pattern of the same name. If you have had exposure to Prism 4, then you might also be familiar with EventAggregator from there. If you already know how to use Prism 4’s EventAggregator, you know how to use the one that ships with Prism for Windows Runtime, because this is simply a ported version, no functional differences other than the projects in which you can use it. For those folks, the quick and dirty is this: the EventAggregator of Prism 4 was ported to a Portable Class Library that uses a SynchronizationContext under the covers for the thread dispatching features, which removes the coupling to WPF and Silverlight and avoids taking a new dependency on WinRT for what the EventAggregator does. This library is set up so that it works with any .NET 4.0 or later, Silverlight 4 or later, Windows Phone 7.1 or later, or WinRT project.

Don't miss

All SilverlightShow Ebooks

In this article, for those that don’t already have a lot of experience with EventAggregator, I will show you how you can use it to communicate between components in your application, typically between ViewModels or between client side services, so that those components do not have to take direct dependencies on each other. Additionally, I’ll show how you can benefit from the fact that Prism PubSubEvents use weak references by default, alleviating the need to worry about unsubscribing from events to avoid memory leaks, how to use it’s thread dispatching capabilities, and how to wire up filter methods to keep your event handlers from being called unless some criteria is met.

Step 1: Set up an app with two decoupled ViewModels

I’m using a modified version of the EventAggregator QuickStart from the Prism for Windows Runtime guidance as my starting point. You can download that starting point here.

The official QuickStart is pretty close to the same as the completed sample from this article. The main difference is that the official one does not use the MvvmAppBase class on the App class, so there is a bunch of boilerplate startup code in the App class. This is because this QuickStart was written and documented prior to the MvvmAppBase class being factored out. If you look at the sample code from this article, you will see that the App class is simple and clean by using the MvvmAppBase class instead, the structure of which was discussed in Part 1 and Part 2 of this series.

This app has a parent ViewModel on the MainPage, with two simple child Views/ViewModels – PublisherViewModel and SubscriberViewModel. Here is what the UI will look like running.

Step 2: Grab the Prism Libraries through NuGet

To build the app starting point solution, you will need to add in the Microsoft.Practices.Prism.StoreApps and Microsoft.Practices.Prism.PubSubEvents libraries. You can do that by downloading the code from here, or you can use NuGet to pull in the binaries. I’m going to do the latter for this article. So head out to Nuget, and do a search on the terms Prism.StoreApps and Prism.PubSubEvents. At the time I am writing this, the NuGet feed has not been updated, so I had to select Pre-release at the top. But that should be updated soon since Prism for Windows Runtime officially released on May 17 2013.

At this point, if you downloaded the starting point solution in Step 1, you should be able to build and run, but the buttons don’t do anything noticeable yet.

Step 3: Add the EventAggregator

To do pub/sub events, you need a middleman object to decouple the publisher and the subscriber. The idea is that they can each take a dependency on the middleman, then they don’t have to directly depend on each other. The EventAggregator is that middleman in Prism PubSubEvents. It is a singleton service that acts as a repository or registry of event objects. The event objects are the things that actually do the dispatching of calls from a publisher out to the subscribers for a particular event. So you need to make a reference to the singleton IEventAggregator reference available to the publishers and subscribers. You could do this through a container as was covered in Part 2, but for this article I am just going to use manual dependency injection.

The way the app is structured, the MainPageViewModel explicitly constructs the two child ViewModels (PublisherViewModel and SubscriberViewModel) and renders their views via DataTemplates.

   1: public class MainPageViewModel : ViewModel

   2: {

   3:     public MainPageViewModel()

   4:     {

   5:         SubscriberViewModel = new SubscriberViewModel();

   6:         PublisherViewModel = new PublisherViewModel();

   7:     }

8:

   9:     public SubscriberViewModel SubscriberViewModel { get; set; }

  10:     public PublisherViewModel PublisherViewModel { get; set; }

  11: }

   1: <Page.Resources>

   2:     <DataTemplate x:Key="SubscriberTemplate">

   3:         <views:SubscriberView />

   4:     DataTemplate>

   5:     <DataTemplate x:Key="PublisherTemplate">

   6:         <views:PublisherView />

   7:     DataTemplate>

   8: Page.Resources>

   9: ...

  10: <ContentControl Content="{Binding PublisherViewModel}"

  11:             ContentTemplate="{StaticResource PublisherTemplate}"

  12:             HorizontalContentAlignment="Center"

  13:             VerticalContentAlignment="Center" />

  14: <ContentControl Grid.Column="1"

  15:             Content="{Binding SubscriberViewModel}"

  16:             ContentTemplate="{StaticResource SubscriberTemplate}"

  17:             HorizontalContentAlignment="Center"

  18:             VerticalContentAlignment="Center" />

So I can simply construct the EventAggregator up in the App class, and pass it into the MainPageViewModel by using a Register call on the ViewModelLocator. It is important to construct the EventAggregator on the UI thread so that it can set up the underlying SynchronizationContext correctly for thread dispatching, so I wait until the OnInitialize override to construct it, then pass it into the MainPageViewModel as a parameter, keeping it in a member variable on the App class to make the singleton lifetime match the App lifetime.

   1: sealed partial class App : MvvmAppBase

   2: {

   3:     IEventAggregator _EventAggregator;

4:

   5:     protected override void OnLaunchApplication(LaunchActivatedEventArgs args)

   6:     {

   7:         NavigationService.Navigate("Main", null);

   8:     }

9:

  10:     protected override void OnInitialize(IActivatedEventArgs args)

  11:     {

  12:         base.OnInitialize(args);

  13:         _EventAggregator = new EventAggregator();

  14:         ViewModelLocator.Register(typeof(MainPage).ToString(),

  15:             () => new MainPageViewModel(_EventAggregator));

  16:     }

  17: }

Next I need to modify the MainPageViewModel to accept the constructor parameter, and to pass it down to the PublisherViewModel and SubscriberViewModel.

   1: public class MainPageViewModel : ViewModel

   2: {

   3:     public MainPageViewModel(IEventAggregator eventAggregator)

   4:     {

   5:         SubscriberViewModel = new SubscriberViewModel(eventAggregator);

   6:         PublisherViewModel = new PublisherViewModel(eventAggregator);

   7:     }

8:

   9:     public SubscriberViewModel SubscriberViewModel { get; set; }

  10:     public PublisherViewModel PublisherViewModel { get; set; }

11:

  12:     ...

  13: }

Now likewise, they each need parameterized constructors to accept and hold the reference to IEventAggregator.

   1: public class PublisherViewModel : ViewModel

   2: {

   3:     private readonly IEventAggregator _EventAggregator;

4:

   5:     public PublisherViewModel(IEventAggregator eventAggregator)

   6:     {

   7:         _EventAggregator = eventAggregator;

   8:         ...

   9:     }

  10:     ...

  11: }

   1: public class SubscriberViewModel : ViewModel

   2: {

   3:     private readonly IEventAggregator _EventAggregator;

4:

   5:     public SubscriberViewModel(IEventAggregator eventAggregator)

   6:     {

   7:         _EventAggregator = eventAggregator;

   8:         ...

   9:     }

  10:     ...

  11: }

Step 4: Define an event class for the needed communication

For the sample app, the idea is that the publisher will publish when a shopping cart has changed that the subscriber also needs to monitor and display information about. When using Prism PubSubEvents, you define an event class for each distinct communication along with a strongly typed payload that can be passed along with the event. The event for our sample looks like this:

   1: public class ShoppingCartChangedEvent : PubSubEvent { }

Believe it or not, that is all there is to defining the event. All the implementation is in the PubSubEvent base class. You just need to define a class that represents the specific event you want to publish and maps it through the generic argument to the payload entity you want to pass when it fires. If you have no payload, you can just use object as the type and pass null.

Step 5: Publish

Wherever it is appropriate in your code (based on user interaction or other triggers) you just need one line of code to publish:

   1: _EventAggregator.GetEvent().Publish(_cart);

You call the GetEvent method on IEventAggregator to get a reference to a singleton instance of your event class (managed by the EventAggregator itself), and then call Publish on that event, passing the strongly typed payload. In the sample app, this is done from the command handlers for the buttons in that view, specifically the PublishOnUIThread method for now.

   1: private void PublishOnUIThread()

   2: {

   3:     AddItemToCart();

   4:     _EventAggregator.GetEvent().Publish(_cart);

   5: }

Step 6: Subscribe

Likewise, in the Subscriber, you can hook up the subscription wherever it makes sense, but typically in a ViewModel that is on construction, as soon as the EventAggregator reference is injected:

   1: public SubscriberViewModel(IEventAggregator eventAggregator)

   2: {

   3:     _EventAggregator = eventAggregator;

   4:     ...

   5:     _EventAggregator.GetEvent().Subscribe(HandleShoppingCartUpdate);

   6: }

The handling method that you pass as a delegate reference to this method needs to have a void return (events are fire and forget) and takes in a single parameter of the payload type:

   1: private void HandleShoppingCartUpdate(ShoppingCart cart)

   2: {

   3:     ItemsInCart = cart.Count;

   4: }

That is it for the basic hookup of pub/sub events in Prism. At this point you should be able to run, click on the “Add Item to Cart (UI Thread) button, and see the count increment in the subscriber view.

Step 7: Define a background subscriber for showing weak references

There is a separate class defined in the sample called BackgroundSubscriber:

   1: public class BackgroundSubscriber

   2: {

   3:     CoreDispatcher _dispatcher;

   4:     public BackgroundSubscriber(CoreDispatcher dispatcher)

   5:     {

   6:         _dispatcher = dispatcher;

   7:     }

8:

   9:     public void HandleShoppingCartChanged(ShoppingCart cart)

  10:     {

  11:         var threadId = Environment.CurrentManagedThreadId;

  12:         var count = cart.Count;

13:

  14:         // Assign into local variable because it is meant to be fire

  15:         // and forget and calling would require an await/async

  16:         var dialogAction = _dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>

  17:             {

  18:                 MessageDialog dialog = new MessageDialog(

  19:                     string.Format(CultureInfo.InvariantCulture,

  20:                     "Shopping cart updated to {0} item(s) in background subscriber on thread {1}",

  21:                     count, threadId));

  22:                 var showAsync = dialog.ShowAsync();

  23:             });

  24:     }

  25: }

There is a little complexity in the code there, but basically this is a class with a method that can be targeted by the pub/sub event that will pop a message dialog even if it is called on a background thread and will show what thread it was called on and the number of items in the shopping cart.

The reason for this class is that it is an object that we can explicitly new up, hold a reference to from the view model, then release the reference and cause garbage collection, and see if it sticks around if there is still an event subscription targeting it.

So in the subscriber view you can see two buttons – Add Background Subscriber and GC Background Subscriber. The command handler for the first creates the subscriber, adds an event subscription for it, and holds it in a member variable.

   1: private void AddBackgroundSubscriber()

   2: {

   3:     // Create subscriber and hold on to it so it does not get garbage collected

   4:     _subscriber = new BackgroundSubscriber(Window.Current.Dispatcher);

   5:     _EventAggregator.GetEvent().Subscribe(

   6:         _subscriber.HandleShoppingCartChanged);

   7: }

The second button command handler releases the member variable reference to the subscriber and forces a garbage collection – but note that no code has unsubscribed the event handling that pointed to the object through its handling method.

   1: private void GCBackgroundSubscriber()

   2: {

   3:     // Release and GC, showing that we don't have to unsubscribe

   4:     //  to keep the subscriber from being garbage collected

   5:     _subscriber = null;

   6:     GC.Collect();

   7: }

After adding that code, if you run, click on the Add Background Subscriber button, and then start firing the events from the UI thread, you will see the message dialog pop each time. Then press the GC Background Subscriber button, fire a few more events, and you will see that the background subscriber is no longer there to receive events because it has been garbage collected even though there was never an Unsubscribe call to release the reference that was passed into the event through a delegate.

This is there to address the number one cause of memory leaks in .NET applications – event subscriptions between two objects with different lifetimes where the subscribing object has a shorter lifetime from the consuming code that the object it is subscribing on. A normal event subscription through a delegate holds a strong reference back to the subscriber that will prevent it from being garbage collected if it does not get unsubscribed, even if all other references are released.

But Prism events use a WeakReference under the covers by default, which the garbage collector ignores in its reference counting scheme, so it will allow the underlying object to get garbage collected if nothing else has a reference to it, thus alleviating you from needing to worry about unsubscribing at the appropriate time.

If you want to have a strong reference, just use an overload of the Subscribe method with a second parameter named keepSubscriberReferenceAlive:

   1: _EventAggregator.GetEvent().Subscribe(

   2:     _subscriber.HandleShoppingCartChanged, true);

Step 8: Leverage Thread Dispatching

Another feature of the PubSubEvents is the ability to tell Prism when you subscribe what thread you want to be notified on. If you were to publish from the non-UI thread button in the publisher using a Task to fire on a background thread:

   1: private void PublishOnBackgroundThread()

   2: {

   3:     AddItemToCart();

   4:     Task.Factory.StartNew(() =>

   5:         {

   6:             Debug.WriteLine(String.Format("Publishing from thread: {0}",

   7:                 Environment.CurrentManagedThreadId));

   8:             _EventAggregator.GetEvent().Publish(_cart);

   9:         });

  10: }

You would see you have a problem on the subscriber side when it tries to update a property that is bound from the UI – it throws an exception because the event comes into the subscriber on the background thread of the publisher. All you need to do to fix that is use a different overload of the Subscribe method that takes a ThreadOption parameter. This allows you to dictate from the subscriber that you want to be notified on either the Publisher thread (the default), the UIThread, or a Background thread.

   1: _EventAggregator.GetEvent().Subscribe(

   2:     HandleShoppingCartUpdate, ThreadOption.UIThread);

The PubSubEvents class will handle getting the call dispatched onto the UI thread using a SynchronizationContext it sets up when it is constructed. This means if you are going to use the UIThread option, you need to make sure the EventAggregator is constructed on the UI thread. If you don’t you will get an exception when the Subscribe call is made telling you that. Using SynchronizationContext instead of a Dispatcher means the code can be portable to any .NET platform. If you choose the Background option, a Task will be used to call the subscriber on a Task Scheduler background thread.

Step 9: Leverage Filtering

Sometimes you don’t want your event handler to be called unless some criteria is met first. You could do this by putting a guard condition in the handling method, but from a testability and separation of concerns perspective, that should happen outside of the method that is focused on handling the event. So Prism PubSubEvents lets you pass a filter criteria, in the form of a Predicate delegate (which is equivalent to a Func delegate). You can do that by passing a full delegate reference to a method that takes in the payload type and returns a bool, or you can pass a lambda expression directly to the Subscribe method.

So for our example, if we want to show a warning on the screen if the count of items in the shopping cart exceeds 10, we can do the subscription like this:

   1: _EventAggregator.GetEvent().Subscribe(

   2:     HandleShoppingCartUpdateFiltered,

   3:     ThreadOption.UIThread, false, (cart) => cart.Count > 10);

HandleShoppingCartUpdateFiltered just sets a property that causes a warning to show. But that won’t be called unless the filter criteria (cart.Count > 10) is met.

Summary

In this article, I showed you how simple PubSubEvents in Prism are to use. You saw that once you have a reference to the IEventAggregator in the publisher and subscriber, it is one line of code to publish, one line of code to subscribe, and effectively one line of code to define the event itself. On the subscriber side you have the options of not using weak references (which it does by default), controlling the thread you are notified on, and passing a filter condition that gets evaluated and must pass (return true) before the handling method is called. The publish and subscribe methods are strongly typed based on the payload type specified by the event class.

This allows you to have communications between ViewModels or between repositories and other client side services without needing to pass explicit references between them – meaning more loose coupling in your architecture.

About the Author:

Brian Noyes is CTO of Solliance (www.solliance.net), a software development company offering Architecture as a Service, end-to-end product development, technology consulting and training. Brian is a Microsoft Regional Director and MVP, Pluralsight author, and speaker at conferences worldwide. Brian worked directly on the Prism team with Microsoft patterns and practices. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on Twitter @briannoyes.

WinRT Business Apps with Prism: App State Management

editorial@silverlightshow.net (Brian Noyes ) — Mon, 29 Apr 2013 14:26:00 GMT

Download the source code for this article

This is part 3 in the series WinRT Business Apps with Prism.

Introduction

In the last article in this series, I walked you quickly through using commands, wiring up dependencies, and handling navigation using Prism in a Windows Store app. In this article I am going to focus on the application lifecycle state management features. I’ll show you how you can manage transient application data that you want to survive when your application gets suspended, terminated, and resumed. You’ll see how you can store objects that are properties in your view models, as well as anywhere else in your application such as transient data in a repository.

WinRT Application Lifecycle

Don't miss

All SilverlightShow Ebooks

WinRT apps have a number of different ways they can be started, and phases that they go through while running. An app starts in a not running state. Once the user launches it it is running. But the user can switch to a different Windows Store or desktop app at any time, which will cause your app to go off screen. When it does, it goes into a suspended state. While suspended, no threads are allocated to the program, so it is consuming zero CPU resources. But your app stays in memory and if the user switches back to your app (through Windows-key+Tab or a swiping gesture from the left side of the screen on a touch device), then the app immediately begins running again. Threads are reallocated, and the program picks right back up executing whatever it was doing before.

However, if your app is suspended and the system is running low on memory, WinRT can choose to terminate your application from its suspended state at any time. When that happens, your app is cleared from memory, and all the objects that were built up and connected together while your app was running are gone as well. If the user launches your application again after termination, it is part of the platform guidance that the should have the state of the app restored just as if they were resuming directly from the suspended state. Only if the user explicitly shuts the application down (Alt-F4 or a swiping gesture from top to bottom of the screen on a touch device) are you allowed to reset the application start as if it was a clean start of the application.

This lifecycle is depicted in Figure 1. The key thing to understand is that resuming from suspend or launching after termination should result in the same exact user experience – the last screen the user was on should be there, any transient state in the screen should be restored (i.e.. selections, scroll position, etc), and the navigation stack should be back to what it was when they left.

Figure 1: Windows Store Application States

To create that user experience, it means you need to be able to save and restore state that is maintained by your view models and client side services in a Prism app. Prism makes this very easy for you through several mechanisms available to you in your view models and services.

Step 1: Add a user experience working with data

I need to have a requirement to work with data in the app before I can start designing for it. For this article, I decide that I want a simple data interaction scenario for taking a phone order from a customer. The user can select from the products that their company sells, enter a quantity, and add that to the current order. They also need to be able to see what is currently part of the current order.

I sketch this out and decide it looks something like this:

Figure 2: The AddSalePage UI

The XAML for this looks like this:

   1: <ComboBox ItemsSource="{Binding Products}"

   2:           SelectedValue="{Binding SelectedProductId, Mode=TwoWay}"

   3:           DisplayMemberPath="ProductName"

   4:           SelectedValuePath="ProductId"

   5:           HorizontalAlignment="Left"

   6:           Margin="120,60,0,0"

   7:           Grid.Row="1"

   8:           VerticalAlignment="Top"

   9:           Width="434" />

  10: <TextBox Text="{Binding Quantity, Mode=TwoWay}"

  11:          HorizontalAlignment="Left"

  12:          Margin="580,60,0,0"

  13:          Grid.Row="1"

  14:          TextWrapping="Wrap"

  15:          VerticalAlignment="Top"

  16:          Width="99" />

  17: <Button Content="Add to Order"

  18:         Command="{Binding AddToOrderCommand}"

  19:         HorizontalAlignment="Left"

  20:         Margin="750,60,0,0"

  21:         Grid.Row="1"

  22:         VerticalAlignment="Top" />

  23: <TextBlock Style="{StaticResource SubheaderTextStyle}"

  24:            HorizontalAlignment="Left"

  25:            Margin="120,15,0,0"

  26:            Grid.Row="1"

  27:            TextWrapping="Wrap"

  28:            Text="Product"

  29:            VerticalAlignment="Top"

  30:            Height="25"

  31:            Width="215" />

  32: <TextBlock Style="{StaticResource SubheaderTextStyle}"

  33:            HorizontalAlignment="Left"

  34:            Margin="580,15,0,0"

  35:            Grid.Row="1"

  36:            TextWrapping="Wrap"

  37:            Text="Quantity"

  38:            VerticalAlignment="Top"

  39:            Height="25"

  40:            Width="105" />

41:

  42: <Grid HorizontalAlignment="Left"

  43:       Height="416"

  44:       Margin="120,165,0,0"

  45:       Grid.Row="1"

  46:       VerticalAlignment="Top"

  47:       Width="868">

  48:     <Grid.RowDefinitions>

  49:         <RowDefinition Height="50" />

  50:         <RowDefinition Height="*" />

  51:     Grid.RowDefinitions>

  52:     <Grid Grid.Row="0"

  53:           Margin="5">

  54:         <Grid.ColumnDefinitions>

  55:             <ColumnDefinition Width="300" />

  56:             <ColumnDefinition Width="150" />

  57:             <ColumnDefinition Width="150" />

  58:             <ColumnDefinition Width="300" />

  59:         Grid.ColumnDefinitions>

  60:         <TextBlock Grid.Column="0"

  61:                    Text="Product"

  62:                    Style="{StaticResource SubheaderTextStyle}" />

  63:         <TextBlock Grid.Column="1"

  64:                    Text="Price"

  65:                    Style="{StaticResource SubheaderTextStyle}" />

  66:         <TextBlock Grid.Column="2"

  67:                    Text="Quantity"

  68:                    Style="{StaticResource SubheaderTextStyle}" />

  69:         <TextBlock Grid.Column="3"

  70:                    Text="Category"

  71:                    Style="{StaticResource SubheaderTextStyle}" />

  72:     Grid>

  73:     <ListView x:Name="OrderItemsList"

  74:               Grid.Row="1"

  75:               ItemsSource="{Binding CurrentOrderItems}">

  76:         <ListView.ItemTemplate>

  77:             <DataTemplate>

  78:                 <Grid>

  79:                     <Grid.ColumnDefinitions>

  80:                         <ColumnDefinition Width="300" />

  81:                         <ColumnDefinition Width="150" />

  82:                         <ColumnDefinition Width="150" />

  83:                         <ColumnDefinition Width="300" />

  84:                     Grid.ColumnDefinitions>

  85:                     <TextBlock Grid.Column="0"

  86:                                Text="{Binding Product.ProductName}" />

  87:                     <TextBlock Grid.Column="1"

  88:                                Text="{Binding Product.UnitPrice}" />

  89:                     <TextBlock Grid.Column="2"

  90:                                Text="{Binding Quantity}" />

  91:                     <TextBlock Grid.Column="3"

  92:                                Text="{Binding Product.Category}" />

  93:                 Grid>

  94:             DataTemplate>

  95:         ListView.ItemTemplate>

96:

  97:     ListView>

  98: Grid>

Step 2: Add some data to the app

The demo code at the completion of the last article didn’t have much going on in terms of application state, we just had two pages that we were navigating between with commands. The first thing I need to start fleshing out some state management is some data that the application is managing. I added two repositories to the client application, one for showing a collection of products, and one for managing the state of the current order.

The ProductsRepository exposes a collection of products:

   1: public class ProductsRepository : IProductsRepository

   2: {

   3:     public IEnumerable AllProducts()

   4:     {

   5:         return new List

   6:         {

   7:             new Product { ProductId = 1, ProductName = "Surface Pro",

   8:                 Category="Tablets", UnitPrice = 999.00m, UnitsInStock=42},

   9:             new Product { ProductId = 2, ProductName = "Surface RT",

  10:                 Category="Tablets", UnitPrice = 629.00m, UnitsInStock=33},

  11:             new Product { ProductId = 3, ProductName = "Lumia 920",

  12:                 Category="Phones", UnitPrice = 400.00m, UnitsInStock=12},

  13:             new Product { ProductId = 4, ProductName = "iPhone 5",

  14:                 Category="Phones", UnitPrice = 629.00m, UnitsInStock=54},

  15:             new Product { ProductId = 5, ProductName = "Razr",

  16:                 Category="Phones", UnitPrice = 59.99m, UnitsInStock=987},

  17:         };

  18:     }

  19: }

The OrderRepository manages the state of the current order:

   1: public class OrderRepository : IOrderRepository

   2: {

   3:     readonly ObservableCollection _OrderItems =

   4:         new ObservableCollection();

5:

   6:     public void AddToOrder(Product product, int quantity)

   7:     {

   8:         var orderitem = (from oi in _OrderItems where oi.Product.ProductId

   9:                             == product.ProductId select oi).FirstOrDefault();

  10:         if (orderitem == null)

  11:             _OrderItems.Add(new OrderItem { Product = product, Quantity = quantity });

  12:         else orderitem.Quantity += quantity;

  13:     }

14:

  15:     public ObservableCollection CurrentOrderItems

  16:     {

  17:         get { return _OrderItems; }

  18:     }

  19: }

Step 3: Expose properties from the view model to support the view

If you wade through the XAML in Step 1, you will see that the view has bindings that expect certain things exposed from the ViewModel for data binding. It needs a collection of Products, a SelectedProductId, a Quantity, an AddToOrderCommand, and CurrentOrderItems collection.

Some of these will be fed from the repository, so the resulting view model looks like this so far.

   1: public class AddSalePageViewModel : ViewModel

   2: {

   3:     private readonly INavigationService _NavService;

   4:     private readonly IProductsRepository _ProductsRespository;

   5:     private readonly IOrderRepository _OrderRepository;

   6:     private int _SelectedProductId;

   7:     private int _Quantity = 1;

8:

   9:     public AddSalePageViewModel(INavigationService navService,

  10:         IProductsRepository productsRespository,

  11:         IOrderRepository orderRepository)

  12:     {

  13:         _OrderRepository = orderRepository;

  14:         _ProductsRespository = productsRespository;

  15:         _NavService = navService;

  16:         GoBackCommand = new DelegateCommand(

  17:             () => _NavService.GoBack(),

  18:             () => _NavService.CanGoBack());

  19:         AddToOrderCommand = new DelegateCommand(OnAddToOrder, CanAddToOrder);

  20:     }

21:

  22:     public DelegateCommand GoBackCommand { get; private set; }

  23:     public DelegateCommand AddToOrderCommand { get; private set; }

24:

  25:     public IEnumerable Products

  26:     {

  27:         get { return _ProductsRespository.AllProducts(); }

  28:     }

29:

  30:     public ObservableCollection CurrentOrderItems

  31:     {

  32:         get { return _OrderRepository.CurrentOrderItems; }

  33:     }

34:

  35:     public int SelectedProductId

  36:     {

  37:         get { return _SelectedProductId; }

  38:         set

  39:         {

  40:             SetProperty(ref _SelectedProductId, value);

  41:             AddToOrderCommand.RaiseCanExecuteChanged();

  42:         }

  43:     }

44:

  45:     public int Quantity

  46:     {

  47:         get { return _Quantity; }

  48:         set { SetProperty(ref _Quantity, value); }

  49:     }

50:

  51:     private bool CanAddToOrder()

  52:     {

  53:         var prod = (from p in _ProductsRespository.AllProducts() where

  54:             p.ProductId == _SelectedProductId select p).FirstOrDefault();

  55:         return prod != null;

  56:     }

57:

  58:     private void OnAddToOrder()

  59:     {

  60:         var prod = (from p in _ProductsRespository.AllProducts() where

  61:             p.ProductId == _SelectedProductId select p).FirstOrDefault();

  62:         _OrderRepository.AddToOrder(prod, Quantity);

  63:     }

  64: }

At this point you should be able to run and get the user experience expected.

Step 4: Admit you have a problem

No, I’m not suggesting you find yourself a chapter of Coder’s Anonymous and start going to meetings because you are addicted to code (although that may be appropriate too!). The problem is that our app does not behave correctly in the face of application suspend – terminate – resume. You could see this by adding the code in steps 1-3 to the ending point from the second article in this series and running.

You would navigate to the AddSalePage and select a product and enter a quantity – two pieces of transient state in the view. Then you can force a terminate while debugging a Windows Store app by using the “Debug Location” toolbar in Visual Studio. To do so, switch back to Visual Studio from your running Windows Store app, and select “Suspend and Shutdown”.

This causes the app to suspend and then be terminated in the same way as if the OS were running low on memory while your app was suspended and it decided to terminate your app.

Now run the program again (F5 or click the Start Debugging button in the toolbar). It will start on the correct page (AddtoSalePage), but the selection and the quantity you entered will be gone. This would be a violation of the guideline that says it should be transparent to the user when they launch the app after termination compared to resuming after suspend without termination.

Step 5: Add RestorableState to properties

So what can we do to fix it? Well, Prism makes it really easy to deal with this. The things that cause the selection and that hold the quantity are properties on your ViewModel. You ViewModel inherits (or should) from the Prism ViewModel base class, which has built in wiring to make this simple. All you need to do is decorate your SelectedProductId and Quantity properties with the [RestorableState] attribute.

   1: [RestorableState]

   2: public int SelectedProductId

   3: {

   4:     get { return _SelectedProductId; }

   5:     set

   6:     {

   7:         SetProperty(ref _SelectedProductId, value);

   8:         AddToOrderCommand.RaiseCanExecuteChanged();

   9:     }

  10: }

11:

  12: [RestorableState]

  13: public int Quantity

  14: {

  15:     get { return _Quantity; }

  16:     set { SetProperty(ref _Quantity, value); }

  17: }

Now you could run that same scenario again – Suspend and Shutdown from the Debug Location toolbar, start the app again.

Now when you restart, your selection is retained, as is the quantity that you entered. Nice!

What if the property you want to put [RestorableState] on is a model object or complex type? No problem, you just need to do one more thing to make that work. The way this works under the covers is that the Prism FrameNavigationService is aware when the app is suspending. Likewise, when you navigate away from a view, especially one that you could navigate back to through the back button, you probably want to store and restore state on those transitions as well, and the FrameNavigationService is in charge of that whole process.

So whenever Prism sees that the app is suspending or that your ViewModel is being navigated away from, it will find all of the [RestorableState] properties in your ViewModel through reflection, and it will persist the state of them in Local Storage. It uses the WCF DataContractSerializer to do this, just like the SuspensionManager class that gets injected into your Common folder by Visual Studio does. That means the DataContractSerializer needs to know about all the types it will be serializing. For primitives, this is automatic. But for complex types, you need to tell it about your types.

To do so, you override a method in the MvvmAppBase class and pass the type information for the model objects you will be using as restorable state like so:

   1: protected override void OnRegisterKnownTypesForSerialization()

   2: {

   3:     base.OnRegisterKnownTypesForSerialization();

   4:     SessionStateService.RegisterKnownType(typeof(Product));

   5:     SessionStateService.RegisterKnownType(typeof(OrderItem));

   6:     SessionStateService.RegisterKnownType(typeof(OrderItem[]));

   7: }

Now just so you don’t get yourself confused like I have often done to myself, you might be tempted to change the AddSalePageViewModel to use a SelectedProduct property instead of a SelectedProducyId property and bind the SelectedItem property of the ListView to it instead of the SelectedValue property. Just realize that if you do, you won’t get what you expect when the app starts back up. This is because the SelectedItem property has to point to an instance of an object that is in the bound collection that ItemsSource points to. For this demo, that is the Products collection. But when the [RestorableState] attribute kicks in, it is really going to be populating your SelectedProduct property (assuming it had that attribute) with a new instance of an object based on the data serialized from a previous session. This object is not going to be part of the new collection of Products that are getting returned separately from the ProductsRepository, so the selection will not show up. Just be warned. This is why I went with SelectedValue, which is more resilient to that subtle fact because it is matching by value instead of by object reference.

Now if you poke and prod the app and play with Suspend and Shutdown some more, you will realize your still have a problem. Add a couple items to the order and then suspend and terminate. Start the app again and the items are gone. Darn it, we still have more work to do.

Step 6: Use ISessionStateService in your client services

ViewModels are not the only objects in an MVVM app that need to retain state across termination. Your views might too (i.e. a scrollbar position – see the HubPage in the AdventureWorks Shopper sample in Prism for an example of this. They have built in support for this through the Prism VisualStateAwarePage and its Page base class.

But what about repositories and other client side services that sit logically behind the ViewModel. They often retain transient state as well.

The way you handle this in Prism is to have those objects take a dependency on the Prism ISessionStateService that is managing all the automatic state load/save as the app starts up and shuts down. If you read and write your data into that state service (which exposes a Dictionary API), then it will survive terminations correctly as well.

So I just need to modify the OrderRepository that is caching the order data to do this. First I add a dependency on the ISessionStateService:

   1: private readonly ISessionStateService _StateService;

   2: private const string CurrentOrderKey = "CurrentOrderKey";

   3: public OrderRepository(ISessionStateService stateService)

   4: {

   5:     _StateService = stateService;

   6: }

Notice that I need a unique string key that I will end up associating the state of this service with.

Then whenever my state changes, I also write it into the state service:

   1: public void AddToOrder(Product product, int quantity)

   2: {

   3:     var orderitem = (from oi in _OrderItems where oi.Product.ProductId

   4:         == product.ProductId select oi).FirstOrDefault();

   5:     if (orderitem == null)

   6:         _OrderItems.Add(new OrderItem { Product = product, Quantity = quantity });

   7:     else orderitem.Quantity += quantity;

   8:     // Write the collection out to the state service

   9:     _StateService.SessionState[CurrentOrderKey] = _OrderItems.ToArray();

  10: }

Notice the last line of code there, simply using the exposed SessionState Dictionary to write the current state of the service into it.

Finally, I need to make sure that the state of the service is initialized based on the state service if there is any state there from a previous session. So I modify the constructor of the service, which will only be called once the first time some other code (i.e. the ViewModel) takes a dependency on it because it is set up as a singleton through the container. When the app starts up after termination, it does still have to reconstruct everything because everything about the app is cleared from memory on termination. So the repository constructor now looks like this:

   1: public OrderRepository(ISessionStateService stateService)

   2: {

   3:     _StateService = stateService;

   4:     if (_StateService.SessionState.ContainsKey(CurrentOrderKey))

   5:     {

   6:         IEnumerable sessionItems =

   7:             _StateService.SessionState[CurrentOrderKey] as IEnumerable;

   8:         if (sessionItems != null)

   9:         {

  10:             foreach (OrderItem item in sessionItems)

  11:             {

  12:                 _OrderItems.Add(item);

  13:             }

  14:         }

  15:     }

16:

  17: }

And because this is the first time a ViewModel has taken a dependency on the ISessionStateService, we need to make sure the Container knows how to resolve it. So we add one more registration to our OnInitialize method in the App.xaml.cs file to expose the singleton SessionStateService created by the MvvmAppBase class to anyone who wants to dependency inject ISessionStateService. If you were not using a container, you could pass that SessionStateService reference to the constructor of the OrderRepository through manual dependency injection if you were constructing it in the app class as a singleton.

   1: protected override void OnInitialize(IActivatedEventArgs args)

   2: {

   3:     base.OnInitialize(args);

   4:     _Container.RegisterInstance(SessionStateService);

   5:     ...

   6: }

7:

Now you should be able to run, add items to the order, suspend and terminate, re-launch the app, and all your transient state is right where it was when the user left the app.

Summary

In this article I have demonstrated how to use the RestorableState attribute in your ViewModels in Prism for Windows Runtime as well as how to use the ISessionStateService. There is one thing I didn’t show – in the last article I showed the OnNavigatedTo and OnNavigatedFrom overrides in the ViewModel base class. Those both get passed a dictionary as one of their arguments. This is basically the dictionary that the view can write state into as well. You could explicitly read and write values into those dictionary when you are navigated to or from, and it would survive termination as well. The RestorableState attribute just makes it a lot more declarative and easy for your ViewModels since the state you care about will typically be in properties anyway.

So remember to use RestorableState on properties that affect what the user sees on the screen if it is transient data. If you are already proactively loading and saving state as you are navigated to and from through a service, or to disk with Local Storage or into roaming settings, you just need to make sure you are symmetrical about that as your ViewModels are navigated to and from. But for those things that are logically just “held in memory”, realize they won’t be if you are terminated, but your app is still supposed to pretend they were. [RestorableState] and ISessionStateService make it easy to do that.

In the next article I'll take a look at starting to validate data when the user enters it.

About the Author

Brian Noyes is CTO of Solliance (www.solliance.net), a software development company offering Architecture as a Service, end-to-end product development, technology consulting and training. Brian is a Microsoft Regional Director and MVP, Pluralsight author, and speaker at conferences worldwide. Brian worked directly on the Prism team with Microsoft patterns and practices. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on Twitter @briannoyes.

WinRT Business Apps with Prism: Commands, Dependencies, and Navigation

editorial@silverlightshow.net (Brian Noyes ) — Mon, 11 Mar 2013 14:11:00 GMT

Download the source code for this article

UPDATE: This article was updated because the name of the guidance changed from it’s code name “Kona” to “Prism for Windows Runtime” for release. The content has not really changed since the original article, just updates for changes in the name of the guidance and for the change in code namespaces.

This is part 2 in the series WinRT Business Apps with Prism.

Introduction

Don't miss

All SilverlightShow Ebooks

In Part 1 of this series I covered the background of what Prism for Windows Runtime is and got you started building an app reusing the Microsoft.Practices.Prism.StoreApps project that contains the reusable code library of Prism. The sample application I put together in Part 1 was not very impressive, after seven steps, you had nothing more than a “Hello World” kind of application. But what may not have been apparent is that those steps let you lay down the foundation on which you could build a big, complex Windows Store business application with Prism, using the MVVM pattern, integrating with the navigation system, handling state management in the face of suspend/terminate easily and more.

In this article I will continue to build out the application a little farther, showing you how you can manage view model dependencies, how to handle commands from the UI in your view models, and how to let the view model participate in navigation as well as having it command navigation.

The starting point for the code in this article is the completed code from Part 1, which you can download here.

Step 1: Add a navigation control to the MainPage

I could just be totally crude and throw a button on the main page, but in a Windows Store application, top level navigation is usually presented by showing items in a GridView and allowing the user to click on those items to make things happen. So I will add a GridView to the main content area of the MainPage and add a single item to it for now, which will be the moral equivalent of a big fat navigation button for the user.

So I added the following to the outer Grid control that lays out the page with two rows – one for the header and one for the main content:

   1: <GridView Margin="120,10,0,0"

   2:             Grid.Row="1"

   3:             SelectionMode="None"

   4:             ItemsSource="{Binding NavCommands}">

   5:     <GridView.ItemTemplate>

   6:         <DataTemplate>

   7:             <Grid Height="500"

   8:                     Width="250"

   9:                     Background="#33CC33">

  10:                 <StackPanel VerticalAlignment="Center">

  11:                     <TextBlock Text="{Binding}"

  12:                                 Style="{StaticResource SubheaderTextStyle}"

  13:                                 HorizontalAlignment="Center" />

  14:                 StackPanel>

  15:             Grid>

  16:         DataTemplate>

  17:     GridView.ItemTemplate>

  18: GridView>

Notice that I am expecting to expose a collection of strings I will name NavCommands from my view model. The ItemTemplate is set up to display those as big tall rectangles, with the display text in the rectangle as one string in the collection of NavCommands names.

Step 2: Add an Attached Behavior to hook up a command on ItemClick

Now the only trick is that I need a way to cause interaction with the GridView items – specifically clicking on an item – to dispatch a call into my view model. The GridView does not raise commands, which are a common way to communicate between a view and a view model. However, it does have an ItemClick event which you can enable with a flag called IsItemClickEnabled. A common approach in MVVM to pass an event from the UI to the view model is to use a behavior. to fire a command when the event fires. I wrote an article on my blog that explains what an Attached Behavior is and compares it to a simple attached property and to Blend Behaviors. Attached Behaviors are the only kind of behavior supported out of the box.

The code below shows an Attached Behavior class that can be used with the GridView (or a ListView since they share a common base class ListViewBase where the ItemClick event is defined).

   1: public static class ItemClickToCommandBehavior

   2: {

   3:     #region Command Attached Property

   4:     public static ICommand GetCommand(DependencyObject obj)

   5:     {

   6:         return (ICommand)obj.GetValue(CommandProperty);

   7:     }

8:

   9:     public static void SetCommand(DependencyObject obj, ICommand value)

  10:     {

  11:         obj.SetValue(CommandProperty, value);

  12:     }

13:

  14:     public static readonly DependencyProperty CommandProperty =

  15:         DependencyProperty.RegisterAttached("Command", typeof(ICommand),

  16:             typeof(ItemClickToCommandBehavior),

  17:             new PropertyMetadata(null, OnCommandChanged));

  18:     #endregion

19:

  20:     #region Behavior implementation

  21:     private static void OnCommandChanged(DependencyObject d,

  22:         DependencyPropertyChangedEventArgs e)

  23:     {

  24:         ListViewBase lvb = d as ListViewBase;

  25:         if (lvb == null) return;

26:

  27:         lvb.ItemClick += OnClick;

  28:     }

29:

  30:     private static void OnClick(object sender, ItemClickEventArgs e)

  31:     {

  32:         ListViewBase lvb = sender as ListViewBase;

  33:         ICommand cmd = lvb.GetValue(ItemClickToCommandBehavior.CommandProperty) as ICommand;

  34:         if (cmd != null && cmd.CanExecute(e.ClickedItem))

  35:             cmd.Execute(e.ClickedItem);

  36:     }

  37:     #endregion

You can see that what the behavior does is to hook up to the ItemClick event when the Command attached property gets set. It expects that the property will be set through a binding to point to an ICommand object in the view model. When the ItemClick event fires, it gets a reference to the bound command off the GridView element and fires the command, passing the clicked item as a command parameter. This allows the view model to do all the handling of that interaction.

To use this behavior, I add a setter for the Command attached property to the GridView like so, and enable IsItemClickEnabled:

   1: <GridView Margin="120,10,0,0"

   2:           Grid.Row="1"

   3:           SelectionMode="None"

   4:           ItemsSource="{Binding NavCommands}"

   5:           beh:ItemClickToCommandBehavior.Command="{Binding NavCommand}"

   6:           IsItemClickEnabled="True">

Step 3: Flesh out the MainPageViewModel nav commands

First I need to expose a property named NavCommands from the MainPageViewModel that is a collection of strings, one for each big fat navigation item we want to present in the GridView. For now that will just be one called “Add Sale”. In addition (based on the binding shown on the Command attached property) I need to expose a command property called NavCommand. The view model now looks like this:

   1: public class MainPageViewModel : ViewModel

   2: {

   3:     public MainPageViewModel()

   4:     {

   5:         NavCommands = new ObservableCollection<string>

   6:         {

   7:             "Add Sale"

   8:         };

   9:         NavCommand = new DelegateCommand<string>(OnNavCommand);

  10:     }

11:

  12:     public ObservableCollection<string> NavCommands { get; set; }

  13:     public DelegateCommand<string> NavCommand { get; set; }

14:

  15:     private void OnNavCommand(string navCommand)

  16:     {

17:

  18:     }

  19: }

At this point you should be able to set a breakpoint in the OnNavCommand method, run, click the Add Sale item in the grid and see that the command handler gets invoked.

Step 4a: Change to a Factory Method for ViewModel construction

In order to cause navigation to happen in the view model, it is going to need access to a NavigationService that gets set up in the MvvmAppBase class. That means we need to be able to inject that into the view model as a dependency. There are two ways to do that in Prism for Windows Runtime. The first is that you can set up a factory method for the view model type in the ViewModelLocator and write your own construction code for the view model, passing in whatever dependencies it needs. This is called manual dependency injection. The other is to use a dependency injection container, which I will also show in a later step.

So first I declare the dependency that the view model is going to take on:

   1: public class MainPageViewModel : ViewModel

   2: {

   3:     private readonly INavigationService _NavService;

   4:     public MainPageViewModel(INavigationService navService)

   5:     {

   6:         _NavService = navService;

   7:         ...

   8:     }

   9:     ...

  10: }

Then I go to the App.xaml.cs code behind file and add an override for the OnInitialize method from the base class. In that method, I call the Register method on the ViewModelLocator to set up a factory method (in the form of a Func lambda expression) for the MainPageViewModel type:

   1: protected override void OnInitialize(IActivatedEventArgs args)

   2: {

   3:     base.OnInitialize(args);

   4:     ViewModelLocator.Register(typeof(MainPage).ToString(),

   5:         () => new MainPageViewModel(NavigationService));

   6: }

Now whenever the ViewModel locator View-to-ViewModel type mapping happens, it will then look to see if there is a registered factory method for the ViewModel type, and if so will use it to construct the view model instead of using the default logic that just constructs the ViewModel with a default constructor. You can see in the snippet above that this allows me to pass in the NavigationService from the MvvmAppBase class as the implementation of INavigationService that the view model is depending on.

Step 4b: Set up a Dependency Injection Container for the App

As an alternative to the approach shown in step 4a, if you are already comfortable with the concepts and usage of a dependency injection (or Inversion of Control – IOC) container, then you can use that instead of the manual dependency injection approach of using the factory methods. If you use a container like Unity that supports constructor injection, then you would define the view model dependency exactly the same as shown in the first code snippet of Step 4a.

Next I pull in Unity as my container of choice for known dependencies in WinRT apps. At the time of this writing, Unity for WinRT has not yet been released, but it is available in pre-release form as a NuGet package. So I right click on my project in Solution Explorer, select Manage NuGet Packages, make sure “Include Prerelease” is selected at the top of the NuGet dialog, and do a search for Unity.

After installing that NuGet package, The modifications to App.xaml.cs look like this:

   1: sealed partial class App : MvvmAppBase

   2: {

   3:     IUnityContainer _Container = new UnityContainer();

   4:     public App()

   5:     {

   6:         this.InitializeComponent();

   7:     }

8:

   9:     protected override void OnLaunchApplication(LaunchActivatedEventArgs args)

  10:     {

  11:         NavigationService.Navigate("Main", null);

  12:     }

13:

  14:     protected override void OnInitialize(IActivatedEventArgs args)

  15:     {

  16:         base.OnInitialize(args);

  17:         _Container.RegisterInstance(NavigationService);

  18:         ViewModelLocator.SetDefaultViewModelFactory(

  19:             (viewModelType) => _Container.Resolve(viewModelType));

  20:     }

  21: }

Notice on line 3 I construct the container and keep it around as a singleton for the life of the application just by declaring it as a member variable on the App class. On lines 14-20 I override the OnInitialize method from the base class, set up a registration in the container for the INavigationService interface, and then change the default factory for the ViewModelLocator to construct all view models through the container. By doing so, the container will automatically try to resolve and pass in any dependencies indicated in the view model constructor.

Step 5: Navigate – To AddSalePage and Beyond!

Now that the view model has access to the navigation service, it can cause navigation to happen when it sees fit. Add the following code to the MainPageViewModel.OnNavCommand method:

   1: private void OnNavCommand(string navCommand)

   2: {

   3:     _NavService.Navigate("AddSale", null);

   4: }

As mentioned in Part 1 of this series, navigation is done based on string tokens for the pages, where the “Page” part of the page name is left off by convention. That convention is overridable in the MvvmAppBase.GetPageNameToTypeResolver method. If you have followed along to this point, you should be able to fire up the app at this point, click on the Add Sale tile in the MainPage and land on the AddSalePage (which is empty at this point).

Once you have landed on the AddSalePage, it has a Back button in the upper left corner, but it is not hooked up to anything yet. To let the view model be in charge of all navigation logic, the AddSalePageViewModel needs access to the NavigationService as well. If you added a container in Step 4b, then you don’t have to do anything other than declare the dependency on INavigationService as a constructor argument. If you stuck with the container-less approach in Step 4a, then you will need to register another factory method for AddSalePageViewModel to the OnInitialize method:

   1: ViewModelLocator.Register(typeof(AddSalePageViewModel).ToString(),

   2:     ()=> new AddSalePageViewModel(NavigationService));

To set up the view model to take in the INavigationService and handle GoBack commands, it would look like this:

   1: public class AddSalePageViewModel : ViewModel

   2: {

   3:     private readonly INavigationService _NavService;

   4:     public AddSalePageViewModel(INavigationService navService)

   5:     {

   6:         _NavService = navService;

   7:         GoBackCommand = new DelegateCommand(

   8:             () => _NavService.GoBack(),

   9:             () => _NavService.CanGoBack());

  10:     }

11:

  12:     public DelegateCommand GoBackCommand { get; set; }

  13: }

Now a simple modification to the backButton in AddSalePage gets it all lit up and ready to use:

   1: <Button x:Name="backButton"

   2:         Command="{Binding GoBackCommand}"

   3:         Style="{StaticResource BackButtonStyle}" />

Step 6: Add navigation from an AppBar

In addition to the GridView navigation on the home page, you might also want to let people navigate to specific pages regardless of where they are in the application. To do that you would include a top AppBar on each page with navigation buttons for the places in your application you want to allow them to navigate to from there. For example, I could add the following to my MainPage:

   1: <Page.Resources>

   2:     <Style x:Key="AddSaleAppBarButtonStyle"

   3:            TargetType="ButtonBase"

   4:            BasedOn="{StaticResource AppBarButtonStyle}">

   5:         <Setter Property="AutomationProperties.AutomationId"

   6:                 Value="AddAppBarButton" />

   7:         <Setter Property="AutomationProperties.Name"

   8:                 Value="Add Sale" />

   9:         <Setter Property="Content"

  10:                 Value="" />

  11:     Style>

  12: Page.Resources>

  13: <Page.TopAppBar>

  14:     <AppBar>

  15:         <StackPanel Orientation="Horizontal">

  16:             <Button Command="{Binding AddSaleCommand}"

  17:                     Style="{StaticResource AddSaleAppBarButtonStyle}" />

  18:         StackPanel>

  19:     AppBar>

  20: Page.TopAppBar>

Then I would just add an AddSaleCommand to the view model:

   1: public DelegateCommand AddSaleCommand { get; set; }

And wire up its handler to use the navigation service to cause the navigation.

   1: AddSaleCommand = new DelegateCommand(() => _NavService.Navigate("AddSale", null));

Obviously in a complex app with many pages, this would be a bad idea to repeat across many pages if you wanted to be able to navigate to the AddSalePage from anywhere in the application. To avoid that, what I would do is wrap it up in a user control that I could add to any page’s app bar declaratively in the XAML.

Step 7: Let the ViewModel know when it is navigated to

Sometimes you might need to pass arguments between view models when navigation happens. For example if you were presenting a list of items to select in one view, and the next view you navigated to was going to present that item for editing or other interaction. You can see in the navigation service Navigate method in the first snippet of Step 5 that there is a second parameter that lets you pass some context. In that step I passed null, but that won’t always be sufficient. The way you can receive that parameter in the view model that is being navigated to is to override a method from the ViewModel base class called OnNavigatedTo. Additionally if you need to do some clean up when the user navigates away from a view, there is a corresponding OnNavigatedFrom method as well.

If I add an override for OnNavigatedTo to the AddSalePageViewModel, the signature looks like this:

   1: public override void OnNavigatedTo(object navigationParameter,

   2:     NavigationMode navigationMode, Dictionary<string, object> viewState)

   3: {

   4:     base.OnNavigatedTo(navigationParameter, navigationMode, viewState);

   5: }

The parameters to the method include the navigation parameter that can be passed from the view model that caused the navigation, a NavigationMode parameter, and a viewState parameter. The NavigationMode parameter is part of WinRT and tells you whether you arrived at your destination through a “New”, “Forward”, “Back”, or “Refresh” navigation. A call to INavigationService.Navigate results in a “New” navigation – meaning it will be another step in the navigation stack that is maintained by WinRT. INavigationService.GoBack will result in the “Back” value. The other two are exposed by the Frame class in WinRT when you use the GoForward or Refresh navigation methods. We chose not to implement those in the FrameNavigationService class in Prism since they are fairly uncommon to expose in a Windows Store app as explicit navigation controls, but you could easily extend the FrameNavgationService to add those if it made sense for your app, and their implementation would just be to wrap the Frame.GoForward or Frame.Refresh methods.

The viewState argument is a dictionary that you can read and write values into that will participate in suspend/terminate state persistence – which will be the subject of my next article in the series, so just ignore that parameter for now.

Summary

In this article, I showed you how you can use the Prism DelegateCommand class to handle communications from the view down into the view model, with the assistance of a behavior to map GridView.ItemClick events into command invocations. You also saw how to wire up dependencies in your view models either through manual dependency injection with a factory method supplied to the ViewModelLocator (Step 4a) or by using an IOC/DI container (Step 4b). You saw how to use the INavigationService to control navigation from the view models, as well as how to let the view models know when they are being navigated to or from.

In the next article, I will show how we can manage application state in the face of suspend/terminate/resume – which is an inherent part of WinRT application lifecycle.

About the Author

Brian Noyes is CTO of Solliance (www.solliance.net), a software development company offering Architecture as a Service, end-to-end product development, technology consulting and training. Brian is a Microsoft Regional Director and MVP, Pluralsight author, and speaker at conferences worldwide. Brian worked directly on the Prism team with Microsoft patterns and practices. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on Twitter @briannoyes.

WinRT Business Apps with Prism: Getting Started

editorial@silverlightshow.net (Brian Noyes ) — Wed, 20 Feb 2013 13:42:00 GMT

Download the source code for this article

UPDATE: This article was updated from the original version because the name of the guidance changed from “Kona” to “Prism for Windows Runtime” after initial publication. The content has not changed in the update other than the name of the guidance and the namespaces in the code.

This is Part 1 in the series WinRT Business Apps with Prism.

Introduction

Even if you are an experienced XAML developer, to be successful building business applications for the Windows Runtime (WinRT), you can't just start slinging code in the code behind of pages and let your application evolve into a pile of new spaghetti code. You need to focus on maintainability and testability of your application. You need loose coupling and separation of concerns. But if you get started by looking at the samples and documentation that comes with the platform, you will have a hard time figuring it how to get started with that.

Don't miss

All SilverlightShow Ebooks

Luckily someone has already blazed a trail for you - Microsoft patterns & practices (p&p). For the last 6 months or so I have had the privilege of working as a member of the p&p team whose charter is to provide guidance for line of business XAML developers starting to build Windows Store applications. This project was originally code named "Kona", but was renamed for release to Prism for Windows Runtime. I will be referring to the code and samples and documentation that comes with the guidance collectively as "Prism" for short, but just realize I am referring to this new variant of Prism targeting WinRT apps, not Prism 4 which targets WPF and Silverlight apps. For Prism 4 you can check out my other article series Working with Prism 4.

In this article series I will be showing you everything that Prism has to offer to help you build your WinRT application right, to leverage the reusable code of Prism, to follow the coding patterns of Prism where no reusable code exists, and to leverage the features of the platform that most business applications will need to integrate with. A lot of these same things can apply whether you are building a game, productivity app, or line of business applications that only employees of your company will use. But the main focus of the guidance is for line of business applications including internal business applications (which will probably be side loaded and never go in the Windows Store, but are still referred to by Microsoft as “Windows Store apps”) as well as business-to-consumer applications where the end users of your application are mostly outside your control as the development organization.

You will learn about structuring your application with MVVM, navigation, application state management, loosely coupled communications, validation, calling Web APIs, and leveraging platform features including Settings panels, Search charm integration, Live Tile updates, Toast Notifications, Roaming Settings, and more. I will do this mostly by building out a Windows Store application in the series, but for the things that are a little too involved to build up in a single sample, I will end up pointing to some example code in Prism.

This is not a introductory tutorial in building Windows Store applications. I am assuming you have already had some exposure to the WinRT platform, Windows Store applications, and have some experience building XAML applications. I also expect you have some exposure to the MVVM pattern, its goals and structure. If you want a good comprehensive overview of all of these, check out my Pluralsight course “Building Windows 8 MVVM XAML Apps”. I also will have a Pluralsight course titled Building Windows Store Business Apps with Prism out by June 2013.

Prism Guidance Overview

A big part of the Prism guidance is a realistic sample application, the AdventureWorks Shopper application. This is referred to as a "Reference Implementation" (RI) by p&p. It is more than your average sample application, it is a complete end to end application that represents the kind of applications many businesses will need to build for WinRT, whether they deploy through the Windows Store to consumers or whether they deploy through side loading in the Enterprise. In building the AdventureWorks Shopper RI, the p&p team constantly looked for opportunities to write code in a reusable way so that developers could not only learn from the code of the application , they could also use some of the common code we were writing. The result of that is a library called Microsoft.Practices.Prism.StoreApps that is part of the Prism download that you can reuse in your own applications. There is also a separate reusable library called Microsoft.Practices.Prism.PubSubEvents that I will cover in a later article in the series. The RI also includes extensive unit and integration tests that you can use to learn how to write tests for your own application. Additionally, Prism comes with several Quickstart applications that demonstrate distinct features or capabilities of Prism in isolation, including a Hello World, Validation, PubSubEvents, and Search. Finally, there is fairly comprehensive documentation of the RI and Quickstarts that can walk you through that code.

There is a conceptual tie between Prism for Windows Runtime and Prism 4. Prism 4 was a previous set of guidance from Microsoft p&p focused on building loosely coupled, maintainable, and extensible desktop client applications with WPF and Silverlight. Some of the same concepts and even a tiny bit of the code was carried over where appropriate, but from the outset the goal of Prism was not to just port Prism 4 to WinRT, it was to build a good set of guidance for WinRT XAML applications without presuming that you should build WinRT applications in any way similar to WPF or Silverlight.

One thing that was definitely carried over in concept was the presumption that we would be focused on writing maintainable code. That meant we wanted to make sure that the core logic of our application would be unit testable and well factored. We wanted the code that supported one view to be decoupled from the code that supported another view. That of course led us quickly to plan on using the Model-View-ViewModel (MVVM) pattern that is common in WPF and Silverlight and that was also used in Prism 4. But we also quickly found that the WinRT platform is substantially different in the way you go about doing MVVM and we had to come up with a number of new things that our view models were responsible for - including integrating nicely with the WinRT navigation system and with the application lifecycle and state management of the platform.

So this series of articles will help you explore the concepts covered in Prism by demonstrating them in code.

At the time of writing this article, the Prism team is in the process of getting Prism for Windows Runtime ready for release. However, the current source code for Prism is available as open source and can already be downloaded from http://konaguidance.codeplex.com.

Getting Started

I have to start somewhere, so the most logical place to start is the same place you will – with a blank slate. In this article I will show you how to quickly put together a new application based on the Prism reusable class library (Microsoft.Practices.Prism.StoreApps). The code I write in this article will be the stuff you will end up doing in probably every Windows Store application you choose to build leveraging Prism – specifically it will lay down the patterns that enable you to use the MVVM pattern, manage your dependencies, integrate with the navigation system, and manage your application state through your view models and application services. I won’t go into detail in this article on the navigation and state management – those are both big enough topics that I will get into those in the next couple articles in the series. This one will just get you bootstrapped on using Prism.

The scenario for the application I will be building up over the series is for a line of business worker whose job it is to take sales order calls and enter the sales. They may also need to look up past sale information, product information, and enter and modify customer information as part of their normal job task.

Step 1: Create a Windows Store Application

The first step is to open Visual Studio 2012 and create a new Windows Store Application. Select the Blank application template, and name the project HelloPrismForWinRT.

After the project is created, you have a single page in the application named MainPage with no content to it.

Step 2: Create a couple Pages and ViewModels

In a Windows Store application, you design your application around Pages. The user navigates from Page to Page to get to all the functionality in your application. Your Pages are your top level Views from an MVVM sense, and you will set up ViewModels to support them. You might have views that are children of the pages – for example you could have a ContentControl within a page that you swap different child views into as the content. But this kind of composition is much less common than it was in WPF and Silverlight because of the Modern UI style guidelines – you should be keeping things a lot less dense than traditional line of business applications have tended to in the past, and spread the functionality of the application over multiple pages that the user navigates between instead of doing everything in one big complicated view.

Prism uses convention over configuration for a number of things. There is a ViewModelLocator class that makes it really easy to get views (Pages primarily) wired up to their ViewModels following the conventions of MVVW. This ViewModelLocator has a default convention that assumes you will put your Pages in a subfolder of the project named Views, and your ViewModels in a subfolder named – you guessed it – ViewModels. If you don’t like that convention, there are hooks to put them wherever you want. But a lot of the reusable code of Prism is designed around doing things based on common patterns, and if you follow those patterns you have less work to do in getting your application up and running.

So to start structuring things this way, delete the MainPage.xaml that was added to the root of the project by the template. Add two project folders: Views and ViewModels. Next, right click on the Views folder and select Add > New Item from the context menu. In the Windows Store category, select the “Basic Page” item template and name the first one “MainPage”.

When you click Add, you will be prompted to add some common files to your project that Visual Studio wants to add for every Windows Store application. Go ahead and click Yes, even though in the end we won’t use most of those classes – there are Prism equivalents that fit better with the MVVM pattern that we will use instead.

Go into the XAML of MainPage and change “My Application” to “Hello Prism” in the resources section.

Repeat Add > New Item to add a second Basic Page named AddSalePage to the Views folder.

Now you can see we have some duplicate resources in the different pages declaring the application name. I moved those up into the App.xaml resources dictionary and removed them from each of the pages to eliminate the duplication.

   1: <Application.Resources>

   2:     <ResourceDictionary>

   3:         <ResourceDictionary.MergedDictionaries>

   4:             <ResourceDictionary Source="Common/StandardStyles.xaml" />

   5:         ResourceDictionary.MergedDictionaries>

   6:         <x:String x:Key="AppName">Hello Prismx:String>

7:

   8:     ResourceDictionary>

   9: Application.Resources>

Next add two classes to the ViewModels folder: MainPageViewModel and AddSalePageViewModel. At this point, your project should look like this in Solution Explorer:

Step 3: Add Microsoft.Practices.Prism.StoreApps to your solution

Now it is time to get Prism involved. If you haven’t already, go download the Prism bits from http://konaguidance.codeplex.com. It is a self extracting executable that will unpack all the samples and code to a local folder. I extracted mine to the same root solution folder that was created when I created the project so that the references can remain local and I can just zip things up for the samples.

Once you have done that, go ahead and add the Microsoft.Practices.Prism.StoreApps project to your solution – right click on the solution root node in Solution Explorer, select Add > Existing Project, and navigate to the Microsoft.Practices.Prism.StoreApps project in the extracted code from Prism. This is a Windows Store Class Library project that contains all the classes that were designed for direct reuse in Prism. I will be using base classes for our application, views, and view models from it.

Once you have added the project to your solution, add a reference to Microsoft.Practices.Prism.StoreApps to your HelloPrismForWinRT application.

Step 4: Replace the App base class with MvvmAppBase

The App.xaml.cs code behind of your App.xaml file in the project contains the definition for the App class – which derives from the WinRT Application class by default. It also has a bunch of code in there for managing the lifetime of the application, creating the first view, handling suspension and some other stuff. All of this has been encapsulated into the MvvmAppBase base class with some overridable methods for the hooks that you may need to customize on an application by application basis.

So strip out all the code in the App class except the constructor that calls InitializeComponent, and change the base class to inherit from MvvmAppBase. You will also need to override OnLaunchApplication and navigate to the main page using the NavigationService that is exposed from the base class. Note that there is also an OnLaunched base class method that you should not override.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using Microsoft.Practices.Prism.StoreApps;

   5: using Windows.ApplicationModel.Activation;

6:

   7: namespace HelloPrismForWinRT

   8: {

   9:     sealed partial class App : MvvmAppBase

  10:     {

  11:         public App()

  12:         {

  13:             this.InitializeComponent();

  14:         }

15:

  16:         protected override void OnLaunchApplication(LaunchActivatedEventArgs args)

  17:         {

  18:             NavigationService.Navigate("Main", null);

  19:         }

  20:     }

  21: }

Note that I am overriding the OnLaunchApplication method in the App class. This is an abstract method in the base class and the minimum thing you need to do in this override is what I am showing here: you need to navigate to the right initial view for your application. For a “cold start” of your application, that means navigating to whatever the “main” page of your application is. But keep in mind that your Windows Store application can be launched in a number of ways, including being launched as a target for a Search charm operation, a secondary tile on the Start screen, or even an application protocol mapping launch. In these cases you might need to navigate somewhere different based on the launch arguments that come into this method. To make that more clear, MvvmAppBase has other overrides for handling search or settings activations. But for now just going to the MainPage from the OnLaunchApplication override is good enough.

Note that we navigate to “Main”, not MainPage as a type. This was a design decision we made in Prism that navigation requests like this should not be coupled to the specific type of the view or page. Keep in mind that if you are really planning your application appropriately, you will first storyboard or wireframe out what the pages are in your application and what the navigation between them is. You will probably define logical names for the views even though you probably won’t have decided on specific type names for the views at that point, even though they will most likely start with type names that are those view names + Page. Nor should you couple code that (as you will see in a future article) will often live in a decoupled view model to a specific view type. So the convention used for navigation in Prism by default is that you navigate to a logical view name, and it assumes that the type name is that logical view name + Page.

If this is not your convention, you can override a method on the MvvmAppBase class named GetPageNameToTypeResolver. This method returns a Func, so you are expected to return a delegate that points to a method that takes in a logical view name and returns a type. So for example if you wanted to adopt a convention where you would navigate to views based on their view type name, and they would live in the application root namespace + “.Views”, you would define a GetPageNameToTypeResolver that looks like this:

   1: public override Func<string, Type> GetPageNameToTypeResolver()

   2: {

   3:     return (viewName) =>

   4:         {

   5:             var rootNamespace = this.GetType().Namespace;

   6:             var viewNamespace = rootNamespace + ".Views";

   7:             return Type.GetType(String.Format("{0}.{1}", viewNamespace, viewName));

   8:         };

   9: }

But I won’t do that in the sample application, I’m going to stick to the Prism conventions that the page token is simply the Page type name with Page left off.

Next open the App.xaml file and replace the root element opening and closing XML elements with ones that use the MvvmAppBase base class, as well as adding a XAML namespace for Microsoft.Practices.Prism.StoreApps:

   1: <prism:MvvmAppBase x:Class="HelloPrismForWinRT.App"

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

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

   4:              xmlns:prism="using:Microsoft.Practices.Prism.StoreApps"

   5:              xmlns:local="using:HelloPrismForWinRT">

6:

   7:     <Application.Resources>

   8:         <ResourceDictionary>

   9:             <ResourceDictionary.MergedDictionaries>

  10:                 <ResourceDictionary Source="Common/StandardStyles.xaml" />

  11:             ResourceDictionary.MergedDictionaries>

  12:             <x:String x:Key="AppName">Hello Prismx:String>

13:

  14:         ResourceDictionary>

  15:     Application.Resources>

  16: prism:MvvmAppBase>

At this point you should be able to launch the app and land on a totally underwhelming main page that says Hello Prism.

Step 5: Change the Page base class to ViewStateAwarePage

Prism has a base Page class that is similar to the LayoutAwarePage that Visual Studio injects, but it is just about layout and not state management and navigation. In an MVVM application, you really want the navigation and state management code to live in the ViewModel, so the Prism ViewModel base class takes care of those responsibilities, which we will hook up in the next step.

For the Pages, replace LayoutAwarePage as the base class in both the XAML and the code behind, with the addition of a corresponding XAML namespace like we did in the App.xaml:

   1: <prism:VisualStateAwarePage x:Name="pageRoot"

   2:                             ...

   3:                             xmlns:prism="using:Microsoft.Practices.Prism.StoreApps">

   4: ...

   5: prism:VisualStateAwarePage>

You can also strip out all the other code in the code behind of the Pages other than the constructor with the InitializeComponent call:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using Microsoft.Practices.Prism.StoreApps;

5:

   6: namespace HelloPrismForWinRT.Views

   7: {

   8:     public sealed partial class MainPage : VisualStateAwarePage

   9:     {

  10:         public MainPage()

  11:         {

  12:             this.InitializeComponent();

  13:         }

  14:     }

  15: }

Make sure to make this same change for both MainPage and AddSalePage, and for each Page you add to the app after that.

Any reader with experience in MVVM should already be giving a little sigh of relief – yes, you can stick to almost zero code in the code behind, even in the Windows Store world.

You’ll need to get rid of one thing that is in the Basic Page template by default – it has a button wired up in the header for the GoBack navigation action, and it expects to find a Button.Click handler named GoBack in the code behind of the view. So in both the MainPage.xaml and AddSalePage.xaml, locate this code and remove the Click handler. Change this:

   1: <Button x:Name="backButton"

   2:         Click="GoBack"

   3:         IsEnabled="{Binding Frame.CanGoBack, ElementName=pageRoot}"

   4:         Style="{StaticResource BackButtonStyle}" />

to this:

   1: <Button x:Name="backButton"

   2:         Style="{StaticResource BackButtonStyle}" />

Step 6: Add the ViewModel base class to the ViewModels

Add a base class to the view models of ViewModel from the Microsoft.Practices.Prism.StoreApps namespace:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using Microsoft.Practices.Prism.StoreApps;

5:

   6: namespace HelloPrismForWinRT.ViewModels

   7: {

   8:     public class MainPageViewModel : ViewModel

   9:     {

  10:     }

  11: }

We won’t actually be doing anything in this article where it makes any difference what the view model base class is, but we will in future articles in the series, and in general when you are building out a Prism-based MVVM application, you will want to inherit from ViewModel for the Page view models so that you can integrate with the navigation and application lifecycle state management that I will cover in the next couple articles.

Step 7: Add the ViewModelLocator to the views to hook up their view models

Prism defines a reusable ViewModelLocator that can be used to hook up views and view models. It can do this automatically based on conventions, you can provide it factory methods that map a given view type to a given view model type, or you can override the default conventions of the ViewModelLocator to use your own conventions.

The default conventions of the ViewModelLocator are that for a given View type, it will assume the view is defined in a “.Views” child namespace off the project root or a sub-namespace, and the view model type has the same type name of the View plus “ViewModel” on the end of it and lives in a sibling “.ViewModels” namespace to the view. And this is precisely the folder and namespace structure I had you set up by adding the Views and ViewModels project folders in Step 2.

The way you use the ViewModelLocator from Prism is through an attached property on the view root element. So add the view model locator to the MainPage and AddSalePage root elements like so:

   1: <prism:VisualStateAwarePage ...

   2:                             xmlns:prism="using:Microsoft.Practices.Prism.StoreApps"

   3:                             prism:ViewModelLocator.AutoWireViewModel="True">

The ViewModelLocator will take care of creating an instance of the view model type for this view instance, and will also set the view model as the DataContext for the view, which is standard MVVM structuring.

After you have added this to MainPage.xaml, you could add a default constructor to MainPageViewModel and you should see that the constructor gets called as the app starts and navigates to the MainPage.

So at this point you should be able to fire up the application, and you have MVVM structuring and you could start fleshing out your views and view models to do some more meaningful work. To do much more, we need to get into navigation a little deeper, as well as managing dependencies. For example, the next logical step is to add a button to the MainPage that will let us navigate to the AddSalePage. But to do that in an MVVM way, we should fire a command from the button into the MainPageViewModel and control the navigation from there. That requires commands, some sort of Navigation service, and dependency injection of that service into the view model. It’s all there in the Prism code, and I’ll cover it in the next article. But that is all I have room for in this installment. For those that can’t wait for the next article, you could go check out the HelloWorld Quickstart in the Prism bits. It covers some of the same stuff I will get into in the next article that lets you get to the point of controlling navigation in your view models.

You can download the completed code for this article here.

Summary

In this article I introduced you to the concepts behind the Prism guidance from Microsoft patterns & practices. I showed you how to create a simple application based on Prism, using the Prism MvvmAppBase class, VisualStateAwarePage, and ViewModel base classes. I also used the ViewModelLocator to get the views and view models hooked up to one another.

Next time I’ll show you how you can use factories to construct the ViewModels so that you can inject dependencies into them manually, or how to instead use a container such as Unity to do Inversion of Control and Dependency Injection through a container to resolve dependencies when your view model gets constructed. You’ll see how to use Prism’s DelegateCommand, which is a ported version of the Prism 4 DelegateCommand it was based on, and you’ll also see how to have the view model know when it is navigated to, as well as how to control navigation.

About the Author

Brian Noyes is CTO of Solliance (www.solliance.net), a software development company offering Architecture as a Service, end-to-end product development, technology consulting and training. Brian is a Microsoft Regional Director and MVP, Pluralsight author, and speaker at conferences worldwide. Brian worked directly on the Prism team with Microsoft patterns and practices. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on Twitter @briannoyes.

Designer-friendly MVVM for XAML Windows Store applications

editorial@silverlightshow.net (András Velvárt ) — Thu, 07 Feb 2013 13:49:00 GMT

Introduction

It was almost three years ago that I published my company’s preferred approach to MVVM with Silverlight. Time sure flies, and now I can say that the basic ideas and general way of thinking outlined in that article stood the test of time – we created dozens of applications that used that approach, many of them ended being in the top 5 apps in the Windows Phone Store in their own categories.

Don't miss

All SilverlightShow Ebooks

And then, WinRT happened. WinRT (or Windows 8 Store application) development does not support Behaviors, Actions or Triggers, which were the foundation of the two key pieces of our MVVM puzzle: CallDataContextMethodAction and VSMChangerBehavior. We found that we had to write a lot of repetitive code in the codebehind, and often could not avoid littering it with some business logic that belonged in the ViewModel instead.

Note: I am not an MVVM purist – I think that using code behind is fine when it comes to manipulating the UI itself, and not the data that drives the UI. However, a lot of this functionality could be abstracted and reused with Behaviors – e.g. you could write a behavior that selected the content of an entire TextBox when it got focus, making it easier to replace the text within. Sadly, this is not really an option with WinRT without proper tool support.

After gaining enough experience with WinRT development, I set out to port over our proven approach to WinRT. A lot had to be changed since we could not take advantage of Behaviors, but the basics remained the same. This article introduces the WinRT version of the Designer-friendly MVVM Helpers library.

A Word about MVVM

Discussing what MVVM is and why it’s useful is waaaay beyond the scope of this article. I am assuming that You already know what it is, at least on a conceptual level. If not, please read the original Silverlight version of this article, which discusses the most important things about MVVM, and also gives you pointers for further reading.

Goals of the Designer-friendly MVVM Helpers

The goals are mostly the same as they were in the Silverlight / Windows Phone version.

For the project itself:

Total separation of the designer and developer workflows
Shallow learning curve for both the designer and the developer
Allowing both the designer and the developer to remain in their comfort zone, and only use the tools they are familiar with
Approachable solution for projects with low or medium complexity

For the designer:

As much Blend support as possible (this is not totally achieved yet due to limitations in Blend and lack of Behaviors)
Use of Visual States to reflect different states of the application
High level of flexibility
Almost everything can be done in XAML
Create a modern UI, including animations, transitions, custom skins, etc.

For the developer:

Focus only on coding
Display logic (ViewModel) code is unit testable, including user actions
Application states can be expressed naturally, via enum values
Ability to include techniques from other MVVM approaches, such as the MVVM Light Toolkit

Using the Designer-friendly MVVM Helpers

When discussing the relationship between a ViewModel and a View, XAML technologies use two key concepts:

Data binding – to get data from the VM to the View and vice versa
Commanding – to notify the VM of the user’s actions, such as the pressing of a button

Our library extends data binding by creating a bi-directional link between a View’s Visual States and an Enum in the ViewModel, and also provides a way for the View to call ViewModel methods upon user interactions. This covers 90% of the use cases for a typical, well architected MVVM app. For the rest, we are still relying on code behind, and desperately wait for the arrival of Behaviors in an upcoming WinRT / Blend release.

First, let’s see how the VM can be notified of user interactions.

The CallVMMethod Attached Property

For the Silverlight / Windows Phone version, this used to be the CallDataContextMethodAction. With Triggers, you had a very flexible way of specifying when the VM method should be called. While a similar approach could be used for WinRT using third party Behavior libraries, due to the lack of Blend support, these result in a ton of XAML code you had to write, making the solution designer-unfriendly. I looked at our usage of this pattern in our projects, and found that 98% of the time, we are just using a simple EventTrigger to trigger the CallDataContextMethodAction. So, for Windows 8, I focused on this use case, and I went for the most fluid experience I could achieve (leaving the other 2% to codebehind solutions).

Basic Example

Our first example simply shows the content of a TextBox in a dialog. Showing a MessageDialog from a ViewModel is not a good practice (beats testability and also separation of concerns), but I am using it as an example here to illustrate that the VM did receive a message.

The entire Page has a DataContext (MainVM), defined as follows:

   1:  <Page.DataContext>

   2:         <df:MainVM>df:MainVM>

   3:  Page.DataContext>

Here is the relevant code snippet from the ViewModel:

   1:  public string Message { get; set; }

2:

   3:  public void ShowMessage()

   4:  {

   5:      string msg = Message ?? "Enter something in the textbox";

   6:      MessageDialog dialog = new MessageDialog(msg, "Dialog from ViewModel");

   7:      dialog.ShowAsync();

   8:  }

The UI for this sample looks like this:

And the XAML is:

   1:  <TextBox  Text="{Binding Message, Mode=TwoWay}"/>

   2:  <Button Content="Message!" df:CallVMMethod.Click="ShowMessage"/>

The ViewModel learns about the content of the TextBox with a simple binding –0 no surprises here. The more interesting part is the second line, where the new attached property is used to call the ShowMessage method of the ViewModel (or technically, the DataContext of the Button), when the Button’s Click event is fired.

When you are typing the above line, Intellisense helps you as much as possible. Here is what it looks like:

As you can see, the most used event handlers are available – and if the one you are looking for is not, you can easily add a new one.

Using from an ItemTemplate

This is all nice, but often you want to call a VM method from a list. E.g. the VM should know when you selected an item, or clicked the “Delete” button next to an item.

Suppose we have a list of strings, and want the user to choose one of those. Here is the VM (again, simplified to focus on the main point of the article):

   1:  public MainVM()

   2:  {

   3:      SomeStrings = new ObservableCollection<string>();

   4:      for (int i = 0; i < 10; i++)

   5:          SomeStrings.Add(Guid.NewGuid().ToString());

   6:  }

7:

   8:  public ObservableCollection SomeStrings { get; private set; }

We have a ListView in the View to display these strings. Pretty straightforward so far:

<ListView ItemsSource="{Binding SomeStrings}" ItemTemplate="{StaticResource DataTemplate1}"/>

You could bind the SelectedItem to a property in the VM and handle selection in the property setter, but the setter does not get called if you click on the item already selected. Instead, you could do something like this in the ItemTemplate:

   1:  <DataTemplate x:Key="DataTemplate1">

   2:      <TextBlock TextWrapping="Wrap" Text="{Binding}" df:CallVMMethod.Tapped="StringSelected"/>

   3:  DataTemplate>

This would call the StringSelected method of the DataContext, except… the DataContext of the DataTemplate in this case is just a String, which does not have such a method. What happens in this case, is that the CallVMMethod starts to traverse the Visual Tree. If the DataContext of the TextBlock does not have a StringSelected method, maybe its parent does. Or maybe the parent of that… and so on, and so on, until the method with the right signature is found (see below), or the top of the Visual Tree is reached (in which case you get an ArgumentException).

This way, as we go up, we reach the parent ListBox, the DataContext of which does have the StringSelected method defined in the MainVM class:

   1:  public void StringSelected(string dataContext)

   2:  {

   3:      MessageDialog msgd = new MessageDialog("Selected: " + dataContext);

   4:      msgd.ShowAsync();

   5:  }

This StringSelected method excepts a single parameter, with the type of String. This is important – since we have traversed up the Visual Tree until the point where the original DataContext of the tapped TextBlock is no longer visible, we have to have a way for the StringSelected method to know which string was tapped on. This technique can also be used to pass a business object, such as a Person or Company to the VM.

Method signatures

As you saw above, there are several ways you can define the methods in the ViewModel to be called by CallVMMethod. Here is a reference table of all the supported signatures:

MethodName()
No parameters, no data passed to the method

MethodName(T dataContext)
If the DataContext of the source FrameworkElement mathes the type T (or can be assigned to a variable of type T), this method is a match. The value passed is the DataContext of the source FrameworkElement

MethodName(T dataContext, Targs args)
It is rare, but sometimes you may want to pass the original event’s arguments to the ViewModel. If so, this signature is understood by CallVMMethod and invoked.

The CallVMMethod will look for all these methods in the DataContext of the source FrameworkElement and its parents’ DataContext until it finds a suitable method or reaches the top of the tree.

Adding more events

You may find that the events implemented by CallVMMethod does not include the event you want to use. Luckily, it is easy to expand the list of events: open the CallMVVMMethodHandledEvents.tt file (which is a T4 template), and add your event to the others by listing the event name, event handler type and event argument type. For example, this is what the first few events look like in the template:

   1:  string[] handledEvents = new string[] {

2:

   3:  "Click,RoutedEventHandler,RoutedEventArgs",

   4:  "DoubleTapped,DoubleTappedEventHandler,DoubleTappedRoutedEventArgs",

   5:  "DragEnter,DragEventHandler,DragEventArgs",

The T4 code generator will take care of the rest.

The EnumToVisualState Control

The other piece of the designer-friendly MVVM puzzle was the VSMChangerBehavior, which mapped ViewModel enums to Visual States in the View. Again, due to the lack of Behavior support in WinRT, this had to be rewritten, but the basic idea remained the same.

The sample I am going to show for the EnumToVisualState control is a simple one: the ViewModel controls whether a panel is to be open or closed via a simple Toggle method.

Configuration

Let’s define a simple enum for the panel’s two states: On and Off:

public enum PanelState { Off, On }

…and use it in the ViewModel:

   1:  private PanelState _panel = PanelState.Off;

   2:  public PanelState Panel

   3:  {

   4:      get { return _panel; }

   5:      set

   6:      {

   7:          _panel = value;

   8:          if (PropertyChanged != null)

   9:              PropertyChanged(this, new PropertyChangedEventArgs("Panel"));

  10:      }

  11:  }

12:

  13:  public void TogglePanel(object dataContext, TappedRoutedEventArgs args)

  14:  {

  15:      Panel = Panel == PanelState.Off ? PanelState.On : PanelState.Off;

  16:  }

You can use a more sophisticated method for raising the PropertyChanged event, but it is important that you do perform this call.

Next, you need to define the Visual States that correspond to the enum values and property names above. For this example, we need to define a Visual State Group called “Panel”, and two states within it: “Panel_On” and “Panel_Off”. Here is an example for a panel that slides in from the left:

   1:  <VisualStateManager.VisualStateGroups>

   2:      <VisualStateGroup x:Name="Panel">

   3:          <VisualStateGroup.Transitions>

   4:              <VisualTransition GeneratedDuration="0:0:0.5">

   5:                  <VisualTransition.GeneratedEasingFunction>

   6:                      <CircleEase EasingMode="EaseInOut"/>

   7:                  VisualTransition.GeneratedEasingFunction>

   8:              VisualTransition>

   9:          VisualStateGroup.Transitions>

  10:          <VisualState x:Name="Panel_On"/>

  11:          <VisualState x:Name="Panel_Off">

  12:              <Storyboard>

  13:                  <DoubleAnimation Duration="0" To="-340" Storyboard.TargetProperty="(UIElement.RenderTransform).(CompositeTransform.TranslateX)" Storyboard.TargetName="grid1" d:IsOptimized="True"/>

  14:              Storyboard>

  15:          VisualState>

  16:      VisualStateGroup>

  17:  VisualStateManager.VisualStateGroups>

The last step is to add an EnumToVisualState control to your Page:

<df:EnumToVisualState Opacity="0" VerboseInitialization="True" ElementWithVisualStates="{Binding ElementName=grid}" />

The control is invisible. It has three important properties:

DataContext
The ViewModel where the enums are defined. Since DataContext is inherited in the Visual Tree, most of the time you can leave it as is – however, if you need to, you can bind it to something else, using the full binding arsenal of WinRT

ElementWithVisualStates
This is the FrameworkElement the Visual States of which we want to control.

VerboseInitialization
Set this to true to have EnumToVisualState write detailed initialization information to the Debug output window. This will show you what kind of properties and methods the control is looking for in the ViewModel, and help hunt down typos.

Finally, we can add a Button to the UI to toggle the panel by calling the TogglePanel VM method using the CallVMMethod technique:

<Button Content="Toggle Panel" df:CallVMMethod.Tapped="TogglePanel" />

Tapping the button now invokes the TogglePanel VM method, which in turn changes the PanelState enum, which causes the Visual State to change and the animation to be played.

Conventions

EnumToVisualState uses a convention-based approach. This means that instead of using a lot of binding, you only have to make sure that the enums in the ViewModel and the state names in the View match to work. Here are the naming conventions you have to follow:

To map a Visual State Group to an enum, all you have to do is make sure they both have the same name.
To map a Visual State to a value of an enum, you have to name the Visual State correctly: _.
To get notified in the ViewModel when a visual state transition is finished, you need to have a method called TransitionComplete() with no parameters.

So, if you have an enum called PanelState, which has the possible values of “Off” and “On”, and you have a ViewModel property called “Panel”, you need to call your Visual State Group “Panel”, and the states withing it “Panel_Off” and “Panel_On”.

Callbacks

Since Visual States can have transition animations which can take a while to finish, it is sometimes useful to know when the user actually sees the final scene. EnumToVisualState provides you with this information: if you have a method called “PanelTransitionComplete”, this method will be called every time the “Panel” Visual State Group finishes a transition animation. Here is an example:

   1:  public void PanelTransitionComplete()

   2:  {

   3:      MessageDialog msgd = new MessageDialog("Panel transition to " + Panel.ToString() + " complete!");

   4:      msgd.ShowAsync();

   5:  }

The new state is not passed to this method, it can be determined from the value of the corresponding enum.

Initial State

You can also set an initial state for the enums in the VM, and the Visual States will be initialized in that state. For example, if you set the Panel to PanelState.Off, the Panel will not be visible when the Page first shows up. While this is achieved without a visible transition animation, the TransitionComplete method is still invoked.

Download

Finally, you can download the entire demo project here. You will need to copy four files to your project: CallVMMethod.cs, CallVMMethodHandledEvents.tt, EnumToVisualState.cs, and also . I will also prepare a Nuget package, and will upload it soon after this article is published.

Summary

Porting our tried and proven Behaviors to WinRT was not a simple task. However, I believe that in the end, the core values of the original solution are preserved despite the different architecture. Please let me know if you find this library useful, or if you have any feedback!

Metro style applications – designing for the user

editorial@silverlightshow.net (Lazar Nikolov ) — Wed, 02 May 2012 12:21:00 GMT

It has been months since Windows 8 is available for developers and the need for new applications is growing in a fast pace.

Don't miss...

All SilverlightShow Ebooks

And nothing is more exacting than a computer user in 21^st century. It’s quite difficult to build the right application, moreover – it’s even more difficult to stay on top and not to be, metaphorically, stepped over by the big players. They always know what exactly the user wants and have the resources to provide it to him. But that’s not always what has to happen after all.

You have the power to build what the user wants and even build it so that s/he would feel it so natural to use your Metro application. That is to design the application in a way that using the fingers on the display seems to be a pleasure, but not a challenge.

Okay, let’s make our Metro applications look great!

Designing the Metro application is different from designing the common and straightforward desktop application. Obviously, using fingers on touch instead of mouse cursor is a big difference. And the Metro style applications will soon become the mainstream.

Here you can find design assets for creating great Metro application mock-ups. The download contains layered PhotoShop files representing common controls and components, project layouts and templates.

In the download you will find lots of .psd files that you can use to build a sketch or mocked prototype of your application. It seems that everything you would ever need is in:

Common controls. A variety of styles of all controls in dark and light Metro themes.
Common components. Tiles with the 1x1 and 2x1 ratio, contracts – the charms bar, search, share and settings side menus and more, and the keyboard.
Base layouts. For fill, full, portrait and snap views.
Project templates. For light and dark themes.

Microsoft provides you with all you could need, but you are, of course, not limited only to the list. All files are layered and fully editable to stick with your mock-up design needs.

User experience design patterns

Here come the UX design patterns. They encapsulate the most important principles in Windows 8 Metro applications and guide you to the ultimate design. Using the patterns helps you in finding answers to questions related to content organization in pages, placing buttons and commands and the touch gestures and interactions.

Navigation design

The navigation design patters guide developers in organizing application content in pages, subpages, sections and categories so the users feel it comfortable and intuitively to switch between application screens and navigate through different views. It focuses mainly on two types of navigation.

The Hub design pattern, or hierarchical system of navigation, is the most commonly used in the consumers preview. It is appropriate when the application consists of large amount of data that also varies a lot. The content is organized in levels and each level is responsible for a specific context. The top-most page – the Hub page, also referred as initial page, is where the content is presented in different sections with different contexts. The Hub page usually provides very different categories of content and less functionality. Its main focus is the content presentation. Each section of the Hub page is associated with a Section page that is more specific in its content presentation. It often contains a number of data items. Each item is then presented in details in the Details page – the third and last level of content.

The Flat design system is used mostly in applications that have a single purpose and clear interaction and process flow. Such an application is document creation tool that has small number of pages that have to be executed all in a specific order.

On the navigation design documentation page here you can also find guidelines and basic navigation concepts for Metro applications.

Commanding design

The commanding design guidelines that you can find here describe the best practices in Metro applications for placing and using command buttons in all possible ways. The focus is on what the user should be able to do and how this should happen. When possible you must allow manipulating items and executing commands directly from the canvas and not by the charms and the application bar. The command buttons have to be consistently used in all application views so it is the same and intuitively for users to execute commands from everywhere. To avoid complexity limit the number of commands and always consider the placement of the button – this could improve the speed a command can be acted upon.

Touch interaction design

On the Microsoft Build conference last year Jensen Harris of the Windows User Experience team announced the results from usability research conducted from Microsoft in their dedicated labs for the comfortable zones of interaction and behavior when using a touch screen device like the Metro tablet. Everyone uses the touch device in a slightly different way in different postures – on the knee, on tables, with two hands on the side, etc. The last turned to be the most common posture.

The touch interaction guidelines (that you can find in details here) describe how to provide good touch interaction experience with your application partly relying on researches among users.

Interaction comfortable area: Because the Windows 8 tablets are most often held along the side, the bottom corners and sides are ideal locations to put your interaction elements. To comfortably reach the center of the screen it takes you a posture change – put the important interaction interface close to the edges in the user’s comfortable zone.

Reading comfortable area: Content in the top half of the screen is easier to read than content in bottom half or the middle because it is often partly covered by your fingers.

Windows 8 has several standard touch interactions, which effects shouldn’t change when the display is touched with more fingers than expected.

Elements from your interface that could be moved around should follow the finger direction while the display is touched. Just like in real world – the pen is in your hand while you don’t put it on the desk. All interactions should be observed, i.e. user should feel or see a feedback from his actions. It’s not acceptable to press a button with your finger and don’t see any flash or any kind of feedback. You could be misled that your touch hasn’t been registered from the device. And last but definitely not least – always consider the size of the things. The error rate increases with the size getting smaller. The recommended minimum size for a touch target is 7x7 mm (40x40 pixels) with at least 2 mm padding. Of course, when the accuracy matters, the size gets bigger.

Touch interactions are important. Think if the interactions as the language that your application uses to communicate with the user. You need this language fluent!

Conclusion

Designing your application in a way that you put yourself in the user shoes is a key factor for the vitality of a future product. In a world where the user is ruling and defines the standards, the design and feel of your application is also the packaging. And the bad pack is even not considered as an option. This article is about attracting users with nice and intuitive user experience in Windows 8 Metro applications. To keep a user, though, you need also the content and value. Harnessing the power of the navigation, commands and touch interactions guidelines and patterns parallel with the content may be the key of your success!

Working with Prism 4 Part 4: Region Navigation

editorial@silverlightshow.net (Brian Noyes ) — Thu, 16 Feb 2012 16:02:00 GMT

This is part 4 in the series Working with Prism 4.

Introduction

At Microsoft ASP.NET Connections March 26- 29 2012 I’ll be presenting a session on Prism development that includes the capabilities covered in this article – the URI-based navigation capabilities of Prism.

More resources...

All SilverlightShow Ebooks

In this article I am going to right some wrongs in the code from the past couple articles that I put there to keep things simple and focused on other things for the first few articles. When using the MVVM pattern, one of the major goals is to maintain loose coupling and separation of concerns between views and their view models. But even more important is that different view models should not be coupled to each other unless it is a parent-child kind of relationship, and view models should not be coupled to other views or their own view either. When I set up the code in the previous article to load and switch CustomerEditView instances and their view models, I did it all from the CustomerListViewModel. That code involved using the Prism RegionManager to do the view loading and switching, but it required me to create instances of CustomerEditView and CustomerEditViewModel in the code of CustomerListViewModel. That is a violation of the decoupling goals of MVVM.

To fix this I am going to leverage one of the other features of Prism 4 – view switching navigation. In the previous articles, you have seen two parts of the API of the RegionManager service. One involved the Add and Activate methods of the IRegionManager interface. These allow you to explicitly add a view to a region and activate (or show) it at the appropriate times. You also saw in the last article that the AddToRegion method simplifies the process of adding a view if it will be the only. However, these approaches require you to have a view instance available to pass to the methods. That means the code that makes those calls is inherently coupled to the view instances. If you also need to initialize some state of the view model at the point where you are adding the views, that means you might also be coupled to the view model class in that same code. This is the code I placed in the CustomerListViewModel that really should not have been there.

The sample code for this article builds on the code from the last article. You can download the completed code from Part 3 here. You can download the completed code for this article here.

View Switching Navigation

In Prism 4 the capability was added to have a more implicit and loosely coupled form of view switching that mimics the URI-based navigation of the web. If you think about what a user is doing when they navigate to a particular page on a web site by putting in an address, they are not really requesting a specific implementation of a page, they are requesting a named view that is the relative portion of the URI (minus the site address at the root). Through mechanisms like the ASP.NET Routing Service, that URI could map to any kind of implementation behind the scenes, and the requester need not know what or where it is. They just need to know the logical name of the view they are trying to get to in the form of a URI. Additionally, the web addressing scheme allows you to pass additional information as part of the URI, including parameters to be passed to the receiver of the request.

If a view model or other code is going to cause views to switch out in the user interface, it would be nice if that code had the same degree of decoupling from the implementation of the target views as well as a similar logical addressing mechanism. Prism added a great capability that mimics this to load and switch views within a region based on an extension method that was added to the IRegionManager interface, called RequestNavigate. This method has several overloads, but they all take two key parameters: the region name in which you want navigation to happen (similar to the site root address in the web browser analogy) and the logical name of the view you want to navigate to. The caller of the method does not have to know what view type or instance the request for navigation maps to, it just knows there is a logical view out there that is wants to see.

This capability includes more than just the ability to load a view into a region. You can pass parameters to its view or view model as part of the navigation request, and the view or view model can use that information to initialize itself or to refresh its state. The view or view model can participate in the decision of whether to create a whole new view or to reuse one that has been shown before. The view can also participate in deciding if and when the navigation can be completed, so that it could for example prompt the user to save changes or to allow the view switching. I’ll be showing you how to leverage all of this in this article.

Step 1: Export the views by logical name

The first modification to make is to declare the logical name of the view as it will be requested by a piece of code wanting to navigate to it. The way this is done with MEF is by using the [Export] attribute with a contract name. When a view is first requested within a region, Prism will create a new instance of it, add it to the region, and activate it. Subsequent requests to navigate to that view type will either get a new instance or will reuse the existing instance, base on some interfaces I’ll discuss a little later in the article.

The modifications to the views look like this:

   1: [Export("CustomerListView")]

   2: [PartCreationPolicy(CreationPolicy.NonShared)]

   3: public partial class CustomerListView : UserControl

   4: {

   5: ...

   6: }

Notice the association of the logical name with the class. In this case, they happen to be the same. But there is no requirement for them to match. The PartCreationPolicy is required because by default, MEF creates singleton instances of any class it exports unless you change the CreationPolicy to NonShared as shown. This allows us to have multiple instances of the view if desired.

Do the same for the CustomerEditView:

   1: [Export("CustomerEditView")]

   2: [PartCreationPolicy(CreationPolicy.NonShared)]

   3: public partial class CustomerEditView : UserControl

   4: {

   5:     public CustomerEditView()

   6:     {

   7:         InitializeComponent();

   8:     }

   9: }

Step 2: Switch to “View First” construction of the CustomerEditViewModel

In the previous article’s code, the CustomerEditViewModel and CustomerEditView were being constructed and married together by code in the CustomerListViewModel. That is part of what we are trying to fix. It is much easier and better from a development tools perspective (Visual Studio and Blend designers – aka “Blendability”) and code simplicity perspective if the view creates the view model declaratively in the XAML. The CustomerListView and OrdersView were already doing this, but I needed to switch the CustomerEditViewModel so that it is structured the same so that when the view gets constructed (which will happen in the Prism framework with the navigation features we are looking at), the view model is also created and wired up as the view’s DataContext.

   1: <UserControl x:Class="Prism101.Modules.Core.CustomerEditView"

   2:              xmlns:local="clr-namespace:Prism101.Modules.Core"

   3:              ...>

   4:     <UserControl.DataContext>

   5:         <local:CustomerEditViewModel />

   6:     UserControl.DataContext>

   7: UserControl>

Step 3: Request navigation to the CustomerListView on initial load

This step is not explicitly required, but just want to show an alternative to the initial adding of the CustomerListView to the main region. In the previous few articles, the Core module’s IModule.Initialize code looked like this:

   1: public void Initialize()

   2: {

   3:     var view = new CustomerListView();

   4:     RegionManager.AddToRegion("MainContent", view);

   5: }

Instead, using the navigation features, we could do this:

   1: public void Initialize()

   2: {

   3:     RegionManager.RequestNavigate("MainContent", "CustomerListView");

   4: }

Not a huge savings there, but at least this code no longer has to be coupled to the CustomerListView type and worry about its instance lifetime. In the next few steps you will see how it can really start to shine in other areas.

Step 4: Remove the view model coupled code

In the last article, I had the following code invoked when the Edit button was pressed in the CustomerListViewModel:

   1: private void OnEditCustomer()

   2: {

   3:     IRegion secondaryContentRegion = RegionManager.Regions["SecondaryContent"];

   4:     bool alreadyExists = false;

   5:     foreach (var view in secondaryContentRegion.Views)

   6:     {

   7:         var custView = view as CustomerEditView;

   8:         var custViewModel = custView.DataContext as CustomerEditViewModel;

   9:         if (custViewModel.Customer == SelectedCustomer)

  10:         {

  11:             secondaryContentRegion.Activate(view);

  12:             alreadyExists = true;

  13:         }

  14:     }

  15:     if (!alreadyExists)

  16:     {

  17:         CustomerEditView editView = new CustomerEditView();

  18:         CustomerEditViewModel viewModel = new CustomerEditViewModel { Customer = SelectedCustomer };

  19:         editView.DataContext = viewModel;

  20:         secondaryContentRegion.Add(editView);

  21:         secondaryContentRegion.Activate(editView);

  22:     }

  23: }

This is the code that not only has coupling to the CustomerEditView and CustomerEditViewModel types, it is also doing instance management of those objects, which is really just wrong. Remove all the code in this method.

Step 5: Request navigation to the CustomerEditView for the right customer

Replace the code that was handling editing with the following code:

   1: private void OnEditCustomer()

   2: {

   3:     var uriQuery = new UriQuery();

   4:     if (SelectedCustomer != null)

   5:     {

   6:         uriQuery.Add("customerId", SelectedCustomer.CustomerID);

   7:     }

8:

   9:     var uri = new Uri("CustomerEditView" + uriQuery.ToString(), UriKind.Relative);

10:

  11:     RegionManager.RequestNavigate("SecondaryContent", uri);

  12: }

Not only is this code much simpler, you can see that there is no type coupling in there at all. The first part of the method uses a helper object from Prism called UriQuery to formulate a query string with a name of customerId and the value from the selected customer. It then concatenates this with the logical view name it wants to request navigation to, and then calls the RegionManager.RequestNavigate extension method, identifying in which region it wants the view to be shown (SecondaryContent in this case). Could not be simpler, right?

Because SecondaryContent happens to be a tab control, it means that each time navigation happens, it could do one of several things:

Add a new tab to the control on every navigation, regardless of what customer is selected
Add only one tab and replace its content with the information for the customer identified in the query string (in which case there would not be much point in having a tab control)
Add a new tab when the customer identified does not already have an active tab, and if it does just activate it

The last option is the one that will be most intuitive for the user, so that is the one we will go with here. But just realize with the mechanisms I’ll be showing shortly, you could do any of these with the exact same RequestNavigate call.

Step 6: Let the CustomerEditViewModel control its own initialization and instancing

In the code that I stripped out of the CustomerListViewModel, the code was not only managing the instancing of the edit view and view model, it was also initializing the state of the view model by setting the Customer property to the SelectedCustomer. Now that Prism is going to take care of creating the view (and implicitly the view model with the view-first construction), you still need a way to initialize the state of the view model. This can easily be done with an interface defined in Prism called INavigationAware. This interface has three members which allow your view or view model to

Known when it has been navigated to and get access to the query string parameters to initialize state
Known when it is being navigated away from (to do something like persist its state to a cache, service, or DB)
Influence whether the view is the target of the navigation or should be reused for navigating to that view type but with different contents

When RequestNavigate is called for a region, the navigation service that does the handling will check the views that are currently contained by that region. If one matches the URI for the view being requested, it will invoke the IsNavigationTarget method to allow that instance to decide whether it should be activated for the navigation to complete. If the view or view model returns true from that, it will be activated if its URI path matches the one being requested. If it returns false, Prism will create a new instance of the view type and place it in the region and activate it. The method is passed a NavigationContext object that contains the URI and parameters for the request to help guide it in its decision to answer the question “are you the one?”

To accommodate the MVVM pattern but not force you to adopt it, whenever Prism looks for an interface implementation on a view, it also checks to see if the DataContext of the view (which should be the view model if doing MVVM) implements it. This allows you to put the logic that supports the interface only on the view model and leave the view as just the structural definition of the visual aspects of the view.

After IsNavigationTarget is called, if it returns true, then the OnNavigatedTo method is called with the same NavigationContext object. This is the chance for the view or view model to initialize itself (possibly based on URI parameters).

The implementation of the INavigationAware interface in the CustomerEditViewModel looks like this:

   1: bool INavigationAware.IsNavigationTarget(NavigationContext navigationContext)

   2: {

   3:     string custId = navigationContext.Parameters["customerId"];

   4:     if (!string.IsNullOrWhiteSpace(custId) && Customer != null && Customer.CustomerID == custId)

   5:         return true;

   6:     return false;

   7: }

8:

   9: void INavigationAware.OnNavigatedTo(NavigationContext navigationContext)

  10: {

  11:     // Choosing to not refresh the customer every time the view is loaded

  12:     if (Customer != null) return;

  13:     // Initial load - Load customer based on ID passed in

  14:     string custId = navigationContext.Parameters["customerId"];

  15:     if (string.IsNullOrWhiteSpace(custId)) return;

  16:     CustomersDomainContext context = new CustomersDomainContext();

  17:     EntityQuery custQuery = context.GetCustomersQuery().Where(c => c.CustomerID == custId);

  18:     context.Load(custQuery, OnCustomerLoadCompleted, null);

  19: }

20:

  21: private void OnCustomerLoadCompleted(LoadOperation obj)

  22: {

  23:     if (obj.HasError)

  24:     {

  25:         MessageBox.Show("Error loading customer: " + obj.Error.Message);

  26:         obj.MarkErrorAsHandled();

  27:         return;

  28:     }

  29:     Customer = obj.Entities.FirstOrDefault();

  30: }

31:

  32: void INavigationAware.OnNavigatedFrom(NavigationContext navigationContext)

  33: {

  34: }

You can see that the logic for IsNavigationTarget checks to see if the query string parameter customerId matches the CustomerID property of the Customer that the view model is managing. If you simply wanted to reuse the view and view model instance and only have one instance of that view type (for containment in a ContentControl for example), you could just hardcode a true return value from the IsNavigationTarget. But in our case we are going to have multiple instances of this view type in a tab control, so we want to use the IsNavigationTarget to drive the logic that if the navigation request is for a customer for which there is already a view, just activate that view. If not, create a new instance of that view type and initialize it based on the customerId.

So the OnNavigatedTo method checks to see if the Customer is already set, this view would not be navigated to unless the IsNavigationTarget had found that the Customer matched the request, so there is no initialization needed (unless you wanted to always refresh the customer data from the back end for example). But if the Customer is null, it is the first time activating this view for a given CustomerId, so the code uses RIA Services to load a Customer from the back end. This approach has the additional advantage that the views are more self-deterministic – instead of requiring some other code to know how to get a Customer and shove the right one into the view, the view (or better yet its view model) knows how to go get the right state based on nothing more than a state identifier of some sort that is placed in the query string. This allows you to move the views around within the app, change who their parent view/view model is, and not have to change anything about how the view gets initialized.

If you are concerned that this pattern will make you make more round trips to the back end, all you need to do is adopt the Repository pattern and have your view models call the repository with their state identifiers, and have the Repository cache the data client side and encapsulate what the cache invalidation scheme is so the views don’t have to worry about it and can just request their current state at any time.

Finally, in this case, we have no logic to perform in the OnNavigatedFrom method so we can just leave that one blank.

Step 7: Let the view decide when navigation happens

There is a very important but subtle point in the way the RequestNavigate method is named. It is a request for something to happen, but it doesn’t say when it should happen or make the implication that navigation will be complete when the method returns. Navigation needs to be a non-blocking request because the view that is currently presented might need to do something (such as prompt the user to save) before allowing the navigation to complete. That is inherently a non-deterministic and potentially long-running block (the user might be distracted tweeting in another window for example). Additionally, a view needs to be able to reject navigation because it may be in the middle of an operation it cannot cancel immediately or you may want to let the user decide whether to dismiss a view for example.

So the RequestNavigate method is a non-blocking asynchronous call. If the caller needs to know when navigation is complete, there is an overload that takes a callback reference that will be invoked by the Prism navigation service once the navigation happens or is rejected. If the view does want to decide if and when navigation should occur, it (or its view model) implements an interface called IConfirmNavigationRequest. This interface has one method, ConfirmNavigationRequest, which is passed a NavigationContext like the INavigationAware methods, and a callback for the method to invoke when it has decided to either allow the view to be deactivated (navigated away from) or to reject the navigation.

In the same application, I chose to demonstrate this by using the IsDirty state of the edit views (the same one that is enabling and disabling Save commands as discussed in the last article). If the view state IsDirty, then the view model will prompt the user with a message box to let them confirm or deny navigation with an OK/Cancel action.

The implementation of this interface is shown below. You can see that is IsDirty is true, it prompts the user. If they press OK, the callback is invoked with a true argument, meaning navigation can proceed. If Cancel, then it gets invoked with false.

   1: void IConfirmNavigationRequest.ConfirmNavigationRequest(NavigationContext navigationContext,

   2:     Action<bool> continuationCallback)

   3: {

   4:     if (IsDirty)

   5:     {

   6:         string prompt = "The view's state has changed and has not been saved, do you want to allow view switching?";

   7:         var result = MessageBox.Show(prompt,"Confirmation",MessageBoxButton.OKCancel);

   8:         if (result == MessageBoxResult.OK)

   9:         {

  10:             continuationCallback(true);

  11:             return;

  12:         }

  13:         else

  14:         {

  15:             continuationCallback(false);

  16:             return;

  17:         }

  18:     }

  19:     continuationCallback(true);

  20: }

Now the one hitch in the sample application is that because these views are presented in a tab control, the user can click on a tab header at any time and cause view switching to occur and the Prism navigation service would not be involved at all, so your view implementations of the INavigationAware and IConfirmNavigationRequest interfaces would not be called. To intercept and prevent tab switching would require a lot lower interception of events on the tab control. So this mechanism for preventing navigation is better suited for containment in a ContentControl where the user does not have a direct user interface mechanism to cause views to swap. But as long as the changing occurs through the navigation controls you put in place that call RequestNavigate, life will be good.

Summary

In this article, you learned how to leverage the navigation capabilities of Prism in a more loosely coupled and flexible way with the IRegionManager.RequestNavigate method, INavigationAware and IConfirmNavigationRequest interfaces. These capabilities allow you to compose a much more loosely coupled application where no code is explicitly tied to view or view model types. The view models can be designed to operate independently of their containers and the code that causes navigation or view switching to happen does not have to be coupled to what the specific implementation of the view is or how it needs to be initialized. This approach still gives you control over when views are created and added to regions and activated, but puts the control in the hands of the views themselves instead of the code that triggers the navigation.

This capability can also be mixed in with the Silverlight navigation framework as shown in this article by Karl Shifflet.

You can download the completed code for this article here.

About the Author

Brian Noyes is Chief Architect of IDesign, a Microsoft Regional Director, and Silverlight MVP. He is a frequent top rated speaker at conferences worldwide including Microsoft TechEd, DevConnections, VSLive!, DevTeach, and others. Brian worked directly on the Prism team with Microsoft patterns and practices and co-authored the book Developers Guide to Microsoft Prism 4. He is also the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding in Windows Forms 2.0. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on Twitter @briannoyes.

Working with Prism 4 Part 3: Composite Command and Pub/Sub Events

editorial@silverlightshow.net (Brian Noyes ) — Tue, 24 Jan 2012 10:10:00 GMT

This is part 3 in the series Working with Prism 4.

Introduction

In the last article, I showed how to structure your Prism application to use the MVVM pattern and use DelegateCommands to communicate between the view and view model. Additionally, I showed how to pull some data in using WCF RIA Services and display it in the view, as well as using Prism Regions and the ability to add and activate different views in a region to accomplish simple navigation for the user (view switching).

More resources...

All SilverlightShow Ebooks

In this article, I’ll extend that sample application a little farther and show you how to leverage two other loosely coupled communication features of Prism 4: CompositeCommands and Prism CompositePresentationEvents (aka pub/sub events). The code presented in this article builds on what was the completed code from the last article.

You can download the complete code from the last article that acts as the starting point here. You can download the completed code for this article here.

Note: Now that Silverlight 5 has released, the code for this article uses an updated version of the Prism 4 code recompiled to Silverlight 5 as a target. That code can be downloaded from prism.codeplex.com and is included in the completed code sample for this article.

CompositeCommands

CompositeCommands are another implementation of the ICommand interface defined by Silverlight and WPF. There are several differences about the CompositeCommand implementation and the DelegateCommand implementation. The first is that the CompositeCommand is an aggregation of other commands – a list of ICommand references internally. It allows you to hook up multiple command targets to a single root command that itself can be hooked up to a command source such as a button or menu item. Figure 1 shows this relationship. The CompositeCommand can hold references to any ICommand object, but typically you will use it in conjunction with DelegateCommands. When the CompositeCommand.Execute method is invoked, it will invoke the Execute method on each of the child commands. When CompositeCommand.CanExecute is called to determine whether the command is enabled, it polls its child commands for their result from CanExecute.

Figure 1: CompositeCommands contain other commands

Child commands register themselves with the composite command and can also unregister if appropriate. In this way, it is very similar to a subscribe/unsubscribe of an event, but with the additional functionality of commands to enable and disable the commands based on custom logic.

Another thing different about CompositeCommands is that they can be hooked up to a source control ahead of time, before any child commands have registered. DelegateCommands have to be pointed to their target methods through a delegate at the point where they are constructed. As a result, CompositeCommands allow an extra layer of separation between the source (i.e. toolbar button or menu item) and the target (handling method) – decoupled in lifetime. Because they can target multiple child commands, they also work well for distributed logic such as a Save All command that needs to be dispatched to multiple open documents, each of which has their own handling logic in their view model.

You will see both of these aspects at work in the sample code for this article – separated hook up of the command, and multiple handlers for command execution.

Pub/Sub Events

Another form of loosely coupled communications offered by Prism are pub/sub events. Normal events in .NET are fairly tightly coupled – both the publisher and subscriber objects have to be alive at the same time, the subscriber needs explicit type information and a reference to the publisher to hook up their event handler, and once subscribed, the publisher maintains a reference back to the subscriber through the delegate.

Pub/sub events are designed to break that tight coupling. The idea is that you really want publishers and subscribers to not need either type information or coupled lifetimes. They should be able to come and go independently, and different types of subscribers and publishers should be able to participate in the same event scenario. The event is what is important, not the specific parties who raise or handle the events. To achieve this, you need a middleman or mediator between the publishers and subscribers. The Event Aggregator pattern is a means of achieving this. Prism provides an implementation of the Event Aggregator pattern that is easy to use and that provides several options including strong or weak references for subscribers, thread dispatching, and event filtering.

Figure 2 shows the basic architecture of using the EventAggregator service in Prism. Publishers and Subscribers make calls directly against the EventAggregator to obtain references to event class instances. The EventAggregator is really nothing more than a Registry for event types. Publishers then use those event classes to publish an event with a strongly typed payload and subscribers hook up a listener through a delegate to a method that will accept the payload and handle the event for that subscriber. The event classes are derived from CompositePresentationEvent and do not need any implementation themselves, the class declaration is really just a way to tie together a base class reference with the strongly typed payload through the generic type definition. The CompositePresentationEvent base class provides all the infrastructure to maintain the list of subscribers, dispatch the calls on the appropriate thread, maintain weak or strong references, and filter the calls if desired.

Figure 2: Event Aggregator Architecture

Step 1: Add the Prism Libraries and Recompile for Silverlight 5

The first step for this article is that I downloaded a recently added source code release of Prism 4 from the CodePlex site and added the projects to the solution, as well as changing their compilation target to Silverlight 5. This is because there were a few incompatibilities discovered in using the Silverlight 4 versions of the libraries with Silverlight 5. And I actually stumbled upon one of those incompatibilities in putting together the sample for this article.

Step 2: Modify the application to present multiple edit views

To demonstrate the use of CompositeCommands, I wanted to have a reasonably realistic scenario of where you might use them. As mentioned earlier, CompositeCommands let you separate the hook up of the invoker from the hookup of the receiver in terms of the Command pattern. They also let you have multiple handlers for a given command, to address a Save All kind of scenario, which is what I will be putting together in this article.

To do this, I need more than one thing open at a time to save. I added a TabControl to the MainPage shell view and made it a Prism Region so that multiple CustomerEditView instances could be opened in tabs there instead of swapping out the MainContent region view as was done in the last article.

   1: <sdk:TabControl prism:RegionManager.RegionName="SecondaryContent"

   2:                 Grid.Row="2">

   3:     <prism:TabControlRegionAdapter.ItemContainerStyle>

   4:         <Style TargetType="sdk:TabItem">

   5:             <Setter Property="HeaderTemplate">

   6:                 <Setter.Value>

   7:                     <DataTemplate>

   8:                         <StackPanel Orientation="Horizontal">

   9:                             <TextBlock VerticalAlignment="Center"

  10:                                         Margin="3"

  11:                                         Text="{Binding Title}" />

  12:                             <Button VerticalAlignment="Center"

  13:                                     Margin="3"

  14:                                     Content="X"

  15:                                     Command="{Binding CloseCommand}" />

  16:                         StackPanel>

  17:                     DataTemplate>

  18:                 Setter.Value>

  19:             Setter>

  20:         Style>

  21:     prism:TabControlRegionAdapter.ItemContainerStyle>

  22: sdk:TabControl>

Note the attached property to indicate that this is a Prism Region as discussed in the last two articles, as well as a Style to modify the HeaderTemplate of the TabItems in the TabControl to contain a TextBlock and an X Button to be able to close them. This style gets attached through a custom attached property provided by Prism called TabControlRegionAdapter.ItemContainerStyle. This is needed because the TabControlRegionAdapter is the thing in the Prism toolkit that generates the TabItems as views are added to the region. Also note that the template expects the DataContext to have a Title property for the text in the tab header, as well as a CloseCommand for the button Command. Those will be present on the view models for the individual views which are set as the DataContext based on the MVVM pattern.

To populate the tabs, the EditCommand handling code in the CustomerListViewModel changed to the following:

   1: private void OnEditCustomer()

   2: {

   3:     IRegion secondaryContentRegion = RegionManager.Regions["SecondaryContent"];

   4:     bool alreadyExists = false;

   5:     foreach (var view in secondaryContentRegion.Views)

   6:     {

   7:         var custView = view as CustomerEditView;

   8:         var custViewModel = custView.DataContext as CustomerEditViewModel;

   9:         if (custViewModel.Customer == SelectedCustomer)

  10:         {

  11:             secondaryContentRegion.Activate(view);

  12:             alreadyExists = true;

  13:         }

  14:     }

  15:     if (!alreadyExists)

  16:     {

  17:         CustomerEditView editView = new CustomerEditView();

  18:         CustomerEditViewModel viewModel = new CustomerEditViewModel { Customer = SelectedCustomer };

  19:         editView.DataContext = viewModel;

  20:         secondaryContentRegion.Add(editView);

  21:         secondaryContentRegion.Activate(editView);

  22:     }

  23: }

This code is very similar to what was discussed in the last article – it determines if there is a view already being presented within the “SecondaryContent” region for the selected customer. If so, it activates it. If not, it adds one. The main difference here is that the code is now targeting the SecondaryContent region, which is the tab control, and it allows more than one view to be created at a time.

The structure of the CustomerEditView itself did not change at all, but the CustomerEditViewModel had to change quite a bit. First, it needed to have the Title and CloseCommand properties expected by the tab item headers.

   1: public string Title { get { return _Customer != null ? _Customer.CustomerID : "Empty"; } }

2:

   3: public DelegateCommand CloseCommand { get; private set; }

Second, the CloseCommand handling needs to simply remove its view from the region, not swap views as the SaveCommand handling did from the last article:

   1: private void OnClose()

   2: {

   3:     IRegion secondaryContentRegion = RegionManager.Regions["SecondaryContent"];

   4:     foreach (var view in secondaryContentRegion.Views)

   5:     {

   6:         if (view is CustomerEditView && ((FrameworkElement)view).DataContext == this)

   7:         {

   8:             secondaryContentRegion.Remove(view);

   9:             break;

  10:         }

  11:     }

  12: }

Third, it needed the SaveCommand logic to not swap views but to just manage the “saved” state of the view. In this case, for demo purposes, that meant just modifying the view model to support an IsDirty flag. That flag gets set when the customer is modified (one of its properties change). The flag gets cleared when the SaveCommand fires. Additionally, the SaveCommand was modified to have a CanExecute handler that checks that IsDirty flag. If the view’s state is not dirty, there is no reason to invoke the SaveCommand so its invoker should be disabled.

   1: Customer _Customer;

   2: bool _IsDirty = false;

3:

   4: public CustomerEditViewModel()

   5: {

   6:     SaveCommand = new DelegateCommand(OnSave, CanSave);

   7:     ...

   8: }

9:

  10: public DelegateCommand SaveCommand { get; private set; }

11:

  12: public Customer Customer

  13: {

  14:     get { return _Customer; }

  15:     set

  16:     {

  17:         if (_Customer != value)

  18:         {

  19:             if (_Customer != null) _Customer.PropertyChanged -= OnCustomerChanged;

  20:             _Customer = value;

  21:             if (_Customer != null) _Customer.PropertyChanged += OnCustomerChanged;

  22:             RaisePropertyChanged(() => Customer);

  23:         }

  24:     }

  25: }

26:

  27: public bool IsDirty

  28: {

  29:     get

  30:     {

  31:         return _IsDirty;

  32:     }

  33:     set

  34:     {

  35:         _IsDirty = value;

  36:         SaveCommand.RaiseCanExecuteChanged();

  37:     }

  38: }

39:

  40: private bool CanSave()

  41: {

  42:     return IsDirty;

  43: }

44:

  45: private void OnSave()

  46: {

  47:     IsDirty = false;

  48: }

49:

  50: private void OnCustomerChanged(object sender, PropertyChangedEventArgs e)

  51: {

  52:     IsDirty = true;

  53: }

Notice that the CanSave handler just returns the flag. But since the enablement of the command depends on that flag, that means whenever that flag changes, the command should raise the CanExecuteChanged event. The best way to do that is to encapsulate the call to the DelegateCommand.RaiseCanExecuteChanged method in the setter for the IsDirty property and use that property internally throughout the view model instead of the member variable.

At this point I have the setup to be able to edit multiple customer views at the same time in individual tabs. Next I want to be able to add a “Save All” command invoker at a shell level and have it invoke the SaveCommand on the individual open edit views as shown in Figure 3.

Figure 3: Multiple edit views active in the tab region

Step 3: Add a CompositeCommand for the Save All command

A common way to define a CompositeCommand is similar to how WPF defines the built-in routed commands – as a public static readonly singleton instance of the command. In order for the invoker to be in one module and the handlers to be in different modules, they all need to be able to get to that definition of that command to hook up to it. So you will need to have a common or shared assembly that all the parts of your solution can reference to hold shared types like CompositeCommands and Pub/Sub events.

The sample solution has a Silverlight Class Library project added with a Commands class to contain the CompositeCommand instances you want to define – in this case the SaveAllCommand.

   1: public class Commands

   2: {

   3:     public static readonly CompositeCommand SaveAllCommand = new CompositeCommand();

   4: }

Step 4: Hook up the CompositeCommand Invoker

The invoker is simply a button in the MainPage.xaml:

   1: <Button Content="Save All"

   2:         Command="{Binding SaveAllCommand, RelativeSource={RelativeSource AncestorType=UserControl}}" />

If you are using CompositeCommands in WPF, you can refer directly to the static instance with the {x:Static} markup extension. Because Silverlight does not have that markup extension in the framework, you will have to bind to a property exposed to your XAML. In this case to keep it simple, I expose that property from the code behind of the MainPage view itself and use a RelativeSource binding to get to the root element that corresponds to the code behind class. Then in the code behind I expose the static command variable via the property that the XAML is binding to. Alternatively I could have just hooked up the command in the code behind with a reference to the button.

   1: public ICommand SaveAllCommand { get { return Commands.SaveAllCommand; } }

At this point the invoker is ready to invoke the command, but the button will be disabled because the CompositeCommand, as a container for command instances, is empty. The default logic of CompositeCommand is to be disabled unless all of its child commands are enabled. If there are no child commands, it is disabled because there is nothing to invoke. If you find you want different logic, such as enabling the command if any one of its child commands is enabled, all you need to do is derive a class from CompositeCommand and override the CanExecute method.

Step 5: Hook up the child command instances

As mentioned earlier, CompositeCommand exposes a Register/Unregister API for adding and removing child commands. To add a child command, simply call Register, passing an ICommand reference. Because the CustomerEditViewModel already has a SaveCommand that I want invoked when Save All is invoked, I just need to pass a reference to that in the constructor for the view model:

   1: Commands.SaveAllCommand.RegisterCommand(SaveCommand);

Likewise, when the view is going away (in the CloseCommand handler), you should unregister the command, otherwise the CompositeCommand will keep it, and be indirection, your view model, alive.

   1: private void OnClose()

   2: {

   3:     IRegion secondaryContentRegion = RegionManager.Regions["SecondaryContent"];

   4:     foreach (var view in secondaryContentRegion.Views)

   5:     {

   6:         if (view is CustomerEditView && ((FrameworkElement)view).DataContext == this)

   7:         {

   8:             secondaryContentRegion.Remove(view);

   9:             Commands.SaveAllCommand.UnregisterCommand(SaveCommand);

  10:             break;

  11:         }

  12:     }

  13: }

At this point you should be able to run the application and open several edit views as shown in Figure 3. Initially all of the Save buttons in the edit views as well as the Save All button will be disabled because none of the views are dirty. Go make an edit to each one of the views, and you will see their individual Save button become enabled. With the default CanExecute logic of the CompositeCommand, not until all of the child commands becomes enabled is the CompositeCommand itself enabled. So at the point where you have each of the child views Save enabled through an edit, the Save All button will become enabled. Clicking it invokes the SaveCommand handler in each instance of the CustomerEditViewModel, setting its IsDirty flag to false and raising the CanExecuteChanged handler for that command, which the CompositeCommand will monitor to refresh its own command enabled state.

Step 6: Add an Orders Module

A common usage of pub/sub events is to communicate between loosely coupled module components, particularly from one view model to another, especially if those view models are defined in separate modules. To demonstrate this, I want to add the capability to display the last 10 products ordered by a customer in a side panel whenever a customer is selected. I want this functionality to be decoupled from the customer listing and editing capabilities in the Core module, possibly developed by a separate team or added as a separate pluggable feature of the application.

To do this, I added a new Orders module to the solution following the procedures outlined in the first article for defining a Prism module:

Add a Silverlight Application project
Delete MainPage.xaml and App.xaml
Set the Startup Object in the project settings to Not Set.
Add Prism references, setting the Copy Local property on the references to false so that you don’t get multiple copies of the Prism libraries loaded when the module loads.
Defined an OrdersModule class with a ModuleExport attribute and an implementation of the IModule interface.
Added the Orders module to the Silverlight hosting settings of the Web project so that it is available for download by the module manager in Prism.
Added module information to the ModuleCatalog.xaml in the shell project.

Additionally, since now both the Core module and the Orders module will need to use WCF RIA Services to retrieve data from the back end, it makes sense to move the client WCF RIA Services code out to a shared library so that there is just one definition of the entity types and the DomainContext that lets the client code talk to the server. As a result, I also did the following in the solution:

Removed the RIA Services link from all the client projects.
Added a NorthwindRIAClientLibrary Silverlight Class Library project with the RIA Services link in the project properties set to the hosting web project where the domain services live.
Added a reference to NorthwindRIAClientLibrary to each of the projects, with them all set to Copy Local = false except the reference in the shell application.

Step 7: Add another region for the view to plug into

In MainPage.xaml in the shell application, I added another region named SidePanel to the right of the listing of customers for the order summary to plug into.

   1: <Grid Grid.Row="1">

   2:     <Grid.ColumnDefinitions>

   3:         <ColumnDefinition Width="*" />

   4:         <ColumnDefinition Width="Auto" />

   5:     Grid.ColumnDefinitions>

   6:     <ContentControl prism:RegionManager.RegionName="MainContent"

   7:                     Grid.Column="0"

   8:                     Margin="5" />

   9:     <ContentControl prism:RegionManager.RegionName="SidePanel"

  10:                     Grid.Column="1"

  11:                     Margin="5" />

  12: Grid>

Step 8: Add a View and ViewModel to present the order summary

The view simply contains a DataGrid with three columns: Order date, product name, and quantity. The view model uses WCF RIA Services to retrieve the order information for a given customer and populate a collection of OrderItem data structures to populate the DataGrid with the three columns.

   1: public class OrdersViewModel : INotifyPropertyChanged

   2: {

   3:     CustomersDomainContext _Context;

   4:     public OrdersViewModel()

   5:     {

   6:         if (!DesignerProperties.IsInDesignTool)

   7:         {

   8:             _Context = new CustomersDomainContext();

   9:         }

  10:     }

11:

  12:     ObservableCollection _Orders = new ObservableCollection();

  13:     public ObservableCollection Orders

  14:     {

  15:         get { return _Orders; }

  16:         set

  17:         {

  18:             if (_Orders != value)

  19:             {

  20:                 _Orders = value;

  21:                 PropertyChanged(this, new PropertyChangedEventArgs("Orders"));

  22:             }

  23:         }

  24:     }

25:

  26:     public void OnCustomerSelected(Customer cust)

  27:     {

  28:         Orders = new ObservableCollection();

  29:         if (_Context == null || cust == null)

  30:         {

  31:             return;

  32:         }

33:

  34:         EntityQuery detailQuery = _Context.GetOrder_DetailsQuery();

  35:         _Context.Load(detailQuery.Where(

  36:             det => det.Order.Customer.CustomerID == cust.CustomerID).OrderByDescending(

  37:             det => det.Order.OrderDate).Take(10), OnDetailsLoaded, null);

38:

  39:     }

40:

  41:     private void OnDetailsLoaded(LoadOperation loadOp)

  42:     {

  43:         var details = loadOp.Entities;

  44:         if (details != null)

  45:         {

  46:             var detailsList = details.ToList();

  47:             detailsList.ForEach(det => Orders.Add(

  48:                 new OrderItem

  49:                 {

  50:                     ProductName = det.Product.ProductName,

  51:                     Quantity = det.Quantity,

  52:                     OrderDate = det.Order.OrderDate.Value

  53:                 }));

  54:         }

  55:     }

  56: }

Now the only thing left to do is call the OnCustomerSelected method whenever a Customer is selected in the main listing. But that code lives in a totally separate module that you are trying to keep decoupled. Prism events to the rescue.

Step 9: Add a Prism Event

When working with Prism events, the first thing to do is to declare the event type. You do this by deriving a type from CompositePresentationEvent as described earlier, and indicating through the generic type argument what the payload type will be:

   1: public class CustomerSelectedEvent : CompositePresentationEvent { }

Like the CompositeCommand, this type will need to be referenced by both sides of the communication, even though those two sides need to be decoupled from each other. So this is another one of those types you will want to declare in a shared library that any modules in the solution can reference.

Step 10: Hook up the subscriber

To hook up a subscriber, the subscribing code first needs access to the EventAggregator service in Prism. This is a singleton service like the RegionManager that you can simply obtain by using dependency injection and importing it through the container. Add the following code to the OrdersViewModel:

   1: public OrdersViewModel()

   2: {

   3:     if (!DesignerProperties.IsInDesignTool)

   4:     {

   5:         CompositionInitializer.SatisfyImports(this);

   6:         EventAggregator.GetEvent().Subscribe(OnCustomerSelected);

   7:         _Context = new CustomersDomainContext();

   8:     }

   9: }

10:

  11: [Import]

  12: public IEventAggregator EventAggregator { get; set; }

Because the view model will be constructed in the XAML of the view, the container will not be involved in its construction. To get the container to satisfy the imports in the class, which in this case includes the event aggregator, the CompositionInitializer class can be used. It is put in a guard condition as discussed in a previous article so that the designer does not break since it should not execute that code in the designer.

After the SatisfyImports call, the Import property will be set by the container. So the next line of code can then use that IEventAggregator reference to subscribe. That involves calling the GetEvent() method to get a reference to the event, then calling subscribe on the returned event, which can be done in a single line of code as shown. The Subscribe method just takes an Action delegate, where T is the payload type defined by the event class. The OnCustomerSelected method was shown earlier.

By default, Prism events maintain weak references to the subscribing class method. That means that if all other references to the object go away, the event reference will not keep it alive. This solves a lot of memory leak issues where you either forget or it is difficult to know where in the code to do the Unsubscribe call. If you want the event subscription to keep the object alive, there is an overload to the Subscribe method with a keepSubscriberReferenceAlive bool parameter.

Additionally, by default the event publication will happen synchronously using the publisher’s thread. If you want control over what thread is used to call the target method pointed to by the Subscribe call, you can use another overload that takes a ThreadOption with three choices: use the Publisher’s thread (the default), use the UI thread, or use a background thread from the thread pool.

Finally, there is an overload that also allows you to pass a Predicate delegate for filtering purposes. This allows you to pass a lambda expression or point to a method that returns a boolean. The method or lambda will be passed the payload object of the event. It can use that to decide whether to return true or false. True means to call the subscription method, false means don’t.

Step 11: Publish the event

To publish a Prism event, it is just as simple as subscribing. you first need a reference to the EventAggregator service, which you get through dependency injection as shown earlier. Then you publish at the appropriate point in your code calling the Publish method on the event returned from the same GetEvent() method shown earlier:

   1: EventAggregator.GetEvent().Publish(_SelectedCustomer);

Summary

In this article, you saw how to define multiple modules that can communicate with each other through a combination of CompositeCommands and Prism events. CompositeCommands let you have handlers registered or unregistered in a loosely coupled fashion, and allows you to have multiple handlers (child commands) that will be used by the CompositeCommand. Prism events are for situations that are not necessarily an action->reaction kind of set up where enablement and disablement is needed. You simply define the event type with its strongly typed payload and then subscribe or publish by obtaining the event reference through the EventAggregator. Both of these mechanisms give you a really powerful combination for having loosely coupled communications between composite parts of your application.

You can download the finished code from this article here.

About the Author

Working with Prism 4 Part 2: MVVM Basics and Commands

editorial@silverlightshow.net (Brian Noyes ) — Mon, 21 Nov 2011 00:13:00 GMT

This is Part 2 in the series Working with Prism 4.

Introduction

In the first part of this series, I introduced you to the concepts of Prism 4 – what the toolkit is for, as well as what the top level features are. Additionally, I stepped through the basic setup of getting a Prism application up and running – creating the shell project, a module, declaring a region in the shell, and plugging a view into that region from the module.

More resources...

All SilverlightShow Ebooks

In this article, I will flesh out that application a little more and show you some of the basic support for the Model-View-ViewModel (MVVM) pattern that Prism has, as well as how to use the DelegateCommand type that Prism provides, which fits well with MVVM scenarios. An important thing to understand is that Prism is not first-and-foremost an MVVM framework. It is a toolkit for building composite applications, which may or may not choose to use the MVVM pattern. As a result, there is not a ton of framework infrastructure provided in Prism that is specifically focused on MVVM. There are other good toolkits out there, such as the MVVM Light or Caliburn Micro toolkits that can be used in conjunction with Prism or instead of Prism if your primary goal is just to put together an MVVM application. However, I have found the combination of features of Prism for composition and MVVM to be more than sufficient for many big and small real world applications, so I usually just use Prism on its own without mixing in other toolkits, and I will keep the focus just on Prism in these articles.

This article will build on the sample application developed in Part 1. You can download the starting point code from Part 1 here. You can download the finished sample for this article here.

MVVM Basics

I don’t intend this article to be a starting point for learning the MVVM pattern. There are many other good resources out there for that, including the excellent article by Josh Smith and the two chapters we wrote in the Prism book which is also available online in various electronic forms. But just so you don’t have to go brush up on MVVM too much to follow along with what I will show in this article, here are the key essentials.

MVVM is a UI separation pattern for keeping the structural aspects of the UI (the XAML elements that you see on the screen) separated from the state and logic that supports that view. The view is just the structure of what you see on the screen. It may contain some dynamic elements such as animations, but it has no logic defining the behavior of the application from a user interaction perspective. Ideally in an MVVM application, there is no code in the code-behind class of a XAML view, just the constructor with its InitializeComponent method call. The state (data) that is presented in the view is provided and manipulated by the view model, and interactions from the user such as selections, button presses, etc. are handled in the view model. The data that the user interacts with is stored in the model, which may not structure the data exactly as it is shown on the screen. The model data structures should be chosen based on the needs of the application as a whole. Another responsibility of the view model is to transform, as necessary, the data from the way the model wants to store and manipulate it to the shape that the view wants to see the data in.

The basic structure of MVVM is that the view’s DataContext property at the root of the view will be set to an instance of the view model (View.DataContext = ViewModel). There is typically a 1:1 relationship of the class defined for the view and the class defined for the view model – for example a CustomerListView will have a CustomerListViewModel. But there are situations where one view model definition might support more than one view or vice versa. But at runtime, the view’s DataContext gets set to a reference to some view model instance that will provide its data and interaction logic. There are many ways the DataContext of the view can get set to an instance of a view model. In this article I will just focus on a couple of those, specifically hooking them up statically from the XAML of the view or using DataTemplates. But you can find many other variants out there in samples of ways to get the two hooked up to one another.

To hook up a view to its view model statically from the XAML, you simply create an instance of it in the XAML like the following snippet:

   1: <UserControl x:Class="Prism101.Modules.Core.CustomerListView"

   2:              ...

   3:              xmlns:local="clr-namespace:Prism101.Modules.Core" ...>

   4:     <UserControl.DataContext>

   5:         <local:CustomerListViewModel />

   6:     UserControl.DataContext>

To use a DataTemplate to get them hooked up, you bind something in a parent view (typically a ContentControl or ItemsControl) to an instance of the view model whose view you want to render. Then you define a data template in the resources of the parent view that ties the view and view model together, and through the way DataTemplates work, sets the DataContext of the rendered view to the bound instance of the view model.

   1: <UserControl x:Class="Prism101.Modules.Core.ParentView"

   2:              ...

   3:              xmlns:local="clr-namespace:Prism101.Modules.Core"

   4:              ...>

   5:     <UserControl.Resources>

   6:         <DataTemplate DataType="local:CustomerListViewModel">

   7:             <local:CustomerListView />

   8:         DataTemplate>

   9:     UserControl.Resources>

  10:     <Grid x:Name="LayoutRoot" Background="White">

  11:         <ContentControl Content="{Binding ChildViewModel}" />

  12: ...

Commanding Basics

Commands in WPF and Silverlight are based on the Gang of Four Command design pattern. With commands you have an invoker and a receiver and some infrastructure in between to keep those two parties decoupled from one another as much as possible. The invoker is typically a UI element of some sort like a button, menu, or possibly a ComboBox selection. The receiver is the handling code that takes some action based on the command being invoked. With traditional code-behind event handling of UI control events, the event handling code represented that receiver code, but it was tightly coupled to the UI element event and had to be co-located in the code behind of the view to work. With commands, particularly with the support of bindings in WPF and Silverlight, and with dependency injection support in Prism, you can have the command invoker and receiver be very loosely coupled from one another – often defined in separate modules that have no references to one another or knowledge of each other’s presence.

Prism has two command types I’ll be covering in this series: the DelegateCommand type which is perfect for hooking up interaction logic between an MVVM view and its view model, and the CompositeCommand, which supports more loosely coupled, cross-module kinds of communication. Both are implementations of the ICommand interface defined in WPF and Silverlight, which defines three members: an Execute method, a CanExecute method, and a CanExecuteChanged event. The Execute method is the crux of the ICommand interface, it is what will be invoked whenever the invoker element has the triggering action happen to it (i.e. a button is clicked that has a command hooked up to it). The CanExecute method can be optionally hooked up to conditionally say whether the associated invoker should be enabled or not – for example if a document is not dirty, the Save command should be disabled. The associated CanExecuteChanged event is a way for the supporting logic that determines whether the command should be enabled to notify the invoker that it should re-evaluate the CanExecute state of the command and update the UI appropriately as things are changing behind the scenes (i.e. the document just went dirty because the user input some text or some other formatting command was invoked on the document that the Save command relates to).

Step 1: Getting Some Data Into the Application

Message boxes and Hello World prompts can only keep your attention for so long. So the first thing I am going to do is to use some Northwind data to add a little more real world structure to the application that I will be expanding on in this article. The sample code for this article includes a SQL script for creating the Northwind DB on your machine (assumes you have SQL Server on your machine in one of its forms). Additionally, the sample code has a WCF RIA Services domain service added to the host Web project to make it easy to retrieve and update the Northwind data from the Silverlight sample application. I am not going to go into any detail on the structure of how to do that since I have covered it in detail in my article series on WCF RIA Services here.

The steps I followed for the Silverlight sample application here is as follows:

Ran the SQL script to create a clean copy of the Northwind database on my machine.
Added an ADO.NET Entity Data Model to the Prism101.Web project from the Data project item templates in the Add New Item dialog, using the Database-first model approach to generate an entity framework model including the Customers, Orders, and Order Details tables from the Northwind database.
Build the project so that the next step will see the EF model.
Add a Domain Service Class to the Prism101.Web project from the Web project item templates in the Add New Item dialog, naming it CustomersDomainService. In the wizard, I selected those same three tables from the entity model.
Build the project so that it code generates the client side support for consuming the domain service and the client side entity types.

Step 2: Creating a CustomerListView

To get started with some MVVM views, I will replace the WelcomeView view that was plugged in from the Core module in the last article with a CustomerListView with a supporting view model.

In the Prism101.Modules.Core project, add a new Silverlight User Control to the project and name it CustomerListView. With the designer showing in the editor, bring up the Data Sources window (Data menu, Show Data Sources). This allows you to code generate user interface controls and have the bindings for them set up (at least partially) from data types in your application. I wrote about these features in details in my book Data Binding with Windows Forms 2.0 a long time ago, but you can find a more recent coverage in this Hands on Lab from Microsoft for WPF.

After a moment, if you have done the steps in Step 1, you should see the Data Sources window populate with the Customer, Order, and Order_Detail types.

If you drag and drop the Customer type from this window into the Grid in the designer, it will code generate a DataGrid with the appropriate columns based on the properties of the Customer entity. Because these entities are generated by RIA Services, it will also add some additional stuff into the XAML that I stripped out to transform it into an MVVM structure, specifically a DomainDataSource. I did some other clean up in the sample code to reorder the columns from the order they were generated in. But after the cleanup, the XAML looks like that shown in the following code listing.

   1: <UserControl x:Class="Prism101.Modules.Core.CustomerListView"

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

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

   4:              xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

   5:              xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

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

   7:              mc:Ignorable="d"

   8:              d:DesignHeight="300"

   9:              d:DesignWidth="400">

  10:     <Grid x:Name="LayoutRoot" Background="White">

  11:         <sdk:DataGrid ItemsSource="{Binding Customers}"

  12:                       AutoGenerateColumns="False"

  13:                       Name="customerDataGrid"

  14:                       RowDetailsVisibilityMode="VisibleWhenSelected">

  15:             <sdk:DataGrid.Columns>

  16:                 <sdk:DataGridTextColumn x:Name="customerIDColumn"

  17:                                         Binding="{Binding Path=CustomerID, Mode=OneWay}"

  18:                                         Header="Customer ID"

  19:                                         IsReadOnly="True"

  20:                                         Width="SizeToHeader" />

  21:                 <sdk:DataGridTextColumn x:Name="companyNameColumn"

  22:                                         Binding="{Binding Path=CompanyName}"

  23:                                         Header="Company Name"

  24:                                         Width="SizeToHeader" />

  25:                 <sdk:DataGridTextColumn x:Name="contactNameColumn"

  26:                                         Binding="{Binding Path=ContactName}"

  27:                                         Header="Contact Name"

  28:                                         Width="SizeToHeader" />

  29:                 <sdk:DataGridTextColumn x:Name="contactTitleColumn"

  30:                                         Binding="{Binding Path=ContactTitle}"

  31:                                         Header="Contact Title"

  32:                                         Width="SizeToHeader" />

  33:                 <sdk:DataGridTextColumn x:Name="phoneColumn"

  34:                                         Binding="{Binding Path=Phone}"

  35:                                         Header="Phone"

  36:                                         Width="SizeToHeader" />

  37:                 <sdk:DataGridTextColumn x:Name="faxColumn"

  38:                                         Binding="{Binding Path=Fax}"

  39:                                         Header="Fax"

  40:                                         Width="SizeToHeader" />

  41:                 <sdk:DataGridTextColumn x:Name="addressColumn"

  42:                                         Binding="{Binding Path=Address}"

  43:                                         Header="Address"

  44:                                         Width="SizeToHeader" />

  45:                 <sdk:DataGridTextColumn x:Name="cityColumn"

  46:                                         Binding="{Binding Path=City}"

  47:                                         Header="City"

  48:                                         Width="SizeToHeader" />

  49:                 <sdk:DataGridTextColumn x:Name="countryColumn"

  50:                                         Binding="{Binding Path=Country}"

  51:                                         Header="Country"

  52:                                         Width="SizeToHeader" />

  53:                 <sdk:DataGridTextColumn x:Name="postalCodeColumn"

  54:                                         Binding="{Binding Path=PostalCode}"

  55:                                         Header="Postal Code"

  56:                                         Width="SizeToHeader" />

  57:             sdk:DataGrid.Columns>

  58:         sdk:DataGrid>

  59:     Grid>

  60: UserControl>

You can see that the code just contains a DataGrid and its columns for the properties of a Customer. I’ve modified it to assume that the DataContext of the view has a property called Customers that the DataGrid.ItemsSource property is bound to. There is also a Loaded event handler for the DomainDataSource that is added into the code behind of the view from the Data Sources window drag/drop operation that I stripped out after deleting the DomainDataSource.

Step 3: Replace WelcomeView with CustomerListView

Open the CoreModule class in the Prism101.Modules.Core project and replace the creation of the WelcomeView with the CustomerListView.

   1: public void Initialize()

   2: {

   3:     var view = new CustomerListView();

   4:     RegionManager.AddToRegion("MainContent", view);

   5: }

You can now delete the WelcomeView.xaml from that project. You should be able to build and run at this point and see that the grid shows up in the MainContent region in the shell now instead of the Hello Prism of the WelcomeView. This helps to emphasize that when using regions in Prism, the hosting view that contains a region does not need to be touched to completely alter its content, you just change what is being plugged into that container.

Step 4: Add a View Model

Add a class named CustomerListViewModel to the Prism101.Modules.Core project. Add the following code to that class.

   1: public class CustomerListViewModel : NotificationObject

   2: {

   3:     CustomersDomainContext _Context = new CustomersDomainContext();

   4:     IEnumerable _Customers;

5:

   6:     public CustomerListViewModel()

   7:     {

   8:         if (!DesignerProperties.IsInDesignTool)

   9:         {

  10:             _Context.Load(_Context.GetCustomersQuery(), OnLoadComplete, null);

  11:         }

  12:     }

13:

  14:     public IEnumerable Customers

  15:     {

  16:         get { return _Customers; }

  17:         set

  18:         {

  19:             if (_Customers != value)

  20:             {

  21:                 _Customers = value;

  22:                 RaisePropertyChanged(() => Customers);

  23:             }

  24:         }

  25:     }

26:

  27:     private void OnLoadComplete(LoadOperation loadOp)

  28:     {

  29:         if (loadOp.HasError)

  30:         {

  31:             MessageBox.Show(loadOp.Error.Message);

  32:             loadOp.MarkErrorAsHandled();

  33:             return;

  34:         }

  35:         Customers = _Context.Customers;

  36:     }

  37: }

The view model provides the Customers collection of data that the view wants to bind to. It does that by having WCF RIA Services make a call to the back end and load the customer data using the CustomersDomainContext that is a member of the view model, then exposes the resulting customer data through a property on the view model that the view will bind to. The CustomersDomainContext is part of the code generated client code for RIA Services that acts as a proxy to the server side domain service. You can see that the Load call is an asynchronous service calls with a callback hooked up to the OnLoadComplete method to handle errors and to populate the Customers collection property once the call is complete.

There are a couple of important things to point out about this code. One is that in the next step I will be hooking this view model up to the view statically. That means it will get created in the designer as well. The WCF RIA Service calls to load data are not going to work in the designer. Often you will have things in your view model initialization or construction that will break the designer. To guard against this, you can use the DesignerProperties class to avoid executing that code if you are in the designer. So the call to the CustomerDomainContext.Load method is only done at runtime, not at design time.

Another is to notice the base class that I added to the view model class – NotificationObject. This is a base class that Prism provides that encapsulates the implementation of the INotifyPropertyChanged interface, which is important for your view models to support for the properties they expose. The base class exposes several overloaded RaisePropertyChanged methods you can call from your property set{} blocks to make sure that bindings in the view are refreshed when the underlying properties change. The call to RaisePropertyChanged in the Customers property set{} block shows that the Prism base class supporting using strongly typed lambda expressions to point to the property (Customers) itself, instead of using a string for the name of the property as is normally done when raising the PropertyChanged event directly. This makes the code more maintainable because refactoring the property name will update the RaisePropertyChanged calls as well. If declared as a string, it may not be picked up depending on what refactoring tools you use.

Step 5: Hook the view up to the view model

Add a XAML namespace to the CustomerListView so it has access to the types in its own assembly:

   1: xmlns:local="clr-namespace:Prism101.Modules.Core"

Then set the DataContext of the view in the XAML to an instance of the view model as shown earlier:

   1: <UserControl.DataContext>

   2:     <local:CustomerListViewModel />

   3: UserControl.DataContext>

You should now be able to run and see the data pop into the view after the asynchronous call completes.

This structuring of view and view model is often referred to as “view-first”, because the view is constructed, and then it constructs and wires up its own view model (either from XAML as done here or from code behind). View-first has advantages of simplicity as well as the fact that you can leverage the design time data support of Visual Studio and Expression Blend.

Step 6: Adding an Edit Command

To demonstrate using DelegateCommands to hook up communication between our view and view model for some interaction logic as well as navigating to another view using regions, I will modify the CustomerListView slightly to add an Edit button to the top of the form.

The XAML for the button looks like this.

   1: <Button Content="Edit"

   2:         Command="{Binding EditCustomerCommand}"

   3:         Height="23"

   4:         HorizontalAlignment="Left"

   5:         VerticalAlignment="Top"

   6:         Width="75" />

Notice the binding on the Command property assumes there is a property on the DataContext (the view model) named EditCustomerCommand. Buttons in Silverlight and WPF have a Command property that can point to an instance of an ICommand object. If that is hooked up, the button will be enabled or disabled based on calls to the CanExecute method of the ICommand interface as described earlier. Additionally, when the button is clicked, it will call the Execute method of the ICommand object.

Rather than implementing ICommand directly on an object, a common approach is to use an intermediary class that implements ICommand to dispatch the calls to target methods on some other object, which in this case will be our view model. The first command type that Prism provides is the DelegateCommand class. To add this support, first we declare the property that the button Command binding points to in the CustomerListViewModel class, passing the target Execute and CanExecute handling methods through delegate inference to the constructor.

   1: public DelegateCommand EditCustomerCommand { get; private set; }

Next we populate that property in the constructor of the view model class:

   1: public CustomerListViewModel()

   2: {

   3:     EditCustomerCommand = new DelegateCommand(OnEditCustomer, CanEditCustomer);

   4:     ...

   5: }

Then we define the handling method that those point to.

   1: private bool CanEditCustomer()

   2: {

   3:    return true;

   4: }

5:

   6: private void OnEditCustomer()

   7: {

   8: }

At this point you should be able to build and run, set a breakpoint in the OnEditCustomer method and see that your command handler is being called. Because right now the CanEditCustomer method returns true, the command will always be enabled. I will remedy that shortly.

Step 7: Pushing selection state into the view model

An important aspect of user interaction is selection in the view. But as mentioned before, in an MVVM design, all state and state manipulation should happen in the view model, not in the view. So when the user selects something in the view, the view model needs to know about it so it can take any appropriate action at that point, as well as making that selection available to command handling logic like our edit command.

Add the following property to the CustomerListViewModel.

   1: Customer _SelectedCustomer;

   2: public Customer SelectedCustomer

   3: {

   4:     get { return _SelectedCustomer; }

   5:     set

   6:     {

   7:         if (_SelectedCustomer != value)

   8:         {

   9:             _SelectedCustomer = value;

  10:             RaisePropertyChanged(() => SelectedCustomer);

  11:             EditCustomerCommand.RaiseCanExecuteChanged();

  12:         }

  13:     }

  14: }

Notice that in addition to doing raising the PropertyChanged event through the base class RaisePropertyChanged method, whenever the selected customer changes, the code makes a call to the EditCustomerCommand.RaiseCanExecuteChanged method. This causes the CanExecuteChanged event of the DelegateCommand’s implementation of ICommand to fire, which causes any command invoker such as our Edit button to update its enabled state by calling CanExecute again.

Change the CanEditCustomer method to the following.

   1: private bool CanEditCustomer()

   2: {

   3:     if (SelectedCustomer == null) return false;

   4:     else return true;

   5: }

Finally, on the DataGrid in the view, bind the SelectedItem property to the SelectedCustomer property in the view model.

   1: <sdk:DataGrid ItemsSource="{Binding Customers}"

   2:               SelectedItem="{Binding Path=SelectedCustomer, Mode=TwoWay}" .../>

As a result of this change, the Edit button will now be disabled if there is no selection in the DataGrid. One the user selects a row in the DataGrid, the SelectedItem binding will push a reference to that Customer bound object into the SelectedCustomer property in the view model. That will fire the CanExecuteChanged event on the command, which will cause the button to requery CanExecute, and it will enable the button since the SelectedCustomer will no longer be null at that point.

Step 8: Define an edit view to switch to

As you have already seen with the MainContent region in Part 1, regions in Prism allow you to plug a view into a parent view’s region for presentation. This can be used to logically navigate the user from view to view. What I want to do when the edit command is invoked is to swap out the main view from presenting a list of customers to one that presents an edit form for the selected customer. To do this, I can just plug another view into the MainContent region, replacing the list view as the active view.

A region is a logical container for a collection of views that can be presented within that region. You can add multiple views into the region, and depending on what kind of control the region is, it can present those views either one at a time or all at once. So far I am using a ContentControl in the MainPage.xaml shell view as the MainContent region. A ContentControl can only have a single child element as its Content at one time. But the Prism IRegion abstraction can keep track of a collection of views and set the appropriate view as the Content for that control when you tell it to. This concept is called activating a view in a region in Prism. The thing that actually maps the abstract region to a concrete container control is called a region adapters. There are built in region adapters supporting ContentControl, ItemsControl, and Selector controls in Prism.

To switch to the edit view for a customer, we first have to have one. I won’t go through all the details of defining the CustomerEditView, that is Silverlight basics and is similar to what I described earlier for creating the CustomerListView. Instead of dragging and dropping the Customer type from the Data Sources window with the default settings, you drop down the selection on the Customer type in that window and select Details. Then when you do the drag and drop onto the designer, it generates a data form for a single instance of the type instead of a data grid for a collection of the type. I again trimmed out the DomainDataSource that is added in that operation and patched up the bindings to expect a Customer property exposed from the view’s DataContext (view model) once it is hooked up.

Notice the Button at the bottom of the listing that is bound to a SaveCommand property it also expects to be exposed from the view model. I will hook that up once I get to defining the view model for this view in the next step. Also notice that in this case I did not wire up the view model as the DataContext from the XAML. I will do that programmatically for this sample when the Edit command is invoked in the listing view.

   1: <UserControl x:Class="Prism101.Modules.Core.CustomerEditView"

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

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

   4:              xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

   5:              xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

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

   7:              mc:Ignorable="d"

   8:              d:DesignHeight="212"

   9:              d:DesignWidth="301">

  10:         <Grid x:Name="LayoutRoot"

  11:           Background="White">

12:

  13:         <Grid DataContext="{Binding Customer}"

  14:               HorizontalAlignment="Left"

  15:               Margin="12,12,0,0"

  16:               Name="grid1"

  17:               VerticalAlignment="Top"

  18:               Width="272">

  19:             <Grid.ColumnDefinitions>

  20:                 <ColumnDefinition Width="Auto" />

  21:                 <ColumnDefinition Width="Auto" />

  22:                 <ColumnDefinition Width="5*" />

  23:             Grid.ColumnDefinitions>

  24:             <Grid.RowDefinitions>

  25:                 <RowDefinition Height="Auto" />

  26:                 <RowDefinition Height="Auto" />

  27:                 <RowDefinition Height="Auto" />

  28:                 <RowDefinition Height="Auto" />

  29:             Grid.RowDefinitions>

  30:             <sdk:Label Content="Company Name:"

  31:                        Grid.Column="0"

  32:                        Grid.Row="0"

  33:                        HorizontalAlignment="Left"

  34:                        Margin="3"

  35:                        VerticalAlignment="Center" />

  36:             <TextBox Grid.Column="1"

  37:                      Height="23"

  38:                      HorizontalAlignment="Left"

  39:                      Margin="3,3,0,3"

  40:                      Name="companyNameTextBox"

  41:                      Text="{Binding Path=CompanyName, Mode=TwoWay, NotifyOnValidationError=true, ValidatesOnExceptions=true, TargetNullValue=''}"

  42:                      VerticalAlignment="Center"

  43:                      Width="164" />

  44:             <sdk:Label Content="Contact Name:"

  45:                        Grid.Column="0"

  46:                        Grid.Row="1"

  47:                        HorizontalAlignment="Left"

  48:                        Margin="3"

  49:                        VerticalAlignment="Center" />

  50:             <TextBox Grid.Column="1"

  51:                      Grid.Row="1"

  52:                      Height="23"

  53:                      HorizontalAlignment="Left"

  54:                      Margin="3,3,0,3"

  55:                      Name="contactNameTextBox"

  56:                      Text="{Binding Path=ContactName, Mode=TwoWay, NotifyOnValidationError=true, ValidatesOnExceptions=true, TargetNullValue=''}"

  57:                      VerticalAlignment="Center"

  58:                      Width="164" />

  59:             <sdk:Label Content="Contact Title:"

  60:                        Grid.Column="0"

  61:                        Grid.Row="2"

  62:                        HorizontalAlignment="Left"

  63:                        Margin="3"

  64:                        VerticalAlignment="Center" />

  65:             <TextBox Grid.Column="1"

  66:                      Grid.Row="2"

  67:                      Height="23"

  68:                      HorizontalAlignment="Left"

  69:                      Margin="3,3,0,3"

  70:                      Name="contactTitleTextBox"

  71:                      Text="{Binding Path=ContactTitle, Mode=TwoWay, NotifyOnValidationError=true, ValidatesOnExceptions=true, TargetNullValue=''}"

  72:                      VerticalAlignment="Center"

  73:                      Width="164" />

  74:             <sdk:Label Content="Phone:"

  75:                        Grid.Column="0"

  76:                        Grid.Row="3"

  77:                        HorizontalAlignment="Left"

  78:                        Margin="3"

  79:                        VerticalAlignment="Center" />

  80:             <TextBox Grid.Column="1"

  81:                      Grid.Row="3"

  82:                      Height="23"

  83:                      HorizontalAlignment="Left"

  84:                      Margin="3,3,0,3"

  85:                      Name="phoneTextBox"

  86:                      Text="{Binding Path=Phone, Mode=TwoWay, NotifyOnValidationError=true, ValidatesOnExceptions=true, TargetNullValue=''}"

  87:                      VerticalAlignment="Center"

  88:                      Width="164" />

  89:         Grid>

  90:         <Button Content="Save"

  91:                 Command="{Binding SaveCommand}"

  92:                 Height="23"

  93:                 HorizontalAlignment="Left"

  94:                 Margin="162,134,0,0"

  95:                 VerticalAlignment="Top"

  96:                 Width="75" />

  97:     Grid>

  98: UserControl>

Step 9: Define the CustomerEditViewModel

When you define a view like the edit view, you quickly identify what properties are needed from your view model to support the view, in this case a Customer property and a SaveCommand property. Add a CustomerEditViewModel class to the project and add the following contents to it.

   1: public class CustomerEditViewModel : NotificationObject

   2: {

   3:     public CustomerEditViewModel()

   4:     {

   5:         SaveCommand = new DelegateCommand(OnSave);

   6:     }

7:

   8:     public DelegateCommand SaveCommand { get; private set; }

9:

  10:     Customer _Customer;

  11:     public Customer Customer

  12:     {

  13:         get { return _Customer; }

  14:         set

  15:         {

  16:             if (_Customer != value)

  17:             {

  18:                 _Customer = value;

  19:                 RaisePropertyChanged(() => Customer);

  20:             }

  21:         }

  22:     }

23:

  24:     private void OnSave()

  25:     {

  26:     }

  27: }

Step 10: Switch to the edit view when the Edit command executes

As you learned in Part 1, the RegionManager service provides the mechanism for plugging views into regions. That means if you are going to switch to the edit view from the list view model, you will need access to that service there. To gain access, you can leverage dependency injection through MEF in your view model. Add the following property declaration in the CustomerListViewModel.

   1: [Import]

   2: public IRegionManager RegionManager { get; set; }

This view model gets constructed from the XAML of the view, so the container is not involved and can’t do the dependency injection automatically. But thanks to the CompositionInitializer class, you can ask the container to do the injection as the view model gets constructed explicitly. Add line 7 in the the following code to the constructor of the CustomerListViewModel.

   1: public CustomerListViewModel()

   2: {

   3:     EditCustomerCommand = new DelegateCommand(OnEditCustomer, CanEditCustomer);

   4:     if (!DesignerProperties.IsInDesignTool)

   5:     {

   6:         _Context.Load(_Context.GetCustomersQuery(), OnLoadComplete, null);

   7:         CompositionInitializer.SatisfyImports(this);

   8:     }

   9: }

That will get the IRegionManager reference injected (the set block of the property will be called to provide the reference) by the container. However, to make sure there is a single container used by both Prism and the CompositionInitializer class, you need to add one more overload to the Bootstrapper class in the Prism101 shell project.

   1: protected override CompositionContainer CreateContainer()

   2: {

   3:     var container = base.CreateContainer();

   4:     CompositionHost.Initialize(container);

   5:     return container;

   6: }

This makes it so the container that Prism sets up is the one that is used by the CompositionHost that sits underneath the CompositionInitializer class.

Now you are ready to actually do the view switching with the region manager. Modify the OnEditCustomer code with the following.

   1: private void OnEditCustomer()

   2: {

   3:     IRegion mainContentRegion = RegionManager.Regions["MainContent"];

   4:     bool alreadyExists = false;

   5:     foreach (var view in mainContentRegion.Views)

   6:     {

   7:         if (view is CustomerEditView)

   8:         {

   9:             CustomerEditViewModel viewModel = ((FrameworkElement)view).DataContext as CustomerEditViewModel;

  10:             viewModel.Customer = SelectedCustomer;

  11:             mainContentRegion.Activate(view);

  12:             alreadyExists = true;

  13:         }

  14:     }

  15:     if (!alreadyExists)

  16:     {

  17:         CustomerEditView editView = new CustomerEditView();

  18:         CustomerEditViewModel viewModel = new CustomerEditViewModel { Customer = SelectedCustomer };

  19:         editView.DataContext = viewModel;

  20:         mainContentRegion.Add(editView);

  21:         mainContentRegion.Activate(editView);

  22:     }

  23: }

If you look at what this code is doing, first it obtains a reference to the IRegion reference for the MainContent region. Then it loops through the Views collection exposed on the region to see if it contains an instance of a CustomerEditView. That would be the case if the user had already switched to the edit view at least once before. If so, it obtains a reference to the view model for that view by casting the DataContext of the view. Remember that in MVVM, View.DataContext = ViewModel. Once it has the view model reference, it can push the reference to the selected customer into the Customer property of the edit view model. Finally in that case it calls Activate on the region to get that as the currently presented view.

If the view was not in the Views collection, it simply constructs a new instance and goes through a similar process, first calling Add before Activate. This chunk of code should only execute the first time the edit view is visited, because the region will cache the reference to the edit view in its Views collection.

One thing to point out here is that I am kind of violating the principles of MVVM by explicitly constructing the CustomerEditView type in the list view model. Typically if you were going to do it this way you would factor this code out to a Controller that managed multiple views and their view models and use a CompositeCommand to hook things up. I’ll show that kind of structure in the next article, and in a later one I’ll highlight the newer navigation features of Prism regions that were added in Prism 4 as an even more decoupled way to switch views. But for now I wanted to show the basic view switching mechanisms of Prism regions and not have too many moving parts, so I am sacrificing a little bit of view model cleanliness for compactness for writing purposes here.

Once you have this code in place, you should be able to build, fire up the application, select a Customer in the grid, press the Edit button and have the main view’s content switch to the edit form.

The last piece for this article is to hook up the Save button in the edit form so that it can at least switch back to the main form. That means you need access to the region manager from that view model as well. The code there is very similar:

Add an Import property for the IRegionManager
Call CompositionInitializer.SatifyImports from the constructor in a guard clause checking to see if you are in the designer
Use the region manager to activate the list view in the region

The following code shows those changes to the CustomerEditViewModel.

   1: [Import]

   2: public IRegionManager RegionManager { get; set; }

3:

   4: public CustomerEditViewModel()

   5: {

   6:     SaveCommand = new DelegateCommand(OnSave);

   7:     if (!DesignerProperties.IsInDesignTool)

   8:     {

   9:         CompositionInitializer.SatisfyImports(this);

  10:     }

  11: }

12:

  13: private void OnSave()

  14: {

  15:     IRegion mainContentRegion = RegionManager.Regions["MainContent"];

  16:     foreach (var view in mainContentRegion.Views)

  17:     {

  18:         if (view is CustomerListView)

  19:         {

  20:             mainContentRegion.Activate(view);

  21:         }

  22:     }

  23: }

At this point you have a simple but functioning example of an MVVM Prism application that uses a bit of view model base class infrastructure that Prism provides in the NotificationObject base class, DelegateCommands to communicate from the view to the view model, and regions to do the switching of views in the main window.

Summary

You can see that it is not a lot of code, nor a lot of complexity that Prism provides with respect to MVVM and commanding, but it provides the common pieces you need for a clean MVVM application. There is no built in implementation of the ICommand interface in Silverlight, so it provides the DelegateCommand to step in nicely for hooking up views to view model logic. There are other discrete pieces of functionality related to MVVM that Prism supports. I’ll touch on some of those when we get to the navigation services in Prism in a later article. There are also features like the DataTemplateSelector capabilities, which are not as necessary in Silverlight 5 with the addition of implicit data templates, but can still come in handy in other scenarios. Another piece is the interaction request capabilities that allow you to be more decoupled in your view model and not directly present pop ups but leave it up to the view to decide what the appearance of the notification to a user looks like.

In the next article I will expand on the communication by looking at CompositeCommands and loosely coupled events in Prism. You can download the completed code for this article here.

About the Author

Working with Prism 4 Part 1: Getting Started

editorial@silverlightshow.net (Brian Noyes ) — Mon, 07 Nov 2011 08:15:00 GMT

This is Part 1 in the series Working with Prism 4.

Introduction

Prism is a toolkit produced by Microsoft patterns & practices to aid you in building Silverlight and WPF composite applications.

More resources...

All SilverlightShow Ebooks

Now, that probably doesn’t tell you much unless you have been building composite applications with other toolkits or frameworks and know what that term really means, so let me expand on what that means and what the real purpose of Prism is to get started.

A composite application can be thought of as the opposite of a monolithic application. I can hear you thinking now: “Ah, now I see. I know monolithic applications are bad, therefore composite applications must be good. Yin/Yang, Dark/Light. I need to check this out!” Or at least that is what I hope you are thinking. Composite applications are built from more granular, loosely coupled parts. Two of the primary reasons for approaching application development in a composite way are for maintainability and extensibility. If your application is composed of fine grained, well-focused, loosely coupled parts, it should be easier to develop and easier to maintain and add new functionality over time. Things like the code that defines the structure of your user interface (XAML in Silverlight, WPF, and Metro), the code that supports the interaction logic with the user (view models in the MVVM pattern), the data structures and logic (the model in MVVM), and services that provide shared functionality for service or data access in your application are examples of things that are better separated into parts rather than getting all woven together in spaghetti code. The fact that building composite applications will help you with maintainability is a little hard to prove up front, but the over 50,000 downloads of Prism 4 should tell you that there are a lot of companies out there that get this and like Prism as a toolkit for building apps that way.

To get more specific, Prism has a number of specific feature sets that I will explore in this series that helps you to build your client application as a composite application. These include:

Modularity – Functionality to define and dynamically load chunks of loosely coupled functionality into a single running application instance.
UI Composition – Functionality to plug in views into parent containers in a loosely coupled fashion where the parent and child do not need to know explicitly about one another with direct object references.
Communications – Functionality to support loosely coupled commands and pub/sub events between the components of your application.
Navigation – Functionality to switch views when the user interacts with the application within a container without every view and parent view needing to know about all the others.
Application Structure – Support for the Model-View-ViewModel pattern, as well as a dependency injection container, and other implementation patterns to help set up your solution for the best separation of concerns for different kinds of code in your application.

An important thing to understand about Prism is that it is not an all-or-nothing framework. You can use any one or several of the features in isolation and ignore the other parts if they do not make sense for your application or your requirements. In addition to these major features, there are many small little helper classes and utilities in Prism that can be used on their own as well.

In the rest of this article, I will quickly step you through creating a simple Prism application that uses modularity and regions to plug a view into the main application. You will see that there are a number of steps that may seem a bit complicated at first. The first thing to keep in mind is that these activities are a one-time set up of your solution as you lay down the structure of your solution. The other is that at the end of the article I will point you to some project templates that make it all much quicker. But I think it is important to go through the steps manually at least once so you understand what all the moving parts are. In the next article, I will flesh that application out some more to use commands and events and later articles will explore other aspects of Prism.

Download the source code for the Prism 101 completed solution.

Step 1: Create your Prism application

To get started, create a new Silverlight Application project in Visual Studio and name it Prism101.

In the New Silverlight Application dialog that asks about creating a host application, accept the defaults by clicking OK. (Note: I am using Silverlight 5 RC for my example, but all of what I will show works equally well for Silverlight 4).

Step 2: Decide which Dependency Injection container to use

Prism uses the Inversion of Control and Dependency Injection patterns under the covers with the help of a Container. Out of the box, Prism supports using either Unity or Managed Extensibility Framework (MEF). You can also plug in other containers by implementing the IServiceLocator interface similar to the implementations that are provided for Unity and MEF.

I won’t go into a full discussion of the differences and similarities between Unity and MEF. Each has distinct capabilities, but for the purposes of what I will be covering in this article series, either one is equally sufficient. I generally prefer MEF myself since it is a part of the .NET and Silverlight Frameworks, and because I like the declarative approach that MEF uses. So I will be using MEF throughout the article series. The sample applications that come with Prism have numerous examples of using Unity instead.

Step 3: Add the Prism Library assemblies

To follow along with the coding, you will need to download the Prism 4 toolkit. It is a self-extracting executable that you can point to any folder on your machine where you want to store the libraries, source code, sample code, and documentation for Prism 4. Once you have extracted the files, add references to the Prism101 Silverlight client application project to the Microsoft.Practices.Prism, Microsoft.Practices.Prism.Interactivity, and Microsoft.Practices.Prism.MefExtensions libraries in the \Bin\Silverlight folder wherever you extracted Prism to:

For this sample article I will not be using any functionality from the Interactivity library, but it is easier to just always add references to all three of these libraries in your client projects so that you have the full Prism toolkit at your disposal. If you were using Unity instead of MEF, you can see that instead of adding the MefExtensions library, you would add the UnityExtensions and Unity.Silverlight libraries instead

Also add references to the System.ComponentModel.Composition, System.ComponentModel.Composition.Initialization and the System.Windows.Controls libraries.

Step 4: Add a Bootstrapper

If you are going to use modularity, UI composition, or navigation in your application, you will need to have some Prism-specific initialization code in your application. The standard way to set up this initialization code is to have it in a separate class called a bootstrapper. The bootstrapper is just a way to centralize all the initialization logic for your application in one well known location, separate from the App.xaml code behind. Prism provides a base bootstrapper class for each of the containers that takes care of initializing all the types and services in the Prism toolkit. All you need to do is derive from it and handle a couple of overrides to initialize the specifics of your application.

Add a class named Bootstrapper to your Prism101 project. Modify the code to match the code below.

 1: public class Bootstrapper : MefBootstrapper

 2: {

 3:     protected override DependencyObject CreateShell()

 4:     {

 5:         MainPage shell = new MainPage();

 6:         Application.Current.RootVisual = shell;

 7:         return shell;

 8:     }

 9: }

Part of the initialization of the application is to create the main page. The outermost UI (Window in WPF or RootVisual in Silverlight) is referred to as the Shell in a Prism application. Part of the design of a composite application is that the shell is just a place for content to live. The specific content and functionality of your application will be contributed by the modules that load into the shell. I will get to creating a module later in the article. The shell is responsible for setting up the overall look and feel of the application (i.e. contributing the application scoped resources), determining the top level window layout and navigation. However, the shell should remain ignorant of the details of what is going to load into the application other than those aspects.

So the code above just initializes the application’s RootVisual to an instance of the MainPage class and returns a reference for that instance to the bootstrapper base class. Prism will use that reference to hook up some of the region functionality that I will be using shortly.

As you may know, normally your RootVisual is set in the App.xaml.cs file of your project, and you can only set the RootVisual once per application. Additionally, for the bootstrapper to do anything, it has to be called from somewhere. Open your App.xaml.cs file and modify the Application_Startup event handler to run the bootstrapper instead of setting the RootVisual:

 1: private void Application_Startup(object sender, StartupEventArgs e)

 2: {

 3:     new Bootstrapper().Run();

 4: }

The Run method on the MefBootstrapper base class will execute an intialization workflow that performs the following:

Creates the container
Adds MEF exports to the container for the types contributed by Prism
Creates and initializes the shell
Loads and initializes the modules

The third bullet is the point where the overridden CreateShell method in your bootstrapper will be called. The main application project (Prism101) is referred to as the Shell application project since it is the root application that loads and hosts the shell.

Build and run the application at this point to make sure all is well. Your Silverlight application should launch like normal with an empty main page, but you should not see any exceptions. There is not much there to see yet, but the addition of the bootstrapper has made it so all the functionality of Prism is now at your disposal in your application. Next I will show how to start harnessing some of that functionality by defining a module.

Step 5: Add a Module project to your solution

A Module in Prism is an abstract container for a set of functionality. The way you partition your sets of functionality into modules is completely arbitrary, but common lines of separation are to put individual feature sets that you want to be able to turn on or off as a whole in the application into separate modules. Another common approach is to separate modules based on team composition and which team will be working on which set of functionality. For this article, I will just add a single Core module with the main view that will load up to welcome the user and get them started using the application. In later articles I will add additional modules and show how you can plug functionality from multiple modules in at the shell level, or can even plug functionality into the views of one module from another module.

Add another Silverlight Application project to your solution and name it Prism101.Modules.Core.

When the New Silverlight Application dialog pops up, uncheck the option at the top to host the application and click OK.

Normally you only create a Silverlight Application project type for your main application, and any types that you separate into other assemblies you would create with a Silverlight Class Library project type. A module in Prism is an independently loadable unit of functionality. By creating it as a Silverlight Application project, it will get compiled into its own XAP file and can be downloaded and loaded independently from the rest of the application. That is part of the decoupling you are going after when you develop an application as a composite application.

Because this project will not launch as a standalone Silverlight Application itself though, delete the MainPage.xaml and App.xaml files from the project. Then go to the project properties and change the Startup object drop down to (not set).

Step 6: Add the Module class

The thing that identifies an assembly as a module to Prism is that it contains one or more module classes. A module class is just a class that implements the Prism IModule interface. When using MEF as the container, you also have to decorate the class with a [ModuleExport] attribute so that Prism can discover the module class through the container. Even though Prism supports defining more than one module class in a single assembly, my design recommendation is to only ever have one module class for a given module project. That allows you to treat the assembly boundary as the container for a single module’s functionality rather than trying to rationalize which types within the assembly are associated with which logical module.

Before you add the module class, you will need the same references for each module that you added to the shell project:

Microsoft.Practices.Prism
Microsoft.Practices.Prism.Interactivity
Microsoft.Practices.Prism.MefExtensions
System.ComponentModel.Composition
System.ComponentModel.Composition.Initialization
System.Windows.Controls

However, one important difference is that you need to set the Copy Local property for each of the Prism references to false so that those assemblies do not get copied into the application multiple times. They will be present at runtime because the Shell project will already have them in its XAP file. Having multiple copies load up causes problems in the module loading process.

Add a class to the Prism101.Modules.Core project and name it CoreModule. Add code to the class so it matches the following code snippet:

 1: [ModuleExport(typeof(CoreModule))]

 2: public class CoreModule : IModule

 3: {

 4:     public void Initialize()

 5:     {

 6:         MessageBox.Show("Core Module initialized!");

 7:     }

 8: }

Step 7: Define the Module catalog

Prism supports several ways of loading modules into the shell application. Modules can be downloaded along with the main application or they can be downloaded asynchronously in the background. They can be loaded as soon as they have been downloaded or you can defer loading of the module until the first point where the functionality is invoked from the module. You can declare which modules the application is composed of programmatically or declaratively in a module XAML file. The module loader is also extensible, so if you wanted to write your own module catalog implementation that went out and made a service call with the logged in user identity to get back a tailored list per user of what modules to download and load, you could easily do that as well. In fact, that might make a good future article… leave a comment if you would like to see that.

For this sample, I will use a ModuleCatalog.xaml file to indicate which modules to load. For the Core module I will have it download and initialize as the application starts up since it represents the initial landing page for the user. In a later article I will show how to defer downloading and initialization until additional functionality is first invoked.

Add a Text File from the General category of project item templates named ModuleCatalog.xaml to the Prism101 project.

Edit the contents of the file to contain the following markup.

 1: <Modularity:ModuleCatalog xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

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

 3:                           xmlns:sys="clr-namespace:System;assembly=mscorlib"

 4:                           xmlns:Modularity="clr-namespace:Microsoft.Practices.Prism.Modularity;assembly=Microsoft.Practices.Prism">

 5:     <Modularity:ModuleInfo Ref="Prism101.Modules.Core.xap"

 6:                            ModuleName="CoreModule"

 7:                            ModuleType="Prism101.Modules.Core.CoreModule, Prism101.Modules.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />

 8: Modularity:ModuleCatalog>

This markup identifies the module assembly information in a declarative fashion outside the compiled code so that it could potentially be changed on the deployment site to add or remove modules without needing to recompile anything. Go to the properties for the file and make sure its Build Action is set to Resource.

Step 8: Add the module XAP to the host site

For Prism to be able to download the module XAP file, it will have to be present in the hosting web applications \ClientBin folder. To add this, open the Prism101.Web project and go to its project properties. Select the Silverlight Applications tab and Click the Add button at the bottom.

In the Add Silverlight Application dialog, select Prism101.Modules.Core from the drop down list for “Use and existing Silverlight application project in the solution”. Uncheck the option towards the bottom to “Add a test page that references the control”. Click Add.

You should now see both the Shell project (Prism101) and the module project (Prism101.Modules.Core) listed as hosted applications.

Step 9: Read the ModuleCatalog.xaml from the bootstrapper

The final step to get the module loaded is to modify the bootstrapper so it knows where to find the module catalog information. Add this method to your Bootstrapper class:

 1: protected override Microsoft.Practices.Prism.Modularity.IModuleCatalog CreateModuleCatalog()

 2: {

 3:     return Microsoft.Practices.Prism.Modularity.ModuleCatalog.CreateFromXaml(

 4:         new Uri("/Prism101;component/ModuleCatalog.xaml", UriKind.Relative));

 5: }

At this point you should be able to run the application again and you will see the message box pop up as the application loads, indicating that the module has in fact loaded.

Step 10: Add a Region to the Shell

Popping a message box at least tells us our module is loading and initializing, but is not very interesting. What you will typically do as a module loads up is start presenting some screens or at least commanding functionality to the user that lets them take advantage of the functionality that is encapsulated in the module. So now I will show how you can define a view in a module and present it to the user by plugging it into the shell as the module loads.

The first step in doing that is to define somewhere for the view to plug in within the shell. The most common way to do this is to add either a ContentControl or ItemsControl (or derived type) to the shell and mark it as a Prism region.

Open MainPage.xaml and add the Prism XAML namespace to the XML namespaces on the root UserControl element so that you can access types from the Prism Library in XAML

 1: xmlns:prism="http://www.codeplex.com/prism"

Then add a ContentControl and mark it as a region named MainContent:

 1: <Grid x:Name="LayoutRoot" Background="White">

 2:     <ContentControl prism:RegionManager.RegionName="MainContent" />

 3: Grid>

Step 11: Add a View to the Core Module and plug it into the Shell region

Add a new Silverlight User Control to the Prism101.Modules.Core project named WelcomeView. In the XAML, add a TextBlock with its Text property set to “Hello Prism!” and set the font size big to celebrate your excitement with Prism.

 1: <Grid x:Name="LayoutRoot" Background="White">

 2:     <TextBlock Text="Hello Prism!"

 3:                 FontSize="24" />

 4: Grid>

Next, open the CoreModule class and replace the code there with the following code.

 1: [ModuleExport(typeof(CoreModule))]

 2: public class CoreModule : IModule

 3: {

 4:     [Import]

 5:     public IRegionManager RegionManager { get; set; }

6:

 7:     public void Initialize()

 8:     {

 9:         var view = new WelcomeView();

 10:         RegionManager.AddToRegion("MainContent", view);

 11:     }

 12: }

The import allows your module class to access the RegionManager service exposed by Prism. This manager knows about all regions declared in any view throughout the application and allows you to dynamically plug in child views into those regions. The Initialize method code then creates an instance of your module’s view and plugs it into the MainContent region you placed in the shell as a ContentControl. To do this without Prism you would somehow have to feed an object reference to that ContentControl from the MainPage down into the module code that is loading into the application so that it could programmatically set the Content property to the view instance. That would be an example of the kind of coupling that you are trying to avoid when building composite applications. At this point the only coupling between the main application and the module are the declaration of the module in the ModuleCatalog.xaml and the shared “contract” of the MainContent region name as a string.

Step 12: Making it easier

I’m sure that seemed like a lot of work to get a Hello Prism view displayed in your application. And if you app is fairly small – say less than a couple dozen screens, you might not bother with using modularity and regions at all. In later articles in the series I’ll get into other features of Prism including commands, events, and some of the Model-View-ViewModel pattern support that can be very handy regardless of the scale of your application.

But even all this initial setup cries out for automation, and it happens to be readily available in the form of the Prism Template Pack created by David Hill, a Microsoft Program Manager from the Prism team.

If you follow the instructions at that link to download an install the template pack, you can quickly create a Prism starter app with a module following these steps:

Create a new project, select the Prism templates in the New Project dialog, and pick the MEF category. Start by selecting the Prism Silverlight 4.0 Shell (MEF) project type. This will create a pre-populated shell project with several regions already defined in the shell, the bootstrapper all set up for you, references added, etc.

Next, add another project to the solution and this time select the Prism Silverlight 4.0 Module (MEF) project type. Keep the default name of Module1.

Next go into the ModuleCatalog.xaml in the shell project and uncomment the Module1 information:

 1: <prism:ModuleInfo Ref="Module1.xap"

 2:                     ModuleName="Module1.ModuleInit"

 3:                     ModuleType="Module1.ModuleInit, Module1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"

 4:                     InitializationMode="WhenAvailable"/>

Next add a new ASP.NET Empty Web Application project to act as a host. The Readme.txt file in each project tells you how to configure it, but it is similar to what I showed in Step 8 of this article to configure the web application as the host for the Shell and to add the Module1 XAP to be hosted in the site as well for download. Then you will want to launch the app using the web project as the startup project with the test page for the Shell as the startup page. If you do that, viola – you have a running Prism app with a module and a bit more functionality than the one we put together in this article because it has some views wired up with some sample data and navigation commands and other things we will be talking about in later articles.

These templates will need to be updated for Silverlight 5 and you can customize them yourself if you want to trim them down to get rid of all the sample data and such to be a better (empty) starting point for real projects.

Download the source code for the Prism 101 completed solution.

Summary

In this article I gave you a quick introduction to the concepts and capabilities of Prism and walked you through creating your first Prism application, explaining as we went what some of the moving parts and pieces are that make a Prism application a little different than a normal Silverlight app. You saw that there is some initialization required with the bootstrapper to get the Prism services and types initialized to support your application. The bootstrapper is also where you create your main shell view as your RootVisual and where you indicate, either directly or indirectly through a module catalog XAML file, which modules you want to load into your application. You then saw how to define a module and get it initialized, as well as how to plug views into the shell with Regions. In the next article, I’ll put a little more “meat” in the views to include some commands and the MVVM pattern. In later articles I’ll expand to multiple modules, navigation, events and more.

About the Author

Brian Noyes is Chief Architect of IDesign, a Microsoft Regional Director, and Silverlight MVP. He is a frequent top rated speaker at conferences worldwide including Microsoft TechEd, DevConnections, VSLive!, DevTeach, and others. Brian worked directly on the Prism team with Microsoft patterns and practices and co-authored the book Developers Guide to Microsoft Prism4. He is also the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding in Windows Forms 2.0. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on Twitter @briannoyes.

WP7 for iPhone and Android Developers - MVC and MVVM

editorial@silverlightshow.net (Kevin Hoffman ) — Thu, 01 Sep 2011 13:41:00 GMT

Don't miss...

($2.99)

All SilverlightShow Ebooks

So far in this series of articles, we have been taking topics that might be second nature to iOS developers and relating them to the relatively new feature set found in the Windows Phone 7 SDK. Typically this involves talking about a few classes and code samples as they might appear in iOS and then relating them to classes with a similar purpose in the WP7 SDK.

This article focuses more on a set of design patterns to illustrate that patterns themselves are universal and the code used to implement them is secondary to the pattern and its purpose. In this article we’ll take a look at the Model – View – Controller pattern and a variant of it, the Model-View-ViewModel pattern.

In a typical data-bound user interface you generally have a view composed of controls and these controls are usually bound to some underlying source of data. For example, if you have a customer edit form you might have controls like text fields for editing the customer’s name and address and other types of controls for editing additional customer data. The model in this scenario might be an object called Customer (which could be a regular Objective-C or C# object or it could have been served up by a database access library or an Object-Relational Mapper).

If this were an iOS application you might have created a class called CustomerEditViewController which inherits from UIViewController. The view is actually a view hierarchy composed of controls that allow a user to edit customers. Because iOS doesn’t actually support bindings the way the full desktop version of Cocoa does (or WP7 for that matter) the controller has to do an awful lot of work to react to user input and manually force values into control properties.

A typical Model-View-Controller interaction looks like the following diagram:

In a bindings-capable environment, the model is bound to the view and the model is loaded and updated by the controller. Additional properties of the view are dealt with by the controller and user interaction events are passed on to the controller for handling.

This works out pretty well in many scenarios and it’s original goal of separating concerns to make our applications easier to maintain and debug is still valid. Unfortunately what happens quite often is that with the MVC pattern we only have a single model. In order to keep bindings working, we end up making changes to the model to accommodate things that only have relevance in the UI. For example, we might add an isSelected property to the Customer class so that we can modify the background color of currently selected customers or, we’ll add a CurrentCustomer object to some other model and use that to help our UI maintain navigational consistency.

In a typical iOS scenario, we might have a UITableViewController subclass. This class is responsible for handing instances of custom view cells to the UI subsystem. It performs the customization of these cells by pulling information from a model.

What we really need are two different types of models. The first type is a model that represents the actual source of data which will more than likely be some kind of POCO (Plain-Old C# Object) that came from a database, an XML file, a Web Service, or somewhere else. The second type of model is a model whose properties and behaviors are designed specifically to support the view with which the user interacts. This type we call a View Model, and it is part of a variant of the MVC pattern called Model-View-ViewModel.

In a Model-View-ViewModel pattern, we take advantage of the fact that virtually all aspects of our user interface can be controlled via data binding. We wouldn’t really need to add the complexity of this pattern to our iOS applications because we don’t have bindings support but it comes in extremely handy when building large Windows Phone 7 applications.

Notice that this pattern doesn’t actually have a controller – there is no single over-arching all-powerful class that is responsible for coordinating everything. This takes a little getting used to at first, but, once you’ve gotten into the habit of building highly data-bound UIs in Windows Phone 7, the use of MVVM seems like a natural evolution.

As mentioned, MVVM is a pattern, it is a way of doing things and, as such, there is no single right way of doing it. For example, one thing people strive for in MVVM is to have as little code in a view’s code-behind as possible (it’s really not possible to avoid this entirely). If you ask folks building MVVM applications today about code-behind, you will probably start an argument.

One concept that is especially hard for iOS developers to let go of is the idea of the controller. If you find yourself writing code that looks like this:

myControl.Text = myModel.Property;

Then you need to stop right there – this isn’t MVVM. Your view needs to be bound to a view model and the properties of the various controls and sub-controls should all be set via bindings and converters wherever possible. The trick with MVVM is figuring out how your view needs to get instances of view models. You can do this by creating factory methods, or you can use a view model locator, which is a static helper class responsible for doling out instances of view models to views.

Take a look at the following XAML, which illustrates how you might create a single customer view that is bound to a view model object:

"MyApp.CustomerPage"

  ...

  DataContext="{Binding Customer,Source={StaticResource Locator}}">

  ...



Basically what we’re saying is that there is a view model object called Customer to which this entire page is bound. This is also a very common practice with MVVM – try and make the binding as wide in scope as possible. It might be hard at first, but try and match your view models directly to pages and user controls. The benefit of having a view model in addition to a data-centric model is that you can have multiple view models for a single model, with each view model tailored specifically for a given control or page.

Inside our App.xaml we can declare a global resource that points to the view model locator:

<Application.Resources>

 <vm:ViewModelLocator x:Key="Locator" />

Application.Resources>

Here “vm” is the namespace prefix of the CLR namespace where we have our view model locator defined. This class really just has public properties on it that allow our XAML to obtain instances of view models. This is also unfamiliar territory for iOS developers and developers who traditionally follow a more MVC style. Instead of having a controller object that knows about the view and knows about the model that is responsible for hooking the two up, the view declares its intent via bindings. In the sample case, the view says that it should be bound to a view model called Customer which can be found on the view model locator class. The view model locator is responsible for instantiating the view model. During this instantiation, the view model also typically has an initialization method which is called directly or indirectly (again, this is a source of difference and debate depending on how you decide to implement your MVVM pattern).

So the flow of control and instantiation might go something like this: Customer View Page –> Locator –> Customer View Model –> Customer Model (database or web service source).

The UI intentionally has absolutely no idea how the bound data is actually persisted on disk (or in the cloud). All it cares about is how the data is represented visually to the user and made available for interaction – this is the job of the view model. Many of the tasks we traditionally keep in controllers, such as responding to user input and manipulating model values, all take place within the view model whenever possible.

At first you might be thinking that MVVM seems a lot more complicated than just having code-behind in your WP7 views that manipulates controls directly, especially when this looks a lot like the code you may have been writing in iOS. For really small applications, this may be true. However, once you start writing applications that have several pages and these pages have multiple controls, different states, and need to respond to when users navigate to and away from those pages and finally when you try and attach an asynchronous data source (such as web services in the cloud) to your application – the small increase in complexity of code is well worth it in the long run.

Bindings is only a small part of MVVM, it is far more than that. Let’s take another very common scenario – navigating between pages. In iOS, you might write code in a method that is invoked when a user selects a row in a table view. Here, you might create an instance of the view controller responsible for the next screen and then pop it into the stack via the navigation controller. If this view controller needs a model in order to prep the UI, the parent controller is often responsible for creating an instance of this model, loading it from some source, and then passing it as a parameter to the child controller.

With MVVM we do things a little differently. A user might tap a button which results in the execution of a Command object that is actually a property of the view model (view models encapsulate both behavior and data!). As a result of this execution, a message might be broadcast indicating that Customer 123 has been selected. The CustomerViewModel class is listening for such a message. When it receives this message, it loads Customer 123 from disk, populates all of its properties accordingly, and then tells the WP7 navigation system to navigate to the CustomerView.xaml page. As you can see, the “concerns” here are even more separate than in MVC – the parent controller doesn’t actually know what happens when someone selects a customer and many proponents of MVVM argue that it shouldn’t. The view model that backs the view that should appear upon selecting a customer is responsible for listening for the event (or events, and this is key to re-usability) that trigger the appearance of that view.

It might seem like a minor detail but if you go back into an application written MVC style a few months after writing it – it could take you a very long time to figure out all of the different paths through an application. If you’re looking at an MVVM view model, then a quick glance at the message subscribers on that model will tell you exactly the list of actions that can cause that view to appear.

In this article I’ve tried to explain the basics of the MVVM pattern and how it differs from the MVC pattern that iOS developers are familiar with. I have deliberately avoided talking about any one MVVM implementation because the decision as to which MVVM library you use (or whether you roll your own) is entirely up to you.

MVVM isn’t limited to just Windows Phone 7, and there are implementations on just about every platform you can imagine. For Windows Phone 7, the library that I have used most often is MVVM Lite. If you don’t feel like writing your own view model locator classes, your own pub/sub messaging system, and your own command helpers, then using a library like MVVM Lite will save you a lot of time and effort.

At one point, the installation process for MVVM Lite was so cumbersome that many people just wrote their own stuff rather than attempting the install. Recently, they have released an automated installer that makes adopting MVVM Lite much easier. You can find the code for MVVM Lite, the downloader, and related documentation here: http://mvvmlight.codeplex.com/.

In closing, iOS developers are very used to having to manually fetch objects from a data source via a controller and then, using that same controller, instantiate custom views and set view properties and manually build view hierarchies programmatically. Using the MVVM pattern on Windows Phone 7 allows developers to take full advantage of bindings, resource dictionaries, templating, and the flexibility of Xaml-based object hierarchies. As an iOS developer if you ever find yourself writing code like this:

myControl.Text = myModel.TextProperty;

Then you should take a step back and see if the MVVM pattern and possibly an MVVM toolkit might help you.

The ABC of streaming in Silverlight

editorial@silverlightshow.net (Walter Ferrari ) — Tue, 31 May 2011 00:00:00 GMT

Advanced media integration is one of Silverlight’s greatest strengths. In this tutorial we delve into this topic by carrying out some simple exercises. We will learn how to play a movie, how to interact with webcam and microphone and how to create a live streaming solution using Expression Encoder 4 and VLC and capture it in a Silverlight application.

Play a movie

In Silverlight there is a native control called MediaElement which allows you to do a lot of things. The first thing obviously is the possibility to play a video: using its Source property you can define the location of the video you want to see and you can use either a relative or absolute URL. Suppose you have a collection of videos in a subdirectory called “Videos” of your web application and you want to play one of them. The xaml code snippet below is all you will need:

"LayoutRoot" >

"mediaEl" Source="videos/video1.wmv" />

If you launch the application the movie will start automatically. This happens because the Autostart property of the MediaElement is true by default. To control the video, the MediaElement exposes the canonical Play(), Pause() and Stop() methods. At this point adding a commandbar to control the video is fairly easy ; just add a StackPanel in the xaml as below:

"CommandBar" Orientation="Horizontal" Background="Beige" Height="39" Width="783" Margin="5" HorizontalAlignment="Center" Canvas.Left="3">

And, in the code behind, the following event handlers:

private void PlayMovie_Click(object sender, RoutedEventArgs e)

        {

            if(mediaEl.CurrentState != MediaElementState.Opening ||

                mediaEl.CurrentState == MediaElementState.Stopped ||

                mediaEl.CurrentState == MediaElementState.Paused)

                mediaEl.Play();

        }

        private void PauseMovie_Click(object sender, RoutedEventArgs e)

        {

            if (mediaEl.CurrentState == MediaElementState.Playing)

                mediaEl.Pause();

        }

        private void VideoStop_Click(object sender, RoutedEventArgs e)

        {

            if(mediaEl.CurrentState == MediaElementState.Playing ||

                mediaEl.CurrentState == MediaElementState.Paused)

                mediaEl.Stop();

        }

Let’s focus on the video formats supported. The list below recaps all the formats recognized by Silverlight 4:

Container	Supported Codecs
ASF (Windows Media)	Windows Media Audio 7, 8, 9 (WMA Standard) Windows Media Audio 9, 10 (WMA Professional) WMV1 (Windows Media Video 7) WMV2 (Windows Media Video 8) WMV3 (Windows Media Video 9)
MP4	H.264, AAC-LC, HE-AAC v1 (AAC+), HE-AAC v2 (eAAC+)
MP3	ISO MPEG-1 Layer III (MP3)

Drop & Know…

How do we know if a video is supported? Well, instead of digging into the properties of the file and compare them with the list above, we can be way more pragmatic, i.e. by simply dragging the video from the file system to the Silverlight app and dropping it over the MediaElement. If the MediaElment does not recognize the video, it fires an exception that we can catch the internal error and redirect to the user as a comprehensible message. Let’s see how we can achieve that.

After seeing the list of the properties of the MediaElement you will find that it exposes an AllowDrop property since it derives from UIElement . Yet hooking a drop event here won’t work because the Mediaelement is not a container. No panic! You can embed the MediaElement in a Canvas container and handle the drop event of this one. In the xaml below the Canvas object incorporates the StackPanel above mentioned and the MediaElement:

"VideoCanvas_Drop" x:Name="VideoCanvas" Width="800" Height="600" AllowDrop="True" Background="RosyBrown" HorizontalAlignment="Center">

    "CommandBar" Orientation="Horizontal" Background="Beige" Height="39" Width="783" Margin="5" HorizontalAlignment="Center" Canvas.Left="3">

            Margin="50,5,0,5" Width="100"/>

                Margin="50,5,0,5" Width="100"/>

                Margin="50,5,0,5" Width="100" />

    "mediaEl" Canvas.Top="50"  Width="800" Height="450" AutoPlay="False" />

Let’s take a look at the VideoCanvas_Drop event handler:

void VideoCanvas_Drop(object sender, DragEventArgs e)

{

    DragEventArgs dr = e as DragEventArgs;

    if (dr.Data == null)

        return;

    IDataObject dataObject = dr.Data as IDataObject;

    FileInfo[] files = dataObject.GetData(DataFormats.FileDrop) as FileInfo[];

    if(files.Count() > 0)

        mediaEl.SetSource(files[0].OpenRead());

}

The trick here is to use the SetSource property of the MediaElement instead of Source. Since it accepts a Stream as an argument, we can pass it the FileStream related to the dropped file. If the FileStream does not contain a natively supported media source then the MediaElement fires a MediaFailed event that we can catch as below:

public MainPage()

{

    InitializeComponent();

    mediaEl.MediaFailed += new EventHandler(mediaEl_MediaFailed);

    …

}

void mediaEl_MediaFailed(object sender, ExceptionRoutedEventArgs e)

{

    WarningTxtBlock.Text = "Cannot open this media:\r\n" + e.ErrorException.Message;

}

Using a webcam

Starting From Silverlight 4 it is possible to access to webcam and microphone of the machine. Fortunately the steps required to get a working application are nicely easy. We need substantially two objects: a VideoCaptureDevice and a CaptureSource.

private VideoCaptureDevice myWebCam;
private CaptureSource myCaptureSource;

The first represents the physical webcam and the second one offers some methods to manage the webcam. In this case we won’t use a MediaElement but a VideoBrush object to paint a Rectangle with the video stream coming from the webcam. Let’s create a new Silverlight project and add the following xaml code to the MainPage.xaml:

"LayoutRoot" Background="Black" Width="1024" Height="768" >

        "*"/>

        "70"/>

    "Horizontal" 

              HorizontalAlignment="Center" 

              Grid.ColumnSpan="2" 

              Grid.Row="1">

             x:Name="StartButton" Click="StartButton_Click"

             Content="Start" />

             x:Name="StopButton" Click="StopButton_Click" 

             Content="Stop" />

             x:Name="SnapshotButton" Click="SnapshotButton_Click" 

             Content="Snapshot" />

    "DarkRed" BorderBrush="Beige" BorderThickness="5" Height="380" Margin="10,25,10,10"> 

        "webcamRectangle" />

    "Gray" BorderBrush="Beige" Grid.Row="0" Grid.Column="1" BorderThickness="5" Height="380" Margin="10,25,10,10">

        "snapshotRectangle" />

As you can see there are two rectangles; the first will be painted with the VideoBrush and the second will be used to show a snapshot from the video. Now in the .cs file we can initialize the two objects mentioned above (myWebCam and myCaptureSource) and prepare everything for the video capture:

private void InitializeWebCam()

{

    myCaptureSource = new CaptureSource();

    //1° step: get the default capture device

    myWebCam = CaptureDeviceConfiguration.GetDefaultVideoCaptureDevice();

    // 2° step: indicate the video capture device to be used by the CaptureSource 

    myCaptureSource.VideoCaptureDevice = myWebCam;

    // 3° step: initialize a VideoBrush with the CaptureSource just initialized 

    myVideoBrush = new VideoBrush();

    myVideoBrush.SetSource(myCaptureSource);

    // 4° step: fill the Rectangle with the stream provided by the VideoBrush

    webcamRectangle.Fill = myVideoBrush;

As you see, getting the VideoCaptureDevice that represents the webcam available is just a matter of calling the GetDefaultVideoCaptureDevice() of the static CaptureDeviceConfiguration class. Then we have to indicate the myCaptureSource object which is the video capture device from which we want to actually capture. The following step is to initialize a VideoBrush object and set its source to the myCaptureSource. In this way the VideoBrush is ready to paint a target with the stream coming from the capture device. This is what has been done in the fourth step. We then have to handle the click events of the play and stop buttons to control the video:

private void StartButton_Click(object sender, RoutedEventArgs e)

{

    if (CaptureDeviceConfiguration.AllowedDeviceAccess ||

        CaptureDeviceConfiguration.RequestDeviceAccess())

        myCaptureSource.Start();

}

private void StopButton_Click(object sender, RoutedEventArgs e)

{

    if (CaptureDeviceConfiguration.AllowedDeviceAccess ||

        CaptureDeviceConfiguration.RequestDeviceAccess())

        myCaptureSource.Stop();

}

As you may notice before starting or stopping the capture we need to make a formal request in order to use the webcam and/or the microphone. The first time involves opening a dialog box asking for an explicit consent for access to the webcam and microphone as in the image below:

Fortunately the following accesses can skip this request by checking if the AllowedDeviceAccess flag is set. This means that this explicit consent request saves you from being watched when you are picking your nose.

And what about a snapshot taken from the video? Nothing complicated! just modify the previous InitializeWebcam() method by adding this code snippet at the end:

mySnapshotBrush = new ImageBrush();

snapshotRectangle.Fill = mySnapshotBrush;

myCaptureSource.CaptureImageCompleted +=new EventHandler(myCaptureSource_CaptureImageCompleted);

In the code above the snapshotRectangle is the Rectangle where we want to place the snapshot and its Fill property is set to an ImageBrush. So when the ImageBrush contains an image it is painted on the rectangle. How do we acquire an image from the video? You can use the CaptureImageAsync() method of the CaptureSource object. Since it is an asynchronous method you need to add an event handler to the CaptureImageCompleted event of the CaptureSource as shown below:

void myCaptureSource_CaptureImageCompleted(object sender, CaptureImageCompletedEventArgs e)

{

    mySnapshotBrush.ImageSource = e.Result;

}

You are almost done;

the only thing to add is calling the async method when the snapshot button is clicked:

private void SnapshotButton_Click(object sender, RoutedEventArgs e)

{

    if (myCaptureSource.VideoCaptureDevice != null &&

        myCaptureSource.State == CaptureState.Started)

    {

        myCaptureSource.CaptureImageAsync();

    }

}

Capturing a live stream

To capture a live stream we will use the MediaElement object again. But first we need a media streaming source. Fortunately there is more than one way to create your own little home streaming service to experiment a little. In the next paragraph we will learn how to broadcast the webcam on our pc live over the network using two different programs, Microsoft Expression Encoder 4 and VLC media player.

Live broadcasting with Expression Encoder

Microsoft Expression Encoder 4 is freely downloadable from here . Unlike the professional version, i.e. Encoder PRO 4, it does not support live Smooth Streaming and does not have support for H.264 but it is more than enough for our purposes. When you start the program you will find three options as in the image below:

Then Expression Encoder offers you a rich UI to create your own streaming project. The first step to do is to add a Live Source. After doing so a yellow framed box appears in the “Live Sources” area on the left:

Focusing on the “Live Source 1” just created you can attach a video device to it by choosing “Video Device” from the drop down list. If you have at least one webcam on board it should be listed in the drop down as below:

Similarly you can add an audio device choosing from the drop down list below. By the way, there is no simple way here to set an IP webcam as a video source since Encoder 4 has no support for RTSP streams. In that case you need a directshow source filter.
Once you have your working live source you have to activate it by clicking on the “Cue” button in the box:

Now let’s focus on the “Presets” section on the right. Starting from the top there is a System tab which collects several predefined encoding profiles. In my experience the best compromise between video quality and latency (I will go back to this later on) is the “Standard Encoding / VC-1 High Speed Broadband” preset.

You can try to change the video parameters, for instance reducing the Buffer Window but probably you will lose quality in the video.

The final step is set your output type. In order to be able to capture the live stream from a Silverlight application we will choose the broadcast - streaming option on port 8080 as below:

Now you are ready to press the start button in the centre:

Live broadcasting with VLC

VLC is known as an efficient and free multimedia player but perhaps not everybody knows that it can be used also as a streaming server. The nice thing is that it is able to stream all that it can read, for instance it can perform a live broadcasting stream even from an IP camera. But let’s stay on track: here as in the Expression Encoder tutorial above, we want to capture the video from the built-in webcam of our PC and stream it over the network. So let’s download the software from here and read the following steps.

The first thing to do is to open the “Media” menu and choose “Open Capture Device…”:

In the dialog box make sure to select your built-in webcam in the “Video device name” section as in the image below:

As for the audio device, you can do the same. Then click on the pick button at the right of the play button to get the other button options as below:

A new stream configuration wizard will appear. On the first page just click on the “next” button to jump directly to the “Destinations” configuration:

In the “Destinations” page there are two things to do: one is configuring the streaming method and the other is choosing the appropriate transcoding. Let’s start with the first one. Open the “New destination” dropdown list and choose the MS-WMSP (MMSH) option as below:

Don’t forget to set the “Display locally” check box in order to be able to capture the live stream from the same PC. Then click to “Add” button on the right of the drop down list. You should see something like that:

The streaming method configuration is completed. Lets’ focus on the transcoding options below now. Expand the Profile dropdown list and choose the “video – VMW + WMA (ASF) option. Then click on the edit button:

In the Edit Trascoding dialog box, click on the “Video codec tab and select the WMV2 codec as below (it could be already automatically set):

Click on “Save” to return to the “Destinations” page. Click on “Next” to go to the final page where there is a useful output string which allows you to launch vlc.exe with the same configuration by adding it to the command line. Click on the “Stream” button and you are done.

The output string is (in case you want to skip all the boring steps above and launch VLC from cmd):

Vlc.exe :sout=#transcode{vcodec=WMV2,vb=800,scale=1,acodec=wma2,ab=64,channels=2,samplerate=22050} :no-sout-rtp-sap :no-sout-standard-sap :ttl=1 :sout-keep

Using the live broadcasting with Silverlight

In the two previous paragraphs we have seen how to create a live broadcasting using two different softwares and you may expect that in Silverlight you have to configure the source of the stream differently in the two cases. Fortunately it is not true: if you use the configurations shown above you will be able to use one or the other option to your liking. The only requirement you need is to set the Source property of the MediaElement as below using the mms moniker:

"MediaElement" Width="320" Height="240" Source="mms://127.0.0.1:8080"/>

Let’s start a new Silverlight project to create a very basic live TV. Include this xaml in the MainPage.xaml:

"LayoutRoot">

  "Vertical">

      "MediaElement" Width="320" Height="240" Source="mms://127.0.0.1:8080"/>

      "Horizontal" HorizontalAlignment="Center">

          "Status" Text="status" Margin="0,5"/>

          "Buffer" Text="buffer" Margin="10,5"/>

      "Beige" Orientation="Horizontal" HorizontalAlignment="Center">

Grid>

And in the code behind:

public MainPage()

{

    InitializeComponent();

    MediaElement.BufferingTime = new TimeSpan(0,0,0);

    MediaElement.CurrentStateChanged += (sender, e) => {

        Status.Text = MediaElement.CurrentState.ToString(); 

        Buffer.Visibility = MediaElement.CurrentState == MediaElementState.Buffering ? Visibility.Visible : Visibility.Collapsed;

    };

    this.MediaElement.BufferingProgressChanged += (sender, e) => {

        this.Buffer.Text = string.Format("{0:0.0} %", this.MediaElement.BufferingProgress * 100);

    }; 

}

private void Play_Click(object sender, RoutedEventArgs e) 

{

    this.MediaElement.Play();

}

private void Pause_Click(object sender, RoutedEventArgs e) 

{

    this.MediaElement.Pause();

}

private void Stop_Click(object sender, RoutedEventArgs e) 

{

    this.MediaElement.Stop();

}

As you see, there is a rude panel which contains the basic functionalities (Play, Pause, Stop) to interact with the video. It is interesting that I set to zero the BufferingTime of the MediaElement in order to reduce as much as possible the delay between the real events and what we see through the MediaElement. In fact, in my attempts I measured a latency of around 7 seconds using EE4 and 1,5 seconds using VLC on a private LAN. This latter value is not too bad to me.

Conclusion

Streaming media with Silverlight is easy and funny. The MediaElement object is like a Swiss army knife which allows you to create a complete media player capable of playing a movie, capturing the output of a webcam and even reproducing a live stream. Microsoft Expression encoder 4 and VLC are two great free programs which allow you to create multimedia platforms to play with Silverlight. For more advanced scenarios it could be useful to take a look at the following topics:

MediaStreamSource: a part of the Silverlight runtime which allows direct access to APIs to manipulate audio and video streams. (An example application here)
IIS Smooth Streaming: an advanced platform which enables you adaptive streaming of media to Silverlight over HTTP.
Microsoft Media Platform-Player Framework v.2.5: an open source platform which allows developers to create sophisticated video players for IIS Smooth Streaming delivery. It is available on Codeplex.

About the Author

Walter Ferrari is an environmental engineer and cultivates his passion for software development for a long time. He is currently a consultant working for his company, Abertech. He develops applications based on Microsoft technologies since 1995 and works primarily with .NET since 2003. He is currently focused on Silverlight and Sharepoint and acts as representative of CompletIT/SilverlightShow.
Walter is used to wearing a helmet while writing code..just to avoid serious damages when slamming his head against the monitor :) He blogs about his passion at http://www.snello.it/eng

Silverlight WCF RIA Services: strategies for handling your Domain Context - Part 2

editorial@silverlightshow.net (Kevin Dockx ) — Sat, 19 Mar 2011 08:22:00 GMT

Don't miss...

($0.99)

All SilverlightShow Ebooks

This is the second in a two-part article series on the WCF RIA Services Domain Context.

This article series is accompanied by source code, which can be downloaded here.

In the first part, we went through a general introduction on what the WCF RIA Services Domain Context is, looked into different strategies on how to work with it, and had a detailed look at the first possible strategy: using one instance per ViewModel. In this article, we’ll look into the other strategies.

Strategy 2: using one shared Domain Context Instance

Let’s have a look at the other approach: using one shared Domain Context instance across different ViewModels. As you might have guessed, the pros and cons are more or less the opposite of the previous approach: the good part is that you get automatically synced collections across your ViewModels: as they’re using the same Domain Context instance, adding a Book in one ViewModel will mean it’s also reflected in the other ViewModel (well, as long as you’re working directly with the EntitySet or with one of the built-in CollectionViews – eg, anything that tracks the collections on the Domain Context).

This is the approach I tend to prefer for most intranet-applications we’re building these days. Keep in mind: you’ll still have multiple Domain Context instances because you should think about how to separate your operations in different Domain Services, however, that’s not the same as different instances of the same Domain Context.

In our example, I’ve created a static LocalStateContainer class, which is where the Domain Context instance resides. The ViewModels have a Context property which links back to the Domain Context instance in the LocalStateContainer class:

public static class LocalStateContainer
{
    private static BookDomainContext _context;
    public static BookDomainContext Context
    {
        get
        {
            if (_context == null)
            {
                _context = new BookDomainContext();
            }
            return _context;
        }
    }
}

This results in the following application screen:

If you look into the code, you’ll notice the ViewModel of the View on the left loads the data, and the one on the right doesn’t, yet: the data is available on both screens.

If you click the “Add both books” button on the View on your right, you’ll notice the Books that are submitted to the database are automatically reflected in both Views:

One (possibly big) disadvantage is the fact that a submit operation is “all or nothing”: you cannot do partial submits, so submitting changes will submit all changes across different screens. Depending on how you design your application, this may or may not be a problem: an easy way to solve this would be to disallow your users to navigate away from pages which have unsaved changes. In such a case, a submit op would still only submit the changes from the last page, as you can be sure that will be the only page with possible changes.

However, if you want to give your users a more open experience (multi-window MDI-like applications, or applications which allow the user to navigate back and forth between pages without having to save the changes), this could pose some problems: imagine changing an Entity in one part of your application, navigating to another part, changing another Entity and submitting the changes: what if the first Entity has some invalid values? You’ll end up with an error message which actually belongs to a page that isn’t active nor necessarily visible anymore to your user – not exactly user friendly. One way to solve this (an approach we used in one of our applications) could be to keep a list of “active screens” (much like a task bar) on your screen. If a submit operation fails, you could easily use that “task bar” to show your user which active screen has problems, so he can go and fix those before retrying the submit operation. But as you’ve probably guessed: this is not exactly trivial code.

So let’s look into another way to solve this issue: partial saves. A partial save means you’ll only submit a part of the changed Entities: only the once you want to submit. Like this, you can submit the changes on one ViewModel without having to save changes on one of the other ViewModels.

Wait a minute. I’ve been saying throughout this article that partial saves aren’t possible through a Domain Context, so how can this be done? Well, the workaround is easier than it might look. I’ve already talked about attaching an Entity to a Domain Context, which implies you can also detach an Entity. The reasoning here is quite simple: a partial save can be done by detaching the entities you want to save from your Domain Context (IF they are attached to it), creating a new Domain Context instance (which will only be used for the submit operation), attaching them to that new instance in the correct state, submitting the changes, and on the completion of the submit operation, re-attach the submitted entities to the original Domain Context.

At least, that’s how it works in theory. In practice, you’ll find out that the part where you should attach entities in the correct state is the tricky part: if you attach an Entity, it’s attached with state “Unmodified” by default, and you cannot easily change that state. For our example, the solution is quite easy: attaching it in the correct state boils down to adding the Book to the Books collection on the new Domain Context.

The code to achieve this looks as such:

private void AddFirstBookExecution()
{
    // for example purposes, we'll first add the two
    // books to the original context.
    Context.Books.Add(NewBook);
    Context.Books.Add(SecondNewBook);
    // create a new context instance
    BookDomainContext submitContext = new BookDomainContext();
    // detach the book
    Context.Books.Detach(NewBook);
    // attach the book to the new context in the correct state,
    // eg: add it.
    submitContext.Books.Add(NewBook);
    // submit the new context
    var submitOp = submitContext.SubmitChanges();
    submitOp.Completed += (send, args) =>
    {
        if (submitOp.HasError == false)
        {
            // detach
            Book submittedBook = (Book)submitOp.ChangeSet.AddedEntities[0];
            submitContext.Books.Detach(submittedBook);
            // attach the book back to the old context
            Context.Books.Attach(submittedBook);
            // inspecting the old context through
            // Context.HasChanges => will be true: the 
            // SecondNewBook will not be submitted.
        }
    };
}

But what about modified entities, or deleted entities? Essentially, you’re going to have to write custom code to handle these cases. Luckily, a great starting point for these cases is WCF RIA Services Contrib, by Colin Blair. This project consists of a bunch of extensions on WCF RIA Services, one of which allows you to achieve partial saves through the Entity.ApplyState-method.

Strategy 3: a mix of 1 & 2?

The third approach is a mix of the approaches I’ve described above: the same pros and cons apply, but instead of having no cons at all, you might end up with all of them in the same project… In general, I’m not such a fan of this – often, this simply results in having to have all possible workarounds in one project.

Conclusion

The Domain Context is really powerful, but you should be aware of how it works, and what the different strategies are for working with it. Each strategy has its own advantages and disadvantages, and workarounds for those disadvantages. The right strategy will highly depend on your project. In general, I would use the “one Domain Context instance per ViewModel” in cases where you absolutely need to be able to submit only the changes that are made on one ViewModel, and I’d use the “one shared Domain Context for all ViewModels” approach in cases where keeping the data automatically synced is important. From experience however, I find that most projects use the shared Domain Context approach.

Oh, and don’t forget: if you model your domain services right (eg: don’t design one Domain Service to track all your entities), you just might avoid a lot of problems, so that’s always the first thing to do.

About the author

Kevin Dockx lives in Belgium and works at RealDolmen, one of Belgium's biggest ICT companies, where he is a technical specialist/project leader on .NET web applications, mainly Silverlight, and a solution manager for Rich Applications (Silverlight, Windows Phone 7 Series, WPF, Surface). His main focus lies on all things Silverlight, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a Silverlight enthusiast, he's a regular speaker on various national and international events, like Microsoft DevDays in The Netherlands, Microsoft Techdays in Portugal and Belgium, or on BESUG events (the Belgian Silverlight User Group). Next to that, he also authored a best-selling Silverlight book, Packt Publishing's Silverlight 4 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on Silverlight, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/, and of course he can also be found on Twitter @KevinDockx.

Silverlight WCF RIA Services: Strategies for handling your Domain Context - Part 1

editorial@silverlightshow.net (Kevin Dockx ) — Thu, 17 Mar 2011 08:21:00 GMT

Don't miss...

($0.99)

All SilverlightShow Ebooks

This is the first in a two-part article series on the WCF RIA Services Domain Context.

This article series is accompanied by source code, which can be downloaded here.

Introduction

A lot of business applications that are being developed in Silverlight today are built with the help of WCF RIA Services. This should come as no surprise, as it’s a really powerful, extensible framework which provides us with a lot of features out of the box (validation, authentication, authorization, …) that otherwise would require quite a lot of custom code, workarounds & plumbing. In WCF RIA Services, you’re going to be working with a client-side Domain Context instance. This article will look into a few strategies on working with this Domain Context, and is accompanied by a demo & source code, which you can download here.

But let’s start with a short introduction on what a Domain Context actually is.

What is a Domain Context?

When you create a new Domain Service & build your project, you’ll notice a Domain Context class (a class inheriting DomainContext) has been generated for you on the client (in a Silverlight class library project if you’re using a WCF RIA Services class library, or straight into your Silverlight project): one for each Domain Service. If you create a Domain Service named MyDomainService, you’ll get a generated Domain Context on your client named MyDomainContext, which inherits from the DomainContext class. It contains query operations to fetch data, collections of the entities you’re exposing through the Domain Service, submit and reject operations, … It provides a lot of functionality to help you with change tracking & interacting with the underlying Domain Service.

Those of you who are familiar with an object relation mapper (ORM), like the Entity Framework, will feel right at home: working with the WCF RIA Services Domain Context is quite similar to working with the Object Context you get when using the Entity Framework: you load data into the Context, the Context has collections of Entities you’re exposing through your Domain Service(s), it allows for change tracking on these entities, and you get your typical submit & reject-operations. Of course, you’re working in an asynchronous, service oriented environment when using WCF RIA Services: what actually happens when you submit the changes on your Domain Context is that that same context is rebuilt on the server side, and submitted once completely built.

As an example, we’ll assume we’ve got an Entity Model with a Category & Book object (cfr John Papa’s Bookstore Club example). A Book belongs to a Category, so one Category can have multiple Book objects: we’ve got a Navigation Property Books on our Category. When you create a Domain Service, BookDomainService, and select these 2 entities, WCF RIA Services will generate all the CRUD operations for you. Note that this “generation” is done once; it’s nothing more than a bit of help to get you started (however: in real-life scenarios, take care of this: you do not want operations to be exposed through your services which aren’t used) – this is different from the generation of the client-side Domain Context, which happens on each build.

In your Silverlight application, you’ve now got a BookDomainContext. This Domain Context contains a list of Books and a list of Categories. Each Category from that list has a list, Books (eg: the NavigationProperty from the EntityModel).

Image we load all the categories & their books. We change 1 book, add 1 category and add 1 new book to that category. When you submit these changes, the UpdateBook method will get executed once, the InsertCategory & InsertBook methods will get executed once as well, and only after that, the server-side Object Context is submitted, resulting in the necessary queries to your DB. You can easily check this behavior by overriding the Submit method on your Domain Service: if you set a breakpoint on it, you’ll notice it will only get hit after the CUD operations have been executed.

So, in essence, what we’ve got is a client-side version of a server-side Object Context. Needless to say: this approach became very popular in a short amount of time, and WCF RIA Services is being used for large, line of business applications all over the world.

However: when you choose this approach, you should be aware of how the DomainContext works and what the different strategies for using it are. The explanation above should already give you an idea of its inner workings, but when starting a new project, an important question will always rise up: should I use one or more instances of my Domain Context(s)?

Instance strategies for your Domain Context

In essence, you’ve got to choose between 3 different approaches: working with one general Domain Context instance, shared across all your ViewModels, working with a specific Domain Context instance on each ViewModel, or a mix of the previous 2 approaches, where some ViewModels share the same Domain Context instance, and others have their own. We will now look into these approaches, list a few reasons to choose (or reject) a certain approach, and look into the issues that you might face with each approach.

First things first though: regardless of the chosen approach, it’s always a good idea to think about what should go in each Domain Service. Just a few months ago, we didn’t have a lot of choice: using the same entity in two different Domain Services wasn’t supported and resulted in an error. Since SP1, this has been solved: you can now easily share the same entity in different Domain Services (and thus have it tracked by different Domain Contexts). So that would be the first tip: split up your domain services depending on the functionality a certain module of your application requires. This not only keeps them much easier to maintain, it also allows for greater abstraction & code re-use.

Strategy 1: one Domain Context instance for each ViewModel

Choosing the right approach will typically depend on the (functional) requirements of your application. First of all, we’ll look into the “one Domain Context instance for each ViewModel” approach. This approach is used in a lot of examples you can find online, and it looks as the right way to go for a lot of applications.

The advantages aren’t hard to see: as a Domain Context cannot do partial submits, a submit operation on your context will submit all the changed entities on that context at once. One instance per ViewModel allows you to easily submit only the changes that have been made to your data used in that ViewModel. Next to that, if you’ve got different VM’s working on different sets of data of the same type, you can keep on working straight on the EntitySets (or CollectionViews on those entity sets) of your Domain Context instance. For example: in one ViewModel you could load all new Books in the Book collection on your Domain Context instance, in another ViewModel you could load all Books from a certain author in that collection on your Domain Context (of course, there are other ways to achieve the same – for example, working with ICollectionViews and filtering the data on the client or server, using filters on your EntityQuery, …). The essence is: your Domain Context isn’t shared, so it’s kept within the boundaries of that ViewModel: whatever you do on it, it’s not reflected in other ViewModels.

This is the approach we took when creating our 360 Review Application, of which I wrote a white paper a few weeks ago. Our main concerns here were: allow the user to navigate wherever he wants without requiring him to save changes before leaving an active screen (eg: a user could easily have 4, 5 active screens with unsubmitted changes), and only submit the data that is needed to the server per screen, not for all screens at once.

However, this does pose a problem: keeping your Domain Contexts in sync across different ViewModels. For example, imagine two parts of an application, two different ViewModels working on the same (or rather, related) data. A simple example could be: in one ViewModel, for example the one used in a sort of Dashboard screen in your application, you get an overview of all the Books in your DB. In another ViewModel, you’re allowing the user to add, edit, delete, … one of those books. Image you’re adding a new Book, submit the changes to server, and go back to the other view: the new Book won’t show up there, as, at the moment, it’s not being tracked by that DomainContext instance. You could of course automatically refetch the Employee collection whenever a user navigates to the dashboard View (and underlying ViewModel), but that’s not too good, performance and bandwidth wise.

How can we handle this? Well, out of the box, you can’t: there’s no way to automatically “sync” different Domain Context instances. It will require some custom code, and how do this, again, depends on your application requirements.

I’ve created an example application to show this behavior (note: the example applications uses Laurent Bugnions’ MVVM Light Toolkit - powerful & really lightweight, check it out if you haven’t done so yet, and John Papa’s Bookstore Club database).

In this application, you can see 2 views on the same page, of which the ViewModels have their own Domain Context instance. Both Views show a list of all the books in the database – they are bound to an EntitySet (Context.Books), which is loaded in the VM’s constructor. When you add a Book on the second view, a new Book (with some default values filled out) is added to the Domain Context, and the Domain Context is saved by calling its SubmitChanges() method. You’ll notice that the book is correctly added to the end of the book ListBox on the right, but it’s missing in the ListBox on the left.

So, how do we make sure both Domain Contexts are kept in sync? One possible approach would be to manually redo the changes you’ve made on one instance on the other. As you might know, entities can be attached to a context in code: what you can do is send a message when the book has been submitted, containing the entity you’ve just added, to a ViewModel that’s handling entities of the same type. The receiving ViewModel would then attach the Entity you pass in to its Context, resulting in 2 synced Domain Context instances. You do need to create a copy of the Entity to attach, as an Entity can only be tracked by one Domain Context instance at the same time. In our example, the code would look like this:

Submit the book in the ViewModel on the right, and create a new message:

private void AddBookAndAttachExecution()
{
    // add the book to the context, and save changes
    Context.Books.Add(NewBook);
    var submitOp = Context.SubmitChanges();
    submitOp.Completed += (send, args) =>
         {
             if (submitOp.HasError == false)
             {
                 // send a message telling any registered VM's a book has been added
                   Messenger.Default.Send(
                     new BookAddedMessage(NewBook));
                 // create a new book with default values
                 NewBook = new Book()
                 {
                     ASIN = "123",
                     AddedDate = DateTime.Now,
                     Description = "Default description",
                     Author = "Author",
                     Title = "Title",
                     PublishDate = DateTime.Now,
                     CategoryID = 1,
                     MemberID = 1
                 };
             }
         };
}

The message constructor creates a copy of the Book:

public class BookAddedMessage
{
    public Book Book;
    public BookAddedMessage(Book book)
    {
        // create a COPY of the book that's passed in. This one
        // is attached to another context, and you cannot attach the
        // same entity to two domain context instances.
        this.Book = new Book()
             {
                 BookID = book.BookID,
                 ASIN = book.ASIN,
                 AddedDate = book.AddedDate,
                 Description = book.Description,
                 Author = book.Author,
                 Title = book.Title,
                 PublishDate = book.PublishDate,
                 CategoryID = book.CategoryID,
                 MemberID = book.MemberID
             };
    }
}

The message recipient, in our example: the ViewModel on the left, attaches the Book to its context:

private void BookAddedMessageReceived(BookAddedMessage msg)
{
    // attach the newly added book (in an unmodified state)
    Context.Books.Attach(msg.Book);
}

This results in the following (Domain Context instances are in sync):

The advantage of this approach is that it doesn’t require an extra load operation to refetch the list of books from the server – the Book is submitted once, and all the rest is handled on the client (you might want to write an extension method to copy Entities to make your life easier). However, you’ll quickly run into the fact that designing your application like this will require a lot of maintenance: in this example, we’re only talking about 1 list of books, but in a real-life application, you’ll typically be handling a multitude of possible objects & child objects, which could be added, updated or removed, on a multitude of ViewModels with a multitude of Domain Context instances.

Another possible approach is to send messages to the related ViewModels, telling them that they have to refresh themselves. A refresh would re-load the data from the server, in this case: reload the list of books. In the example application, that would look like this:

Submit the book in the ViewModel on the right, and create a new message:

private void AddBookAndRefreshExecution()
{
    // add the book to the context, and save changes
    Context.Books.Add(NewBook);
    var submitOp = Context.SubmitChanges();
    submitOp.Completed += (send, args) =>
    {
        if (submitOp.HasError == false)
        {
            // send a message telling any registered VM's to refresh
            Messenger.Default.Send(
              new RefreshBooksMessage());
            // create a new book with default values
            NewBook = new Book()
            {
                ASIN = "123",
                AddedDate = DateTime.Now,
                Description = "Default description",
                Author = "Author",
                Title = "Title",
                PublishDate = DateTime.Now,
                CategoryID = 1,
                MemberID = 1
            };
        }
    };
}

The message recipient, in our example: the ViewModel on the left, refetches the list of books:

private void RefreshBooksMessageReceived(RefreshBooksMessage msg)
{
    // reload the data
    LoadData();
}
private void LoadData()
{
    Context.Load(Context.GetBooksQuery());
}

The disadvantage of this approach is that it comes with higher bandwidth usage: you’re refetching data from the server. But the advantage comes in the form of simplicity and lower maintenance: instead of having to pass through all the changed objects & child objects, you simply send one message: refresh entities of this type. Depending on how you wrote your EntityQueries, the child objects (when applicable) will be refetched if they need to be.

That’s all for the first strategy. Stay put for the second and third approach in the next part of this article series!

About the author

Getting ready for Microsoft Silverlight Exam 70-506 (Part 3)

editorial@silverlightshow.net (Gill Cleeren ) — Tue, 01 Feb 2011 03:39:00 GMT

SilverlightShow and Gill Cleeren start a series of materials aimed at helping you get prepared for taking Microsoft Silverlight Exam 70-506. Through this series we will try to structure the resources available on the internet, grouping them by topic covered in the exam. Any feedback would be much appreciated! Thanks!

More resources...

($9.99)

All SilverlightShow Ebooks

This article is Part 3 of the series on Microsoft Silverlight Exam.

In the previous parts of this series on getting yourself ready for the Silverlight exam, we mainly looked at UI related items. In the very first part, we looked at how Silverlight could help with layout, navigation, media and the core controls. In part 2, we focused on the many features Silverlight has on board to create better user interfaces, such as the Visual State Manager, styling, templating and animations.

This third part is going to be more aimed at the code-side of things. We’ll start our journey by looking at specifics of Silverlight such as routed events (these also exist in WPF by the way and asynchronous communication with services. We’ll look at dependency and attached properties as well, these are very important to a deeper understanding of Silverlight. We’ll look at the ICommand interface as well, which forms the base of commanding support for the MVVM-pattern in Silverlight. As you can see, we’ll be spending more time looking at C# code this time!

For your convenience, the following list contains links to the other parts of the article series which have been finished already:

Laying Out a User Interface (15%)
Enhancing the User Interface (14%)
Implementing Application Logic (16%) -> this part
Working with Data (17%)
Interacting with a Host Platform (11%)
Structuring Applications (13%)
Deploying Applications (13%)

Part 3: Implementing Application Logic

Do you remember the name WPF/E (the E stands for Everywhere)? It was the name Silverlight was known by before it got its final name. The reason I bring this up here is that it shows that Silverlight has inherited from WPF (Windows Presentation Foundation). The original name gives this away. Much of the core development platform we have today in Silverlight found its origin in Silverlight. Things like dependency properties and attached properties were introduced in WPF and later were ported into Silverlight. Some of these implementations are identical in the 2 technologies, others are somewhat trimmed down in Silverlight. Still, the development model available in Silverlight is solid and ready to build all types of applications on. Let’s dive into writing some code for Silverlight applications!

Handle events

Working with events in Silverlight is not very different from any other technology (note that we’re not looking at MVVM/commanding here yet). When we have some control in the designer, we can select it and select an event in the event window. Visual Studio will generate the event handler for us then as well as generate the event on the control in XAML. Not very different from ASP.NET or WinForms indeed! We can also choose to attach the event handler in code-behind using a delegate or even a lambda expression.

Silverlight has the notion of routed events. An event raised on a control nested within another control will bubble into the parent control so this parent can handle the event. This model is easy because Silverlight promotes nesting. This way, a TextBlock and an Image inside of a container (such as a Grid), all nested within a Button, will raise the click event to the Button, instead of us having to wire the event for the Button and its children manually.

To learn more about event handling, take a look at the following links:

Handling routed events / Bubbling events:
Bubbling of an event is a type of a routed event. At the time of writing, there’s only support for bubbling events in Silverlight. WPF also supports tunneling. Bubbling can be seen as a way to send an event higher in the hierarchy. Hence the name bubbling: it will bubble up in the XAML tree. Tunneling, which is only available for WPF, does the opposite, drilling down so to say in the XAML tree.
- Routed events in Silverlight 3: http://msdn.microsoft.com/en-us/library/cc189018(v=vs.95).aspx (contains information on AddHandler as well)
- http://www.silverlightshow.net/items/Routed-Events-in-Silverlight.aspx
- http://www.silverlightshow.net/news/Training-Session-on-Silverlight-Routed-Events.aspx
- Interesting thread on the Silverlight forums: http://forums.silverlight.net/forums/p/153909/343601.aspx
- http://www.silverlightshow.net/items/More-on-Routing-and-Bubbling.aspx
- http://www.kirupa.com/net/event_bubbling_tunneling.htm
- http://rongchaua.net/blog/silverlight-routed-event/
Implementing AddHandler:
Using the AddHandler, we can add an event handler for a routed event to the handler collection of an element.
- http://msdn.microsoft.com/en-us/library/ms598899(v=vs.95).aspx

Consume services asynchronously

Services are a vital building block for Silverlight applications. As business applications become more and more the focus of where Silverlight is going, data is needed in any app. Since out-of-the-box, Silverlight has no support for client-side database (I specifically said out-of-the-box, since there are some custom implementations such as Sterling database but these are not the focus for the exam), it has to access services for its data needs. Client-side databases would not be the solution for all problems either: if we build a shopping website in Silverlight, no developer would get it in his mind to transfer the entire product database to the client (let’s hope so at least!).

Luckily, Silverlight is well-equipped for working with all kinds of services. ASMX, WCF, REST, POX and RSS pose no problem for Silverlight. We can easily say that today, the default for building new services should be WCF or REST. However, if you have an existing implementation (legacy) in ASMX (plain web services), there’s no problem to consume these from a Silverlight environment.

When working with WCF or ASMX services, Visual Studio helps us out by generating a proxy class when adding a reference to the service. This proxy will make the actual calls to our service. This is not different from adding service references in other .NET technologies.

One big difference however is the fact that all communication happens asynchronously in Silverlight. No service can be communicated with in a synchronous manner. This would, while the Silverlight application waits for a response, lock the UI thread and therefore also the browser. Even in WCF RIA Services, where the async behavior is somewhat abstracted away, the communication still happens asynchronously.

(Shameless plug: in my book Silverlight 4 Data and Services Cookbook (Gill Cleeren – Kevin Dockx, Packt Publishing 2010), we have a very deep coverage of all things happening around accessing services).

Let’s look at some important information regarding working with services from Silverlight.

Creating and adding service references / Handling asynchronous completed events
Configuring service endpoints
- http://wildermuth.com/2008/11/08/Controlling_Service_References_in_Silverlight_2
- http://timheuer.com/blog/archive/2010/04/05/managing-service-references-in-silverlight-applications-for-different-environments.aspx
Handling service exceptions
- http://msdn.microsoft.com/en-us/library/ee844556(v=vs.95).aspx
- http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2#WCFSilverlightHandlingFaults
Handling timeouts

Work with background threads

Threading is the ability to push some long running task to a separate thread. By default, all the work is done on the single UI thread in Silverlight. If we launch for example a calculation that takes several seconds to complete in the main thread, the UI will be blocked and won’t be accepting any input until it has finished the calculation. By creating a separate thread to execute the work on, the UI thread won’t be blocked and the user can keep working with the application in the meantime. This is similar to what happens when connecting with a service: there’s also a time-consuming task that would block the UI if invoked synchronously.

Silverlight has a threading stack on-board. While it doesn’t contain all threading options available in the full .NET framework, there’s more than enough for scenarios where Silverlight is to be used. Silverlight also contains the BackgroundWorker class which makes working with threads easier.

One important thing concerning threading is that all code that executes on a separate thread has no access to the UI elements. It’s therefore not possible to write code in a callback that does something with a UI element (such as setting the Text of a TextBlock). There’s a workaround though in the form of the Dispatcher.BeginInvoke(), to which we can pass code that will be executed on the UI thread.

To learn more about threading, take a look at the following links and articles:

Spawning a background thread to execute code
- Thread class on MSDN: http://msdn.microsoft.com/en-us/library/system.threading(v=VS.95).aspx
- BackgroundWorker on MSDN: http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker(v=VS.95).aspx and http://msdn.microsoft.com/en-us/library/cc221403(VS.95).aspx
- http://10rem.net/blog/2010/04/23/essential-silverlight-and-wpf-skills-the-ui-thread-dispatchers-background-workers-and-async-network-programming (also contains overview of the BackgroundWorker class)
- http://www.silverlight.net/learn/videos/silverlight-videos/using-multiple-threads-with-the-backgroundworker/ (video)
Returning data to the UI thread by using the dispatcher object
The Dispatcher allows to pass code to execute on the UI Thread. Without this, we wouldn’t be able to change anything on the UI elements from a background thread.
Implementing the DispatcherTimer
The DispatcherTimer is a Timer which is integrated in the Dispatcher queue. It should be your default when using any timer in a Silverlight application.
- DispatcherTimer class on MSDN: http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatchertimer(v=vs.95).aspx
- http://blogs.silverlight.net/blogs/msnow/archive/2009/11/09/69731.aspx

Working with Dependency Properties

When I teach a Silverlight class, one of the hardest things to explain I think are dependency properties. Not because they’re that hard, certainly not. The thing is that dependency properties make something you know (the regular property system) to a new level. However, they do relieve us from writing a lot of code ourselves.

Dependency properties are the enabler for data binding, styling and animations. Without them, we would have to write a lot more code to get these things working. Most properties on UI objects in Silverlight (the FontSize property on a TextBlock, the Width property of a Rectangle…) are dependency properties, so in most cases, you’ve used them without even knowing it! When you start writing your own controls, you’ll need to start creating them as well, if you want your control to be able to take part in data binding, styling… It’s certainly recommended to do so, since other users of your custom-built controls will expect your controls to behave just like the default controls of Silverlight.

Let’s take a look at working with dependency controls:

Creating dependency properties / Specifying dependency property metadata / Getting and setting dependency property values
Creating dependency properties is more complicated than writing regular properties. You have to declare the DP by registering it with the dependency property system (on the DependencyObject). Optionally, you have to write code in a PropertyChangedCallback that will trigger when the value changes. Finally, you have to write a public wrapper for your DP. You won’t be accessing the value of the DP directly: you’ll always use this wrapper which internally uses the GetValue/SetValue defined on the DependencyObject class. These methods will retrieve the exact value of the DP at the given time, taking into account all the current influences taking place on the value and their priorities.
The topic of dependency properties in Silverlight is inherited from WPF. There’s a lot of interesting material on DPs in WPF as well from the following links:

Interacting with attached properties

Attached properties are properties defined on one control but used on a different control. Confused? Let me explain it with a simple example. Take the Row property on a Grid control. When we want to place a TextBlock in row #3 inside a Grid, we specify the Grid.Row property to have the value 3. However, the TextBlock does not have a “Grid.Row” property defined. Instead, the Grid has the Row property defined as an attached property. The attached property is defined as a global property, so that other control can use it. Most attached properties are defined on containers (Grid, Canvas…). This is because there needs to be some “communication” between the child control and the parent control. However, this is not required: your own control can too define attached properties if needed.

To learn more about attached properties, take a look at the following articles:

Setting attached properties in XAML
- http://www.silverlightshow.net/items/Attached-Properties-in-Silverlight.aspx
- http://msdn.microsoft.com/en-us/library/cc265152(v=vs.95).aspx
Getting and setting attached properties programmatically

Implementing ICommand

The MVVM pattern is something you’ve surely heard about already. The ViewModel (aka View-Model-ViewModel) pattern promotes separation of concerns. The ViewModel is an abstraction of the View: the View mostly XAML-only and it’s the place where the designer is focusing on. The ViewModel contains state and operations for the View. State can be seen as properties, operations are commands. The View falls back on the concepts of data binding and the DataContext to bind to an instance of the ViewModel.

When executing an action in the UI, for example clicking a Button, we think of adding an event handler and writing some event handling code in the code-behind. MVVM promotes commanding, which comes down to writing a public command in the ViewModel and binding to this instance in the View. When the command fires, the related code in the ViewModel gets executed. Therefore, we don’t write an event handler, instead we create a command instance and the ViewModel and bind to it.

Commanding is possible in Silverlight 4 because of the introduction of the ICommand interface. When creating a command implementation, we have implement the ICommand interface. Once we have our implementation, we can instantiate it, expose it as a public property on the ViewModel and bind to it in the View. In Silverlight 4, commanding is only supported on the ButtonBase class though. (Note: in many cases, we don’t implement the ICommand ourselves but we’ll use an existing implementation such as RelayCommand of MVVM Light or DelegateCommand from Prism).

The following articles can helpful when exploring the ICommand interface:

General implementation of ICommand:
Implementing an ICommand
- http://www.orktane.com/Blog/post/2009/03/09/I-Command-Silverlight.aspx
Binding to an ICommand:
- http://www.dotnetfunda.com/articles/article859-command-binding-in-silverlight-4-stepbystep-.aspx
Passing a parameter
- http://www.silverlightshow.net/news/ICommand-in-Silverlight-4-.aspx
- http://geekswithblogs.net/HouseOfBilz/archive/2009/05/22/adventures-in-mvvm-ndash-commands-in-silverlight.aspx

Summary

In this part, we prepared ourselves for the code-side of Silverlight. Not everything is XAML so there are some really important things to understand that you need to know in this area. Aspects such as Dependency Properties, Attached Properties and the ICommand interface are tools you’ll surely want in your Silverlight toolbox!

In part 4, data will be our focus, when we look at things like data binding and validation.

About Gill

Gill Cleeren is Microsoft Regional Director (www.theregion.com), Silverlight MVP (former ASP.NET MVP), INETA speaker bureau member and Silverlight Insider. He lives in Belgium where he works as .NET architect at Ordina. Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd Berlin 2010, TechDays Belgium, DevDays NL, NDC Oslo Norway, SQL Server Saturday Switserland, Spring Conference UK, Silverlight Roadshow in Sweden… He’s also the author of many articles in various developer magazines and for SilverlightShow.net. He organizes the yearly Community Day event in Belgium.

He also leads Visug (www.visug.be), the largest .NET user group in Belgium. Gill recently published his first book: “Silverlight 4 Data and Services Cookbook” (Packt Publishing). You can find his blog at www.snowball.be.

Twitter: @gillcleeren

A classic memory game: Part 2 - The game logic, connecting the ViewModel and the View

editorial@silverlightshow.net (Levente Mihály ) — Fri, 21 Jan 2011 09:54:00 GMT

This article is compatible with the latest version of Silverlight.

Don't miss...

Show more books

This article is Part 2 of “A classic memory game”.

The series is about building the following classic memory game in Silverlight, and porting it to Windows Phone 7. In the first article we started a new MVVM Light project, created the controls and designed the game-states. Now it’s time to put some code behind the game, and finish it.

Here’s the game itself and you can download the source code here.

The Game Logic

MVVM Light template

The MVVM Light project template contains a ViewModelLocator and a MainViewModel in the ViewModel folder. The ViewModelLocator’s job is to hold a reference of the ViewModels and to create them when needed. In the App.xaml there’s an instance of the ViewModelLocator, so the Views can bind to the ViewModel via this instance.

App.xaml:

<Application.Resources>

   <ResourceDictionary>

    <vm:MemoryViewModelLocator x:Key="Locator"

        d:IsDataSource="True" />

   ResourceDictionary>

Application.Resources>

MainPage.xaml:

<UserControl.DataContext>

   <Binding Path="Main" Source="{StaticResource Locator}"/>

UserControl.DataContext>

Model

To represent the cards, we have a MemoryCard class with the following properties:

the ID specifies which image is on the card
the Upside property indicates if a card is showing it’s face or back
the Solved property is set true once the card and its pair are found

The MemoryCard class implements the INotifyPropertyChanged interface. Classes that implement this interface must have an event delegate PropertyChangedEventHandler. Raising this event enables the View (that’s the MainPage.xaml) to track changes. So we need to raise this event when setting the Upside and the Solved properties. The ID won’t change in a MemoryCard’s lifetime so we don’t need to do anything there.

Here’s the Upside property and the raisePropertyChanged method.

/// 

/// The  property's name.

/// 

public const string UpsidePropertyName = "Upside";

private bool _upside = false;

/// 

/// Gets the Upside property.

/// Changes to that property's value raise the PropertyChanged event. 

/// 

public bool Upside

{

  get

  {

   return _upside;

  }

  set

  {

   if (_upside == value)

   {

     return;

   }

  _upside = value;

  // Update bindings, no broadcast

  raisePropertyChanged(UpsidePropertyName);

 }

}

public event PropertyChangedEventHandler PropertyChanged;

private void raisePropertyChanged(string propertyName)

    if (PropertyChanged != null)

        this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

The game logic

The logic is simple. In the MainViewModel’s constructor we’re setting up two timers (DispatcherTimers), one to turn back cards after a while and one for tracking the elapsed time. In the Start method we load the selected number of cards (based on the difficulty) and reset the score and start the elapsed timer.

We have a few properties to store the state of the game. The most important one is the list of the cards (MemoryCardList). The MainViewModel derives from BaseViewModel that means we don’t have to explicitly implement the INotifyPropertyChanged interface because it’s already implemented in the base class as well as the RaisePropertyChanged method.

Here’s the LoadCards method:

public void LoadCards()

{

    int cardCount = 0;

    switch (Difficulty)

    {

        case Difficulties.Easy:

            cardCount = 8;

            CardSize = 100;

            break;

        case Difficulties.Normal:

            cardCount = 10;

            CardSize = 78;

            break;

        case Difficulties.Hard:

            cardCount = 15;

            CardSize = 62;

            break;                

    }            

    // clear

    MemoryCardList.Clear();

    // add cards

    for (int i = 0; i < cardCount; i++)

    {

        MemoryCardList.Add(new MemoryCard(i)

        {

            Upside = false

        });

        MemoryCardList.Add(new MemoryCard(i)

        {

            Upside = false

        });

    }

    // shuffle them

    var rand = new Random();

    for (int i = MemoryCardList.Count - 1; i > 0; i--)

    {

        int n = rand.Next(i+1);

        var temp = MemoryCardList[i];

        MemoryCardList[i] = MemoryCardList[n];

        MemoryCardList[n] = temp;

    }

    IsGameEnded = false;

}

Note that we are adding two cards with the same ID at a time in the loop so we can pair them. After adding the cards we shuffle them. One last thing to explain: the CardSize specifies the actual size (width and height) of the cards in the View as we have smaller cards when there more. Keeping the CardSize in the ViewModel is not very elegant, it should belong to the View, I’ll probably refactor it.

The heart of the game is the OnSelectionChanged method. First we count the upside cards, if it’s two (which is actually one plus the newly flipped) we compare the IDs. If there’s a match they are solved. We have to check if there are any unsolved cards there to track the end of the game. If two cards are already upside showing their front, the newly selected would be the third card to show it’s front, so we have to flip back everything. Here’s the code:

public void OnSelectionChanged(MemoryCard lastCard)

{

    int upsideNo = MemoryCardList.Count((m) => m.Upside);            

    if (upsideNo == 1)

    {

        // one is upside + lastCard is 2, check IDs

        MoveCounter++;

        var upsideCard = MemoryCardList.First((m) => m.Upside);

        if (upsideCard.ID == lastCard.ID)

        {

            if (MemoryCardList.Count((m) => !m.Solved) == 2)

            {

                _elapsedTimer.Stop();

                EndGame();

            }   

            upsideCard.SetSolved();

            lastCard.SetSolved();

            PairCounter++;                                     

            return;

        }

        if (!_timer.IsEnabled)

        {

            _timer.Start();

        }

    }                

    else if (upsideNo == 2)

    {

        // two is already upside, hide them, lastCard will be the only upside

        _timer.Stop();

        hideCards();

    }            

}

Connecting the ViewModel and the View

After building the project the MainViewModel properties should show up in Blend’s databinding windows. We bind the MemoryCardList to the ListBox’s ItemSource. Click on the little square next to the ItemSource, choose DataBinding and select the MemoryCardList in the DataContext tab.

Now the ListBox will always display the cards in the ViewModel’s MemoryCardList property.

Converters

Blend’s databinding window shows only the compatible types by default. That means for example an IsVisible property type of bool won’t show up (by default) when you try to bind it to any element’s Visibility property, because the Visibility is type of a Visibility enum. Here enters the IValueConverter interface. When you build a class implementing this interface, you can pass it to the binding to have the data converted to compatible type.

A classic example is the VisiblityConverter for the Solved property (so it’s working the opposite way), note that only one way is implemented, we won’t need the ConvertBack:

public class VisibilityConverter : IValueConverter

{

    #region IValueConverter Members

    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

    {

        if (value == null) return Visibility.Visible;

        if ((bool)value) return Visibility.Collapsed;

        else return Visibility.Visible;

    }

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

    {

        throw new NotImplementedException();

    }

    #endregion

}

After build, you can set it up in Blend for the MemoryCard’s Solved property. Edit the CardList’s ItemTemplate, select the ToggleButton and bind the Visibility property:

Switch to all properties, select the Solved property, open the dropdown at the bottom of the window, and select the VisibilityConverter as Value converter.

You can bind the Checked property to the Upside property without a converter, because both of them are a type of bool.

Sometimes we need the ValueConverter in both ways, and sometimes we need additional parameters. To set the difficulty I needed both. There is a RadioButton for each difficulty, and we have one Difficulty property in the ViewModel type of an enum. So to make it work I needed to pass which RadioButton is the target. Here’s the code for the DifficultyConverter:

public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

{

    if (System.Convert.ToString(value).Equals(System.Convert.ToString(parameter)))

    {

        return true;

    }

    return false;

}

public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

{

    if (System.Convert.ToBoolean(value))

    {

        return Enum.Parse(typeof(Difficulties), System.Convert.ToString(parameter), true);

    }

    return null;

}

And here’s the Binding for the Easy difficulty to the button’s Checked property:

Another converter was needed for displaying the images based on the ID. The ImageConverter takes the ID and converts it to an ImageSource by resolving a naming convention.

Formatting text

Converters are often used to format text, for example converting a number to string in a desired format. Silverlight 4 however introduced the StringFormat extension. Unfortunately I couldn’t find any Blend support here, so we have to dive into code to make it working. The following code formats the move counter to a 2-digit style:

You can find a good summary about StringFormat on DesignerSilverlight.

CallDatacontextMethodAction

We have to connect not just the data in the ViewModel to the View, but user-actions too. The standard way for the View to notify the ViewModel that something is happened is by commands. A simpler and more designer friendly approach is the CallDatacontextMethodAction behavior by András Velvárt. You might have already read the article about it: A Designer-friendly Approach to MVVM.

After adding it to the project and building it we can add it to our Start button to call the Start method on the ViewModel.

Delaying an action

For the MemoryCard I had to delay the effect of setting the Solved property to true. What happened is by setting the card to solved it immediately disappeared, even before the control would arrive to the Checked state. This was clearly not okay, the player couldn’t see the card before it was marked as solved and disappeared. That’s why I introduced the SetSolved method that starts a timer and only after 1.5 seconds sets the Solved property to true thus making the card disappear.

The Messenger class

The ViewModel sends a signal to the View once all of the cards are collected by using MVVM Light Messenger class. The View then moves into the EndState:

Messenger.Default.Register<string>(this, (msg) =>

    if (Constants.EndGameMessage == msg)

        VisualStateManager.GoToState(this, EndState.Name, true);

});

The Messenger is used in the MemoryCard class as well. When the card is flipped it notifies the MainViewModel and that is when the OnSelectionChanged method runs, which is the heart of the game.

Summary

In this article we inspected the development aspects of a game leveraging on MVVM using bindings, visual states, transitions and behaviors. Expression Blend turned out to be a really powerful tool as for the whole game we needed only little coding.

In the final article of the series I will port this game to Windows Phone 7, exploring performance optimizations, phone-specific UI, and tombstoning. Don’t hesitate to drop a comment if you have questions or want to see something specific in the next article.

About the Author

My name is Levente Mihaly. I've entered the .NET world in 2006, and after graduating at Budapest University of Technology (Msc in Computer Science) I started working as a .NET software developer. After meeting technologies like WinForms and ASP.NET, Silverlight quickly became my favourite platform from the early Silverlight 2 beta stages. I was always interested in mobile development and now I'm very happy since with Windows Phone 7 I can easily expand my knowledge to the mobile world. Nowadays beside following Silverlight I'm focusing on WP7 in my free time. I'm also the runner-up of the 2010 Silverlight ecoContest. You can reach me on twitter (@leventemihaly).

Caching of, in, and around your Silverlight application (part 3)

editorial@silverlightshow.net (Kevin Dockx ) — Wed, 01 Dec 2010 10:13:00 GMT

This article is compatible with the latest version of Silverlight.

Don't miss...

($0.99)

All SilverlightShow Ebooks

This is the third in a 3-part series of articles about caching & Silverlight.

This is the third part in a 3-part series on Silverlight and Caching. The first part was about XAP & Assembly caching, which you can find here. In the part, we learned how we can leverage the Isolated Storage for caching in the same and between different Silverlight applications. You can find that article here. In this third and final part, we’ll look at the server side of things, and an extra piece of code to throw in the mix: a Silverlight caching provider.

The source code for this part can be found here.

Server side caching with a WCF Service

In the previous part, we’ve seen how we can make sure a certain server side method is only called once: when the data isn’t available on the client. But next to caching data on the client, it can also be cached on the server. But what’s the advantage of this? Sure, caching your data on the server might mean you only need to call your database once (assuming we’re fetching data from a database) – the next times, the data will come from the server side cache. But if we’re already caching the data on the client, aren’t we better off with that? With server side caching, you still need to call your service method every time, with client side caching, you only call it once, right?

Well: image a multi-user environment – pretty typical for most applications. If we use the example from the previous article, our GetCities operation, including the actual fetching of the data (which, in the example, is just using some dummy data, but in real-life would probably come from some kind of database), would be called once for each user. If you cache the data server side after the first data fetch, the first user call to the operation would result in a hit on your database. All the following calls, from different users, would result in getting the data from the server side cache instead of the database.

As you can see, this can offer tremendous advantages in multi-user environments. In a real-life environment, you should always combine client side caching with server side caching.

In a WCF service, you leverage the HttpContext’s Cache for this. Let’s adjust our example method:

[OperationContract]
public List GetCitiesCachedServerSide()
{
    string cacheKey = "CachedCities";
    // create a new generic list to hold the cities. 
    List cityList = new List();
    // check if the list is in cache
    if (HttpContext.Current.Cache.Get(cacheKey) == null)
    {
        cityList.Add(new City() { ID = "ANT", Description = "Antwerp" });
        cityList.Add(new City() { ID = "BRU", Description = "Brussels" });
        cityList.Add(new City() { ID = "GHE", Description = "Ghent" });
        cityList.Add(new City() { ID = "AMS", Description = "Amsterdam" });
        cityList.Add(new City() { ID = "PAR", Description = "Paris" });
        cityList.Add(new City() { ID = "LON", Description = "London" });
        cityList.Add(new City() { ID = "BAR", Description = "Barcelona" });
        // add list to cache for 5 minutes
        HttpContext.Current.Cache.Add(cacheKey, cityList, null, DateTime.Now.AddMinutes(5), 
Cache.NoSlidingExpiration, CacheItemPriority.Default, null);
    }
    else
    {
        // get list from cache
        cityList = (List)HttpContext.Current.Cache[cacheKey];
    }
    return cityList;
}

As you can see, we check if the list of countries already exists in the cache. If it doesn’t, we add it, making sure each next call will fetch the data from the cache.

internal void GetFromWCFCachedServerSide()
{
    // call WCF Service
    CityServiceReference.CityServiceClient client = new CityServiceClient();
    client.GetCitiesCachedServerSideCompleted += (send, args) =>
    {
        if (args.Error == null)
        {
            Cities = args.Result;
            userIsolatedStorageSettings["CachingCities"] = new ObservableCollection(args.Result);
            userIsolatedStorageSettings.Save();
        }
    };
    client.GetCitiesCachedServerSideAsync();
}

You’ve got a few options when adding an item to cache:

absoluteExpiration: enables you to define when an item in cache should become invalid, and thus removed from the cache. If you’re using sliding expiration, this should be set to NoAbsoluteExpiration.
slidingExpiration: defines the interval between when an object was last accessed and when it must be removed from the cache. If you’re using absolute expiration, this should be set to NoSlidingExpiration.
cacheItemPriority: the relative cost of an item in your cache. Items with lower cost are removed first.
onRemoveCallback: a callback method which will be called when an item is removed from cache.
dependencies: CacheDependency for the item you’re adding in the cache. If a dependency is changed, the item in cache automatically expires.

Server side caching with WCF RIA Services

A lot of Silverlight applications are built with WCF RIA Service. Rightfully so, as it offers tremendous advantages and is quite extensible. With WCF RIA Services, you’ve got a client side DomainContext, in which you can load your entities – and it keeps your entities there by default. This already results in quite a lot less data fetching operations when used correctly: often, the client side DomainContext is kept in an application-wide accessible LocalStateContainer (a simple static class) as a static property. The ViewModels that need data can directly access it from the DomainContext instance, keeping the need to refetch data to a minimum, and at the same time offering you the advantage that your screens stay “in sync” (as they’re all referring to the same data – change that data in one screen, and it’s automatically updated in a different screen using the same entities).

What’s less know is that you can also cache your WCF RIA Services result sets on the server – again, offering big advantages in a multi-user environment. The magic word here is the OutputCach attribute: decorate a query method with this method, and (depending on the options you provide), the resultset is cached for a certain amount of time. In the demo code, I’ve added a DomainService which returns a list of cities – this time, using WCF RIA Services instead of regular WCF. The resultset will be cached on the server:

[OutputCache(OutputCacheLocation.Server, 180, UseSlidingExpiration = true)]
public IQueryable GetCities()
{
    // create a new generic list to hold the cities
    List cityList = new List();
    cityList.Add(new CityForRIA() { ID = "ANT", Description = "Antwerp" });
    cityList.Add(new CityForRIA() { ID = "BRU", Description = "Brussels" });
    cityList.Add(new CityForRIA() { ID = "GHE", Description = "Ghent" });
    cityList.Add(new CityForRIA() { ID = "AMS", Description = "Amsterdam" });
    cityList.Add(new CityForRIA() { ID = "PAR", Description = "Paris" });
    cityList.Add(new CityForRIA() { ID = "LON", Description = "London" });
    cityList.Add(new CityForRIA() { ID = "BAR", Description = "Barcelona" });
    return cityList.AsQueryable();
}

And this is how we call the EntityQuery:

internal void GetFromRIAServCachedServerSide()
{
    var loadOp = LocalStateContainer.CityDomainContext

.Load(LocalStateContainer.CityDomainContext.GetCitiesQuery());
    loadOp.Completed += (send, args) =>
    {
        if (loadOp.HasError == false)
        {
            CitiesFromRIAServices = LocalStateContainer.CityDomainContext.CityForRIAs;
        }
    };
}

The OutputCache attribute can be provided with different options, of which these are the most important ones:

cacheLocation: defines where items can be cached: client, server, or both.
duration: the duration, in seconds, before an item will expire.
UseSlidingExpiration: if this is set to true, the duration will be reset each time an item from cache is accessed. If set to false, the item will expire after the duration – in absolute terms – has passed.
VaryByHeaders: if the message headers are different, a new item will be added to the cache instead of returning the already existing one.

Providing the missing parts: a Silverlight Cache Provider.

Throughout this article series, we’ve talked about various ways of caching. Those familiar with the ASP .NET Cache might have noticed something is missing in the Silverlight framework: yes, you can leverage the Isolated Storage for caching, but in a true caching scenario, you’d want to be able to make sure items in cache expire after a while. And are refetched automatically when needed, maybe? You might also want to make sure this is done with as little effort as possible throughout the development of your application. In ASP .NET, you’ve got the Cache store for this, but an equivalent doesn’t really exist in Silverlight: you have to write that yourself.

In the next few paragraphs, we’re going to do just that: write a Silverlight enabled cache provider.

What we want to end up with is:

A way to add items to your cache
A way to make sure these items expire after a while
A way to make sure these items are automatically refetched when needed
… and it should be easy to use

We’ll start out by defining the contracts. These contracts can be pretty simple – most of the work should be done in the specific implementations, which can vary depending on how you want to fetch the data (WCF, WCF RIA Services, …) and how you want to save the data (in memory, in Isolated Storage, …).

To start, we’ll need an ICache contract, which is our cache store. In the contract, we define a CacheStoreKey, a Put method and a Get method. Important to notice is this Get method should have a callback, as we’re working async if the item data isn’t loaded yet.

public interface ICache
{
    void Put(ICacheItem cacheItem);
    void Get(string key, EventHandler> callback);
    string CacheStoreKey { get;}
}

Next, we’ll need an ICacheItem contract, which should have a key, a function used to check if the data is available (and, eventually, fill the item with data) with a callback (used to pass through the Get method callback from the cache store), and a timespan which tells us how long the item is valid in cache.

public interface ICacheItem
{
    void CheckAndFillOrUpdate(EventHandler> callback);
    string Key { get; }
    TimeSpan ExpiresAfter { get; }
}

The specific implementation of the ICache contract will provide the cache dictionary used to keep the items. This results in the following code:

public class InMemCache : ICache
{
    Dictionary<string, ICacheItem> CacheDictionary = new Dictionary<string, ICacheItem>();
    public InMemCache(string cacheStoreKey)
    {
        _cacheStoreKey = cacheStoreKey;
        CacheDictionary = new Dictionary<string, ICacheItem>();
    }
    public void Put(ICacheItem cacheItem)
    {
        CacheDictionary.Add(cacheItem.Key, cacheItem);
    }
    public void Get(string key, EventHandler> callback)
    {
        if (CacheDictionary.ContainsKey(key))
        {
            var currentItem = CacheDictionary[key];
            currentItem.CheckAndFillOrUpdate(callback);
        }
    }
    private string _cacheStoreKey;
    public string CacheStoreKey
    {
        get
        {
            return _cacheStoreKey;
        }
    }
}

The idea is that putting an item in cache will not fetch it immediately: putting an item in cache is equal to defining how it will be fetched.

The ICacheItem implementation is a bit more complex. For this example, we’ll assume we’re working with WCF RIA Services, as this is the framework of choice often used in Silverlight applications. This means our implementation should be able to accept a function to load our items (which accepts an EntityQuery returns a LoadOperation) and the EntityQuery itself. You could probably simplify this somewhat with reflection, but as we’re writing a cache provider performance is important, and using reflection is typically quite resource intensive. Although you could argue that, to simplify the use of this provider, using reflection can be justified – it’s up to you.

This is how the implementation of ICacheItem looks:

public class InMemCacheItem : ICacheItem where S : Entity
{
    public T Value;
    public DateTime? LastCheck;
    public Func, LoadOperation> FillAndUpdateFunction { get; set; }
    public EntityQuery EntityQuery { get; set; }
    private string _key;
    public string Key
    {
        get
        {
            return _key;
        }
    }
    private TimeSpan _expiresAfter;
    public TimeSpan ExpiresAfter
    {
        get
        {
            return _expiresAfter;
        }
    }
    public InMemCacheItem(string key, TimeSpan expiresAfter,
        Func, LoadOperation> fillAndUpdateFunction,
        EntityQuery entityQuery)
    {
        this._key = key;
        this._expiresAfter = expiresAfter;
        this.FillAndUpdateFunction = fillAndUpdateFunction;
        this.EntityQuery = entityQuery;
    }
    public void CheckAndFillOrUpdate(EventHandler> callback)
    {
        if ((LastCheck == null) || (DateTime.Now.Subtract(ExpiresAfter) > LastCheck))
        {
            // refetch
            var lo = FillAndUpdateFunction.Invoke(EntityQuery);
            EventHandler handler = null;
            handler += (send, args) =>
            {
                lo.Completed -= handler;
                this.Value = (T)lo.Entities;
                LastCheck = DateTime.Now;
                // exec callback
                callback.Invoke(this, new GenericEventArgs(this));
            };
            lo.Completed += handler;
        }
        else
        {
            // the data is in cache and isn't expired, just execute the callback
            callback.Invoke(this, new GenericEventArgs(this));
        }
    }
}

All the pieces are in place, we can start using this provider. When you put an item in cache, you tell it how it should fetch its data:

CacheProvider.Put( new InMemCacheItem, CityForRIA>( "Cities" , TimeSpan.FromSeconds(100) , (query) => { return (LoadOperation)LocalStateContainer.CityDomainContext.Load(query); } , LocalStateContainer.CityDomainContext.GetCitiesForClientCacheQuery() ));

As said, what we’ve done here is the initialization of a cache item: this is not the data fetch itself, it just defines how data should be fetched when needed.

Fetching the data is done with the Get method on the cache store:

internal void GetWithCacheProvider() { // get from cache CacheProvider.Get("Cities", (send, args) => { // the callback CitiesFromRIAServices = new ObservableCollection( ((InMemCacheItem, CityForRIA>)args.Value).Value); }); }

What will happen is: if the data for an item in the dictionary is available and hasn’t expired it will come from that item’s value property: the callback will be executed immediately. If that isn’t the case, the data will be fetched using the method we’ve provided on initialization. After the data has been fetched, the Value property will be set, and the callback from the Get method we’ve provided will be executed.

With these few classes, we’ve now got a basic Silverlight cache provider. Due to the fact that we’re working on interfaces, not specific implementations of these interfaces, you can easily work from this example to create your own provider and extend it to your liking. Like that, you could serialize items to and from Isolated Storage next to using the Dictionary. You could enable multiple Cache stores at the same time. You could make sure your items are saved between different Silverlight sessions, or even shareable between different Silverlight sites by using the caching techniques from part 2 – it’s all up to you and depends on the requirements of your application.

Conclusion

In the last part of these article series, we’ve seen how we can cache server side, and we’ve brought all the previous techniques together by writing an extensible Silverlight cache provider. You should now have a good understanding on what caching in Silverlight means, and how you can profit from it in your applications.

I hope you’ve enjoyed the article series– I know I enjoyed writing it :-)

About the author

Kevin Dockx lives in Belgium and works at RealDolmen, one of Belgium's biggest ICT companies, where he is a technical specialist/project leader on .NET web applications, mainly Silverlight, and a solution manager for Rich Applications (Silverlight, Windows Phone 7 Series, WPF, Surface). His main focus lies on all things Silverlight, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a Silverlight enthusiast, he's a regular speaker on various national and international events, like Microsoft DevDays in The Netherlands, Microsoft Techdays in Portugal or on BESUG events (the Belgian Silverlight User Group). Next to that, he also authored a best-selling Silverlight book, Packt Publishing's Silverlight 4 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on Silverlight, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/.

Caching of, in, and around your Silverlight application (part 2)

editorial@silverlightshow.net (Kevin Dockx ) — Thu, 25 Nov 2010 07:40:00 GMT

This article is compatible with the latest version of Silverlight.

Don't miss...

Read interview with Kevin Dockx

My XAP file is 5 Mb size, is that bad?

This series is now available as a fully offline resource:

($0.99)

     All SilverlightShow Ebooks

This is the second in a 3-part series of articles about caching & Silverlight.

The first part was about XAP & Assembly caching, which you can find here. In this part, we’ll see how we can leverage the Isolated Storage for caching.

You can download the source code here.

Reusing data throughout your Silverlight application

But first, I’d like to tackle another issue I tend to get a lot of questions about: sharing data across different parts of your code, e.g.: across different ViewModels. Most of the people who ask me this type of question come from an ASP .NET / Web Application background, where you’ve got different pages in the same application, and you’d typically use something like Application State, Session State or even query strings to share data across different pages, and to avoid refetching it on each page (e.g.: you’re caching the data). If that’s what you’re used to working with, it’s very understandable you’re wondering what the Silverlight equivalent is.

The keyword here is: state. As you know, (X)HTML is stateless: once you post your page to the server to request a new/changed version, the state of your page (actually: the state of your complete application) is lost. ASP .NET works around this by providing you with various means to get some kind of state: ViewState (page level), Session state (user-specific) or Application state (app-wide, across different sessions). In essence, these techniques try to solve the fact that HTML is stateless by providing you with means to achieve some kind of state in your web application. Data you need across different sessions, for example: a list of countries for a combobox, would typically be saved in the Application State. Data that’s user-specific could be saved in the Session state, et cetera.

Fast forward to Silverlight. One of the big transitions one has to make when coming from a web background to Silverlight programming is getting used to the fact that Silverlight is stateful, not stateless: there’s no need for ViewState, Session state or Application state. If you look at it this way, programming a Silverlight application has much more in common with programming a desktop application than a web application, odd as it may seem. I’ve actually noticed that people coming from programming Windows Forms can often transition faster to correctly programming Silverlight applications, exactly because of this.

So: to share data across different ViewModels, what you need is a part of your application which is accessible by all your ViewModels. A typical way to solve this is to provide your application with a LocalStateContainer class. This is a static class which contains static properties. These properties hold your application-wide data – once you need them in a ViewModel, add a property to your ViewModel which gets its data from the LocalStateContainer.

Let’s assume our application needs to get a list of cities from a service. This list of cities should be available to all ViewModels in your application. We’ll start out by creating a WCF Service to get the list of cities. Add a City class to your Web application, and add a new Silverlight-enabled WCF Service which implements one operation: GetCities:

[ServiceContract(Namespace = "")] [AspNetCompatibilityRequirements(RequirementsMode =
    AspNetCompatibilityRequirementsMode.Allowed)] public class CityService { [OperationContract] public List GetCities() { // create a new generic list to hold the cities. List cityList = new List(); cityList.Add(new City() { ID = "ANT", Description = "Antwerp" }); cityList.Add(new City() { ID = "BRU", Description = "Brussels" }); cityList.Add(new City() { ID = "GHE", Description = "Ghent" }); cityList.Add(new City() { ID = "AMS", Description = "Amsterdam" }); cityList.Add(new City() { ID = "PAR", Description = "Paris" }); cityList.Add(new City() { ID = "LON", Description = "London" }); cityList.Add(new City() { ID = "BAR", Description = "Barcelona" }); return cityList; } }

Next, add a Service Reference to this service from your Silverlight application.

The LocalStateContainer class should now contain a static Observable Collection of cities. In the MainViewModel, we’ll fetch the data from the service, but we’ll only fetch the data when the city list is still empty. Once the cities have been fetched, we’ll put them in the LocalStateContainers’ City property.

internal void GetCitiesFromServiceOrIsolatedStorage() { // is there any country data in the Isolated Storage? if (userIsolatedStorageSettings.Contains("CachingCities")) { Cities = (ObservableCollection)userIsolatedStorageSettings["CachingCities"]; } else { // call WCF Service CityServiceReference.CityServiceClient client = new CityServiceClient(); client.GetCitiesCompleted += (send, args) => { if (args.Error == null) { Cities = args.Result; userIsolatedStorageSettings["CachingCities"] =
                    new ObservableCollection(args.Result); userIsolatedStorageSettings.Save(); } }; client.GetCitiesAsync(); } }

From now on, your city list is available application-wide. If you need access to this list, just add a property to a ViewModel which gets the cities from that LocalStateContainers’ Cities property.

For demo purposes, I’m fetching the list of cities in my MainViewModel. Depending on the type of application you’re designing, you could change this. One way would be to fetch the application-wide data right after your application has been started. Another way would be to fetch each list the first time it’s needed through a method in your LocalStateContainer class. There is no “right way” which works for each and every application: the “right way” always depends on the type of application you’re designing.

Reusing data across different Silverlight sessions.

In the example above, we’ve made sure we only need to fetch the application-wide data once. However: your data isn’t persisted across different Silverlight sessions, meaning that every time a client restarts his application, the data will have to be fetched again. It would be nice to able to save data across different sessions – and this is where the Isolated Storage comes into play.

From a Silverlight application, you can access the Isolated Storage on the client machine. The best way to look at this is as a virtual file system, which stores data in a hidden folder on the client machine. Each Silverlight application is allocated a part of Isolated Storage (by default: 1MB per application).

Through System.IO.IsolatedStorage.IsolatedStorageSettings, you can access the ApplicationSettings. Now you’ve got a Dictionary in which you can store data and/or from which you can fetch data. First, we’ll check if the dictionary already contains an item with key “CachingCities” (a unique key). If it does, we’ll fetch the data from Isolated Storage by filling the Cities property on our MainViewModel with the value from the CachingCities dictionary entry. If there’s no item with that key present, we fetch the data from our service, and save the data in Isolated Storage.

internal void GetCitiesFromServiceOrIsolatedStorage() { // is there any country data in the Isolated Storage? if (userIsolatedStorageSettings.Contains("CachingCities")) { Cities = (ObservableCollection)userIsolatedStorageSettings["CachingCities"]; } else { // call WCF Service CityServiceReference.CityServiceClient client = new CityServiceClient(); client.GetCitiesCompleted += (send, args) => { if (args.Error == null) { Cities = args.Result; userIsolatedStorageSettings["CachingCities"] =
                    new ObservableCollection(args.Result); userIsolatedStorageSettings.Save(); } }; client.GetCitiesAsync(); } }

Once the list is in Isolated Storage, the service call won’t have to be executed, even between different Silverlight sessions. Our application will display the list of cities:

One note of caution: although the Isolated Storage is hidden on the client machine, a user can still access the folder, so data stored isn’t completely secure. You can however use the Cryptography classes to encrypt the data you’re storing.

Clearing the Isolated Storage and asking for higher quota.

The Isolated Storage can be cleared as well, with the following statement:

internal void ClearIsolatedStorage() { userIsolatedStorageSettings.Clear(); }

If you’re only saving small amounts of data, the default 1MB storage space will probably be sufficient. However, if you’re saving large sets of data, you might require more. This requires user interaction: you need to ask the client if he wants to increase the amount of Isolated Storage space available to your application by executing the IncreaseQuotaTo command on the current User Store.

internal void IncreaseQuota() { using (var isf = IsolatedStorageFile.GetUserStoreForApplication()) { // ask for 5MB isf.IncreaseQuotaTo(5242880); } }

This will result in the user getting a popup like this:

To check the amount of space available to your application, right-click your Silverlight application, select “Silverlight” and navigate to the Application Storage tab. You’ll get an overview of the current usage & quote for all Silverlight applications using Isolated Storage on the current machine.

What about sharing the Isolated Storage between different applications?

Image the following scenario: you’re working for a company which uses a number of different Silverlight applications. All these applications use some shared data, for example: a list of employees, a list of company locations, … This is data which is pretty static, so you’d like to cache this data. However, if you’re using the Isolated Storage for this as we did in the previous paragraphs, each Silverlight application will have to fetch the list of employees, locations, … even though they are the same for each application.

There’s a solution to this problem: sharing data from your Isolated Storage across applications. In the previous paragraphs, we’ve used IsolatedStorageSettings.ApplicationsSettings. There’s another user store available: the user store for the current site. This store is shared across all Silverlight applications hosted on the same site.

You can access it through IsolatedStorageSettings.SiteSettings. However, in this case I prefer using the storage file directly (as you might know, IsolatedStorageSettings.ApplicationSettings and SiteSettings are just easy ways to access the underlying file, doing the serialization from/to objects in Isolated Storage for you, instead of having you write them yourself). I do this because IsolatedStorageSettings will save the data in its finalizer, which can actually result in different applications overwriting each others’ site settings with their own, resulting in empty data. By using the lower level API’s, you can make sure you won’t have this problem.

Let’s change the code from the previous example a bit, so we’re storing the data in the Site store for the current user:

internal void SaveCitiesToSiteStorage() { // get the city list and save it to the site store, so other applications on // the same site can access it. // call WCF Service CityServiceReference.CityServiceClient client = new CityServiceClient(); client.GetCitiesCompleted += (send, args) => { if (args.Error == null) { using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForSite()) { IsolatedStorageFileStream fileStream = null; fileStream = isf.OpenFile(
                    "mySiteStore",
                    System.IO.FileMode.Create,
                    System.IO.FileAccess.ReadWrite); XmlSerializer xmlSerializer = new XmlSerializer(
                    typeof(ObservableCollection),
                    "Cities"); xmlSerializer.Serialize(fileStream, args.Result); fileStream.Flush(); fileStream.Close(); fileStream.Dispose(); } } }; client.GetCitiesAsync(); }

If we now add another Silverlight application to our solution, hosted on the same site, we can access the data saved to Isolated Storage from the first application:

public MainViewModel() { // get city list from site settings using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForSite()) { if (isf.FileExists("mySiteStore")) { // fetch the data IsolatedStorageFileStream fileStream = isf.OpenFile(
                "mySiteStore",
                System.IO.FileMode.OpenOrCreate,
                System.IO.FileAccess.ReadWrite); XmlSerializer xmlSerializer = new XmlSerializer(
                typeof(ObservableCollection),
                "Cities"); Cities = (ObservableCollection)xmlSerializer.Deserialize(fileStream); fileStream.Close(); fileStream.Dispose(); } } }

So it’s pretty easy to share data across different Silverlight applications, but: they must be hosted on the same site.

Conclusion

This concludes the second part of this article, in which we’ve looked into various ways of leveraging the Isolated Storage to cache your data between sessions and/or between different applications. Stay tuned for the next (and last) part, which will tackle server-side caching.

About the author

Kevin Dockx lives in Belgium and works at RealDolmen, one of Belgium's biggest ICT companies, where he is a technical specialist/project leader on .NET web applications, mainly Silverlight, and a solution manager for Rich Applications (Silverlight, Windows Phone 7 Series, WPF, Surface). His main focus lies on all things Silverlight, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a Silverlight enthusiast, he's a regular speaker on various national and international events, like Microsoft DevDays in The Netherlands, Microsoft Techdays in Portugal or on BESUG events (the Belgian Silverlight User Group). Next to that, he also authored a best-selling Silverlight book, Packt Publishing's Silverlight 4 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on Silverlight, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/.

WCF RIA Services Part 9 - Structuring Your Application

editorial@silverlightshow.net (Brian Noyes ) — Wed, 24 Nov 2010 06:08:00 GMT

Watch recordings of Brian's WCF RIA Services webinars:

Querying & Updating Data From Silverlight Clients with WCF RIA Services (Feb 03, 2011)

WCF RIA Services Validation (Mar 17, 2011)

Secure and Personalize Your Silverlight App with WCF RIA Services (May 26, 2011)

WCF RIA POCO Domain Services (Sep 29, 2011)

Don't miss...

Deep Dive Into WCF series

See more articles on WCF

WCF RIA Services Show

The WCF series is now available as a fully offline resource:

     All SilverlightShow Ebooks

This article is Part 9 of the series WCF RIA Services.

Introduction

In all the articles up to this point, I have been dumping all the domain service stuff into the single web project that also hosts the Silverlight application. Additionally, I've been putting a lot of functionality into the single Silverlight Application project on the client side. Granted it is only a couple of views so far. But if this app grew to a couple dozen views, I really would not want to be putting all those into a single project. In a real world app, too much code in one place, whether in a single method, a single class, or a single project is a maintenance liability. Additionally, on the server side you might want to start partitioning the code into logical layers, such as breaking out a separate data access layer project from the domain service code, and you might want separate projects for different sets of domain services.

In this article, I'm going to focus on how to break your solution up into multiple projects on both the server and client sides. I'll show how you can break things up into vertical slices that support different use cases in your application or different functional areas. You'll quickly learn how to use WCF RIA Services Class Library projects, as well as how to break things up into multiple XAP files on the client side. Using the Managed Extensibility Framework or Prism 4, you can break up your client application into multiple modules that get developed and built as separate XAP files, and then get downloaded asynchronously when needed by the client application. When you go down this path, unfortunately Visual Studio gets in your way a little bit for setting up your WCF RIA services link with the server project. I'll show you how to easily get past that limitation as well.

You can download the sample code for this article here.

Client-Server Project Relationships

One thing to understand up front is that there are some architectural constraints implied by the use of WCF RIA Services. Because of the way the RIA Services code generation process works, if you want to consume a WCF RIA DomainService from a client project, that client project has to have a link to the server project that contains the domain services you want to consume. That means that a single client project can only point to a single server project. You can have multiple client projects that point to the same server project, and the code generation will happen in each client project. But then if those projects are all used in the same scope, you will have duplicate types defined in the same scope, and will run into problems there. So to keep things clean, you will want to maintain a one-to-one correspondence between a single server project where a set of domain services is defined and a single client project where the client code for those services gets generated. However, the client project can just be a class library that can be reused across multiple modules or client applications. So your architecture will tend to look like this as you start to partition things:

Adding a WCF RIA Services Class Library Project

The way to get started breaking things up is to add a new WCF RIA Services Class Library project to your solution. In this case, say I wanted to add some separable functionality to my application, such as the ability to add notes. I would select Add > New Project from Solution Explorer with the solution node selected, and pick the WCF RIA Services Class Library project type.

Once you add this project, you really are adding two projects, the client Silverlight Class Library and a server normal Class Library project. The RIA Services link will already be set between the projects, and it adds them to the solution under a new solution folder.

You do not really have to use this project type to get this architecture though. You could just add a new Silverlight Class Library to the solution, then add a normal Class Library as well. Then you would just go to the project properties of the Silverlight Class Library and set the WCF RIA Services link drop down to point to the new server class library project. Then you would just have to add the WCF RIA Services references to the client and server projects. This just gets you all that done in one fell swoop. And since the client and server projects are linked, having them in a solution folder is a decent way to group them.

You would then add a new domain service to the TaskManager.Notes.Web project to get started defining your new service functionality and its associated entities. Its code generated client code will end up in the TaskManager.Notes client library. Then you would add a reference from the main client TaskManager Silverlight application to the TaskManager.Notes class library to start using those domain services in the main app. You could add new views and client functionality to that same class library as well. If you wanted to separate out your data access logic into its own class library, you would just add a new class library project and add your Entity Data Model into that project. Then add a reference to that class library from the class library that is going to contain your domain service. Remember to build before adding the new domain service so that it will see your entity framework model and let you pick from its entity types.

The resulting solution tree after adding some views and the data access library is shown below.

Using Entities Across Domain Services

In WCF RIA Services version 1, there is a limitation that you cannot have two domain services being used by the same client application that expose the same entity type. This is just a limitation of the way the client side code generation is done, because it will try to generate the same entity type once for each service and you will have duplicate definitions. This is fixed in WCF RIA Services SP1, which is available in beta form at the time of writing this here. But if you stick to the current release version, you will have to factor your vertical slices so that a given entity type is only used in one of the domain service vertical slices.

Breaking Your Client Application into Multiple Modules

As mentioned earlier, using MEF or Prism you can break your client architecture into modules – or separate chunks of functionality that can be downloaded asynchronously at runtime. For this article, I’ll just use MEF directly. I’ll be doing some articles on Prism 4 in the near future as well.

To do this, you need to put your functionality in a project that compiles to a separate XAP file from the main application. That requires you to pick the Silverlight Application template when creating the project, as opposed to a Silverlight Class Library or a WCF RIA Services Class Library project.

If I were going to do something similar to what I showed earlier in the article but wanted that new notes functionality to be downloaded separately as a module the first time it is used, the first step would be to create a new Silverlight Application project in my solution named TaskManager.NotesModule.

In the pop up that prompts for creating a server project, uncheck the box for hosting the application.

After the project is created, delete App.xaml and MainPage.xaml from the new project.

Next you will add the server class library where the domain service will live. Add a new Windows Class Library project and call it TaskManager.NotesModule.Services. You can delete Class1.cs from the new class library project as well. You could then add a domain service to that project, possibly using an entity data model defined in a separate class library as discussed earlier.

If you open the TaskManager.NotesModule Silverlight project settings at this point, the first thing you will need to do is set the startup object to (not set). That is because this project is not intended to be a standalone Silverlight application, but we are just using the Silverlight Application project type because its build output is to produce a XAP file with the contents of the project.

The trick comes when you go to set up the RIA Services link. If you drop down the WCF RIA Services link setting, you will not see the class library that contains your domain service listed as an option. This is really just a bug in the tooling. That drop down really just sets a relative path to the server project in the client project’s csproj file (or vbproj). Since the tool won’t let you set it correctly, you have to open the csproj file and edit it directly.

To do so, right click on the project and select Edit Project File.

If that option is not available for you, you can also just open the .csproj in any text editor. The setting you are looking for.is called LinkedServerProject. You need to fill it in with the relative path to the .csproj file of the server project. For example, in my case, the path is:

After adding this and saving the file and closing it, you can then right click on the project in Solution Explorer and select Reload Project. If you then go look at the project settings again, you will see it is now showing the right server project. If you build, you will get the client generated code in your module project from the linked server project.

Using MEF To Dynamically Load the Module

Now all that is left is to load the module dynamically with MEF. I don’t have room for a full lesson on MEF, but what I am going to use here is MEF’s ability to download a separate XAP file asynchronously and then plug in the parts it finds in that XAP to the application dynamically. For a great overview of this capability, I recommend you check out this Silverlight TV Episode with Glenn Block.

The first step is to add the MEF System.ComponentModel.Composition reference to the TaskManager.NotesModule project. You can then mark the parts you want to plug in with appropriate Export attributes. In this case, I am going to plug in a single ChildWindow derived view called NotesView. So I add the following Export to the code behind of that view:

[Export(typeof(ChildWindow))]

public partial class NotesView : ChildWindow

{

}

Next, I need to add a little code the main app to download the separate XAP file asynchronously when appropriate. First step is to add references to the TaskManager project to System.ComponentModel.Composition.Initialization and System.ComponentModel.Composition. Then I add the following code to the code behind of the main page:

[Import]

public ChildWindow PlugInPopup { get; set; }

bool plugInsInitialized = false;

private void button1_Click(object sender, RoutedEventArgs e)

{

if (!plugInsInitialized)

{

plugInsInitialized = true;

var deployment = new DeploymentCatalog("TaskManager.NotesModule.xap");

deployment.DownloadCompleted += (s, e2) =>

{

CompositionInitializer.SatisfyImports(this);

ShowPopup();

};

CompositionHost.Initialize(new DeploymentCatalog(), deployment);

deployment.DownloadAsync();

}

else

ShowPopup();

}

private void ShowPopup()

{

if (PlugInPopup != null)

PlugInPopup.Show();

}

The PlugInPopup property will be populated by MEF after the extra XAP is downloaded. Constructing a DeploymentCatalog with a relative path to the XAP file in the host site of this application allows it to download that XAP file asynchronously when told to do so with the DownloadAsync call. You can see that the code subscribes to the completed event for that download, and then calls SatisfyImports to get the container to do dependency injection on this already existing view. At that point the PlugInPopup property gets populated, and is then shown.

The last part to making this work is to add the TaskManager.NotesModule project to the host Web site (it does not need a test page) so that it is in the ClientBin directory and can be downloaded.

The key point here is the need to manually edit the project file to point to the right server project where your domain services live. Just because Visual Studio doesn’t always let you point to any project in your solution (or outside of the solution for that matter), the only requirement is that the LinkedServerProject have a relative path to a compiled project that contains domain services. So a simple edit of the project file gets you want you want to organize your projects how ever you want, as long as you maintain that one-to-one relationship between client and server projects.

Summary

When it comes to organizing and structuring your solution, you can see that you have good flexibility to start breaking up chunks of functionality on the client and server sides into separate libraries and modules however it makes the most sense for your project. You should think in terms of breaking out vertical slices of functionality, composed of a server library project that contains a domain service or several that are related and all their supporting functionality and definitions on the server side. You will link that to a single client project, typically a Silverlight Class Library project or Silverlight Application project if you are trying to be more modular and download modules separately as separate XAPs. Even though you can have a single server project linked from multiple client projects, it will generally cause problems to do so within the same application because of duplicate definitions. So using client side class libraries that just contain the code generated RIA Services code and then referencing that class library from wherever that functionality is needed within the client application gives you flexibility to compose the client side however you want. Also remember that in WCF RIA Services SP1, the constraint on having one domain service “own” a single entity type is lifted.

You can download the sample code for this article here.

About the Author

Brian Noyes is Chief Architect of IDesign, a Microsoft Regional Director, and Connected System MVP. He is a frequent top rated speaker at conferences worldwide including Microsoft TechEd, DevConnections, DevTeach, and others. He is the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding in Windows Forms 2.0. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on twitter @briannoyes.

Caching of, in, and around your Silverlight application (part 1)

editorial@silverlightshow.net (Kevin Dockx ) — Thu, 18 Nov 2010 07:21:00 GMT

This article is compatible with the latest version of Silverlight.

Don't miss...

Read interview with Kevin Dockx

My XAP file is 5 Mb size, is that bad?

This series is now available as a fully offline resource:

($0.99)

     All SilverlightShow Ebooks

This is the first in a 3-part series of articles about caching & Silverlight.

You can download the source code here.

A lot can be written about this subject, and because of that, quite a few misunderstandings about Silverlight and caching exist.

Let’s start with a general definition of caching: this is what Wikipedia has to say about this technique:

In computer science, a cache is a component that improves performance by transparently storing data such that future requests for that data can be served faster. ... (en.wikipedia.org/wiki/Caching)

Well, that sure opens up a lot of possible places to cache, in and outside of your Silverlight application. Can you cache the complete Silverlight application? What’s this assembly caching you keep on reading about? How do you go about keeping your data on the client when navigating to different parts of you application, instead of refetching it all the time? Can you leverage the Isolated Storage for caching, and is it possible to persist data in between different application sessions? Is it possible to share cached items between different Silverlight applications? And what about the server-side: can I minimize database hits when launching queries from my Silverlight application?

If you’ve ever asked yourself one (or more) of these questions, this article series is for you. As you might notice when seeing them in the same paragraph, these questions are about different ways of caching, and they all apply to different scenarios.

In the first part of this series, I’d like to talk about the caching of your Silverlight application itself and Assembly Caching – almost no code is required for this.

XAP Caching

Every Silverlight application consists of one or more XAP files. Smaller applications typically consist of one XAP, but larger applications might benefit from dividing your application into different application modules, compiling into different XAP-files which are loaded on demand. When a user first navigates to a page hosting a Silverlight application, the full XAP has to be downloaded to the client. As an XAP typically contains a bunch of referenced assemblies, your XAML files, compiled code and everything else you’ve included as embedded resources in your Silverlight project, these files have a tendency to get quite big. Therefore, being able to cache these files will reduce the time a user has to wait to access your application.

Luckily, this is done by default with the help of your browser cache. Once a Silverlight application has been downloaded to the client, it will automatically be cached in the browsers’ temporary files. The next time a user accesses your Silverlight application, the XAP will be loaded from the browser cache (well, as long as it hasn’t been cleared of course – browser caching is controlled by the client and/or browser, we cannot assume anything in this case) instead of from the server.

However, as a developer, this might pose some problems. Imagine the following scenario: a user has opened your Silverlight application, so it’s in the browser cache. In the meantime, you find a bug in your application, solve it, and roll out a new version of your app. Next time that user accesses the hosting web page, you of course want him to get the new version of your application. However, as the previous version is in his browser cache, he will get that version instead of the new one… Luckily, you can control when an XAP should expire (as you can with every file) through IIS.

Open up Internet Information Services Manager, and navigate (in Content View) to the website you’re hosting your Silverlight application on. Select the XAP, open up the Features view, select HTTP Response Headers, and click on Set Common Headers in the Actions pane. Choose “Immediately” in the Expire Web Content popup, and close the popup again.

After you’ve done this, a new version of the XAP will be downloaded to the client when he accesses the hosting web page, even if he already has a version of your application in his browser cache.

As you can see, you also have the option to let the file expire at regular intervals. This might come in handy in a development/test environment: if you’re running a server which receives a new nightly build of your application so the test team can work on the new version the day after, it might be a good idea to use one of these options to ensure the testers will always test on the latest version.

XAP Caching in an Out of Browser scenario?

If you’re designing an Out of Browser application, you might notice your XAP doesn’t get updated automatically – even if you’ve made sure it’s expired, and a new version should be downloaded. This is because in an Out of Browser scenario, you need to download the new version yourself. This is typically done in the application startup method:

private void Application_Startup(object sender, StartupEventArgs e)
{
    // OOB new version check
    this.CheckAndDownloadUpdateCompleted += (send, args) =>
        {
            if (args.UpdateAvailable)
            {
                MessageBox.Show("A new version of the application is downloaded, please restart the application to launch the new version.");
            }
        };
    this.CheckAndDownloadUpdateAsync();

    this.RootVisual = new MainPage();
}

This code will ensure your Out of Browser application is updated as well.

Assembly Caching

In Silverlight 3, a new feature was introduced: assembly caching. A lot of people don’t seem to know what this feature actually does, and therefore hesitate to use it. Assembly caching makes sure external assemblies are not packaged in the XAP file, making the XAP itself significantly smaller. Whenever a user accesses your application, the external assemblies will be downloaded from their respective locations: this can be the Microsoft site, a vendor-specific location (if you’re using a 3^rd party control library, for example), or even your own central assembly repository. In a default scenario, the assemblies themselves are copied to the ClientBin directory, so they’re always available.

You might wonder: what’s there to gain from this? In the end, the assemblies must be downloaded anyway, so the total download size / time is about the same, right? This is where your browser cache comes into play: as with the XAP file itself, the external assemblies are cached by your browser. This means that if the assembly is already in your browser cache, it does not have to be downloaded again. If you combine this knowledge with content expiration, you can now image a scenario where you roll out a new version of your Silverlight application, expire the XAP immediately (so a new version is delivered to the client), but leave the unchanged external assemblies alone, so they don’t expire. Now, when a client navigates to your application, the new version of the XAP will be downloaded, but the external (unchanged) assemblies will come from the browser cache.

To enable assembly caching, navigate to the project properties of your Silverlight application, and check Reduce XAP size by using application library caching:

If you rebuild your application, you will notice your ClientBin directory now contains zip-files (one for each external assembly you referenced). For example purposes, I’ve added a reference to System.Windows.Controls.Toolkit to my Silverlight application, resulting in 2 zip files: System.Windows.Controls.Toolkit.zip and System.Windows.Controls.zip (which is used by the Toolkit assembly):

Needless to say, as far as strategies to reduce your XAP size (and thus: decrease download time) are concerned, this feature should not be overlooked.

One final word of notice: this feature cannot be combined with an Out of Browser Silverlight application.

Conclusion

This concludes the first part of this 3-part series on caching, in which we’ve learned about how to leverage and control the browser cache, and how to enable Assembly Caching in your Silverlight application. In the next part, we’ll have a look at using the Isolated Storage to enable various caching scenarios.

About the author

Kevin Dockx lives in Belgium and works at RealDolmen, one of Belgium's biggest ICT companies, where he is a technical specialist/project leader on .NET web applications, mainly Silverlight, and a solution manager for Rich Applications (Silverlight, Windows Phone 7 Series, WPF, Surface). His main focus lies on all things Silverlight, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a Silverlight enthusiast, he's a regular speaker on various national and international events, like Microsoft DevDays in The Netherlands, Microsoft Techdays in Portugal or on BESUG events (the Belgian Silverlight User Group). Next to that, he also authored a best-selling Silverlight book, Packt Publishing's Silverlight 4 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on Silverlight, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/.

Paging WCF Ria Services entities in Model-View-ViewModel applications

editorial@silverlightshow.net (Andrea Boschin ) — Wed, 20 Oct 2010 11:16:00 GMT
This article is compatible with the latest version of Silverlight.
Download sources & video

More on this topic..

See more articles on WCF

See more articles on MVVM

All articles by Andrea Boschin

There is no doubt that "WCF Ria Services" are a great tool for implementing applications that need to present data from any source. There it is a lot of work spared in creating services and proxies and interacting with the service itself. Personally the thing I love so much is the Validation tools that are very powerful and complete and the capability of sharing code between server and client that make the separation between them something of undistinguishable.

Toghether with WCF Ria Services there are a set of components that are not so useful to consume services. Particularly I usually prefer not to use components like DomainDataSource because it brings my queries directly into the Views and it is a very bad thing. Microsoft has spent long time to create similar components - I remember SqlDataSource and LinqDataSource in ASP.NET - but they are targeted for very simple applications that have a short lifecycle. Someone found ways to use the DomainDataSource in MVVM scenarios but my feel is again bad because of its intrinsec slowness and because many thing I have to do are not strongly typed and this opens the way to runtime errors I wouldn't want to deal with.

In this article I would want to investigate a possible solution, made with a custom PagedDataSource component specifically created for MVVM applications, and the way it might be useful to page queries.

Discovering the inside of DataSource controls

If you investigate about the intimate functioning of the DomainDataSource and of some other similar components (e.g. the CollectionViewSource) you will soon meet an interface ICollectionView that is the very inner core of the component. This interface it the source of many of the functions you expect from the DataSource components while it support current record, filtering and sorting. Watching in more detail you will find also another interesting set of interfaces including IEditableCollectionView and IPagedCollectionView. The one I would like to delineate here is the IPagedCollectionView that grants the capability of paging resultsets. Here is the definition of this interface:

public interface IPagedCollectionView

{

// Events

event EventHandler PageChanged;

event EventHandler PageChanging;

// Methods

bool MoveToFirstPage();

bool MoveToLastPage();

bool MoveToNextPage();

bool MoveToPage(int pageIndex);

bool MoveToPreviousPage();

// Properties

bool CanChangePage { get; }

bool IsPageChanging { get; }

int ItemCount { get; }

int PageIndex { get; }

int PageSize { get; set; }

int TotalItemCount { get; }

}

The interface contains a big number of members, but we can shorten them to a bunch of groups; There are a set of methods to perform navigation in the result set, moving the cursor up and down to the pages. We have a property (PageSize) to configure the component and other properties to read the current state, including the current page index, and the number of items in the view. Finally we have a couple of events that notify about the start and end of the page changes.

The beautiful of this interface is that controls like DataGrid and DataPager directly understands and interacts with it to perform data pagination. So implementing the inteface is the first step to have a MVVM-targeted PagedDataSource. Then we will can pass the component directly to Data controls and having them work seamless like a normal DataSource control.

Implementing the PagedDataSource

Before starting to develop the new DataSource it is important to understand what is the expected behavior. First of all, starting from what we do not want, the component will not be used in the XAML. This mean it is not required it implement a base class like Control or ContentControl. As we will see in the following of the article the component will be very lightweight and it will suffice to implement only a little set of interfaces.

The preferred usage of our new PagedDataSource is that it is exposed by a property in the ViewModel, and this property binded to the controls that have to show the data. To achieve this result it is important that the DataSource implements IEnumerable and INotifyCollectionChanged. This way we can directly connect the consumer to the data source and having it populated and also having the consumer react to the changes we will make to the data.

Finally, due the fact that some properties exposed by the component have to be monitored by the consumer, we have to implement also the INotifyPropertyChanged interface. So, here is how it appear the declaration of the PagedDataSource class:

public class PagedDataSource : IPagedCollectionView, IEnumerable, INotifyCollectionChanged, INotifyPropertyChanged

where T : Entity

{

// implement class here

}

Watching at these few lines there is another thing to say: The component is declared as a Generic type, with a constraint that impose T to be derived from the class Entity. You can understand this constraint if you remember that every WCF Ria Services method returns a IQueryable, where T will be an Entity of the underlying datamodel. What we will expect is to pass a query to the PagedDataSource and having the query "automagically" paged. So, T will be an element we will use often during the implementation to shorten the code required to use the PagedDataSource.

The following step is to connect the PagedDataSource to the DomainContext. It is not required a specific type of domain context but simply handle every class deriving from DomainContext so we will can handle every type of data source and not only the Entity Framework. In the constructor we take a reference to the EntitySet that has to be contained in the DomainContext, for future references.

public PagedDataSource(DomainContext context)

{

this.PagedEntitySet = context.EntityContainer.GetEntitySet();

this.Context = context;

}

Once we have initialized it the PagedDataSource it start to follow a precise lifecycle. First of all it loads the first page, according with the specified PageSize and PageIndex, then it notifies the consumer of the data available raising a CollectionChanged event. The consumer now reads the entity instances from the PagedDataSource using the implemetation of IEnumerable. When the ViewModel or a DataPager calls one of the Move methods, the component loads the new page and again notifies the consumer. The lifecycle is really simple but it have its core in the Refresh method that is responsible to load the required page of entities, without loading all the data in the table. Here is the source of the method:

public void Refresh()

{

this.IsPageChanging = true;

if (this.OnPageChanging(this.PageIndex))

{

this.IsPageChanging = false;

return;

}

this.PagedEntitySet.Clear();

QueringEventArgs query = new QueringEventArgs();

this.OnQuering(query);

query.Query.IncludeTotalCount = true;

this.Context.Load(

query.Query

.Skip(this.PageIndex * this.PageSize)

.Take(this.PageSize),

LoadBehavior.RefreshCurrent,

lo =>

{

this.IsPageChanging = false;

this.ItemCount = this.TotalItemCount = lo.TotalEntityCount;

this.OnPageChanged();

this.OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));

}, null);

}

Probably it is the most complex method in the component so let me explain it row-by-row; In the first part the method sets the IsPageChanging property (it is part of the IPagedCollectionView interface) to indicate that the change of the page is in progress. Then it raises the PageChanging event giving to the ViewModel the last chance of cancel the change since its EventArgs is cancelable.

If the code authorizes the component to perform the page change, the EntitySet into the DomainContext is cleared then the component asks the query to perform with a Quering event. Here it expects that the returned arguments contain an EntityQuery that are the data to which we must apply paging rules. There is a specific reason to ask for the query every time we have to refresh the page. This way it lets the developer to change the parameters to the query. It is useful if we need to filter data on the server and have some parameters acquired by the user interface. We will see an use of this in the following parts of the article.

Finally the method append to the query a call to Skip and Take. This is the part that does the trick. Thanks to the capability of serializing queries the call to these methods is passed to the server that apply them to the data just before to send it to the client. If you use Entity Framework the serialized query is applied directly to the generated SQL statement created by EF to extract data. It is really wonderful and astounding.

Under this trick there is WCF Data Services that is the REST implementation build over WCF. When you call the Load method the framework translates it to a querystring that describes the query. Here is a catch from the browser:

When the call to the service returns there is a bunch of tasks to accomplish: after setting the IsPageChanging to false we need to read the TotalItemCount and copy it to two properties of IPagedCollectionView and finally raise the PageChanged event and the CollectionChanged event to ask the consumer to update itself. The TotalItemCount is the total number of records we expect without the paging applied. This information is required to calculate the exact number of pages available.

Model-View-ViewModel aspects

If you know the MVVM pattern you already understand how this class might be useful. We have to expose from the ViewModel a property to which connect the consumer ItemsControl and the DataPager. In my sample I did a step forward and I thought about the fact often you need to have a lot of pages made in the same way just because your application needs to perform CRUD operations to each one. So I created a ListViewModel class that include all the logic needed to create a DataGrid + DataPager page:

public abstract class ListViewModel

where T : Entity

where K : DomainContext, new()

{

///

/// Gets or sets the context.

///

/// The context.

protected K Context { get; set; }

///

/// Gets or sets the items.

///

/// The items.

public PagedDataSource Items { get; set; }

///

/// Initializes a new instance of the class.

///

public ListViewModel()

{

this.Context = new K();

this.Items = new PagedDataSource(this.Context);

this.Items.Quering += new EventHandler>(Items_Quering);

this.Items.ItemCreating += new EventHandler(Items_ItemCreating);

this.Items.MoveToFirstPage();

}

///

/// Wraps the item.

///

/// The item.

///

protected abstract object WrapItem(object item);

///

/// Gets the query.

///

///

protected abstract EntityQuery GetQuery();

///

/// Handles the ItemCreating event of the Items control.

///

/// The source of the event.

/// The instance containing the event data.

private void Items_ItemCreating(object sender, ItemCreatingEventArgs e)

{

e.Item = this.WrapItem(e.Item);

}

///

/// Handles the Quering event of the Items control.

///

/// The source of the event.

/// The instance containing the event data.

private void Items_Quering(object sender, QueringEventArgs e)

{

e.Query = this.GetQuery();

}

}

The ListViewModel require two type arguments: T is the entity to page and K is the DomainContext to use. Inside this ViewModel I have a property of type PagedDataSource initialized with the type arguments. The instance of the DomainContext is created by this class and saved in the Context property. The class handles the Quering event and pass it to an abstract method. The reason is that the query to execute is the only thing a concrete ViewModel must provide to the PagedDataSource.

Curiously there is another event, MVVM related, that we have not already met. It is the ItemCreated evnt that is raised every time an item is prepared by the IEnumerable implementation of the PagedDataSource. This event is useful when you have to bind to a DataGrid and collect from each row some commands (e.g. open, delete, etc...). If you bind to the DataGrid the pure entity there is not any way to handle these events but you need to have a row ViewModel that wraps the entity and exposes the commands. The ItemCreated let you to intercept the item just before it is provided to the DataGrid and let you create the required RowViewModel instance.

Here is the final code from the concrete ViewModel of the datagrid page:

public class MainPageViewModel : ListViewModel

{

///

/// Gets or sets the max value.

///

/// The max value.

public int MaxValue { get; set; }

///

/// Gets or sets the show command.

///

/// The show command.

public DelegateCommand ShowCommand { get; set; }

///

/// Initializes a new instance of the class.

///

public MainPageViewModel()

{

this.ShowCommand = new DelegateCommand(o => this.Show(o));

this.MaxValue = 10000;

}

///

/// Gets the query.

///

///

protected override EntityQuery GetQuery()

{

return this.Context.GetNumbersQuery(1, this.MaxValue);

}

///

/// Wraps the item.

///

/// The item.

///

protected override object WrapItem(object item)

{

return new NumberRowViewModel((Item)item, this.ShowCommand);

}

///

/// Shows the specified item.

///

/// The item.

private void Show(Item item)

{

// do what you want with the selected item

}

}

The code from the attached sample has been cut to the minimal required to apply paging.

Future improvements

As you have seen the PagedDataSource is a key component to simplify the development in MVVM scenarios. It grants the capability to easily apply paging and customize the queries. Obviously there are many improvements you can imagine. Since it does not require a Filter event like the CollectionViewSource does, because you apply restrictions directly to the query, it is understandable someone needs to add sorting to the PagedDataSource. I figure out you can do this task in multiple ways, but please remember the better is add another part of the query into the Refresh method and having the sorting execute on the server side on all the records in the repository and not only on the few rows returned.

How to distribute a Silverlight OOB Application?

editorial@silverlightshow.net (Kunal Chowdhury ) — Tue, 12 Oct 2010 00:00:00 GMT
This article is compatible with the latest version of Silverlight.

More on this topic..

SilverlightShow OOB Webinar

SL4 elevated permissions article

An article on OOB applications

Table of Contents

Introduction

Background

Step1 : Creating a Silverlight OOB Application

Creating a Project

Configuring OOB Settings

Publishing Application as .XAP

Step2 : Configuring CD-ROM Installation

Basic to Silverlight OOB Installation

Basic to Silverlight OOB Silent Installation

Basic to HTA File

Creating the Folder Structure

Configuring Silverlight Runtime Detection

Configuring OOB Application Installation

Configuring CD-ROM Installation Launch

Step3 : Demo

Summary

Introduction

One of the new features introduced in Silverlight 4 is the silent installation of Silverlight Out-of-Browser application. This means, without user intervention, you can directly install them to their machines. You don’t have to open the browser window to install the OOB app. This is perfect for CD-ROM distribution. You can even automate the process from the CD/DVD media; if the user already has permission to auto run external media.

Here in this article, I will first create a simple OOB Silverlight application and then show you the steps to install it as OOB application silently.

Step1 : Creating a Silverlight OOB Application

In this first step, we will first create a Silverlight Application and design the UI. As our goal in this article is to deploying the application as OOB, hence we will not focus deeply into the UI. Later we will configure the application for OOB and after the successful build; we will publish the .XAP file to a local folder. If you already know about these steps can skip to the next Step.

Creating a Project

Open your Visual Studio 2010 IDE

Go to File –> New –> Project or just press Ctrl + Shift + N to open the New Project dialog

In the “New Project” dialog Window, expand “Visual C#” and click on the “Silverlight” from the left panel

Now in the right panel, only the Silverlight Templates will be visible

Select “Silverlight Application” from the right panel

Give a proper name for the Project (e.g. SilverlightDistributionDemo)

Choose proper location for the Solution by clicking the “Browse” button

Click “Ok” to continue. This will open the “New Silverlight Application” dialog where you can choose the Silverlight version and Silverlight Hosting Project settings

Be sure to select the “Silverlight 4” from the options pane and hit Ok” to continue

This will create the basic Silverlight project for you. Now design your application as per your requirement. For this sample application, I will create a basic UI. Here is the XAML code for that:

<UserControl x:Class="SilverlightDistributionDemo.MainPage"

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

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

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

Height="300" Width="400">

<Grid x:Name="LayoutRoot" Background="White">

<Border Background="#FFFFA0" Margin="20" CornerRadius="15"

BorderThickness="1" BorderBrush="Red">

<TextBlock Text="Silverlight OOB Application Installer Demo"

HorizontalAlignment="Center" VerticalAlignment="Center"

FontSize="30" FontWeight="Bold" Foreground="Red"

TextWrapping="Wrap" TextAlignment="Center"/>

Border>

Grid>

UserControl>

Here is the output of the Silverlight UI, if you run it in your Browser Window:

Configuring OOB Settings

So, our application UI is ready. Now, we need to configure the application to launch in outside browser window. Hence start with the configuration settings. Follow the simple steps mentioned below and you will be done:

From your solution explorer, right click on the Silverlight project and go to Properties. This will open the following properties pane in your screen:

Select “Silverlight” from the left panel

In the right panel, select the “Enable running application out of the browser” as shown in the above screenshot. This will enable the application to run outside the browser window

Now click on the “Out-of-Browser Settings …” button. This will open up another dialog window on your screen

Give the application Height & Width in this screen. You can also configure running the application in full trusted mode. Also you can configure the Window style here. For this demo, it is not require and hence I am leaving it as it is by default

Click “Ok” to save the “Out-of-Browser Settings”

Save the properties by clicking File –> Save or just by pressing the Ctrl + S key combination

Now your application is ready for running outside the browser. To check this, press F5 to run the application. This will first build the project and run it inside the browser window and you will see the UI as you created. Right click on the application UI and you will see a context menu popped up in the screen. It has two menu items called “Silverlight” and “Install onto this computer…”. The second option will only visible if your application supports running as OOB.

Clicking on the Install menu will start the installation wizard. Wait, our mission is not to install like this. We have to install the application silently from the deployment directory silently, without opening the browser window. We will discuss it step-by-step at latter part of the article.

Publishing Application as .XAP

Build the solution. Once you successfully built your solution, go to the “ClientBin” directory present in the Web application project. Here you will see the published XAP file. Copy this file to a specific folder location for later use.

Here in this example, we don’t have any other dependent services. Hence, just copying the .xap file is perfect for us. But in case, you have some other dependency files you need to publish the project. To do this, right click on the web application project and click “Publish…” menu to launch the publish web wizard.

Select the “File System” as the Publish Method and follow the instructions to publish the Silverlight application. Copy the required files from the published folder to a specific location for later use.

Step2 : Configuring CD-ROM Installation

Now it’s time to configure our application deployment from CD-ROM. Everything should be done silently, means it should check whether the required Silverlight version is installed in the installation PC and based on that it should run either the Silverlight installation or directly start deploying the application as out-of-browser. Let’s do it step-by-step.

Basic to Silverlight OOB Installation

Before jumping into the deployment steps, let us discuss how OOB installation works. Silverlight 4 now has support for installing out-of-browser application silently. When you install Silverlight plug-in, it also installs a .exe file named "sllauncher.exe" which you can find in your "Program Files\Microsoft Silverlight\" directory. This EXE file now has the capability to install your Silverlight OOB application silently without opening the browser window. If you have already installed your OOB application, it will create a shortcut to launch the application from desktop or start menu. Right click on the shortcut & go to its properties. You will notice that the target location is set to "Microsoft Silverlight" and the target is set to something similar to the following line:

"C:\Program Files\Microsoft Silverlight\sllauncher.exe" 744317312.localhost

That is responsible for launching the XAP file as your Out-of-Browser application.

Basic to Silverlight OOB Silent Installation

Let's come to write some scripts to install your XAP silently as out of browser Silverlight application. Hope, you already published our sample application (.xap) after configuring it as out of browser to your local drive in a specific folder (say, C:\MySilverlightApps\XAP). For our case, the complete path of the XAP is: "C:\MySilverlightApps\XAP\SilverlightDistributionDemo.xap".

Now open your Notepad and write the following code in a single line:

"C:\Program Files\Microsoft Silverlight\sllauncher.exe"

/install:"C:\MySilverlightApps\XAP\SilverlightDistributionDemo.xap"

/origin:http://www.kunal-chowdhury.com/private/apps/XAP/SilverlightDistributionDemo.xap

/shortcut:desktop+startmenu

/overwrite

Here, you have to pass the location of your XAP file as a parameter value to the "/install" flag.

You can specify the URL for future update location of the application by setting the "/origin" flag. When you call the CheckAndDownloadUpdateAsync() method from code, it will try to get the update from the specified location.

You can specify the shortcut location of the application by setting the value to the "/shortcut" flag. If you just set desktop or start menu as the value to the flag, it will create the shortcut in desktop or start menu depending on the parameter you set. If you use "desktop+startmenu" as the value to the parameter, it will install it both in the desktop and start menu of your operating system.

Basic to HTA File

HTML Applications (HTAs) are full-fledged applications. These applications are fully trusted and display only the menus, icons, toolbars, and title information that the Web developer sets. In short, HTAs pack all the power of Windows Internet Explorer - its object model, performance, rendering power, protocol support and user interface of the browser. HTAs can be created using the normal HTML and Dynamic HTML (DHTML) tags. You need to save the file as “.hta” to execute the Html Application.

The HTA:APPLICATION tag in the following example specifies application features not available in DHTML. As prescribed by the attributes, this application has neither border (border), nor title bar (caption), nor standard program icon (sysMenu). The application title appears in the Windows task list but not in the taskbar (showInTaskBar), and only one instance of the application is permitted to run at a time (singleInstance).

<HTML>

<HEAD>

<TITLE>My Monster ApplicationTITLE>

<HTA:APPLICATION ID="oMyApp"

APPLICATIONNAME="monster"

BORDER="none"

CAPTION="no"

ICON="/graphics/creature.ico"

SHOWINTASKBAR="no"

SINGLEINSTANCE="yes"

SYSMENU="no"

WINDOWSTATE="maximize">

HEAD>

HTML>

To launch an HTA, double-click its program icon, run it from the Start menu, open it through a URL, or start it from the command line. After starting, the HTA renders everything within the body tag and displays the value set in the title tag as the window title.

Want to read more about HTA file? Read it from MSDN:

HTML Applications (HTA)

Introduction to HTML Applications

Creating the Folder Structure

Before going into the depth, we need to finalize our folder structure. Create a root folder and name it properly. Create two folders inside it & name them as “Silverlight” and “XAP” respectively. Download the latest Silverlight runtime installer from Microsoft Site and save it inside the “Silverlight” directory. Put the application XAP that we published earlier into the “XAP” folder.

The other three files shown in the above screen represents one autorun.inf, one batchInstall.cmd and install.hta. We will create those files later in this article and discuss accordingly.

Configuring Silverlight Runtime Detection

Now we have to detect whether the Silverlight version is installed in client PC. It can be done using the JavaScript. You can use the Silverlight.js file which comes with every Silverlight application project. In our case, the whole file is not require and hence I took a little portion from it and modified as per our requirement.

First of all, we will create a function and inside it, we will create an ActiveXObject named “AgControl.AgControl”. From this instance of agcontrol, we will be able to know about the installed version of Silverlight. If it throws exception, means that, Silverlight is not installed in local PC. In other case, it will return the current installed version of Silverlight. Be sure to check the version in descending order.

Here is the whole code snippet:

function GetSilverlightVersion() {

// initialize the silverlightVersion to -1.

var silverlightVersion = -1;

getSilverlightVersion = function () {

try {

// create the ActiveX Object of AgControl.

// This is the core of Silverlight runtime.

var control = new ActiveXObject('AgControl.AgControl');

// will execute if your latest Silverlight version is 4.

if (control.IsVersionSupported("4.0")) {

silverlightVersion = 4;

}

// will execute if your latest Silverlight version is 3.

else if (control.IsVersionSupported("3.0")) {

silverlightVersion = 3;

}

// will execute if your latest Silverlight version is 2.

else if (control.IsVersionSupported("2.0")) {

silverlightVersion = 2;

}

// if Silverlight version is not supported by your app,

// set it as 0 (zero).

else {

silverlightVersion = 0;

}

control = null;

}

catch (e) {

// if any exception while creating the ActiveX Object,

// will set the silverlightVersion as -1.

silverlightVersion = -1;

alert("Unable to create the ActiveX Object from Browser window.");

}

}

// call to the inner function to detect the Silverlight.

getSilverlightVersion();

// return the version of the Silverlight.

return silverlightVersion;

}

Now depending upon your Silverlight version, you can install the require Silverlight version. This thing also you can do using JavaScript. Wait, you can do this using JavaScript, but if you run from browser window, it will not work. To do this, we are using the HTML Application (.hta). For this, create another JavaScript method and create a WScript.Shell instance object from the ActiveXObject and call the Run() method by passing the required parameters. Here is the code for that:

function InstallSilverlight() {

WshShell = new ActiveXObject("WScript.Shell");

WshShell.Run("Silverlight\\Silverlight.exe /q", 0, true);

}

You can see that, in the Run() method I passed the location of the Silverlight runtime installer as the first parameter. You can see that, I used “/q” as the argument for Silverlight installer. This silently installs the Silverlight in the local PC. As a second parameter I used “0” (zero). This ensures that, the executed application window will remain hidden. So, the end user will not see the installation window. The third parameter ensures whether the call will wait for the application to exit. If you pass “true”, it will wait until the executed application exits in memory. Once that application closes, it will continue running the next line of the script.

As per our requirement, we need to wait until the Silverlight runtime installs in the user’s machine and hence we used “true” as the third parameter.

Configuring OOB Application Installation

Now, we will create a batch file to execute the XAP installation silently. Open your notepad and write the following code inside it:

@ECHO OFF

@"%ProgramFiles%\Microsoft Silverlight\sllauncher.exe"

/install:"XAP\SilverlightDistributionDemo.xap"

/shortcut:desktop+startmenu

/origin:http://www.kunal-chowdhury.com/Private/XAP/SilverlightDistributionDemo.xap

/overwrite

@EXIT

The first line “@ECHO OFF” will hide the prompt of the console while executing. The second line in the above code is a bunch of 5 lines. You must need to write them in a single line. Due to proper formatting of the code snippet and help you to understand it properly, I splitted them in 5 lines. While writing in the notepad, be sure to write those 5 lines in a single line entry. In the second line, you need to call the sllauncher.exe, which comes with the Silverlight runtime. sllauncher.exe is responsible to install/execute a silverlight OOB application. See the parameters that I used there. The first parameter “/install” tells the application to install the .XAP file from the specified location. The second parameter tells the application to install the shortcut of the OOB application in either desktop, startmenu or both places. The third parameter tells to check for updated version in the sepecified link. The forth parameter instructs to overwrite the existing .xap (if any, already installed). In the third line “@EXIT” calls the exit method of the batch file to shutdown the batch processing.

Once you write the above code in notepad, save it as a .cmd file. Give a proper name while saving (in our case, it is “batchInstall.cmd". Save in proper location, as mentioned in the folder structure.

Now, you need to call this batch file from the HTML application file. Write another JavaScript function and call the Run() method of the WScript.Shell object with the proper parameters. In this case, we will use “false” as the third parameter as we don’t need to wait for the installer to install the OOB application.

Here is the full JavaScript code for you:

function InstallSilverlight() {

WshShell = new ActiveXObject("WScript.Shell");

WshShell.Run("Silverlight\\Silverlight.exe", 0, true);

}

function InstallOOBApplication() {

WshShell = new ActiveXObject("WScript.Shell");

WshShell.Run("batchInstall.cmd", 0, false);

}

function Install() {

var silverlightVersion = GetSilverlightVersion();

if(silverlightVersion == 4) {

InstallOOBApplication();

}

else {

InstallSilverlight();

InstallOOBApplication();

}

self.opener = this;

self.close();

}

In the above code, we created another JavaScript method named “Install()”, which actually checks the current installed version of Silverlight. If the required version is available in user’s PC, it will start installing the OOB Application. If the Silverlight or required version is not present, it will start installing the Silverlight first. As we instruct the Run() method to wait for the installation, the OOB Application installation will start once the Silverlight installation completes. Finally terminate the HTA application from the memory.

Now last part in this is to call the Install() method on page load. Use the following code for that:

<body onload="Install();">

body>

Now save all this JavaScript code in a .hta file. Here is the full code inside your .HTA file:

Application Executer

"oMyApp"

APPLICATIONNAME="Application Executer"

BORDER="No"

CAPTION="No"

SHOWINTASKBAR="No"

SINGLEINSTANCE="Yes"

SYSMENU="No"

SCROLL="No"

Width="0"

Height="0"

maximizeButton="false"

WINDOWSTATE="minimize">

"Install();">

Save the file in your root directory where batchInstall.cmd is present. Make sure that your file structure is proper.

Configuring CD-ROM Installation Launch

It’s time for us to run the installer automatically once you insert the CD/DVD installation drive or double click the drive to open. To do this, you have to add a “autorun.inf” file in the root directory where the .hta & .cmd batch files are present (see the folder structure above). Be sure that, the installer will automatically launch, if the end user has enabled the autorun functionality. By default it is enabled.

Write the following code in your “autorun.inf” file:

[autorun]

open = install.hta

shell\install = &Install

shell\install\command = install.hta

The first line will tell the OS to autorun the file. The second line instructs the OS to autorun the mentioned file from the mentioned location. The third line will add a “Install” menu item in the context menu of the drive when you insert the CD media. It will have the installer file location, which is mentioned in the fourth line.

Read more about Autorun.inf file and it’s options from here: Autorun.inf, What is it?

Step3 : Demo

It is very difficult to demo it here. To test it, uninstall your Silverlight plug-in from your PC. Then run the install.hta file from the folder as shown in the below diagram:

This will call the “Install()” method of the JavaScript and check for the installed Silverlight version. As it didn’t find the Silverlight installed there, will start installing the Silverlight runtime silently. Once installed successfully, it will start installing the OOB Application silently. No UI will be visible for the user to interact with (this was our requirement). Once the installer installs the OOB application, you will see the OOB icon immediately in your desktop & start menu.

Double click it to run the application from desktop or click to execute from start menu.

Now, again run the “install.hta” file. It will call the JavaScript method “Install()”. The function will check whether the required Silverlight version installed in user PC & as the required version matches the original installed version, it will skip to the OOB application installation part. It will overwrite the existing XAP if it is already present.

Summary

I hope, you got the basic idea of the installation process from it. I used HTA file to demonstrate it in better way. It will be easy for you to read the JavaScript code and understand it properly. The next step for you is to create an original installer file by using the concept mentioned here.

If you like this article, please vote for it. Appreciate you for your feedbacks/comments/suggestions. Thank you for reading the article.

Download

- Silverlight OOB Application Installer (Source Code)

About the Author

Kunal Chowdhury is a Microsoft MVP in Silverlight,. He has a very good skill over Silverlight, XAML & C#. He worked in various Silverlight & WPF projects including Windows 7 Multitouch applications and delivered a quality output every time. He received various awards related to Software Development.

During his pass time, he always busy to answer in online forums, writing articles and blog postings to share his knowledge across the world.

You can reach him in his Blog - http://www.kunal-chowdhury.com/
He also Tweets. Follow him in Twitter - @kunal2383

WCF RIA Services Part 4 - Integrating with the Model-View-ViewModel Pattern

editorial@silverlightshow.net (Brian Noyes ) — Tue, 03 Aug 2010 02:51:00 GMT

Watch recordings of Brian's WCF RIA Services webinars:

Querying & Updating Data From Silverlight Clients with WCF RIA Services (Feb 03, 2011)

WCF RIA Services Validation (Mar 17, 2011)

Secure and Personalize Your Silverlight App with WCF RIA Services (May 26, 2011)

WCF RIA POCO Domain Services (Sep 29, 2011)

Don't miss...

Deep Dive Into WCF series

See more articles on WCF

WCF RIA Services Show

The WCF series is now available as a fully offline resource:

     All SilverlightShow Ebooks

This article is Part 4 of the series WCF RIA Services.

Introduction

The Model-View-ViewModel pattern (MVVM) is a very popular approach for building more loosely coupled Silverlight and WPF applications. I won’t attempt to full define and explain the pattern here, but will give a quick explanation of what it is about and why you would want to use it. At a high level, MVVM is an alternative or evolution of MVC and MVP patterns, but taking full advantage of the rich data binding, commands, and behaviors that we have available to us in Silverlight and WPF. The view model’s primary responsibility is to offer up state to the view in the way the view wants to see it. It exposes properties that the view can easily bind to that let the view display the data it needs and to also hook up commands and behaviors that point back to the view model to invoke interaction logic that the view model encapsulates. The view model is all about containing and manipulating the data that the view needs and providing the interaction logic to support the view. The view model acts as a translator from the complex world of the overall application model to the specific set of data that a single view needs, structured in the way the view needs to display it. Structurally, you typically set the view’s DataContext equal to an instance of the view model so that the view can easily bind to the exposed properties of the view model. There are many ways to get this hook up done.

The motivations for using it include the fact that it allows you to work on the view and the view model mostly in isolation, facilitating developer/designer workflow. Additionally, by separating your interaction logic into the view model, you can more easily unit test that logic because it is not tightly woven with the UI itself. And finally, the pattern just provides a clean separation of responsibility so the view can just be about the structure and visual behavior of what you see on the screen, and the view model can just be about the data and logic surrounding the data that the view needs to support it. For more in depth coverage, I recommend you read Josh Smith’s excellent article on MVVM, as well as the guidance being developed by the Microsoft patterns & practices Prism team in Prism 4 at http://prism.codeplex.com/. Prism 4 is due out in the September/October timeframe but there are already public drops in the downloads section on CodePlex.

So now let’s see how MVVM fits with WCF RIA Services. The starting point code for this article will be the sample code from Part 3 of the series, which you can download here. You can download the finished code for this article here.

Step 1: Factor out a view model

In the last article’s version of the TaskManager application, I was already starting to have a fair amount of code building up in the code behind of the view (the MainPage user control), even with such a simple application. The first step is to factor that code out into a view model. Create a new class named TasksViewModel in the project. Often a good way to get started defining your view model is to analyze the view and determine what properties would be needed to support it. The image below shows the form as it is currently defined. To clean things up a bit, I’ve replaced the two TextBoxes for date input at the top with DatePickers, removed the unused properties on the Task from the DataGrid, and reordered the columns to look a little better.

By looking at the UI design, you can identify 6 properties the view model should expose to support this view: two DateTime properties for lower and upper dates for a search; three commands to support searching by date, adding a task, and saving changes; and one Tasks collection. In its simplest form, that would look like this:

public class TasksViewModel

{

public DateTime LowerSearchDate { get; set; }

public DateTime UpperSearchDate { get; set; }

public ICommand SearchByDateCommand { get; set; }

public ICommand AddTaskCommand { get; set; }

public ICommand SaveChangesCommand { get; set; }

public IEnumerable Tasks { get; set; }

}

However, you generally need to implement INotifyPropertyChanged on your view model which requires the expanded syntax for each property so that the UI can stay fresh through its data bindings if the bound property on the view model changes, so each property definition should look more like this in its full form, except possibly the private set properties that the view model sets once and does not change.

public class TasksViewModel : INotifyPropertyChanged

{

public event PropertyChangedEventHandler PropertyChanged = delegate { };

DateTime _LowerSearchDate;

public DateTime LowerSearchDate

{

get

{

return _LowerSearchDate;

}

set

{

if (value != _LowerSearchDate)

{

_LowerSearchDate = value;

PropertyChanged(this, new PropertyChangedEventArgs("LowerSearchDate"));

}

}

}

To support the ICommand properties, you will need a decent command implementation. I’ve included a simple RelayCommand implementation, but normally in real projects I use the DelegateCommand from Prism.

A view model is all about managing the data needed by a view, and a DomainContext in RIA Services is all about providing and tracking changes to the data, so a simple approach to using RIA Services with MVVM is to simply use a DomainContext within your view model.

TasksDomainContext _Context = new TasksDomainContext();

public TasksViewModel()

{

SearchByDateCommand = new RelayCommand<object>(OnSearchByDate);

AddTaskCommand = new RelayCommand<object>(OnAddTask);

SaveChangesCommand = new RelayCommand<object>(OnSaveChanges);

Tasks = _Context.Tasks;

if (!DesignerProperties.IsInDesignTool)

{

_Context.Load(_Context.GetTasksQuery());

}

}

Here I have made the TasksDomainContext a member of the view model, and initialized the commands in the constructor to point to methods within the view model. The Tasks property exposed by the view model just holds a reference to the Tasks entity collection exposed by the domain context, which will raise INotifyCollectionChanged events to keep the view fresh when the collection changes, which will happen on the initial load, when you add Tasks, and when SubmitChanges completes and has updated entities from the back end. Notice the use of the DesignerProperties.IsInDesignTool property to prevent calling Load in the designer, which would break it.

Next is to move the methods that were in the code behind of MainPage into the view model. I’ve cleaned them up a bit in the process too. Note that the search method now leverages the deferred execution I talked about in Part 3, making the GetTasksByStartDate domain service method unnecessary since the client can specify that search expression itself. I’ve also moved the creation of a new Task into a simple popup ChildWindow so you can actually edit the values. Note the commend in the code below – showing a dialog from a view model is really a no-no, just doing it here because the focus is on RIA Services, not on full MVVM patterns.

private void OnSearchByDate(object param)

{

_Context.Tasks.Clear();

EntityQuery query = _Context.GetTasksQuery();

LoadOperation loadOp = _Context.Load(query.Where(t => t.StartDate >= LowerSearchDate && t.StartDate <= UpperSearchDate));

}

private void OnAddTask(object param)

{

// Generally don't want to do this for testability reasons

// Simplification because MVVM structuring is not the focus here

// See Prism 4 MVVM RI for a cleaner way to do this

AddTaskView popup = new AddTaskView();

popup.DataContext = new Task();

popup.Closed += delegate

{

if (popup.DialogResult == true)

{

Task newTask = popup.DataContext as Task;

if (newTask != null) _Context.Tasks.Add(newTask);

}

};

popup.Show();

}

private void OnSaveChanges(object param)

{

_Context.SubmitChanges();

}

At this point you have you have a functioning view model, now I’ll clean up the view to work with the view model.

Step 2: Hook up the view to the view model

From Part 1, the view was using the DomainDataSource that was generated from the drag and drop. If you want a clean MVVM design, you will unfortunately have to pass on using DomainDataSource. That object is effectively putting state management and query logic into the XAML itself, which violates the clean separation of responsibilities followed in MVVM.

So basically I took the existing view, deleted out the DomainDataSource, and added appropriate bindings to each of the controls to bind to the exposed view model properties as shown below. For a top level view like this, constructing the view model in the XAML to set it as the data context is a simple way to get the view’s data context set to an instance of the view.

<UserControl x:Class="TaskManager.MainPage" ...>

<UserControl.DataContext>

<local:TasksViewModel/>

UserControl.DataContext>

<Grid x:Name="LayoutRoot" Background="White">

<sdk:DataGrid ItemsSource="{Binding Tasks}" .../>

<Button Command="{Binding SearchByDateCommand}" .../>

<Button Command="{Binding AddTaskCommand}" ... />

<Button Command="{Binding SaveChangesCommand}" ... />

<sdk:DatePicker SelectedDate="{Binding LowerSearchDate}" ... />

<sdk:DatePicker SelectedDate="{Binding UpperSearchDate}" ... />

Grid>

UserControl>

Lastly, remove all the code from the code behind of the view, since it is no longer being used (all the button click handlers were removed in the process of hooking of the commands with bindings to the view model properties).

public partial class MainPage : UserControl

{

public MainPage()

{

InitializeComponent();

}

}

Summary

The simplest way to use WCF RIA Services with the MVVM pattern is to stop using the DomainDataSource in your views and to use a domain context as the repository of data for your view models. You can still leverage the drag and drop Data Sources window features, you just have to do a little clean up to delete off the DomainDataSource after the drop and touch up the bindings a little.

There are two downsides to the approach as I have shown it here: testability and separation of concerns. One of the benefits of the MVVM pattern is supposed to be unit testability. But with a concrete type dependency on the domain context type in your view model, you are out of luck for mocking out that dependency. There are two approaches possible to address this:

Use dependency injection to provide the domain context to the view model, and create a mock DomainClient and pass it to the DomainContext. This allows your view model to keep using the full functionality of the DomainContext, but you are able to mock out the calls to the service underneath the DomainContext. This approach is outlined in this post. I’ll be providing an example in Part 8 of this series, which is focused on testability.

Factor out the DomainContext to a repository service that defines an interface similar to the DomainContext API and consume that from the view model. This would allow you to mock your repository service that contains the domain context. It would also address the separation of concerns problem, because then you would be separating the implementation choice of using RIA Services from the view model, which should really be separated. However, you would give up a lot of flexibility in the view model and it would not be an easy repository implementation.

Neither of these approaches is particularly easy. I’ll cover them in more detail later in part 8, and may blog some more on this topic as well. That’s all for now. You can download the finished code for this article here. See you next time.

About the Author

Brian Noyes is Chief Architect of IDesign, a Microsoft Regional Director, and Connected System MVP. He is a frequent top rated speaker at conferences worldwide including Microsoft TechEd, DevConnections, DevTeach, and others. He is the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding in Windows Forms 2.0. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net.

Navigating between Pages in Different Xaps (by using MEF)

editorial@silverlightshow.net (Pencho Popadiyn ) — Mon, 02 Aug 2010 00:00:00 GMT

This article is compatible with the latest version of Silverlight.

More on this topic..

See more articles on MEF

Watch MEF Webinar by Gill Cleeren

1. The Problem

In this article I’ll show you a simple solution for navigation between pages in different Xaps, by using Managed Extensibility Framework (MEF). Recently I hit the following issue, while playing with MEF. Suppose that you have a Silverlight Navigation Application. Your application is partitioned in different modules (plugins, extensions, add-ons or whatever). Let's imagine that your application has three plugins – Orders plugin, Products plugin and Suppliers plugin, as shown on the snapshot below.

Each one of your plugins contains an entry page (this is the so called Entry Point for the plugin). I’ll show you some technical details about the implementation later in the article. For now let’s stick to the main problem. Your main project (the host project) has static references to two of the plugins, for example OrdersPlugin and ProductsPlugin.

Since both of the plugins are referenced by the main project, during compile time, they are included in the .Xap file! And once you start the application they are automatically loaded without any problems. However, the third plugin – the SuppliersPlugin is not included in the main .XAP file. It is downloaded runtime, by using the mighty DeploymentPackageCatalog (the DeploymentPackageCatalog is not part of MEF, but its implementation is widely spread in Google).

If you try to navigate to the Orders page or Products page, then you won’t have any problems (it’s just like creating a regular Silverlight navigation application). However, when you try to navigate to the Suppliers page, you will see the following exception.

What a shame, isn’t it? :). So where is the problem? By default the Frame class from the Navigation Framework uses the PageResourceContentLoader class to load the pages. The PageResourceContentLoader class has the following limitation: it is designed to load pages from the application package (the .xap file) that correspond to a given URI. However, our Suppliers page is not in the main application package, it is part of another package, downloaded runtime. That’s why the PageResourceContentLoader won’t know about the Suppliers page, and respectively won’t be able to load it.

2. The Solution

Fortunately the System.Windows.Controls.Navigation assembly provides us with the INavigationContentLoader interface. So, as you can guess, we need a custom implementation of the INavigationContentLoader.

public class MefContentLoader : INavigationContentLoader

{

private PageResourceContentLoader pageResourceContentLoader = new PageResourceContentLoader();

private Uri targetUri;

public IAsyncResult BeginLoad( Uri targetUri, Uri currentUri, AsyncCallback userCallback, object asyncState )

{

throw new NotImplementedException();

}

public bool CanLoad( Uri targetUri, Uri currentUri )

{

throw new NotImplementedException();

}

public void CancelLoad( IAsyncResult asyncResult )

{

throw new NotImplementedException();

}

public LoadResult EndLoad( IAsyncResult asyncResult )

{

throw new NotImplementedException();

}

}

The trick here is that our custom content loader should know about the entry points of each plugin.

public class MefContentLoader : INavigationContentLoader

{

[ImportMany( AllowRecomposition = true )]

public UIProviderBase[] Plugins

{

get;

set;

}

//....Rest of the code

}

For our purposes we need to implement only the BeginLoad, CanLoad and EndLoad methods, like demonstrated on the code snippet below:

public class MefContentLoader : INavigationContentLoader

{

private PageResourceContentLoader pageResourceContentLoader = new PageResourceContentLoader();

private Uri targetUri;

public MefContentLoader()

{

CompositionInitializer.SatisfyImports( this );

}

[ImportMany( AllowRecomposition = true )]

public UIProviderBase[] Plugins

{

get;

set;

}

public IAsyncResult BeginLoad( Uri targetUri, Uri currentUri, AsyncCallback userCallback, object asyncState )

{

this.targetUri = targetUri;

return pageResourceContentLoader.BeginLoad( targetUri, currentUri, userCallback, asyncState );

}

public bool CanLoad( Uri targetUri, Uri currentUri )

{

return true;

}

public void CancelLoad( IAsyncResult asyncResult )

{

throw new NotImplementedException();

}

public LoadResult EndLoad( IAsyncResult asyncResult )

{

if ( this.Plugins.Length == 0 ||

this.Plugins.Count( p => p.EntryPage != null && p.EntryPage.Metadata.NavigateUri == targetUri.ToString() ) == 0 )

{

return pageResourceContentLoader.EndLoad( asyncResult );

}

IView page = this.Plugins.First( p => p.EntryPage != null && p.EntryPage.Metadata.NavigateUri == this.targetUri.ToString() ).EntryPage.CreateExport().Value;

return new LoadResult( page );

}

}

The tricky part comes into the EndLoad method. Once we know the entry points for each plugin, and we know the target uri, we can extract the requested page and pass it to the LoadResult.

Finally, you need to set the Frame’s ContentLoader property in XAML.

<navigation:Frame x:Name="ContentFrame"

Style="{StaticResource ContentFrameStyle}"

Source="/HomeView"

NavigationFailed="ContentFrame_NavigationFailed">

<navigation:Frame.ContentLoader>

<local:MefContentLoader />

navigation:Frame.ContentLoader>

<navigation:Frame.UriMapper>

<uriMapper:UriMapper>

<uriMapper:UriMapping Uri=""

MappedUri="/Views/HomeView.xaml" />

<uriMapper:UriMapping Uri="/{assemblyName};component/{path}"

MappedUri="/{assemblyName};component/{path}" />

<uriMapper:UriMapping Uri="/{pageName}"

MappedUri="/Views/{pageName}.xaml" />

uriMapper:UriMapper>

navigation:Frame.UriMapper>

navigation:Frame>

Check out the link at the end of the article, in case you want to download the full source code.

3. Designing Plugin Applications

Since there isn’t a lot of information in the web, I would like to say a few words about how to design (create) plugin applications. The strong definition about the plugin is a set of software components that adds specific capabilities to a large software application. We are surrounded with such kind of applications – the most famous are Office Word, Excel, Outlook, Visual Studio. Basically, each plugin has an entry point (plugin interface). The host application deals only with the plugin interfaces (not directly with the plugin). The host application operates independently of the plugins, making it possible for the end-users to add and update plugins dynamically without the need to make changes to the host application.

Prior to .NET Framework 4, we didn't have any concrete technology for creating plugin applications. Fortunately, in .NET Framework 4, Microsoft provides us with the Managed Extensibility Framework (MEF) which is available for Silverlight, too.

So let’s come back to our demo. I am using an abstract class named UIProviderBase and this is the “plugin interface” (the entry point) for the demo. The class provides a Title (the name of the plugin), an Image (associated with the plugin) and an EntryPage – this is the initial view (the main view) of the plugin. This class serves something like a contract, saying: “Hey, if you want to plug in your module in my application, you have to implement me”.

public abstract class UIProviderBase

{

public abstract string Title

{

get;

}

public abstract string ImageUri

{

get;

}

public abstract ExportFactory EntryPage

{

get;

set;

}

}

Each plugin should provide a UIProviderBase implementation. Additionally, that implementation should be marked with the [ExportAttribute]. Below you can see the entry point for the Suppliers plugin.

[Export( typeof( UIProviderBase ) )]

public class SuppliersUIProvider : UIProviderBase

{

public override string Title

{

get

{

return "Suppliers";

}

}

public override string ImageUri

{

get

{

return "/SuppliersPlugin;component/Images/SuppliersImage.png";

}

}

[Import( ViewNames.SuppliersViewName )]

public override ExportFactory EntryPage

{

get;

set;

}

}

On the other side, the host application is expecting an array of UIProviderBase implementations. Note the [ImportManyAttribute].

[Export( ViewModelNames.HomeViewModelName, typeof( object ) )]

public class HomeViewModel : MyViewModelBase, IPartImportsSatisfiedNotification

{

[ImportMany( AllowRecomposition = true )]

public UIProviderBase[] Plugins

{

get;

set;

}

public void OnImportsSatisfied()

{

this.Plugins = this.Plugins.OrderBy( p => p.Title ).ToArray();

this.RaisePropertyChanged( "Plugins" );

}

}

The other goodies:

If you download the source code (the link is at the end of the article), you will find an implementation of the DeploymentServiceCatalog, which is downloading a XAP file by a given relative uri.

Note the EntryPage property in the UIProviderBase class. An instance of the page is created on demand. What I am using here is a Metadata. For more information, you could read here.

In the HomeView.xaml I am using a PathListBox to arrange the UI.

One last question I should answer is how the different plugins communicate with each other. Well, in this case you need to use the so called “global events (messages)". For example, I prefer the Messanger class from the MVVM Light Toolkit, but you can use the EventAggregator with the same success.

Download Source Code