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.

Part 8: Developing for a multitude of clients: strategies for code reuse and keeping costs in check.

editorial@silverlightshow.net (Kevin Dockx ) — Wed, 24 Oct 2012 10:29:00 GMT

We've already learned quite a bit about code reuse and strategies to keep costs in check in the previous articles in this series: we've created a Silverlight web & OOB client, we split up our code in modules to enable them to be loaded on demand & reused by other clients, and we've created a Windows Phone client, in which we focussed on reuse of skill rather than reuse of XAML & code - but we could still share some common code through the use of a Portable Class Library, and of course: our service layer through its REST endpoints.

As you might have noticed, an important distinction we try to make in this article series is the difference between what can be reused and what should be reused. That will become even more obvious in this article: we're going to add yet another type of client: a Windows 8 Store Application.

Don't miss...

All SilverlightShow Ebooks

Why would we want a Windows 8 Store Application?

Windows Store Applications are vastly different from what we've built up until now. There's a new set of design guidelines to confirm to, there's a new CLR these apps are built against, there's quite a few new coding principles to adhere to, … All in all: a lot of work if you're new to this. So why would we consider a Windows Store Application?

One way to answer this question is by looking at the added value of these apps and the market opportunity we get as developers - a good blog post that sums up these can be found at MSDN.

What should we offer in this client?

This is one of the first questions we should ask ourselves, as quite a bit of the development cost will depend on the features we want to offer, or rather: on what we can use to build these features with.

Let's have a look back at our full-blown Silverlight client: we use this one for quite a bit of data input - and validation on that data, client-side (next to server-side, of course). Thing is, at this point in time, Silverlight is a mature framework, which includes building blocks to make it easier for us to achieve solutions to some common concerns. WinRT, or what’s offered by WinRT, isn’t yet.

For example, thanks to WCF RIA Services, we've got a framework that tackles a very important concern for data input apps: validation. Write validation rules on the server, and they're generated on the client. Next to that, the Silverlight controls have built-in functionality to listen & react to this type of validation, through the INotifyDataErrorInfo interface. This combination results in almost out-of-the-box validation.

For Windows 8 Store Applications, this isn't the case: at the moment, there isn't anything resembling WCF RIA Services available for these types of apps (and we don't know yet if something like that will be available in the foreseeable future). Furthermore: the INotifyDataErrorInfo interface is completely absent for Store Applications - in fact: any kind of validator is absent.

And there's more: a lot of other components we could use - like third-party components for graphs - aren't available either, or are in an initial state. Of course, this is quite normal: after all, at the time of writing, Windows 8 isn't available to the general public yet. All this will get better, but it will take some time.

We should keep in mind that the framework for building Windows 8 Store Applications is very much a "v1.0"-framework - a bit like what Silverlight was when Silverlight 2 was made available. Out of that follows that if we would want to support features that aren't built-in, or for which there aren't any mature helper frameworks available, it will take a lot of time, and thus cost a lot of money.

If we want to keep costs in check, the above should be one of the first things to take into account. When developing software, it's not using the framework as it was intended to build the app that heightens the cost, it's often (mis-)using the framework or trying to add features that it isn't ready for that causes that.

Should we reuse the UI? After all, it's built in XAML, right?

Windows 8 Store Applications come with their own set of UI guidelines, which result in a UI that's quite different from what we've done in our initial Silverlight application. When you're building a Windows 8 application, you're building an application that should easily be controllable using touch - typically, you'd have larger buttons, more whitespace, less reliance on tooltips, … But that's not all. Navigation should typically be achieved hierarchically, or through a navigation bar - different from what we're used to. A lot of commands (the non-essential ones) should be moved to the command bar instead of being on-canvas (as they are now). And then there's charms: to ensure a consistent experience across applications, a few common features of apps should be implemented through the charms bar instead of in the application itself. Searching through the data of our application should be done via the Search charm. If we want to share data to other apps, we should use the Share charm. And our application settings should be accessible through the Settings charm.

Another thing to keep into account is the fact that we're now looking at an application which can be snapped to the left or the right of the screen, which means we have to provide a snapped view for the pages in our application. Optionally, we could also provide a portrait mode next to the default landscape mode.

These are just a few traits that make for a good Windows 8 Store Application, and if you think about this, that's quite a lot of change from what we're used to. But it makes sense: ensuring your app confirms to these guidelines ensures a consistent experience for the end-user, no matter which app (s)he is using.

If you're new to this, you might want to check out the guidelines on this, or have a look at a few case studies at MSDN.

Obviously, it's clear that we shouldn't reuse our current UI. But can we?

Unless you've been building a very simple application: no. The XAML used for Windows 8 Store Applications contains quite a few differences from the XAML used in Silverlight, WPF or Windows Phone: from controls that aren't available or have been replaced by better-suited controls (eg: a ListView instead of ListBox), to some more fundamental concepts like binding changes, supported interfaces, …

There's a great overview available on porting Silverlight or WPF XAML to Windows Store XAML at MSDN.

What about our ViewModels?

Technically, we could think we could reuse most of our ViewModel code from our Windows Phone application. That application uses the REST endpoints of our service layer, which is exactly what we'll be using for this client. However, Windows 8 Store Applications rely heavily on async & await, or, in fact, the Parallel Tasks framework (more on this in the next article) - you won't find the typical completed handlers we've got in Windows Phone to execute code when our async service call returns; instead, we should use the async/await keywords.

Next to that, due to the fact that a View is implicitly connected to a ViewModel, and the fact that we've concluded that reusing the UI isn't a feasible option (if only for the very different design guidelines), we cannot technically reuse our ViewModels, and we should not either, as the use cases will be implemented differently.

Wait a minute. Is there anything left we can reuse?

Well, of course there is. We've used WCF RIA Services for our back-end services, and these services can be consumed through their REST endpoints, much like we did for our Windows Phone client. Next to that, the Portable Class Library project template supports Windows 8 Store Applications, so that's something we can reuse as well. And of course, there's knowledge & skill reuse.

Luckily, it's fairly easy to build Windows 8 Store Applications. The framework might not support everything we're used to (yet), but the concepts it does support are is thought-out quite well. In the next article in this series, we'll effectively start building our Windows 8 client, keeping into account the questions we've raised and answered in this article.

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 applications, mainly XAML-based, and the solution owner for Windows Store Apps. His main focus lies on all things XAML, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a XAML enthusiast, he's a regular speaker on various national and international events, like Microsoft Techdays in Belgium, Portugal & Finland, NDC, Community Day, VISUG, ... Next to that, he also authored two Silverlight books at Packt Publishing, of which the most recent one is the Silverlight 5 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on XAML, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/, and you can contact him on Twitter via @KevinDockx.

Part 7: Developing for a multitude of clients: strategies for code reuse and keeping costs in check.

editorial@silverlightshow.net (Kevin Dockx ) — Tue, 12 Jun 2012 07:55:00 GMT

In the previous articles in this article series, we've looked into different ways of getting our code split up in modules, so they can be loaded on demand, and easily reused across different types of clients - thus cutting costs and saving on development time.

More resources...

All SilverlightShow Ebooks

We created a Silverlight web client & OOB client, and in the last part, we started thinking about our Windows Phone client. We ended up with some thoughts about what we should and shouldn't reuse - the conclusion was that we could reuse our existing XAML & C# skills, our domain services, and that we would be able to share code through the use of a Portable Class Library.

In this article, it's time to delve further into this: we exposed our domain services through SOAP endpoints, and now we'll learn how to consume them. We'll also look into that Portable Class Library.

You can download the source code for this article here (you can log in to the demo application with pete.campbell@madmen.com / abc@123).

Consuming domain services from Windows Phone.

Let's start with the Windows Phone client. We'll add the necessary references to the Windows Phone application by selecting "Add Service Reference…" and inputting the correct URI's: http://localhost/SalesDashboard.ServiceHost/EmployeeOpportunityService.svc/soap for the EmployeeOpportunity domain service, and http://localhost/SalesDashboard.ServiceHost/SalesAuthenticationService.svc/soap for the SalesAuthentication domain service. Visual Studio will generate the necessary proxy classes for us, including NotifyPropertyChanged notifications. We end up with 2 service references & corresponding proxies, which we can now use from our application.

The first thing we need to do is log in, which can be done with the following code:

private void Login()
{
    // try to log in with the provided credentials
    SalesAuthenticationServicesoapClient authenticationClientProxy = 
        new SalesAuthenticationServicesoapClient();
    authenticationClientProxy.LoginCompleted += (sLogin, aLogin) =>
    {
        if (aLogin.Error == null)
        {
            if (aLogin.Result.RootResults != null && aLogin.Result.RootResults.Count() > 0)
            {
                LocalStateContainer.AuthenticatedEmployee = aLogin.Result.RootResults.First();
                LocalStateContainer.CookieContainer = authenticationClientProxy.CookieContainer;
                var root = App.Current.RootVisual as PhoneApplicationFrame;
                root.Navigate(new Uri("/Views/MainView.xaml", UriKind.Relative));
                Messenger.Default.Send(new LoadOpportunitiesMessage() 
                { EmployeeId = LocalStateContainer.AuthenticatedEmployee.Id });
            }
        }
    };
    authenticationClientProxy.LoginAsync(UserName, Password, true, "");
}

After this, we can fetch our data. Note that, if a domain service requires you to be authenticated, you need to pass in the CookieContainer value you got after logging in to each service call. We can do that by setting the proxy clients' CookieContainer to that value:

private void LoadOpportunities(LoadOpportunitiesMessage msg)
{
    var client = new EmployeeOpportunityDomainServicesoapClient();
    client.CookieContainer = LocalStateContainer.CookieContainer;
    client.GetOpportunitiesForUserCompleted += (s, a) =>
    {
        if (a.Error == null)
        { 
            Opportunities = a.Result.RootResults;
        }
    };
    client.GetOpportunitiesForUserAsync(msg.EmployeeId);
}

When we try to test this… we'll get an error message: "Unable to set the CookieContainer. Please make sure the binding contains an HttpCookieContainerBindingElement."

Why is this? Well, by adding a service reference, Visual Studio creates a ServiceReferences.ClientConfig file, but by default, the binding that is create is a regular BasicHttpBinding. We need to change this to ensure the HttpCookieContainer is enabled. We can do this by opening the configuration file, and changing the binding to our EmployeeOpportunityDomainService as such:

<binding name="BasicHttpBinding_EmployeeOpportunityDomainServicesoap"
enableHttpCookieContainer="true"
maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">

Please note that this alone is not sufficient to secure your services, nor to pass and check credentials - it's just the starting point. Detailing the security aspects (transport security certificates & identity) of a Windows Phone application in combination with WCF RIA Services is out of scope for this article series, but if you're interested in this, you might want to have a look at my blog: in the recent past, I delivered a few sessions on this at various conferences, for which both the source code and slidedecks can be downloaded (Techdays session, WiPhug session) - the demo application for those sessions also includes code detailing how to submit data to a WCF RIA Service from a Windows Phone application.

If we build & run our application again and log in, we've got our list of Opportunities, straight from the domain service. However, there seems to be a problem when binding it to our View:

… as you might notice, there seems to be no value for Sector, Status, … What's happening?

Working with child entities.

The problem we're noticing in the above screenshot is due to the fact that only the "simple properties" from our entities are generated by default. While, in the Silverlight application, child entities that were sent over the wire (or were already available in the DomainContext instance) were accessible through, for example, Opportunity.Sector, this Sector property is now missing: we're only getting a SectorId. How can we solve this?

If we look at the generated proxy code, we see that the proxies classes for our entities are implemented as partial:

public partial class Opportunity : object, System.ComponentModel.INotifyPropertyChanged

This enables us to add code to that class in a different file. We can add a new property to another partial implementation of our Opportunity class, and this property will represent the Sector.

On to the next part of the problem: where does this Sector-property come from? As mentioned in the previous article, the result you're getting from a call to a domain service query method are actually divided into two properties: RootResults and IncludedResults. The IncludedResults include possible child entities (it's an ObservableCollection, so it can actually contain different types of entities - you'll have to check for this). This means that, if the query method that returns the list of Opportunities is coded in such a way that it also returns the corresponding Sector entity, we can simply fetch that Sector entity from the IncludedResults list, and assign it to the Sector property we implemented in our partial class.

Easy enough :-)

But… what if the query method didn't return those child entities (remember: we're reusing an existing implementation, and we're trying to change as little as possible to the service layer)? Well, the first part remains the same: extend the partial Opportunity class so it contains a Sector property. You could now go and fetch that entity from another query method for each Opportunity, but that would create a lot of overhead, and way too many requests to our service layer: after all, the list of sectors is quite small, and lots of opportunities share the same sector. So instead, we can opt for loading the list of sectors when we start the application, and storing them in a container. The Sector property would then get the corresponding sector from that list, in its property getter, as such:

/// 
/// The Sector property
/// 
public SalesDashboard.PhoneApplication.EmployeeOpportunityRef.Sector Sector
{
    get
    {
        return 
            LocalStateContainer.Sectors == null ? 
            null : LocalStateContainer.Sectors.FirstOrDefault(s => s.Id == this.SectorId);
    }
}

Either way, our opportunity list now includes the correct sector identification:

The same logic can be applied to add the Customer property of an Opportunity to the screen. After this, our application includes all the information we need to provide to the end user while he's on the road.

Sharing code: the Portable Class Library.

In a lot of projects, you have some common code you want to use across different clients: this might be code to execute some common business logic or algorithms, or some often-used functions. Typically, you'd put these in a class library project, which is then referenced by each client that needs that common code.

However, references are typically only allowed if they're built against the same CLR, and at the moment we already have 3 different CLR's we're working with: the full .NET 4.0 CLR, the Silverlight CLR, and the Silverlight for Windows Phone CLR. For our initial two clients (Silverlight & Silverlight OOB), we could leverage some of WCF RIA Services' shared code features, but this is getting harder as we progress to the Windows Phone client, and will become even more annoying when we're going to add a Windows 8 Metro client to the equation later on in this article series.

One often-used way to achieve code sharing without having to copy code around is by using the "Add as link" option. It works like this:

Create 1 class library project, typically built against the CLR that has the "least" features - in our case, that would be a Windows Phone class library project.
Create extra class library projects for each CLR you need the common code to be built against. For example, we'd end up with Common.WP7, Common.SL and Common.Server class library projects.
In those class library projects, add the files containing the common code "as link".
The class library projects themselves are then referenced by their respective client projects, allowing those clients to access the common code.

While this technique works, it has 2 major disadvantages:

You end up with clutter: extra projects in your solution, simply to be able to reference them.

It's easy to make mistakes: if you happen to add code to the common code files which doesn't result in a successful build against each CLR, your projects won't run anymore - even though the code successfully builds against one specific CLR version.

The Portable Class Library template solves this. On MSDN, we can find the following description:

"The Portable Class Library project enables you to write and build managed assemblies that work on more than one .NET Framework platform. You can create classes that contain code you wish to share across many projects, such as shared business logic, and then reference those classes from different types of projects.

Using the Portable Class Library project, you can build portable assemblies that work without modification on the .NET Framework, Silverlight, Windows Phone 7, or Xbox 360 platforms. Without the Portable Class Library project, you must target a single platform and then manually rework the class library for other platforms. The Portable Class Library project supports a subset of assemblies from these platforms, and provides a Visual Studio template that makes it possible to build assemblies that run without modification on these platforms."

You can add the Portable Class Tools from this link.

So: it allows you to add 1 class library project to your solution, in the properties of which you can tell which CLR's should be supported. The code you add to that class libary project will have to adhere to the lowest common denominator for the combination of selected CLR's (ensuring your code will build against each CLR version you selected). Next to that, Visual Studio allows you to add a reference to this class library from each project which builds against the CLR versions you selected in the class library's project properties, leaving us with only 1 common project.

For reference, I've added a Portable Class Library project to the solution, SalesDashboard.Common, which I referenced without issue in 3 projects built against a different CLR. Doing something like this in the past would have required the "add as link" trick mentioned above - thanks to the Portable Class Library templates, we no longer have to resort to such tricks, making it easier to share code, maintain the code base, and thus: reuse the common library & cut costs.

Conclusion

In this article, we’ve learned how to consume existing domain services from a new type of client: a Windows Phone application. We’ve also learned how we can reuse common code using the Portable Class Library project template.

Stay tuned for the next part! :-)

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 applications, mainly XAML-based, and a solution manager for Rich Applications (Windows 8 Metro, Silverlight, Windows Phone 7 Series, WPF, Surface, HTML5). His main focus lies on all things XAML, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a XAML enthusiast, he's a regular speaker on various national and international events, like Microsoft Techdays in Belgium, Portugal & Finland, NDC2011, Community Day, ... Next to that, he also authored two Silverlight books at Packt Publishing, of which the most recent one is the Silverlight 5 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on XAML, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/, and you can contact him on Twitter via @KevinDockx.

Part 6: Developing for a multitude of clients: strategies for code reuse and keeping costs in check.

editorial@silverlightshow.net (Kevin Dockx ) — Tue, 05 Jun 2012 12:33:40 GMT

Welcome to the sixth part of this article series on developing for a multitude of clients, in which we talk about strategies for code reuse and keeping costs in check. In the previous articles, we've looked into different ways of getting our code split up in modules, so they can be loaded on demand, and easily reused across different types of clients - thus cutting costs and saving on development time. However: up until now, we've focused on clients that were alike: a Silverlight web client, and a Silverlight Out of Browser client. In this article, we'll look into a different one: a Windows Phone client - in which code sharing isn't possible by default, as those apps are built against another version of the CLR.

More resources...

All SilverlightShow Ebooks

In this article, we'll look into what we can reuse from the existing code base when creating a Windows Phone client. Interesting to notice here is that "being able to reuse code" doesn't mean "should reuse code".

What can we reuse from our previous applications and/or backend?

Of course, we've got some skill reuse: after all, Windows Phone development is Silverlight development. That said, there are other things to keep in mind here.

The first one: what do we want to offer to our end users with this mobile application? As stated in the first part of this article series, the general idea of having a mobile component to an already-existing application is that we do not want to offer the complete set of functionalities the full application has to the end user. We're building a way to extend his experience to on-the-road use, we're not building a replacement of the full application - for our business case to succeed, the end user should still have an incentive to use the full-blown application.

Second, there's the connection we're working with: you're typically running on an EDGE or 3G connection, meaning: slower than the Wi-Fi or networked connection used with the other Silverlight clients, and, depending on the plan the end user has with his phone company: potentially (exponentially) more expensive. This means that the amount of data transferred should be kept in mind at all times - and preferably as low as possible. We need to find a good trade-off between data transfer, speed and development time.

Third, there's the UI. When you're designing a Windows Phone application, you're designing for smaller screen estate, with touch-based input, and you'd want your application to feel like it conforms to the way Windows Phone apps typically look. This typically requires a different UI than our Silverlight clients. Microsoft has a great set of guidelines on Metro design, which you can read about here.

With all these things in mind, what can we reuse for our phone client? Obviously, we shouldn't reuse the Views, as they will deliver a sub-par user experience, almost by default (different screen estate, different input method). We shouldn't reuse our ViewModels: after all, they are, by convention at least, coupled to the corresponding Views, and designed for regular Silverlight clients - bandwidth considerations are different. And even if we would ignore that, some of the code in those ViewModels won't just recompile in a Windows Phone application: it's built on a different version of the CLR. One obvious example would be the way we'll access our services: working with a Domain Service from Windows Phone = working with the SOAP or REST (JSON) endpoints.

What can we reuse then?

Existing skills
Our backend services: the Authentication domain service, and the Employee Opportunity domain service.
We can also reuse some common login and/or code, typically by transferring that code to a class library that can be referenced by the Silverlight app as well the Windows Phone app. As you might know, this isn't possible by default: Visual Studio disallows referencing assemblies that are built against a different version of the CLR, or (depending on what it's built against) will warn you about this. Luckily, there's a specific project template designed for this, the Portable Class Library.

Windows Phone client: the demo application case.

The general idea behind our new mobile client is that we want to provide our customers with parts of the functionality of the full application, not all of it. While it's technically possible, we're not trying to rebuild the complete application on the phone: it makes more sense to only provide those parts that are useful when on the road. Coincidently, that fits with the theme of this article series: when you're trying to keep costs in check, scope management is very important.

For the demo application, we're going to enable the user to log in to the app on the phone, get an overview of his opportunities, and look at the detail of them. An app like this contains everything we need for this series: reuse of the services, and sharing of some common logic. Note that if we were to build this app for real-life use, we might want to enable the user to edit/add new opportunities on the go as well.

There's a tremendous amount of resources available at SilverlightShow if you want to learn more about building Windows Phone applications.

Reusing the backend: consuming domain services from a Windows Phone application.

WCF RIA Services is a powerful framework for building Silverlight application: you get client-side change tracking, generation of client-side versions of your entities, validation, authentication/authorization, … When you try to use this in a Windows Phone application, you'll immediately notice this isn't possible in the way you're used to: you cannot reference the necessary WCF RIA Services assemblies in your Windows Phone application, you don't get client-side Domain Contexts corresponding to your domain services, … so - are we stuck?

No, we're not: domain services can be accessed from a Windows Phone application through a variety of endpoints: SOAP, REST and OData (read-only). For our application, we're going to reuse both domain services: the SalesAuthenticationService to log in, and the EmployeeOpportunityService to get data to the Windows Phone application.

The WCF RIA Services Toolkit contains all the necessary components to allow this - and the easiest way to add this is through NuGet. Locate the RIAServices.Endpoints package, and install it to the Dashboard ServiceHost. Installing this will add a few lines of code to the web.config file:

<domainServices>
      <endpoints>
        <add name="OData" type="System.ServiceModel.DomainServices.Hosting.ODataEndpointFactory,
System.ServiceModel.DomainServices.Hosting.OData, 
Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        <add name="soap" type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory,
Microsoft.ServiceModel.DomainServices.Hosting, 
Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        <add name="JSON" type="Microsoft.ServiceModel.DomainServices.Hosting.JsonEndpointFactory, 
Microsoft.ServiceModel.DomainServices.Hosting, 
Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      endpoints>
domainServices>

We're going to use the soap endpoint. As you can see in the web.config file, it's the SoapXmlEndpointFactory that ensures the soap endpoint is created & accessible. To access a domain service through its soap endpoint, you can navigate to "namespace.classname", replacing the dots by dashes, and adding .svc to that url. However, in the second article of this series, we enabled better naming for our services: this makes it even easier to access the soap endpoints, as it's exactly the same URL as before: http://localhost/SalesDashboard.ServiceHost/EmployeeOpportunityService.svc?wsdl

Let's have a look at the WSDL, with these new endpoint factories in the web.config:

<wsdl:service name="EmployeeOpportunityDomainService">
<wsdl:port name="BasicHttpBinding_EmployeeOpportunityDomainServicesoap"
 binding="tns:BasicHttpBinding_EmployeeOpportunityDomainServicesoap">
<soap:address location="http://localhost/SalesDashboard.ServiceHost/EmployeeOpportunityService.svc/soap"/>
wsdl:port>

(note: the WSDL is much bigger than the excerpt above – this is the SOAP-related part)

As you can see, simply by adding the endpoint factories from the RIAServices.Endpoints package, our domain services are accessible through the SOAP endpoint. We're done with the server side for now.

How does a domain service work when exposed through a SOAP endpoint?

An important question remains: how does a domain service function when a client tries to access it through a SOAP endpoint?

For each query method we've defined in our domain service, a corresponding method is generated in the proxy client, so we can load data from the domain service to the Windows Phone application.
When the operation completes, we get a set of results through the completed events' arguments. This result object inherits QueryResult, and contains two properties that are interesting for us: RootResults and IncludedResults. RootResults contains the list of parent items returned by the domain service query method. IncludedResults contains possible child items, if you're returning those (as you know, you can include child entities to be sent over the wire with RIA Services by using the [Include] attribute in your metadata file)
To submit data, you can create a list of ChangeSetEntry on the client, which you can pass to the proxy clients' SubmitChangesAsync method. Once this call reaches the server, the corresponding create, update or delete methods will be executed. This will recreate the change set on the server, entry by entry, after which they will be persisted to the data store (in our case, we're using the Entity Framework as backend store).
The call to that method will return with a list of ChangeSetEntry: this will contain each persisted entry. You can use this list to check for problems when submitting, for ValidationErrors, ...

That is, in a nutshell, how the main functionalities of a domain service are exposed to our Windows Phone application: we've got all our query methods, we can get results including child results, we can create a change set in our Windows Phone app, and we can submit this change set back to our domain service.

What’s next?

In the next article, we’ll look at how we can consume the SOAP endpoints we’ve created from our Windows Phone application: we’ll look into authentication, and passing that authentication cookie to the domain service calls. Next to that, we’ll also look into how we can achieve some further code sharing through the use of a Portable Class Library.

Stay tuned! :-)

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 applications, mainly XAML-based, and a solution manager for Rich Applications (Windows 8 Metro, Silverlight, Windows Phone 7 Series, WPF, Surface, HTML5). His main focus lies on all things XAML, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a XAML enthusiast, he's a regular speaker on various national and international events, like Microsoft Techdays in Belgium, Portugal & Finland, NDC2011, Community Day, ... Next to that, he also authored two Silverlight books at Packt Publishing, of which the most recent one is the Silverlight 5 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on XAML, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/, and you can contact him on Twitter via @KevinDockx.

Part 5: Developing for a multitude of clients: strategies for code reuse and keeping costs in check.

editorial@silverlightshow.net (Kevin Dockx ) — Mon, 16 Apr 2012 13:18:00 GMT

Welcome to the fifth part of this article series on strategies for designing your application for a multitude of different clients. In the first part, we’ve looked into the business case & some general concerns, and in the second part, we made a choice for a service layer: WCF RIA Services. In the third part, we’ve seen how we can use MEF for on demand loading & code reuse across different clients, and in the fourth part, we’ve learned how to load a multitude of assemblies on demand, and we’ve learned how we can navigate to views in an on-demand loaded assembly by implementing a custom content loader in combination with a view factory.

More resources...

All SilverlightShow Ebooks

In this part, we’re going to add another client to equation: a Silverlight Out of Browser client. After all the work we’ve done on the previous articles, we’ll see just how easy it is to reuse most of the code we already have.

You can download the source code for this article here (you can log in to the demo application with pete.campbell@madmen.com / abc@123).

Getting started: adding a new, Silverlight Out of Browser client

To start, we’re going to have to add a new client to our solution. I’ve added a new Silverlight client, named SalesDashboard.Silverlight.DesktopClient, to the solution, and configured it to run as an Out of Browser application (project properties –> Silverlight).

As we’re aiming to reuse a lot of code, the Out of Browser application itself doesn’t really have to contain a lot of code: in essence, we’ll need to ensure the correct references are there, and the correct assemblies are loaded when we start the application – just like we did with the in-browser Silverlight client.

For the references, we can simply go down the same road as explained in the previous article: commonly used code, existing assemblies that contain classes used throughout the application, … are added as a reference. This includes the MVVM Light related assemblies, Toolkit assemblies, … On the other hand, code that belongs to a specific module is loaded on demand: we do add them as references, but we set the Copy Local flag to false, ensuring they’re not copied to the output directory (and thus not packaged in the resulting XAP file, keeping file size and initial load small).

For our new client application, this results in setting the Copy Local flag to false for SalesDashboard.Client.Model (the generated model), SalesDashboard.SL.Modules.EmpOpp.ViewModels (the ViewModels from the Employee Opportunity module) and SalesDashboard.SL.Modules.EmpOpp.Views (the Views from the Employee Opportunity module) : these will be loaded when we start the application.

For demo purposes, this should result in the same application running in the browser as out of the browser, but remember: as this series is about separating out your application in modules & reusable code, nothing stops us from loading different modules in the Out of Browser application.

But wait – if the resulting applications should be the same, and we’ve separated out as much as possible, shouldn’t we simply be able to copy/paste the code from the in-browser application? Well, let’s try that, shall we? Simply copy/paste the MainPage.xaml (and .cs) and App.xaml (and .cs) code into the Out of Browser application, and try to run the application.

It compiles. But it doesn’t run. Although we don’t really have to change a lot – two things, actually. Let’s look into those.

The first issue: errors when loading assemblies.

The first thing we will notice when we try to start our application is a “Type not found” error:

HeaderView is a view which is defined in an assembly we’re loading at startup: SalesDashboard.SL.Modules.EmpOpp.Views. An error like this suggests the assembly hasn’t been loaded, so therefore, an instance of HeaderView cannot be added to the MainPage.

If we look into what happens at application start, something immediately becomes obvious: we’re passing in a list of assemblies to load to our ParallelAsyncProcessor instance. Code like this will try to find these assemblies in its own startup directory – that worked fine for the in-browser application (as the assemblies are deployed to the Webhosts’ ClientBin folder), but for the Out of Browser application, this isn’t sufficient anymore. We need to pass in the exact Uri:

foreach (var dependency in lstDependencies)
{
    // note:  pass in another variable instead of directly passing in the dependency string. 
    // This ensures this new value is used when executing the parallel processes instead 
    // of using the last passed-in string multiple times 
    var foo = dependency;
    var catalogDep = new SuperDeploymentCatalog(
        new Uri("http://localhost/SalesDashboard.WebHost/ClientBin/" + foo));
    catalog.Catalogs.Add(catalogDep);
    EventHandler handler = null;
    handler = (s, a) =>
    {
        parallelAsyncProcesser.ProcessComplete(foo);
        catalogDep.DownloadCompleted -= handler;
    };
    catalogDep.DownloadCompleted += handler;
    parallelAsyncProcesser.AddToParallelQueue(() => catalogDep.DownloadAsync(), foo);
}

If we now build and run the application again, we’ll see we won’t get any errors anymore. The problem? We don’t get anything at all anymore: just a white page, nothing more. What’s going on?

The second issue: no more errors, but a white screen instead of an application.

To be honest, this issue actually left me quite puzzled for a while when I first ran into it. I started looking through my code, but couldn’t find anything out of the ordinary – after all, we’re executing the exact same code as in an in-browser application. What I did notice was that the callback handlers, used by the SuperDeploymentCatalog, didn’t return anymore: it seemed as though the requests for external assemblies were executed, but they never returned: a callback wasn’t received anymore. I started looking around on the internet, and finally found out how this issue can be resolved: by setting the RootVisual element before loading the assemblies on-demand (not sure anymore if it was Pete Browns’ blog or Jeremy Likness’ blog where I read about this first, but both are great resources to check out).

Apparently, setting the RootVisual ensures some behind-the-screens wiring is done, so the handlers actually return, and the applications’ code continues. I don’t find this behavior documented anywhere on MSDN – I would actually qualify this as a bug that only happens in an Out of Browser Silverlight application.

How can we solve this? We cannot set the RootVisual to an instance of MainPage when the application loads, as that would result in composition & instantiation errors: the controls on our MainPage are defined in assemblies that are loaded on-demand. What we can do is create an extra user control, and set that as the RootVisual when we start the application. Afterwards, after our assemblies have been loaded, we add an instance of MainPage to that user control, as its only child (note: setting the RootVisual to a dummy control on load, and changing it to an instance of MainPage after the assemblies have been loaded doesn’t work either).

To this avail, I created a user control, MainPageHost. This is actually a simply, empty control, which only contains a LayoutRoot element.

In Application_Startup, we set the RootVisual to an instance of MainPageHost. Once the assemblies have been loaded, I call a method on MainPageHost, LoadApplication(). This method sets the MainPageHosts’ LayoutRoot (which is a Border) child to an instance of MainPage(). This results in our application getting instantiated, which now works because all necessary assemblies have been loaded.

Code in App.xaml.cs:

parallelAsyncProcesser.AllProcessesCompleted += () =>
{
    // dependencies have been loaded, init app startpage
     (this.RootVisual as MainPageHost).LoadApplication();
};

Code in MainPageHost.xaml.cs:

internal void LoadApplication()
{
    LayoutRoot.Child = new MainPage();
}

We can now build and run our application – and everything will work as it’s supposed to work. We’ve now created an Out of Browser client with very little effort, composing the application on-load by reusing the components we’ve separated out in the previous articles of this series.

Conclusion

In this article, we’ve seen how we can add an extra client to our solution, which reuses a lot of code from the previous articles in this series. We’ve also learned how to work around 2 issues: passing in the correct Uri so the assemblies that have to be loaded can be found, and ensuring the necessary behind-the-screens wiring is done so the application execution can continue as expected.

What’s next?

Stay tuned for the next part of this article series, in which we’ll add a Windows Phone client to the equation!

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, HTML5). 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 Techdays in Belgium, Portugal & Finland, NDC2011, Community Day, ... 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 athttp://blog.kevindockx.com/, and you can contact him on Twitter via @KevinDockx.

Interview with Braulio Diez on the new book 'Mastering LOB Development for Silverlight 5: A Case Study in Action' (by Packt Publishing)

editorial@silverlightshow.net (Silverlight Show ) — Mon, 09 Apr 2012 12:00:00 GMT

In this short SilverlightShow interview we talk with Braulio Diez who is a co-author of the recently released e/book ‘Mastering LOB Development for Silverlight 5: A Case Study in Action’. Thanks to Packt Publishing, SilverlightShow readers may now purchase this book with a 27% discount using discount code dssvl2! Enjoy!

SilverlightShow: Hi Braulio! We have recently announced your new book ‘Mastering LOB Development for Silverlight 5’ on SilverlightShow Book Shelf, and it already got an unusually high number of visits. Following this interest, and thanks to Packt Publishing, we also published a free chapter from the book (read here). What do you think is the reason for this interest?

BD: Developing LOB applications using Silverlight is a perfect match, it allows you to develop at high speed level and base your applications on a robust architecture. This book is focused on this hot topic, we have applied on it lessons learned from real world experience.

SilverlightShow: Which parts of the book have you authored, and what would you name as the top/most interesting concepts covered in those?

BD: I have authored the following parts: Architecture, RIA Services, OOB and Security. The parts I like the best from this book, is the “real” life approach to RIA Services, how to manage unhandled errors, and the Architecture part (MVVM + MEF + MVVM Light toolkit).

SilverlightShow: Which do you think are the top 3 reasons for using Silverlight 5 for LOB applications?

BD: Avoid the browser versioning hell, take advantage of using C# on the client side, and separation of concerns + unit testing.

SilverlightShow: Does Silverlight 5 lack something to become a perfect technology for LOB?

BD: Does not work in an iPad or iPhone :)

SilverlightShow: There have been a lot of discussions on the future of Silverlight. What does Windows 8 mean for the future of Silverlight, and how will Win8 affect the development of LOB apps with Silverlight?

BD: Silverlight will have its place inside a desktop, if a tablet / mobile edition of the app is needed, we can take advantage of XAML + C# in WinRT.

SilverlightShow: Finally, why should someone get this book, rather than try to find coverage of the same topics on the Internet?

We have tried to cover in this book and end to end guide, based on real world experience, to quickly allow developers start implementing Silverlight LOB applications, it contains a complete LOB case study build gradually from start to finish throughout each chapter.

Thanks Braulio! Hope Silverlight developers will truly appreciate this book!

Mastering LOB Development for Silverlight 5: Out of Browser (OOB) Applications

editorial@silverlightshow.net (Silverlight Show ) — Tue, 03 Apr 2012 14:57:57 GMT

This is a free chapter of the book "Mastering LOB Development for Silverlight 5: A Case Study in Action".
Thanks to Packt Publishing, SilverlightShow readers may now purchase this book with a 27% discount using discount code dssvl2! Enjoy!

LOB (Line of Business) applications executing within a web browser are fine, but if we think from the perspective of a final user, it is not the option that they would choose first. This is due to the fact that:

Having a desktop application is easy. It can be directly accessed by double-clicking so that it is launched quickly.
Most of the time, it is necessary to leave Silverlight sandbox application. This happens, for example, when we need to access the filesystem, or with a special hardware via COM (such as an ATM).
It is also crucial that, when executing an application, it allows us to work offline.

Similarly, from the point of view of the user, there are certain restrictions which are normally not well accepted, even though they are 100 percent desktop (namely WPF). It would be great to have the possibility of eliminating them:

Installing a desktop application can carry problems, depending on the OS and installation details. It would be fantastic if they could run under a standard, which is independent from those details.
In order to update a version already installed, it must be uninstalled and installed again. Wouldn't it be preferable that the application itself detected if there is a new version and updated automatically (even though this process is not dramatic)?
Usually, desktop applications only work on a particular OS (that is, Windows). We would love to execute it in different platforms (for example, Mac).
A desktop application normally has quite relaxed permissions. Hence, we dream of an application having restricted access to the hardware and software of our machine. It would only have permissions if allowed.
A desktop application needs a given version of the .NET Framework installed on the machine.

In this chapter, you will learn how to install and execute our applications as Out of Browser (OOB), work with elevated permissions in and out of the browser, support cross domain calls, and work with the WebBrowser control.

Out of Browser (OOB)

Out of Browser (OOB) applications are executed out of the web browser, or that is the impression they give.

Regarding the final user, an OOB application is similar to a desktop application; the user installs it, gets a direct access icon to it, and when executed, it runs under a standard window, as shown in the following screenshot. It can even be uninstalled through the Control Panel.

From the point of view of the Software Developer, an OOB application still runs under a hidden browser, that is, it is a Silverlight application with the same features as an application running under a browser.

Until the arrival of Silverlight 5, the main difference with an application executing in the browser was the fact that it could work with trusted permissions and perform operations, which the sandbox normally does not allow (accessing the filesystem, executing commands via COM+, and so on).

Executing an application in OOB mode

Allowing a Silverlight application to be executed as an OOB is very easy. We just need to tick a checkbox in the project settings. Let's see how to do it.

First, create a new Silverlight application called 01_Simple_OOB_App. In the MainPage, a text block must be added displaying the message Simple OOB App. When you execute it, it will look as a standard in-browser application, as shown in the following screenshot:

In order to enable OOB mode, follow these steps:

1. Right-click on the Silverlight project root. When the context menu is displayed, click on Properties:

2. Select the Silverlight tab and tick the checkbox with the message Enable running application out of the browser:

3. When executing the application, it still runs in the browser but, if we right-click on it, there will be a new option Install 01_Simple_OOB Application onto this computer… in the context menu, as shown in the following screenshot:

4. If we click on that option, we get a message prompt asking to install the app, as shown in the following screenshot:

5. Once we click OK, the application is installed and ready to be used as OOB.

It is great to use apps as a final user, but what happens with developers? In case we want to debug our OOB application, will we have to install it every time we run the environment? Of course not. In the project properties (Context menu | Properties), the Debug tab allows us to choose that the application starts up straight in OOB mode (the Silverlight project will have to be chosen as a start-up project):

Enhancing the experience—tooling up and updating

As we have already seen, enabling the OOB mode in our application is something quite straightforward. Nevertheless, the following doubts may have arisen:

In some cases, I want to know if my application is running in normal or OOB mode to, for instance, show one UI or another. How can I do that?
How can I know if the application is already installed?
When installing from a not very intuitive contextual menu, is there any way to display our own UI in order to allow the user to install the application?
How do I uninstall an OOB application?
I would like to let the users install my application from a CD, eliminating the need to be connected to the Web. Is that possible?
When a new version of my application is uploaded to the production server, is there any way to detect updates and install new versions automatically?

In-browser/OOB detection

Sometimes, the UI we want to show differs depending on whether the application is executing in the browser or as an OOB application. It may also happen that, when it is in-browser, we only want to display a button to install it.

In order to know the mode we are working with, Silverlight offers a function on the level of the application called IsRunningOutOfBrowser, which returns true or false depending on whether the application is executing in OOB mode or not.

To see how it works, let's go back to the previous example, TestOOB, and indicate whether the application is executing in OOB mode or not in the TextBlock we use in the main page. It can be done using the following steps:

1. Open the project previously created (Simple_OOB_Application).

2. Add an ID to the TextBlock of the main page (it will be named tbStatus):

"LayoutRoot" Background="White">

"tbStatus" Text="Simple OOB App" 

FontSize="16"/>

3. In the constructor of the page, check the value of the application variable IsRunningOutOfBrowser, which will display one of two messages depending on the state.

public MainPage()

{

    InitializeComponent();

    if (App.Current.IsRunningOutOfBrowser == true)

    {

        tbStatus.Text = "I'm running out of browser";

    }

    else

    {

        tbStatus.Text = "I'm running in browser";

    }

}

4. Therefore, in case we are executing in OOB mode, the following message will be displayed:

Detecting the application installed

Another common scenario arises when the application is being executed in the browser and we need to know if it has already been installed as OOB. For instance, a common example of this is when we want to display a message asking the user whether to install the application or not. We can make use of the application variable InstallState, which returns a type enumerated with one of the following values: NotInstalled, Installed, Installing, or InstallFailed.

Thus, in the sample application that has been created, it could be checked whether the application is installed or not in the following way:

public MainPage()

{

    InitializeComponent();

    if (App.Current.InstallState == InstallState.Installed)

    {

        tbStatus.Text = "Application Installed";

    }

    else

    {

        tbStatus.Text = "Application not installed";

    }

}

Installing the custom interface

As mentioned previously, installing the application from the contextual menu of our Silverlight application was not intuitive at all. Perhaps it could be possible to place a button so that the user could begin the installation. Up to what point can we customize the installation process of our Silverlight application? Silverlight allows us to launch the installation process by code, as long as it comes from a user petition (such as a click on a button). The dialog which asks if we want to install the application cannot be customized.

To install the application, the method Install of Application must be called. Let's add this functionality to our basic sample:

1. Add a button to the main window:

"LayoutRoot" Background="White">

"tbStatus" Text="Simple OOB App" FontSize="16"/>

Name="button1" VerticalAlignment="Top" Width="75" />

2. Subscribe to the Click event:

Margin="142,55,0,0" Name="button1" VerticalAlignment="Top" 

Width="75" Click="button1_Click" />

3. Check if the application has already been installed in the handler of the button and add the call to Install:

private void button1_Click(object sender, RoutedEventArgs e)

{

    if (Application.Current.InstallState == InstallState.NotInstalled)

    {

        Application.Current.Install();

    }

    else

    {

        MessageBox.Show("Application already installed");

    }

}

4. Execute the application. When you click on the new button, the dialog box asking you if you want to install the application will be displayed, as shown in the following screenshot:

Uninstalling an OOB application

To uninstall a Silverlight application, the user can choose among several options:

They can right-click on the application and, in the contextual menu, choose the Remove this application… option, as shown in the following screenshot:

It can be uninstalled right from the Windows Control Panel:

The customization of the installation is an improvement that is pending to be added to Silverlight.

Offline installation

Sometimes, we face scenarios where it is necessary for the user to be able to install the application from a CD, or that an administrator can make an implementation. This scenario is not ideal for Silverlight applications (normally, the user downloads them from a URL, either intranet or extranet and, moreover, benefits from automatic updates).

If you face this situation, you may wonder whether it is more convenient to orient development to WPF-Click once, or use the method explained by Tim Heuer in his blog: Installing Silverlight Offline (http://timheuer.com/blog/archive/2008/09/29/install-silverlight-2-rc0-offline.aspx).

Even though this method allows us to install our OOB application in a silent mode,
it has certain limitations:

If the user does not have the Silverlight plug-in installed, they will need to be connected to the Internet to download it from the Microsoft website
The installation in silent mode is not valid for trusted OOB applications

Updates

OOB applications are installed on our own machine, which means there are a lot of advantages, such as fast boot, offline work mode, and so on. Nonetheless, what happens if we upload an update to the server? Is there a way to update our local application? Of course there is. What's more? It is possible in an easy and powerful way. Let's see it in action:

In the app.cs file, subscribe to the event named CheckAndDownloadUpdateCompleted and, later, make the asynchronous petition to check if there is a new update and, if so, download it automatically. The following is the source code:

private void Application_Startup(object sender, StartupEventArgs e)

{

    CheckAndDownloadUpdateCompleted += 

    new CheckAndDownloadUpdateCompletedEventHandle

    r(Application_CheckAndDownloadUpdateCompleted);

    CheckAndDownloadUpdateAsync();

    (…)

}

private void Application_CheckAndDownloadUpdateCompleted(object sender, CheckAndDownloadUpdateCompletedEventArgs e)

{

    MessageBox.Show("Application updated, please restart.");

}

Updates will work as long as our XAP is not in a file that needs security.

Offline work

An advantage of working with OOB applications is that, once they have been installed, it is not necessary to have an Internet connection to execute them (they are downloaded locally). What does this mean? It is possible to implement an offline work method for our applications, which permits, for example, that a user on a flight can work with the application and, later, when they have an Internet connection, they can synchronize the data with the server.

To work offline, it is necessary to have a repository to store reference data, as well as changes or new creations. If our Silverlight applications normally work within a sandbox and we do not have access to the HDD of the local machine, what can we make use of? In such cases, we have two options: either requiring elevated permissions for our application to execute (this will be dealt with later) or making use of the Silverlight Isolated Storage.

Isolated Storage is a virtual filesystem that allows a Silverlight application to store data in an invisible folder in the machine. By default, a Silverlight application can use 2 MB of storage. Isolated Storage is a 10 MB OOB application, but the user can
be asked to increase the quota.

Let's see a simple sample of how to read and write data in the Isolated Storage. This example is available in the online material on http://bit.ly/5gEwuM.

You can create a file in the Isolated Storage using the following code:

using System.IO.IsolatedStorage;

using System.IO;

(…)

private void WriteContentToIsoStorage(string content, string filename)

{

    using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication())

    {

        using (IsolatedStorageFileStream isfs = new IsolatedStorageFileStream(filename, FileMode.Create, isf))

        {

            using (StreamWriter sw = new StreamWriter(isfs))

            {

                sw.Write(content);

                sw.Close();

            }

        }

    }

}

You can read the information using the following code:

using System.IO.IsolatedStorage;

using System.IO;

(…)

private string LoadContentFromIsoStorage(string filename)

{

    string data = String.Empty;

    using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication())

    {

        using (IsolatedStorageFileStream isfs = new IsolatedStorageFileStream(filename, FileMode.Open, isf))

        {

            using (StreamReader sr = new StreamReader(isfs))

            {

                string lineOfData = String.Empty;

                while ((lineOfData = sr.ReadLine()) != null)

                data += lineOfData;

            }

        }

    }

    return data;

}

To continue learning how this works, you can follow this link: http://bit.ly/qkY9UM.

How it works

Normally, when data have to be obtained or updated, we communicate with the server via a web service to get or modify this information.

To avoid this connection, we can do the following: first, get the most commonly read data and store them in a cache; second, the user creates his/her own entries, which are stored in the local repository (Isolated Storage). Once the user has an Internet connection again, offline data is sent to be synchronised in the repository.

Offline work is not as easy as it may sound. Another book could be written only on this! If you want further information about this, we can recommend the following session by Steve Lasker, Offline Microsoft Silverlight Applications (http://bit.ly/ltIxNt).

Breaking the sandbox—trusted applications

Up to now, we have seen how an OOB Silverlight application runs within a sandbox. That is to say, its access to certain resources is limited or restricted. What happens if we need to perform operations that the sandbox has restricted due to safety reasons? To solve this issue, there are applications with elevated permissions:

A trusted OOB application is a program the user trusts (similar to when a desktop application is installed on our machine).
Its XAP file is signed with a certificate, which ensures its trustworthy origin.
It has elevated permissions, which makes it possible, for example, to make calls to COM components, P/Invoke calls, or access the local filesystem.
For the application to be installed/executed, it needs the express authorization of the user.

Enabling trusted mode

How can an OOB application be enabled to require elevated permissions? To configure a Silverlight program that already exists, follow these steps:

1. Go to the Properties tab of the Silverlight Project (contextual menu of the project, Silverlight | Properties) and click on the button Out-of-Browser Settings…:

2. A dialog is displayed, where the option Require elevated trust when running outside the browser must be checked, as shown in the following screenshot:

After these steps, our application will be enabled as OOB trusted. However, if a user tries to install it, they will receive a warning indicating the source that published the application cannot be trusted. To eliminate this message, we will have to use our enterprise's certificate or acquire a new one (we can buy one or, if it is an intranet, our IT administrator can generate a new one). This operation can be performed from the Signing tab in the project's properties (right-click on Silverlight project | Properties | Signing).

Advantages of trusted applications

Now we have our trusted application, which has the following additional advantages:
We can access the filesystem of the machine (from the Silverlight 5 version).
We can make calls to COM components. We can read or write to the registry (only current user entry), call other executable files, and so on.
It is possible to make P/Invoke calls.
We can make petitions to a URL, even if they are cross domain. It is not necessary that the server has a cross-domain policy enabled.
It is possible to integrate a WebBrowser control in our application. That is, we can display HTML in our Silverlight application and interact with it.
Real windows can be created. Normally, when new windows are created in a Silverlight application, they are a fantasy; that is to say, they are not physical windows, but they are displayed within the main one. If our application is trusted (only SL version 5), we can create floating windows and, for instance, they can be displayed on several monitors.

Accessing files

Our trusted application has access to the local filesystem (if it is Silverlight 5; in case it is Silverlight 4, it can only access folders, such as My Documents and via COM calls it's possible to gain additional access). The operations on System.IO, which previously returned safety errors, will now be executed flawlessly.

As a sample, let's see how the content of the Program Files file can be listed in our trusted Silverlight application:

public class ViewModel

{

    public ObservableCollection<string> DirNames { get; set; }

    public ViewModel()

    {

        DirNames = new ObservableCollection<string>();

        // Let's try to enumerate the directories that are

        // under Program Files, this operation would throw an

        // exception if the application is not a trusted one.

        DirectoryInfo di = new DirectoryInfo("C:\\Program Files");

        foreach (var info in di.EnumerateDirectories())

        {

            DirNames.Add(info.FullName);

        }

    }

}

Making calls to COM+

We can make calls to COM components, which open plenty of doors, such as reading and (partially) writing on the registry, communicating with devices, launching apps, and even using Excel Automation.

However, the main disadvantage of this approach is that it only works in Windows. So if our application needs to run in Mac, this code must be isolated and will not offer this functionality for that platform.

If you need to detect under which OS a Silverlight application is running, you can use Environment.OSVersion.

Let's see a couple of examples of how to make these calls.

Writing an entry on the registry

In order to do so, create a new Silverlight Application project and tick the checkboxes (Enable Running application out of the browser, Out-of-Browser Settings | Require elevated trust when running outside the browser).

Add the reference to the Microsoft.CSharp DLL (Add Reference | .NET | Microsoft.CSharp):

Make sure this DLL and System.Core are referenced:

You can write the entry on the registry using the following code:

using System.Runtime.InteropServices.Automation;

(…)

private void button1_Click(object sender, RoutedEventArgs e)

{

    using (dynamic shell = AutomationFactory.CreateObject("WScript.Shell"))

    {

        shell.RegWrite(@"HKCU\Software\MyTest", "");

    }

}

The result is as shown in the following screenshot:

Executing notepad from our application

Another interesting feature is the ability of launching other applications from our trusted application. In the following code we will launch a Notepad.

using System.Runtime.InteropServices.Automation;

(…)

private void button1_Click(object sender, RoutedEventArgs e)

    {

        dynamic cmd = AutomationFactory.CreateObject("WScript.Shell");

        cmd.Run(@"c:\Windows\notepad.exe", 1, true);

    }

P/Invoke

As an innovation, Silverlight 5 includes call support via P/Invoke. Platform Invocation Services allows managed code to call unmanaged functions that are implemented in a DLL. This is only allowed for full-trust applications.

Let's see how this works by creating a sample, which calls a kernel32.dll method reproducing system beeps. Follow the steps mentioned next:

1. Create a new Silverlight project (application) and configure it to be an OOB application with trusted permissions.

2. Add a new class (by means of Add New Class) called MyBeep. Implement the Beep method of the Kernel 32 DLL.

using System.Runtime.InteropServices;

public class MyBeep

    {

        [DllImport("User32.dll")]

        private static extern Boolean MessageBeep(UInt32 beepType);

        public void PlaySound(BeepTypes type)

        {

            if (!MessageBeep((UInt32)type))

            {

                throw new Exception("Beep failed!");

            }

        }

    }

public enum BeepTypes : uint

{

    Ok = 0x00000000,

    Error = 0x00000010,

    Warning = 0x00000030,

    Information = 0x00000040

}

public static class BeepTypeExtensions

{

    public static BeepTypes AsBeepTypeEnum(this string beepType)

    {

        BeepTypes beepTypeEnum;

        return Enum.TryParse(beepType,true,out beepTypeEnum)

        ? beepTypeEnum

        : BeepTypes.Error;

    }

}

3. In the main page (mainpage.xaml), add a button to be bound to the Click event as follows:

Click="button1_Click" />

4. In the Code-Behind (MainPage.cs), make the call to the method defined in the MyBeep class.

private void button1_Click(object sender, RoutedEventArgs e)

{

    MyBeep myBeep = new MyBeep();

    myBeep.PlaySound(BeepTypes.Information);

}

If an exception appears when executing the action, check the application settings and make sure that it is running in OOB trusted mode.

Cross-domain calls

When executing our Silverlight application within the sandbox, we can make calls to services, or ask for resources, which are in our domain. However, if we try to access resources in a different domain (namely a feed of Apple's film trailers) this call can return an error since, due to safety reasons, these calls are restricted unless the web service authorizes them explicitly. The following are the solutions we have within sandbox:

The server may have an XML file with the cross-domain policy indicating we have access to these resources. It can be checked by launching a query to the Apple feed and using the Fiddler packages sniffer. We will then realize if this server exposes a cross-domain policy.
It is possible to implement a service in our server acting as a proxy. The bad thing about this approach is that we overload the server and the response to the client is slower.

If our application is executed as trusted, this restriction does not exist. We can make the petition to a cross domain without having the cross-domain policy enabled. For instance, we can make a query to the Apple feed to check new cinema openings.

private void button1_Click(object sender, RoutedEventArgs e)

{

    WebClient wc = new WebClient();

    wc.DownloadStringCompleted += new DownloadStringCompletedEventHandler(wc_DownloadStringCompleted);

    wc.DownloadStringAsync(new Uri("http://www.apple.com/trailers/home/xml/current.xml", UriKind.Absolute));

}

void wc_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)

{

    MessageBox.Show(e.Result);

}

WebBrowser control

Another interesting control we can only use in trusted OOB applications is the WebBrowser control. This allows us to view HTML pages within our Silverlight application. Besides, if the page is in the same domain, we can even interact with it via Silverlight | JavaScript.

How it works

Let's check how this control works by creating a simple example:

1. Create a new Silverlight project (application) and configure it so that it is executed as an OOB application with trusted permissions.

2. In the XAML, add the namespace System.Windows.Controls and instantiate the control:

"WebBrowser.MainPage"

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

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

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

    xmlns:mc="http://schemas.openxmlformats.org/

        markup-compatibility/2006"

    xmlns:controls="clr-namespace:System.Windows.Controls;

        assembly=System.Windows"

mc:Ignorable="d"

d:DesignHeight="300" d:DesignWidth="400">

"LayoutRoot" Background="White">

"http://www.bing.com"/>

3. The result we obtain is shown in the following screenshot:

Limitations to take into account:

Control is placed on top of the ZOrder. In case we want to show a ChildWindow, for example, this will not be visible at first. To give it visibility, we need to create a rectangle using a WebBrowser Brush, make a static picture to the WebBrowser Control content and, when the dialog box is shown, hide the WebBrowser showing our rectangle.
For safety reasons, we cannot capture the moment when the user navigates from one page to another; neither can we make JavaScript calls from Silverlight if the page belongs to a different domain.
It is a heavy control, so it is not a good idea to create and destroy it dynamically quite often.

Real windows

Another advantage of trusted OOB applications is the fact that they can show physical windows.

At the moment, these windows are not modal in Silverlight 5. The following is how it works:

1. Create a Windows object and assign the content property of this control to
a given UserControl.

2. Then, we see how this sort of window can be displayed:

private void button1_Click(object sender, RoutedEventArgs e)

{

    Window wnd = new Window();

    wnd.Width = 500;

    wnd.Height = 350;

    wnd.Title = "This is a test window";

    //We indicate here a custom user control to display in the

    //new window

    wnd.Content = new MyControl();

    wnd.Visibility = Visibility.Visible;

}

3. The result is shown in the following screenshot:

In-browser trusted applications

Having trusted applications, which are executed as if they were desktop applications, is a powerful and interesting idea, but what happens if we need to have elevated permissions for applications running in the browser? For instance, a bank's intranet.

Silverlight 5 incorporates in-browser trusted applications, whose main features are as follows:

It is a specific functionality for enterprise applications.
The administrator controls which applications can be executed via
group policy.
The user is not asked and neither is the application installed. It is marked
as valid, so it will be executed by the administrator.
It can be integrated as part of an HTML website, without the need to give elevated permissions to the entire site.

On the other hand, the doubt arises, when developing, shall we create our own test certificate? The answer is no. If we execute from localhost, the restriction is not applied.

Thus, in the example that was previously implemented (getting the content of C:\Program Files), we only need to select the properties of our Silverlight project (right-click on Silverlight | Properties) and select the option Require elevated trust when running in-browser, as shown in the following screenshot:

When executing the application, it can be seen running flawlessly within the browser.

As we pointed out earlier, if the application in production is displayed, it will fail as it is not executed from localhost. The following are the necessary steps to avoid it:

The XAP file has to be signed with a certificate (this can be seen in depth in Chapter 11, Security).
The network administrator has to specify a setting for the trusted in-browser applications to be executed in all machines. Particularly, the flag of the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Silverlight\AllowElevatedTrustAppsInBrowser must have the value of 1.
The network administrator has to add the certificate in which the XAP has been signed with as a trusted certificate (CurrentUser\Trusted Publishers).

For more information about the display process, please visit the link http://bit.ly/kKbdpl.

In order to know if the application is running with elevated permissions, check the flag Application.Current.HasElevatedPermissions.

LOB application case study: applying what we have learned

As final users, one of the disadvantages of using web applications is the fact that we have to remember URLs, open the browser, and so on. Isn't it easier to double-click on a desktop icon and run an application? That is what has been added to our booking application:

We detect whether it is running or not within the browser
If so, an option is shown to install the application as OOB
Then, we install the application as OOB

Thus, when executing the application within the browser, a new option is added in the navigation menu, as shown in the following screenshot:

When clicking the Install button, the confirmation dialog appears and the application gets installed (then, go to the desktop icon and execute it).

It is necessary to bear in mind that the application item has been customized. This can be set up in the project properties, Out-of-Browser Settings.

Summary

The capabilities offered by Out of Browser (OOB) applications are amazing. If we also add the possibility of elevating permission (in-browser and OOB trusted), the result is a light web application that can be almost as powerful and functional as a desktop application. Remember this chapter when a client indicates non-standard requirements of a web application (such as the integration of the application in an ATM, accessing the local filesystem, and so on). Anyway, before accepting, make the possible concept tests and ensure the functionality is covered.

Additional resources

If you need to dive deeper into any of the features presented in this chapter, you can check the following links:

How far can I get using COM+? This post by Justin Angels summarizes it nicely at http://bit.ly/4Ama4H
In-browser http://bit.ly/kKbdpl and settings http://bit.ly/oKFbzG
P/Invoke, how does it work? http://bit.ly/r2DTQF
P/Invoke and Silverlight, an excellent introduction by Vikram Pendse http://bit.ly/qI3XhN
How to create physical windows, by Pete Brown http://bit.ly/gZ4w7S

Part 4: Developing for a multitude of clients: strategies for code reuse and keeping costs in check.

editorial@silverlightshow.net (Kevin Dockx ) — Tue, 20 Mar 2012 06:50:00 GMT

Welcome to the fourth part of this article series on strategies for designing your application for a multitude of different clients. In the first part, we’ve looked into the business case & some general concerns, and in the second part, we made a choice for a service layer: WCF RIA Services. In the third part, we’ve seen how we can use MEF for on demand loading & code reuse across different clients.

More resources...

All SilverlightShow Ebooks

However, I left out a few things in that article: loading the Views on demand (as it requires extensions to the Silverlight Navigation framework to navigate to Views in an assembly that’s loaded on demand), and loading multiple assemblies on demand (as we need an async component loader for that, to ensure we can load these assemblies at the same time instead of one by one). This article will deal with these two concerns.

You can download the source code for this article here (you can log in to the demo application with pete.campbell@madmen.com / abc@123).

Deciding what to load on demand

First of all, we need to decide what exactly we want to load on demand, and what we’ll keep as a regular reference. As you can see in the following screenshot, the main project requires quite a few assemblies:

What will we load on demand, and what will we keep as reference? You could load almost anything on demand, if you're really set on diminishing the initial load of your application (the size of the XAP), however: I like to keep things a bit more realistic. Take, for example, an assembly like System.Windows.Interactivity. This one contains the classes used to enable commands on any event, like a command on the SelectionChanged event of a ListBox (as you can see throughout the application) - does it make sense to load this on demand?

Well, it depends. Some might say it does: after all, theoretically you could have a part of an application that never uses any of the classes from that assembly. And it does keep down the initial load. As an added bonus, it even allows your assembly to be cached automatically by the browser (have a look at the caching overview article for more information on this).

On the other hand: this might qualify as overkill. Does it really make sense to separate out an assembly that will be used by almost any module, like System.Windows.Interactivity? Or an assembly that will be used by each ViewModel, like the MVVM Light assemblies? I would argue it doesn't - a matter of "it's not because we can do this, that we should."

As a rule of thumb, I like to separate out the assemblies (/classes) that belong to specific modules and aren't used throughout the application. A model, used only by the Employee Opportunity module, would be something that's preferably loaded on demand. The authentication model, used regardless of who's using the application? Not so much. A self-created assembly containing commonly used code, or an existing assembly that contains classes used throughout the application (like System.Windows.Interactivity, or in our case: the MVVM Light-related assemblies), are typically assemblies I'd keep as a reference instead of loading on demand.

With this in mind, we can get going. And we'll immediately bump into 2 issues…

Loading a multitude of assemblies at startup.

The first issue: we now have to load a multitude of assemblies when the application starts, and it's only after all these assemblies have been loaded that we can continue with our application execution (in this case: set the RootVisual to an instance of MainPage). The simplest way to solve this is to call the loading of the next assembly in the completed handler of the previous async call, and continue doing this until all the necessary assemblies have been loaded… While this could be a valid approach with 2 or 3 assemblies, the code becomes very cluttered when we need to load more assemblies. Besides that, assemblies will be loaded one by one instead of in parallel - which is a shame, as the last option would result in faster application startup.

What we need is a way to execute multiple asynchronous calls, in parallel, and start another action after all these calls have completed.

Luckily, this can be done with a bit of custom coding. We'll create a helper class, ParallelAsyncProcessor, in Framework.Silverlight. An instance of this class is initialzed, after which we’ll add the actions to be executed by calling the AddToParallelQueue method. To start executing them, we’ll call the StartParallelProcessing method, which will start executing them in parallel (as they're async calls). When an action completes, the action should be taken from the list of actions, and when all actions have been completed, another action, AllProcessesCompleted, will be executed. This is typically where we’ll continue with the execution of the application.

The following code illustrates the helper class:

public class ParallelAsyncProcesser
{
    public Action AllProcessesCompleted;
    public Dictionary<object, Action> Processes;
    private int _numberOfActions = 0;
    public ParallelAsyncProcesser()
    {
        Processes = new Dictionary<object, Action>();
        _numberOfActions = 0;
    }
    public void StartParallelProcessing()
    {
        foreach (var action in Processes.Values)
        {
            action.Invoke();
        }
    }
    /// 
    /// Add an action to the parallel queue
    /// 
    /// The action to invoke
    /// An optional identifier.  Add this if you want to ensure 
    /// the correct action is removed from the queue.  
    /// If not, the processer acts as a counter.
    public void AddToParallelQueue(Action action, object identifier = null)
    {
        _numberOfActions++;
        if (identifier == null)
        {
            Processes.Add(_numberOfActions, action);
        }
        else
        {
            Processes.Add(identifier, action);
        }
    }
    /// 
    /// Typically executed in the completed method of an async call
    /// 
    /// When this is passed in, the correct action will be removed 
    /// from the internal dictionary.  
    /// If not, any action will be removed.
    public void ProcessComplete(object identifier = null)
    {
        _numberOfActions--;
        if (identifier == null)
        {
            // remove any
            Processes.Remove(Processes.Count);
        }
        else
        {
            Processes.Remove(identifier);
        }
        // invoke action on all processes complete
        if (_numberOfActions == 0 && AllProcessesCompleted != null)
        {
            AllProcessesCompleted.Invoke();
        }
    }
}

To use this, we need to change our Application_Startup method a bit. We need a list of assemblies that have to be loaded (this list can vary depending on custom application logic, like the users' rights - if that's the case, these assemblies will of course have to be loaded after the user logs in instead of in the Application_Startup method). We run through this list, and add the DownloadAsync method to the list of actions that have to be executed. We also ensure actions are removed from the list by calling ProcessComplete in the completed handler.

Once the last action has been fully completed, the AllProcessesCompleted method will be executed. The method is executed automatically, and is used to set the RootVisual to a new instance of MainPage. The code for this looks as such:

// create a list of external dependencies
List<string> lstDependencies = new List<string>()
{
    "SalesDashboard.Client.Model.dll",
    "SalesDashboard.SL.Modules.EmpOpp.ViewModels.dll",
    "SalesDashboard.SL.Modules.EmpOpp.Views.dll"
};
// instantiate a new aggregate catalag
var catalog = new AggregateCatalog();
// instantiate a new parallel async processer
ParallelAsyncProcesser parallelAsyncProcesser = new ParallelAsyncProcesser();
foreach (var dependency in lstDependencies)
{
    // note:  pass in another variable instead of directly passing in the dependency string.
    // This ensures this new value is used when executing the parallel processes instead 
    // of using the last passed-in string multiple times 
    var foo = dependency;
    var catalogDep = new SuperDeploymentCatalog(foo);
    catalog.Catalogs.Add(catalogDep);
    EventHandler handler = null;
    handler = (s, a) =>
        {
            parallelAsyncProcesser.ProcessComplete(foo);
            catalogDep.DownloadCompleted -= handler;
        };
     catalogDep.DownloadCompleted += handler;
    parallelAsyncProcesser.AddToParallelQueue(() => catalogDep.DownloadAsync(), foo);
}
parallelAsyncProcesser.AllProcessesCompleted += () =>
    {
        // dependencies have been loaded, init app startpage
        this.RootVisual = new MainPage();
    };
// start fetching the dependencies, parallel instead of one by one
parallelAsyncProcesser.StartParallelProcessing();

And like that, we can now load assemblies on demand, in parallel.

Navigating to a View residing in an assembly that's been loaded on demand.

The second issue we run into actually consists of 2 related issues.

First, some background information: we're using a View-first approach. This means View is initialized, and it is provided with a DataContext - the ViewModel - by another component (MEF, in this case - the View isn't responsible for initializing the ViewModel). To ensure the View is initialized, we simply place it on MainPage (for the header) or set it as source for the frame on the MainPage. I'll get into the second part immediately, as this has to do with another challenge, but solving the first problem might not be obvious either: after all, how are you going to place a View on a page if you haven't got a reference to the assembly containing the View? Obviously, your code simply won't compile.

Well, let's think back at why exactly we're loading assemblies on demand: it enables shorter initial loading times, makes it easier to roll out changes (you don't have to recompile your complete XAP), but in our case, the most important reason was: allowing reuse of code (the modules) & composability. So how can we reach our goal? It's actually pretty easy: we're going to add a reference to the assembly containing the Views, so we can add an instance of one to the MainPage, AND we're still going to load that assembly on demand. The trick is the "Copy local" value in your reference properties. If you put this on false, this assembly will not be packaged in the XAP (thus keeping your XAP smaller), and thus has to be loaded on demand.

Note that we use the “Copy Local = false” technique extensively, especially in the assemblies we load on demand – in fact, if you look at the project containing the Views we’ll load on-demand, you’ll notice that all the references are set to “Copy local = false”, as they all are either references in the main project, or loaded on-demand.

If we now build and run our application and look into the XAP, we'll notice it no longer contains the View assembly: this is now loaded when the application is launched. After that, MainPage is initialized, and the Header will be shown.

But we immediately run into another challenge, the second of our 2 view-related issues: we get an error on our Frame: apparently, it's not possible to navigate to a View in another assembly when that assembly is loaded on demand. Can we solve this?

Introducing: a custom Content Loader & View Factory

In Silverlight 4, a new interface was introduced: INavigationContentLoader. Going into the details of this would lead us too far for this article, but if you want, you can read about it on MSDN or in one of my previous articles on Authorized Navigation (where a custom implementation of this interface is used). By writing our own implementation of this, we can decide how exactly our Views should be loaded. A few implementations and techniques using this interface already exist: David Poll described one on his blog, and Pencho Popadiyn wrote an article about it on Silverlight Show. However, we’re not using MEF to export our Views: we’re already using MEF to set the DataContext of our Views to an instance of a certain ViewModel, which therefore makes it quite a hassle to export the Views as well – they’re already dependent on importing a ViewModel from another plugged-in assembly. So we’ll need another technique.

What we need is “something”, a component, to provide us with an instance of the View we need. We need a component that “knows” about these views, so it can instantiate them with a bit of reflection, and can return them to the custom NavigationContentLoader. So, in essence: we need a ViewFactory, which should reside in our View assembly, and which we can import using MEF in our NavigationContentLoader. This ViewFactory instance is then used by the NavigationContentLoader to provide us with the View instance we need.

Let’s start with the ViewFactory:

namespace Framework.Silverlight
{
    [Export(typeof(IViewFactory))]
    public class ViewFactory : IViewFactory
    {
        public Page GetViewInstance(string className)
        {
            try
            {
                var instance = Activator.CreateInstance(Type.GetType(className));
                return instance as Page;
            }
            catch (Exception ex)
            {
                return null;
            }
        }
    }
}

As you can see, this is pretty straightforward. It expects a class name, and will return an instance of that class (a View), using some reflection, to whichever component we’re calling the ViewFactory from.

On to the custom content loader. First, we import all instances of ViewFactory. As we need to ensure our application can work with different assemblies containing Views, we need to use ImportMany.

[ImportMany(typeof(IViewFactory))]
public List ViewFactories { get; set; }

In BeginLoad, we try to get an instance of a View back from one of the imported ViewFactory instances (note that this code is used to illustrate a technique – for production-ready code, you’ll probably want to refine the way we fetch the class name some more).

public IAsyncResult BeginLoad(Uri targetUri, Uri currentUri,
    AsyncCallback userCallback, object asyncState)
{
    NavigationAsyncResult ar = new NavigationAsyncResult(userCallback, asyncState);
    string fullUri = targetUri.ToString();
    string className = (fullUri.Substring(1, fullUri.IndexOf(';') - 1) + "." + 
    fullUri.Substring(fullUri.LastIndexOf("/") + 1, fullUri.IndexOf(".xaml") 
    - fullUri.LastIndexOf("/") - 1));
    // use one of the the ViewFactories to load
    foreach (var factory in ViewFactories)
    {
        Page page = factory.GetViewInstance(className);
        if (page != null)
        {
            ar.Result = page;
            ar.CompleteCall(false);
            return ar;
        }
    }
    // in case nothing is found...
    throw new ArgumentException("No view found in any imported assembly with classname " + className);
    return null;
}

In EndLoad, we ensure our custom loader logic is used instead of the default loader:

public LoadResult EndLoad(IAsyncResult asyncResult)
{
    if (asyncResult is NavigationAsyncResult)
        return new LoadResult((asyncResult as NavigationAsyncResult).Result);
    else
        return _loader.EndLoad(asyncResult);
}

And that’s it! Our custom content loader is ready. All that’s left now is making sure it’s used, which we can do by adjusting our XAML code a little bit, as such:

<sdk:Frame x:Name="mainFrame"
           Background="Transparent"
           JournalOwnership="Automatic"
           BorderThickness="0"
           Margin="50,0,50,0"
           Source="/LoginView">
    <sdk:Frame.ContentLoader>
        <fw:CustomXAPContentLoader>fw:CustomXAPContentLoader>
    sdk:Frame.ContentLoader>
    <navigation:Frame.UriMapper>
        <sdk:UriMapper>
            <sdk:UriMapping Uri="/{page}"
                            MappedUri="/SalesDashboard.SL.Modules.EmpOpp.Views;component/{page}.xaml" />
        sdk:UriMapper>
    navigation:Frame.UriMapper>
sdk:Frame>

We’ve now created a way to ensure our View assembly can be loaded on demand, and we can still navigate to these Views even though they reside in a different assembly, by extending the Navigation framework.

Conclusion

In this article, we've seen some best practices on how you can separate your app into different modules so this code can be reused. We've tackled a few issues, or rather: challenges that come with these techniques, by creating a custom loader queue, and extending the Silverlight Navigation framework in such a way that it allows navigating to View in assemblies that are loaded on demand. We've now got a truly composable application that can consist of various modules, each easily reusable by other client applications.

In the next part, we'll add another client to the equation and see how exactly we can reuse all the separated-out components from the last few articles: an Out of Browser Silverlight client.

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, HTML5). 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 Techdays in Belgium, Portugal & Finland, NDC2011, Community Day, ... 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 you can contact him on Twitter via @KevinDockx.

Silverlight and Sharepoint working together: event receivers in Silverlight

editorial@silverlightshow.net (Walter Ferrari ) — Tue, 13 Mar 2012 16:17:00 GMT

In the previous articles of this series (see the panel From this series on the right) we dealt with some introductory aspects such as how to integrate Silverlight into Sharepoint, then we built a Silverlight menu capable of interacting with a Sharepoint site as an example. Throughout this journey we have introduced some basic concepts of Sharepoint useful for Silverlight developers.

Don't miss...

($0.99)

All SilverlightShow Ebooks

Now it's time to dig into it at full throttle facing more advanced concepts. In this article we will become familiar with the Sharepoint event receivers, a cool feature which allows the user to be notified about various events occurring inside a Sharepoint environment. An example is the possibility to receive the notification of an item added to a list. Unfortunately, the mechanism works at server side and that means that there is no “out of the box” possibility to use the feature directly in a Silverlight application.

Nevertheless, we will find a way to make the event receivers available in a Silverlight web part in order to give a new dimension of interactivity to a Sharepoint solution.

As an example we will create a small application to invite our colleagues to a coffee break and get a close to real time answer. This will involve the creation of a wcf service with a service contract for a Sharepoint solution and a service contract for a Silverlight web part. Both contracts are duplex service contracts. Now you may be like “all this mess for a silly application to get someone together for a coffee break?” In fact, it may sound useless but it is not. Event receivers are a great feature of Sharepoint and exporting them into a Silverlight web part opens a very interesting perspective.

The “Coffee break” application

Let’s suppose we want to create a small application running in a Sharepoint site (a kind of widget) to quickly organize a coffee break with colleagues. We want to be able to select a time and send an invitation to our user’s group. The other users should be notified quite immediately and they should be able to accept or turn down the invitation. Eventually we should be notified about all the confirmations received from our colleagues. All this without the need to refresh any page.

The images below sum it all up:

A video showing the application in action is available here.

The source code of the application is available here.

The big picture

In the introduction I gave some clues. I mentioned Sharepoint event receivers, a wcf service with duplex service contracts, a Sharepoint solution and a Silverlight web part. Let me put together the pieces of the mosaic starting with the event receivers. (As usual Sharepoint developers can skip this part)

Event receivers are a convenient way to get notifications about Sharepoint events. The trappable events most used are synthesized in the tables below:

The nice thing is that you can create these event receivers from Visual Studio 2010 selecting the “Event receiver” template for a “new project” or for a “new item” of an existing project.

The template lets you choose the type of event you want to trap and then creates the skeleton code for you.

Once clarified what the event receivers are, let’s move on and suppose you want to trap the events related to the built-in Sharepoint Calendar list. In fact, this list seems the ideal candidate where to store the “coffee break appointments”. So the idea is that when someone (user A) proposes a coffee break, he/she inserts a new item in this list. Then, “an item was added” event is fired and caught by the event receiver that we previously created in a web part. From here the web part should be able to redirect the notification to a Silverlight application.

Obviously the Silverlight application must be hosted in a Silverlight web part in order to be available in a Sharepoint page.

When the Silverlight app received the notification it should be able to display the information to the user B and allow him to express a positive feedback. If a positive feedback is given, the item in the Calendar list is updated causing the firing of a “an item was updated” event. Another event receiver pointed on this event should redirect the feedback to the client Silverlight app of user A.

So the key point is: who is in charge of transferring the signalling of events from the server code in the web part to the client code in the Silverlight application?

The answer is : a wcf Service that serves as a bridge.

Hopefully the following images will help to clarify this.

Figure 1: How the “new coffee break event” is passed from the Silverlight of the user A to the Silverlight app of the user B

Figure 2: How the “coffee break event confirmation” is passed from the Silverlight app of the user B to the Silverlight app of the user A

Note that the built-in Calendar list does not contain any field specifically dedicated to storing the participants of an event or their confirmations. So for this purpose I used the “Description” field of the Calendar. Basically, when user B in figure 2 confirms his will to take a coffee break with user A, he updates the “coffee break” item in the Calendar list by adding his confirmation in the Description field.

A wcf service as a bridge

In the previous paragraph we learned that the idea (behind the possibility to extend the event receivers to a client application) is to use an “ad hoch” wcf service. Furthermore, this wcf service should be able to manage a one-to-many relation when a new item in the Calendar is created and when an item is updated. The image below shows both cases:

Figure 3: the wcf service manages a one-to-many relation

In this way all the users of a group will receive a notification about a new coffee break proposal and a notification about the confirmations of one or more of them.

Previously we have also stated that all these notifications should appear without the need to refresh the Sharepoint page containing the Silverlight application. This means that the Silverlight application should implement some kind of polling to the wcf service or better, the wcf service should be able to “push” the data into the Silverlight application. You as Silverlight developers surely know that there are several ways to accomplish this. For the “coffee break” application I used HTTP Polling Duplex following the details explained in this excellent article. Without going too much in detail (for further explanations you can download and look at the source code linked to this article), I added the following interfaces to the service: the first defines the methods that the client can call on the service:

[ServiceContract(Namespace = "Silverlight", CallbackContract = typeof(ISPDataServiceCallback))]
    public interface ISPDataService
    {
        [OperationContract(IsOneWay = true)]
        void DataFromClient(SPData value);

        [OperationContract(IsOneWay = true)]
        void DataFromSP(SPData value);
    }

As for the DataFromSP(SPData value) method we will come back on this in a while. Instead, the DataFromClient(SPData value) method is called by the Silverlight client application at the first start to be registered on the service. As you may remember, this is due to the fact that the service must ensure a relation “one to many” with the running clients. For this reason the service must keep track of each client available.

The registration is made by the client as follows:

// registration to the server
     SPData regData = new SPData();
     regData.Event = events.client_reg;
     regData.User = currentUser;
     _Proxy.DataFromClientAsync(regData);
}
…
void _Proxy_ReceiveSPDataReceived(object sender, ReceiveSPDataReceivedEventArgs e)
        {
            if (e.spData.Event == events.client_reg)
            {
                LogtxtBlock.Text = "Connection estabilished.";
                AddBreakBtn.IsEnabled = true;
            }

At the service level the DataFromClient(SPData value) method is implemented as follows:

public void DataFromClient(SPData value)
{
    //Get client callback channel
    var context = OperationContext.Current;
    var sessionID = context.SessionId;
    var currClient = context.GetCallbackChannel();
    context.Channel.Faulted += Disconnect;
    context.Channel.Closed += Disconnect;

    ISPDataServiceCallback client;
    if (!_ClientCallbacks.TryGetValue(sessionID, out client))
    {
        lock (_Key)
        {
            _ClientCallbacks[sessionID] = currClient;
        }
    }

    // Get SPData
    if (value.Event == events.client_reg)
    {
        value.ItemValue = "acknowledgment";
        currClient.ReceiveSPData(value);
    }
   
}

For each new client a specific channel is reserved for future communications. Only in the event of a new registration an “acknowledgment” is sent back to the client as feedback that the communication channel has been established.

If you were careful you may have noticed that in the snippet of the code above there was a reference to a ISPDataServiceCallback interface. This interface defines the callback methods that the service can use to communicate with a client:

[ServiceContract]
public interface ISPDataServiceCallback
{
    [OperationContract(IsOneWay = true)]
    void ReceiveSPData(SPData spData);

    [OperationContract(IsOneWay = true, AsyncPattern = true)]
    IAsyncResult BeginReceiveSPData(SPData spData, AsyncCallback callback, object state);
    void EndReceiveSPData(IAsyncResult result);

    [OperationContract(IsOneWay = true)]
    void DataFromSPCallback(string message);
}

Here you may notice the definition of the ReceiveSPData(SPData spData) method used above to communicate to the client that the communication channel is ready.

Let's take a breath now and think: ok, we have seen how the client Silverlight app and the service can communicate but… one more piece is missing. In what way does the event receiver communicate with the service and instruct it to redirect the information gathered to the client?

You can add another service endpoint and a new binding to the wcf service. Using the Microsoft Configuration Editor” in the “coffee break” application I added a new endpoint called “wsdual” and a binding of type “wsDualHttpBinding”. So I was able to use the same contract type used by the Silverlight application.

The DataFromSP(SPData value) method included in the first interface (ISPDataService) that I put in a corner some paragraphs above is just the method used in the event receivers to transfer the notification about new/updated items in the Calendar list into the service.

The snippet below shows the method used by the event receivers:

public void SendSPDataToClient(events eventType, SPItemEventProperties properties, string userColumn)
{
    InitConnectionToWCF();

    DateTime eventDate = (DateTime)properties.ListItem["EventDate"];

    SPData spdata = new SPData();
    spdata.Event = eventType;
    spdata.ItemValue = eventDate.ToShortTimeString();
    spdata.listName = properties.List.Title;
    spdata.ItemID = properties.ListItemId.ToString();

    SPFieldLookupValue userValues = new SPFieldLookupValue(Convert.ToString(properties.ListItem[userColumn]));

    spdata.User = userValues.LookupValue;
    spdataService.DataFromSP(spdata);

}

Once the service receives the notification, it sends the information directly to the clients as follows:

public void DataFromSP(SPData spData)
{
     SendSPDataToClient(spData);
}

public void SendSPDataToClient(SPData spData)
{
      var cbs = _ClientCallbacks.Where(cb => ((IContextChannel)cb.Value).State == CommunicationState.Opened);
      for (int i = 0; i < cbs.Count(); i++)
      {
           var cb = cbs.ElementAt(i).Value;
           try
           {
                cb.BeginReceiveSPData(spData, _ReceiveSPDataCompleted, cb);
           }
           catch (TimeoutException texp)
           {
                //Log timeout error                 
           }
           catch (CommunicationException cexp)
           {
                //Log communication error                 
           }
      }
                        
}

Insert/update items in the Sharepoint Calendar List from Silverlight

If you have read my previous articles on this topic you should be familiar with the use of the Silverlight client object model. In the “coffee break” application the insert/update is carried out in a secondary thread in order to be able to use the synchronous ExecuteQuery() method instead of the conventional ExecuteQueryAsync(). There is no particular reason behind that, it is just another way. Here below the snippet of code that creates a new item:

public void InsertEventThreadFunc(object objData)
{
    ThreadData mthData = (ThreadData)objData;

    List list = mthData.ThClientContext.Web.Lists.GetByTitle(mthData.ThSPData.listName);
    ListItemCreationInformation itemCreateInfo = new ListItemCreationInformation();

    ListItem newEvent = list.AddItem(itemCreateInfo);
    newEvent["Title"] = "Coffee break for " + mthData.ThSPData.User;
    newEvent["EventDate"] = (DateTime)mthData.ThSPData.ItemValue;
    newEvent["EndDate"] = (DateTime)mthData.ThSPData.ItemValue;
    newEvent.Update();

    mthData.ThClientContext.Load(list, i => i.Title);
    
    mthData.ThClientContext.ExecuteQuery(); 
}

And below the snippet that updates the item:

public void UpdateEventThreadFunc(object objData)
{
    ThreadData mthData = (ThreadData)objData;

    List list = mthData.ThClientContext.Web.Lists.GetByTitle(mthData.ThSPData.listName);

    CamlQuery camlQuery = new CamlQuery();
    
    camlQuery.ViewXml =
        @"
        
          
            
              
              " + mthData.ThSPData.ItemID + @"
            
          
        
      ";
    
    
    ListItemCollection listItems = list.GetItems(camlQuery);
                
    mthData.ThClientContext.Load(listItems,
         items => items.Include(item => item["Description"]));
    
    mthData.ThClientContext.ExecuteQuery();

    if (listItems[0] != null)
    {
        listItems[0]["Description"] = listItems[0]["Description"] + " " + mthData.CurrentUser.Substring(mthData.CurrentUser.LastIndexOf(@"\") + 1) + " will join the coffee break!";
        listItems[0].Update();
        mthData.ThClientContext.ExecuteQuery();
    }

}

Summary

In this article we have introduced another interesting feature of Sharepoint: the event receivers. Although this feature seems to be reserved to server side applications like classic Sharepoint web parts, we have explored a way to make it available for a Silverlight application embedded in a Sharepoint web part. The simple application that we have created, i.e. a widget to quickly organize a coffee break with colleagues, is able to transfer to the client code the notification of an item added/updated to the built-in Calendar list. To do that it uses an external wcf service that exposes a HTTP Polling Duplex binding to communicate with the Silverlight part and a WSDualHttp binding to communicate with the server code of the event receiver. This example opens interesting perspectives of interaction between Silverlight and Sharepoint. In one of the next articles we will try to apply this strategy to another big chapter of the Sharepoint world: the workflows. But now, I definitely need a coffee break.

Part 3: Developing for a multitude of clients: strategies for code reuse and keeping costs in check.

editorial@silverlightshow.net (Kevin Dockx ) — Fri, 24 Feb 2012 20:23:00 GMT

Introduction

Welcome to the third part of this article series on strategies for designing your application for a multitude of different clients. In the first part of this series, we've had a look at the business case & some general concerns we'll have to tackle.

In the second part, we made a choice for a service layer: WCF RIA Services, looked into what this choice offered us and why we made it, and looked into some general guidelines you should keep in mind when designing a service layer which will be used by a multitude of clients.

In this part, we'll start with the development of the first client: a web-based Silverlight client.

You can download the source code for this article here (you can log in to the demo application with pete.campbell@madmen.com / abc@123).

Quick 'n dirty?

As stated, the first client we're going to build will be a Silverlight client.

More resources...

All SilverlightShow Ebooks

The easy, quick 'n dirty way would be to simply add a Silverlight application to our solution, add our Views, ViewModels and application app logic to it, and let it communicate with the EmployeeOpportunityService we've created in the second part.

However, as we know we'll have to build multiple clients, that's probably not the best option: reuse of code would be fairly limited, in fact: we would only be able to reuse the service layer (and accompanying client-side model, generated through WCF RIA Services). There's got to be a way to improve on this, right?

The answer lies in modularity. As you might remember from the first parts of this article series, we're only creating one module for demo purposes: the Employee Opportunity module. The main Silverlight client could, before going into production, import multiple modules: a Management Module, a Reporting Module, .... It makes sense to logically separate these out: some clients might offer all modules, some of the modules, … . Separating this out offers an advantage: code reuse. Each module could be reused by a variety of clients (for example: our Silverlight Out of Browser client can reuse the same assemblies).

Add reference…

The first approach is quite similar to what any .NET developer is used to. Instead of adding the Views and ViewModels in our WebClient project, we create a new Silverlight class library. In this class library, we add the Views and ViewModels that logically belong to the Employee Opportunity Module. For other modules, we do the same.

In our WebClient project, we now add a reference to the class librar(y)(ies) of the modules that can be used by this specific client, and we add references to any assemblies that might be used by any of these modules.

Build, run, and we're set.

Or are we?

A better approach.

While the previous approach might be valid (we've got our reusability), it does offer a disadvantage: your final XAP contains all the code from the assemblies from the different modules, in other words: it can get quite big, resulting in slower load times and higher bandwidth consumption. Moreover, in quite a few applications the modules the user can access depends on his rights: why would we want to get an XAP, containing all modules, to a client who only has access to one module?

And what's more: as this is an article series on code reuse, something's not quite right with our modules either: we've still got no way to reuse Views without importing a specific ViewModel implementation, or the other way around: the module contains both. As we're building different clients, it's not unimaginable we'll want to reuse the code in a specific ViewModel, but use it as DataContext to a different View. Or we could have a client which want to reuse a specific View, but has no need for the ViewModel, as it provides its own, client-specific implementation.

So, what we want to do is keep our Views in one assembly, and keep our ViewModels in a different assembly. When we start our Silverlight client, the Employee Opportunity module will be composed by importing what's needed.

What we really need here is composability & on-demand loading: say hello to MEF.

The Managed Extensibility Framework - a short introduction.

MEF, or the Managed Extensibility Framework, was designed to simplify the design of extensible applications and components. Applications can have changing requirements, or need to be able to plug in extra pieces of logic. After some amount of time, it can become difficult to add new functionality easily to your application. MEF solves this problem by making it easy to “plug in” new functionality into your application. In our example, we can use this to "plug in" the modules when needed.

First of all, there's the concept of Composition: you start by telling MEF where it can find the parts of the application it needs to provide by creating a catalog. From this catalog, you then create a CompositionContainer.
Next, there's the Export concept: by using the Export attribute on a component, you tell MEF you want to export this component (type, property), so it can be composed via the container.
Lastly, there's the Import (or ImportMany) concept, which tells MEF what type of components should be imported in a specific part of your application.

These 3 simple concepts are the basics of MEF, and should give a basic understanding of what MEF is and what it does. A lot more information can be found at http://mef.codeplex.com/

Note: in quite a few projects, MEF is used as a replacement for an Inversion of Control container, like Castle or Ninject. In my opinion, this is defendable (depending on your project requirements, of course), but in essence MEF is designed managing unknown dependencies (hence: plugability), while a classic IoC container is used for managing known dependencies.

Some refactoring & custom code

The first thing to do is separate out our Views from our ViewModels: they both need to be in separate assemblies. This results in the following project division:

For now, we'll keep the View assembly as a reference to our WebClient project, and we'll load the ViewModel assembly on-demand when the application starts (more on why I'm making this choice can be found at the end of the article).

… and we've bumped into a problem. In Silverlight, you can load XAP-files on demand with MEF, but you can't load assemblies on demand. Out of the box, there's no way to compose our application with external assemblies - which is what we'd like.

Luckily, Chris Pietschman (http://pietschsoft.com/) made this possible through his SuperDeploymentCatalog implementation. This is actually for about 95% the same code as a regular DeploymentCatalog, but he changed the HandleOpenReadCompleted method so it allows DLL importing. The complete code can be found in the accompanying source code, in Framework.Silverlight, but this is the part that matters:

private void HandleOpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
{
    Exception error = e.Error;
    bool cancelled = e.Cancelled;
    if (Interlocked.CompareExchange(ref this._state, 0xbb8, 0x7d0) != 0x7d0)
    {
        cancelled = true;
    }
    if ((error == null) && !cancelled)
    {
        try
        {
            // Check if a XAP or DLL was downloaded, based on file extension
            if (this._uri.OriginalString.ToLower().EndsWith(".xap"))
            {
                // Load Assemblies from XAP
                IEnumerable assemblies = Package.LoadPackagedAssemblies(e.Result);
                this.DiscoverParts(assemblies);
            }
            else 
            {
                // Load DLL Assembly
                var assemblies = new List();
                assemblies.Add((new AssemblyPart()).Load(e.Result));
                this.DiscoverParts(assemblies);
            }
        }
        catch (Exception exception2)
        {
            error = new InvalidOperationException("Strings.InvalidOperationException_ErrorReadingXap", exception2);
        }
    }
    this.OnDownloadCompleted(new AsyncCompletedEventArgs(error, cancelled, this));
}

In the Application_Startup method, we'll load our ViewModel assembly. First, we create a new AggregateCatalog instance. To this type of catalog, other catalogs can be added dynamically (this will also come in useful later on in this article series). Next, we create a new SuperDeploymentCatalog, pointing to the ViewModel assembly. This catalog is added to the Catalogs collection of the AggregateCatalog instance.

We add an event handler to the DownloadCompleted event of our SuperDeploymentCatalog instance. When this event is correctly completed, we set the RootVisual to a new instance of our applications' MainPage. Note that this shouldn't be done earlier, as MainPage contains a View which in turn imports a ViewModel instance: that ViewModel instance is only available after the ViewModel assembly has been loaded.

Next, we'll call the DownloadAsync() method, and we initialize MEF's CompositionHost by passing in our AggregateCatalog instance.

private void Application_Startup(object sender, StartupEventArgs e)
{
    this.Resources.Add("WebContext", WebContext.Current);
    WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
    WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);
    var catalog = new AggregateCatalog();
    var catalogVM = new SuperDeploymentCatalog("SalesDashboard.SL.Modules.EmpOpp.ViewModels.dll");
    catalog.Catalogs.Add(catalogVM);
    catalogVM.DownloadCompleted += (senderVM, argsVM) =>
    {
        if (argsVM.Error != null)
        {
            MessageBox.Show(argsVM.Error.Message);
        }
        else
        {
           this.RootVisual = new MainPage();
        }
    };
    catalogVM.DownloadAsync();
    CompositionHost.Initialize(catalog);
    CompositionInitializer.SatisfyImports(this);
}

We can now build and run our application. The application is composed on-demand: the ViewModels are not included as a reference, they are loaded when needed. This results in a smaller XAP (faster loading times), composability, and an assembly that can easily be reused. We've now got a technique for code reuse across clients: instead of having to rewrite your ViewModel code, you can simply reuse the existing code.

Note: as we're loading assemblies on-demand, you might want to ensure the correct version is loaded. By default, when you build a project in debug-mode, the resulting assembly is put in the projects' bin/debug-folder (wherefrom it can't be loaded on demand by the Silverlight application, as you won't have rights to access that folder). An easy way to ensure the resulting assembly is always available is by changing its output path to the ClientBin folder of the WebClient.

Conclusion

We've seen a few different techniques to separate out parts of our application: referencing & loading on demand through MEF. This allows us to reuse code across different clients.

Then again, we're not quite there yet. In fact, we're just getting started with this: can we do better?

What's coming up?

You might notice I've carefully avoided a few pretty obvious issues in this article: why are we not loading the Views on demand, but keeping them as a reference instead? And what about those other assemblies, like the model assembly? As we're modularizing the application, it would make sense to only load the model assembly when the ViewModels using that model are necessary, no?

Of course, those are valid concerns, and this is exactly what we'll tackle in the next part of this series. It requires quite a bit of custom coding: we'll need some extensions to the Silverlight Navigation framework (as it's not as straightforward as we would like to navigate to views in assemblies that are loaded on-demand), and we'll need a component loader component (to ensure we can load all necessary assemblies at once, instead of one by one). After that part, we'll end up with a truly composable app, separated out in modules/assemblies that can easily be reused across different clients.

Up until then: happy coding!

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, HTML5). 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 Belgium & Portugal, NDC2011, ... 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 you can contact him on Twitter via @KevinDockx.

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.

Part 2: Developing for a multitude of clients: Strategies for code reuse and keeping costs in check

editorial@silverlightshow.net (Kevin Dockx ) — Wed, 08 Feb 2012 18:41:00 GMT

Introduction

Welcome to the second part of this article series on strategies for designing your application for a multitude of different clients. A lot of businesses face this problem today: your customers expect a rich desktop client, an almost equally rich web client, a mobile client, … and of course, on different form factors and for use with different types of input: typically, a mouse-keyboard combination, or touch.

That typically amounts to higher costs. And in reality, it will - after all, you are building multiple client applications. The good news is: your costs don't necessarily have to spin out of control. The aim of this article series is to look into how you can cut costs when you're faced with these demands: where can you reuse existing code, and how?

More resources...

All SilverlightShow Ebooks

In the first part, we've had a look at the business case, and the clients we're going to develop. We've also looked at the provided data model. In this part, we'll look at the service layer. We've got a few requirements we need take into account. First of all, the service layer should be able to be consumed by the different clients: Silverlight, Windows Phone, HTML, Windows Phone, Metro. We've also got a few common concerns we should tackle: validation & authentication come to mind. And we require something that allows us to rapidly get our applications to the market: development time is an issue to take into account as well.

The accompanying source code for this article can be downloaded here.

Say hello to WCF RIA Services

If you have been building serious Silverlight Line of Business applications, you've undoubtedly heard of WCF RIA Services. A Silverlight client will typically get its data from a server via asynchronous service calls - so when you're building a Silverlight application, you're forced to build it in an asynchronous, service-oriented way. This can quickly become quite cumbersome: you'll have to write quite a lot of application logic to solve some common concerns, like validation logic and authentication, which quickly results in writing code on both sides (client and server), plugging in some code generator or your own mapping tool, …

Here, we're trying to get our applications to the market quickly, and we're trying to cut down on development time & costs. This is where WCF RIA Services really stands out: it obscures a lot of the plumbing details you'd have to write yourself otherwise, and more importantly: it solves most of our common concerns. You'll typically write the code on the server side, and WCF RIA Services will generate the corresponding code on the client - including your validation logic, your domain model, and all the logic you need to fetch and submit entities.

Working with WCF RIA Services feels a lot like working with the Entity Framework (of course, I’m talking about the “feel” here, not the technicalities): you'll load entities to your client, construct change sets, and submit them back to the server, which will take care of committing them to your data store: it obscures the intermittent service layer. This is, of course, a simplified explanation, and in reality it's not as easy as a typical marketing department would like you to believe, but I've used WCF RIA Services on a multitude of real-life Line of Business projects, and I'm convinced it's the fastest option on the market, while still allowing great extensibility and robustness, making it a good fit for most Line of Business applications. In this series, we won't look into the specifics of developing with WCF RIA Services, as there are already some great resources out there: you can learn a lot more about WCF RIA Services in Brian Noyes excellent series on this site, or have a look at some of the WCF RIA Services related articles I wrote.

What about the other clients?

Ok, so it's a no-brainer for building a Silverlight application, and our two main clients are Silverlight-based (web & out of browser), but what about those other clients? Weren't we supposed to build a mobile client (Windows Phone), an HTML-based client, and even a Windows 8 Metro client? Yes, we are, so let's have a look at those.

The mobile client (Windows Phone 7): when you're developing for Windows Phone, you're developing in Silverlight. However, this isn't the same version as the Web/OOB plugin. Contrary to what you might hope, WCF RIA Services isn't supported as we're used to in regular Silverlight. However, WCF RIA Services can expose its Domain Services as SOAP, REST or OData (read-only) endpoints, making it easily accessible from a Windows Phone client. We'll look into how we can enable this a bit further on in this article.

The HTML-based client: for this client, a WCF RIA Services implementation is available, namely RIA/JS: a jQuery client for WCF RIA Services. With this JavaScript-based framework, you get most of what you're used to with a Silverlight-based WCF RIA Services client, but with using JavaScript. You can load data using your Domain Services (query support, including sorting, paging and filtering), you get your validation logic on the client (your server side validation metadata is exposed in jQuery validation format), you can create change sets and you can submit them.

Windows 8 Metro client: at this point, it's unclear whether or not we'll get WCF RIA Services support for Windows 8 Metro apps. However, even it doesn't happen, the SOAP, REST or OData endpoints can be used.

Other future clients (iOS, Android): these would typically use the SOAP or REST endpoints.

Setting it up: logically dividing your services

It may seem like a no-brainer, but it's often forgotten: you should logically divide your domain model into different services, and a service should only expose what's needed, nothing more. This is especially true if you're building different clients: not every client will provide the users with the same functionality, so a client that provides limited functionality shouldn't consume a service which exposes a lot more - for example, if you look at our business case, the mobile client will deal with quickly inputting new opportunities, and thus shouldn't have access to service methods that allow him to access back-end functionality, or customer administration. So, instead of having only one Domain Service which exposes all your logic & entities, you should divide them in different "modules": a Domain Service for customer administration, a Domain Service for employee/opportunity management (this is the one we'll build), … Also, don’t expose unneeded operations: for example, a Domain Service for managing opportunities will probably require access to the Employee object, but shouldn’t be able to edit it (so there’s no need for Insert, Update or Delete operations).

Using this type of division also offers you more scalability options: often-used modules, by various clients, can be published to servers with higher bandwidth capabilities, whereas little-used modules can kept on low-bandwidth servers.

Same goes for security: a back-end service module can be kept in-house, hosted on your intranet rather than on the internet.

Setting it up: the solution division

Often, the WCF RIA Services class library template is used. This creates a .Web project (full .NET 4 CLR), containing your domain services, and a Silverlight class library project, containing the generated code. However, the naming of these projects is quite unclear, and not exactly correct. We're going to change that a bit, resulting in better naming.

First, we'll add a class library to our solution, SalesDashboard.EmployeeOpportunityService. This will contain the Domain Service we'll use throughout this demo application. You'll typically want one of these for each of your logically divided modules, as explained in the previous paragraph. For the demo application we're building, two are sufficient: one for the EmployeeOpportunity service, and one for an authentication service.

Next, we'll add a Silverlight class library to the project, SalesDashboard.Client.Model. This is the project which will be referenced by our Silverlight clients, and this is where we want the generated code to end up. That can be achieved by setting the WCF RIA Services link to the project containing our Domain Service:

All we need now is a Service Host. Create a new ASP .NET application, and make sure it references SalesDashboard.EmployeeOpportunityService. Next, add an SVC file to it, EmployeeOpportunityService.svc. Double-click it, and put in the following code:

<%@ ServiceHost Language="C#" Debug="true" 
Service="SalesDashboard.EmployeeOpportunityService.EmployeeOpportunityDomainService"
Factory="System.ServiceModel.DomainServices.Hosting.DomainServiceHostFactory, 
System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" %>

As you can see, we're stating here that the DomainServiceHostFactory should be used to instantiate a new EmployeeOpportunityDomainService - making our service accessible through the explicit EmployeeOpportunityService.svc URI instead of the auto-generated SVC you normally get with WCF RIA Services.

Note: as this is now your service host, this project should contain all necessary WCF RIA Service references and configuration in the web.config - just as you would normally have in a service host. This is how it looks in the provided solution:

<configuration>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      <add name="DomainServiceModule" preCondition="managedHandler" 
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, 
System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" />
    modules>
    <validation validateIntegratedModeConfiguration="false" />
  system.webServer>
  <connectionStrings>
      <add name="SalesDashboardAuthenticationEntities" 
connectionString="metadata=res://*/SalesDashboardAuthenticationModel.csdl|
res://*/SalesDashboardAuthenticationModel.ssdl|res://*/SalesDashboardAuthenticationModel.msl;
provider=System.Data.SqlClient;provider connection string="data source=.\sql2008;
initial catalog=SalesDashboard;persist security info=True;user id=salesdashboard;
password=salesdashboard;multipleactiveresultsets=True;App=EntityFramework"" 
providerName="System.Data.EntityClient" />
      <add name="SalesDashboardEmployeeOpportunityEntities" 
connectionString="metadata=res://*/SalesDashboardEmployeeOpportunityModel.csdl|
res://*/SalesDashboardEmployeeOpportunityModel.ssdl|res://*/SalesDashboardEmployeeOpportunityModel.msl;
provider=System.Data.SqlClient;provider connection string="data source=.\sql2008;
initial catalog=SalesDashboard;persist security info=True;user id=salesdashboard;
password=salesdashboard;multipleactiveresultsets=True;App=EntityFramework"" 
providerName="System.Data.EntityClient" />
  connectionStrings>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        behavior>
      serviceBehaviors>
    behaviors>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
  system.serviceModel>
  <system.web>
    <compilation debug="true">compilation>
    <httpModules>
      <add name="DomainServiceModule" 
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, 
System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" />
    httpModules>
  system.web>
configuration>

Setting it up: making the service layer available for other clients

Non-Silverlight clients will communicate with our service layer through OData, SOAP or REST endpoints. Setting these up is quite easy – the OData endpoint is even provided out of the box. When you’re going through the Domain Service wizard, simply check the “Create OData endpoint” checkbox, and it will be created for you (you’ll still need to copy/paste the relevant code to the web.config of the Service Host).

If you want to do this manually, you should add some following code to the web.config on the Service Host. This should be added right underneath the configuration tag:

<configSections>
    <sectionGroup name="system.serviceModel">
      <section name="domainServices" 
type="System.ServiceModel.DomainServices.Hosting.DomainServicesSection, 
System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" allowDefinition="MachineToApplication" requirePermission="false" />
    sectionGroup>
configSections>

And this should be added underneath system.serviceModel:

<domainServices>
      <endpoints>
        <add name="OData" type="System.ServiceModel.DomainServices.Hosting.ODataEndpointFactory, 
System.ServiceModel.DomainServices.Hosting.OData, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" />
      endpoints>
domainServices>

The other two endpoints are provided through the WCF RIA Services Toolkit. The most convenient way of getting these is by using NuGet, as they are provided as a NuGet package. Use NuGet to manage the packages for the Service Host, locate the RIAServices.Endpoints package, and click install. The following endpoints will be added to your web.config file:

<add name="soap" type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory, 
Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" />
<add name="JSON" type="Microsoft.ServiceModel.DomainServices.Hosting.JsonEndpointFactory, 
Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" />

That’s really all there is to it: from now on, our Domain Service is accessible through OData (read-only), SOAP and JSON (REST) endpoints.

Conclusion

In this article, we’ve looked into our service layer options, and we’ve settled on WCF RIA Services. We choose this framework mainly for its extensibility, RAD characteristics and possible reuse across different clients. We’ve looked into some pointers on service layer design, and created the Domain Service for the module we’ll develop. At the end, we’ve made this Domain Service available for other (non-Silverlight) clients through the use of endpoints from the WCF RIA Services Toolkit.

In the next part, we’ll start with the first Silverlight client.

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, HTML5). 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 Belgium & Portugal, NDC2011, etc. 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 you can contact him on Twitter via @KevinDockx.

Part 1: Developing for a multitude of clients: Strategies for code reuse and keeping costs in check

editorial@silverlightshow.net (Kevin Dockx ) — Tue, 07 Feb 2012 10:40:00 GMT

Introduction

In this article series, we're going to try and tackle a problem (or opportunity, depending on how you want to put it) a lot of business face today: customers expect to be able to use your applications on a multitude of devices, with different form factors, supporting different technologies.

More resources...

All SilverlightShow Ebooks

And you're supposed to provide them with the best possible experience on all these devices, if you want to keep them. In today's world, consumers are used to the beautiful experiences they get from apps on their smartphones - and yes, enterprise users are consumers as well -, up to the point that they will prefer a nicely designed application which offers a good user experience to an application which has more features, but a badly thought out UI (on a side note, a very interesting post on why projects need to focus on design, and thus need a designer, can be read at Pete Browns' blog).

The situation, today

So, where are we at? More devices, more technologies, more focus on design. For most business, this means: extra costs. You'll have to hire a designer: arguably, this will diminish costs in the long run, but it definitely is an extra cost when your project is starting. However, don't try cut costs by not hiring one: in todays' world, you will definitely regret this when you see potential customers fleeing to the competition because your application isn't user-friendly and intuitive enough.

You'll typically have to adjust your UI to a specific form factor: it's obvious that a UI designed for use with a mouse and keyboard on a laptop with a high screen resolution is unfit for a smartphone or a tablet, which typically have smaller screen estate and touch-based input. Next to that, every technology has its own specifics, its own quirks even - and its own learning curve: you can 't just expect a Silverlight developer, who is used to a stateful model, MVVM and XAML, to be as productive on, for example, an ASP .NET project - in which he has to keep postbacks in his mind and have some knowledge of HTML + JavaScript + CSS.

Depending on the type of service layer you choose, it will take more code to get it working depending on the technology used by the clients which consume the services. Most client technologies are pretty good at communicating with a variety of services, but we'll see that the choice of this service layer can already have a big impact on the total development time & cost - think about a Silverlight client versus a HTML-based client: your Silverlight client should have proxy classes (or a separate layer + mapping component) that implement INotifyPropertyChanged to ensure binding functions correctly. Preferably, there should also be an implementation of INotifyDataErrorInfoChanged, to get client-side validation (and thus diminish client-server communication) - things which you typically don't need in an HTML-based app (well… sometimes they come in handy, but more on that later). There's the place of validation to think about (server side or server/client-side), authentication and authorization, ... How you expose your service layer can have quite an impact on the total cost of your project.

The different clients we’ll build

SilverlightShow is a site which focuses on Silverlight (or, if you want to expand on it: XAML), so you might argue this is the logical choice for our main client applications. But that's not the reason we'll choose this technology: skill reuse is of importance as well if you want to cut costs, and so is the ability to share code between different clients - more code than just the service layer.

Our main clients will be a Silverlight web application (typically used on every laptop which has the Silverlight plugin installed), a Silverlight Out of Browser application (typically used on the home laptop of the user), and a Windows Phone application (for use on the road) - this ensures we have a bit of skill reuse, but we'll also see we can reuse quite a bit of code: what are the options on sharing Views across XAML applications? What about ViewModels, and splitting up our code in different modules? We'll talk about code reuse, but we'll also talk about when we can reuse code, but probably shouldn't. But we won't stop there: not everyone has a Silverlight plugin - or wants to install it, so we'll dive into a HTML5 based client, as this is becoming more prevalent these days. And, why not, a Windows 8 WinRT Metro client (offering even more skill reuse across technologies)?

Lastly, as we're building an application that can be used on a multitude of clients, you can image the usage of your application going up. We'll also dive into some options on how to tackle this: we’re going to take part of our application to the cloud.

Our business case

But let's start with the beginning: the application itself. What we're going to build is a dashboard application to add, edit and follow-up product sales. The company we're building it for sells this software (as a service) to other companies. Clients of this company expect to get an immediate overview of their running offers, past offers, … and the company wants to offer this to them in a nice, modern, user-friendly user interface.

As can be expected, the sales people of their clients are typically on the road a lot, so they've asked for a mobile client. This client won't be as full-featured as the desktop client: the sales people just need to be able to quickly input a possible opportunity, right when they spot one, instead of having to wait until they're in front of their laptops.

When they are (for example: at the customers' location), they prefer to access the application through a web browser, either via a Silverlight plug-in (if it's installed) or via a HTML5-based web application. And when they're behind their own computers, they could prefer to use a desktop-based application which can interact more with their locally installed application. A typical use case would be that the application can look in their Outlook inbox, to check if they've had contact with a specific customer in the past.

The company also expects a lot of its clients will switch to Windows 8 tablets once they become available, so they're looking into developing a Windows 8 Metro application for this.

As you can see: quite a lot of applications, quite a lot of requirements - and very costly. The main purpose of this article series is looking into what can be done to keep costs (and development time) in check - this is not necessarily the same as building the best architecture for every type of situation; it's about building the best architecture for this specific situation with these specific requirements, when you only have a relatively short time to put your app(s) on the market.

Let’s get started with the technical stuff: the data model

Let's look at the data model of the application first: as most of the people reading this are probably quite technical, this should help to clarify the business case somewhat:

As you can guess from this model, it's actually suitable for more than just one type of dashboard: we've got different roles for different employees, and an employee can have another employee as his boss - this implies we'll have different views in our application, for example: an employee might only be able to view his own opportunities, but his boss might want to get an overview of all the opportunities of everyone in his department. Next to that, there's also room for a back-end application (for user administration), and different modules (you might have one where a user can register a new opportunity, but you might also have one where a user with a specific role can manage customers). The focus of this series lies on clarifying techniques, and not on building the complete application: we're going to take one part of the dashboard app, one module if you wish, the employee/opportunity module, and use that to illustrate this series.

Conclusion & coming up next

In this article, we’ve had a look at the problem lots of businesses are facing today: multiple devices, multiple clients. We’ve also dived into the business case we’ll use throughout this article series, and the different clients we’ll build – all the time focusing on code reuse and keeping costs in-check. Lastly, we’ve looked at the data model we’ll use for our applications.

In the next article, it’s time talk about how we're going to design the service layer.

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, HTML5). 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 Belgium & Portugal, NDC2011, ... 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 you can contact him on Twitter via @KevinDockx.

Using the Live SDK in Windows 8 XAML/C# Metro Applications

editorial@silverlightshow.net (Michael Crump ) — Mon, 30 Jan 2012 03:59:34 GMT

Introduction

The Microsoft’s Live SDK (or commonly referred to as Live Connect), provides a set of controls and APIs that enables applications to integrate single sign-on (SSO) functionality using Windows Live ID. You can also use it to access data in SkyDrive, Hotmail, and Windows Live Messenger.

Don't miss...

All SilverlightShow Ebooks

The library supports multiple platforms, including Windows Phone 7 Mango and Windows 8 Metro Style applications using either C#, Visual Basic or JavaScript. In this article, we will build our first metro style application using the Live SDK and XAML/C#.

Download the Bits

Let’s begin by downloading the following items:

You will need to download the Windows 8 Developer Preview to follow along with this article. This will install Windows 8 along with the new Visual Studio 11 which is required to build Metro applications.
Download the Live SDK v5.0 or higher - The Live SDK provides a set of controls and APIs that enable applications to integrate single sign-on (SSO) using Windows Live ID and to access data in SkyDrive, Hotmail, and Windows Live Messenger.
Optional, but highly recommended - The Metro Style App Samples which provides various sample metro applications for future reference. It is licensed for public use, so feel free to use it in your own applications.
Optional, but recommended - Read the Windows 8 Developer Preview guide to start learning about the features/functionality coming in Windows 8.

Signing into Windows 8 Using your Windows Live ID

One of the most important things to learn before building your first application that uses the Live SDK is the various ways to sign into your Windows 8 machine.

You currently have two ways to sign into your Windows 8 machine and each way determines the prompts the users will receive when launching a application that uses the Live SDK.

A Local Account – which stores all of the data regarding your profile on the local machine.
- If you user is using this method, then they will get the prompt to sign in and to allow access.
A Windows Live ID – retrieves profile information directly from your Live ID and enables features such as roaming and easy sign-on to Microsoft services.
- If you user is using this method, then they will only get the prompt to allow access.

In this tutorial, we will be signing into Windows 8 using our Live ID.

If you have already setup a “Local Account” then you can switch very easily by going to Control Panel –> Users then clicking on “Switch to a Windows Live ID” as shown below.

You will then be prompted to enter your current password of the local account and log in using your Live ID username/password. If you don’t have one then you may sign up for one through this wizard.

Immediately following you should receive an email similar to the one below:

If you click on the link to confirm your identity then a web browser will pop open and you will be greeted with “Manage Security Info”. This screen will list mobile devices, email address and trusted PC linked to your account. As we can see below that I have three Windows 8 machines linked to my account.

You can also add a new trusted PC manually with the “Add New” link. To use this feature, you must access your account using Internet Explorer and have Windows Live Essentials installed.

Let’s Get Started

Now that we have the necessary tools to begin building a Metro Application using C#/XAML and we we have signed into Windows 8 using our Live ID, let’s begin.

In this sample application, we are going to retrieve the following information from the users profile:

Users First and Last Name
What gender they are and what region they live in
URL to their Live Profile

As well as add a contact to their address book.

Launch Visual Studio 11 Developer Preview and select Visual C# -> Windows Metro style –> Application. Give the project the name MyFirstLiveConnectApp and hit OK.

Adding the Live SDK References

In case you haven’t already, please download and install the Live SDK v5.0 before proceeding.

Once that is complete, we can add the references to our project by Right Clicking on References inside of Visual Studio 11 and selecting “Add Reference”. Next, you will need to select Windows –> Extension SDKs –> Live SDK then Add.

Registering the Application with Windows Live

Before we begin building this app, you need to register it with Windows Live. You can register your app by going to the application management site and following the instructions on the site.

The only item that you want to pay special attention to is the Package Name in Step 3 as you will copy and paste that into your Application’s Package.appxmanifest file. (A walk-through is included in that site).

If you don’t register your application and try to use Live services, then your user will be presented with the following error message.

Once this process is complete you can view your registered applications here. This page will contain all the API settings needed to use the Live SDK in your projects.

Understanding what is under the hood…

When we select the C#/XAML Application template, Visual Studio 11 provides us with basic application structure. Before we begin building our own, it makes sense to spend a few minutes examining the XAML pages included in the existing structure.

References – It is empty by default because Microsoft decided that all the WinRT assemblies are always referenced by default and they have no reason to display them. Any of your own referenced assemblies or third party references will be shown as in this case our Windows Live SDK is shown.
App.xaml is used by Metro applications (amongst other XAML technologies) to declare shared resources like brushes, various style objects etc. The code behind file of App.xaml is used to handle global application level events like OnLaunched and OnActivated.
MainPage.xaml contains the markup of what our user interface will look like once the application is executed. The default Metro MainPage.xaml file consists of a UserControl and a Grid.
Package.appxmanifest – Is basically an XML file, but if you double click it then you will notice four tab panels inside it (named: Application UI, Capabilities, Declarations and Packaging)

Back to Building a Simple User Interface

Here is a mock-up screen of what our app will look like:

As you can see we have 2 buttons:

Windows Live Sign-In – Provided by the Live SDK and is used to log the user into the app to retrieve Live Services information.
Create Contact – Just a regular button that will be used to create a contact in the users address book.

On the left hand side you can see information retrieved by the Live SDK including first and last name, gender, location and live profile URL.

Double click on your MainPage.xaml and replace the existing Grid with the code snippet provided below.

<Grid x:Name="LayoutRoot" Background="#FF0C0C0C">

    <Grid.ColumnDefinitions>

        <ColumnDefinition Width="251*"/>

        <ColumnDefinition Width="1116*"/>

    Grid.ColumnDefinitions>

    <StackPanel Grid.ColumnSpan="2">

        <live:SignInButton Name="btnLogIn" Scopes="wl.signin wl.basic wl.contacts_create"/>

        <Button x:Name="btnCreateContact" Content="Create Contact" Click="btnCreateContact_Click" />

        <TextBlock Name="tbName" Width="600" Height="150" FontSize="32" TextWrapping="Wrap" />

        <TextBlock Name="tbGender"  Width="600" Height="150" FontSize="32" TextWrapping="Wrap" />

        <TextBlock Name="tbLiveProfile" Width="600" Height="150" FontSize="32" TextWrapping="Wrap" />

        <TextBlock Name="tbError" Text="Error Message" Width="600" Height="150" FontSize="32"/>

    StackPanel>

  

Grid>

You will also want to make sure that your XML Namespaces for the Live SDK have been added to the page:

   1: xmlns:live="using:Microsoft.Live.Controls"

Note: You will get “Invalid Markup” with the XAML provided because we are still in the developer preview stage. It is ok to proceed.

The only thing to really pay attention to here is the Scopes listed in the SignInButton. As you see we have three scopes.

wl.signin - Single sign-in behavior. With single sign-in, users who are already signed in to Live Connect are also signed in to your website.
wl.basic - Read access to a user's basic profile info. Also enables read access to a user's list of contacts.
wl.contacts_create - Creation of new contacts in the user's address book.

The first two are core and the last is an extended scope. We need all three of these to complete the requirements listed in this sample application.

This will give us our user interface, now we will just need to wire up the event handlers which I am going to split up into two sections for learning purposes.

Coding Time – Basic User Information

Let’s go ahead and add in functionality to retrieve basic user information from the Live SDK.

First, add the proper namespaces and then the following code:

using Microsoft.Live;

using Microsoft.Live.Controls;

private LiveConnectClient liveClient;

private LiveConnectSession session;

  

public MainPage()

{

    InitializeComponent();

    this.btnLogIn.SessionChanged += btnLogIn_OnSessionChanged;

}

  

private void btnLogIn_OnSessionChanged(object sender, LiveConnectSessionChangedEventArgs e)

{

    if (e.Session != null && e.Status == LiveConnectSessionStatus.Connected)

    {

        this.liveClient = new LiveConnectClient(e.Session);

        session = e.Session;

        this.liveClient.GetCompleted += OnGetCompleted;

        this.liveClient.GetAsync("me", null);

    }

    else

    {

        this.liveClient = null;

    }

}

  

private void OnGetCompleted(object sender, LiveOperationCompletedEventArgs e)

{           

    if (e.Error == null)

    {

        dynamic result = e.Result;

        this.tbName.Text = "Hello, " + result.first_name + " " + result.last_name;

        this.tbGender.Text = "You are a " + result.gender + " that lives in " + result.locale + ".";

        this.tbLiveProfile.Text = "Your Live Profile can be found at: " + result.link;

    }

    else

    {

        this.tbError.Text = e.Error.ToString();

    }

}

The first thing that you will notice is that we are creating an event hander to handle the SessionChanged event. If we can determine that the session is valid then we create a new LiveConnectClient and pass the session to our LiveConnectSession. We finish up with adding an event handler on GetCompleted which will return the current users profile information and display them in our TextBlocks. Finally, we are outputting all errors to the tbError TextBlock.

Coding Time – Adding a new contact to the users Address Book

Let’s go ahead and add in functionality to add a new contact to the users address book from the Live SDK.

private void btnCreateContact_Click(object sender, RoutedEventArgs e)

{

    LiveConnectClient createContact = new LiveConnectClient(session);

    var contact = new Dictionary<string, object>();

    contact.Add("first_name", "Michael");

    contact.Add("last_name", "Crump");

    createContact.PostCompleted +=

        new EventHandler(CreateContactProperties_PostCompleted);

    createContact.PostAsync("me/contacts", contact);

  

  

}

  

void CreateContactProperties_PostCompleted(object sender, LiveOperationCompletedEventArgs e)

{

    if (e.Error == null)

    {

        tbName.Text = "Contact" +

            e.Result["first_name"].ToString() + " " + e.Result["last_name"].ToString() +

            " created with ID " +

            e.Result["id"].ToString();

    }

    else

    {

        tbError.Text = "Error calling API: " + e.Error.ToString();

    }

}

In this sample, we are creating a new LiveConnectClient by passing into it the existing session. Once that is complete, we create a Dictionary and add the users first_name and last_name to the dictionary. Finally, we create a PostCompleted event handler which will return the textblock with a success or an error. The last call is PostAsync which send a POST request to the specified Uri as an asynchronous operation.

Ready for Liftoff

Go ahead and build the application and run it.

When you first hit the “Sign In” Button you will be presented with the following:

Note: After you accept this one time then you will not have to accept it again.

Notice that the application says it you allow access then it will view your profile and contact list. The application automatically knows which features it is using by the scopes defined earlier.

Select “Yes” and then click the “Sign In Button” located on the right hand side of your screen and you should see your Live profile information as long as you have filled it out in Windows Live.

Next, click on the Create Contact button and you should see the following:

You can now sign into your Windows Live account and select “Contacts” under “Hotmail” and see the contact that you just created.

Congratulations, you have now completed your first Metro application using XAML/C# that uses the Live SDK.

Conclusion

At this point, we have seen how you would create a Windows 8 Metro application using XAML/C# that retrieves and updates information from the Live SDK. Now that you are equipped with the basics of using the Live SDK, I encourage you to explore the Live SDK further as we have barely scratched the surface. I want to thank you for reading this article and if you ever have any questions feel free to contact me on the various sources listed below. I also wanted to thank SilverlightShow for giving me the opportunity to share this information with everyone.

You can follow Michael on Twitter at mbcrump or keep up with his blog by visiting michaelcrump.net.

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

10 Laps around Silverlight 5 (Part 10 of 10)

editorial@silverlightshow.net (Michael Crump ) — Mon, 12 Dec 2011 21:50:15 GMT

This article is sponsored by Telerik RadControls for Silverlight. For similarly awesome content check out Telerik XAMLflix, your step-by-step guide to Telerik Silverlight and WPF controls. Get access to video tutorials, written tutorials, and tons of code!

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

More resources...

All SilverlightShow Ebooks

This article is Part 10 of the series “10 Laps around Silverlight 5.” If you have missed any other section then please see the Roadmap below.

To refresh your memory on what Silverlight is:

Microsoft Silverlight is an application framework for writing Rich Internet Applications.

The run-time environment is available as a plug-in for most web browsers and works on a variety of operating systems including Windows, Mac and Linux.

To recap what we learned in the previous section:

We took a look at several new controls in Silverlight 5 including: Double and Triple click support and ComboBox Type-Ahead.
We then took a deeper dive into the PivotViewer control as it is more complex than the others and provided additional links.

In this article, I am going to discuss several new features that did not fit in any of the above categories. We will discuss In-Browser HTML, PostScript and Tasks for TPL. Please review the Roadmap for the series before going any further.

The Roadmap for this Series

I’ve included the Roadmap for the series below as you may want to visit other sections as you learn Silverlight 5. I picked the following features as I thought that you may find them useful in your day-to-day work. If you want a specific topic covered then please leave it in the comments below.

1) Introduction to SL5 – This post which provides a brief history of Silverlight and relevant links.

2) Binding- Ancestor Relative Source Binding and Implicit Data Templates.

3) Graphics –XNA 3D API and Improved Graphics Stack.

4) Media - Low-Latency Sound using XNA and Remote Control and Media Command (Keys) Support.

5) Text - Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions.

6) Operating System Integration - Part 1 - P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust.

7) Operating System Integration - Part 2 - Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness.

8) Productivity and Performance - XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time.

9) Controls - Double and Triple click support, PivotViewer and ComboBox Type-Ahead.

10) Other items [This post] - In-Browser HTML, PostScript and Tasks for TPL.

In-Browser HTML

In Silverlight 4, we could use the WebBrowser control only in an “Out-of-Browser” application. This has changed in Silverlight 5 as we can now use the WebBrowser control in the browser (IE). It will however require that you make a few changes to your system. Let’s get started:

1) Update the registry – Locate the following keys:

If you running on a 32 bit machine,

HKEY_LOCAL_MACHINE\Software\Microsoft\Silverlight\

and if you are running on a 64-bit machine,

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Silverlight\

change the UpdateConsentMode from a 0 to 1.

2) Sign the XAP File - Right click on the Silverlight application and go to properties. Choose Signing and check the checkbox Sign the .XAP file. Now click on the button Create Test Certificate. Enter any password that you want and hit the OK button. Now click on the More Details button.

Click on the Install Certificate button. Clicking on the button brings up the Certificate Import wizard. Click on the Next button and choose Place all certificates in the following store. Click on the Browse button. This will show you a Certificate Store. Choose Trusted Publisher and finish the wizard. Now repeat the same step to install this certificate in Trusted Root Certification Authorities.

3) Enable Out-of-Browser and Require elevated trust when running in-browser. Right click on the Silverlight application and go to properties. Place a checkmark in Enable Out-of-Browser and Require elevated trust when running in-browser.

Now let’s switch over to the MainPage.xaml and replace the Grid with the following code:

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

       <WebBrowser x:Name="webBrowser" Source="http://michaelcrump.net/"/>

Grid>

If we run our application now (using Internet Explorer), then we will see the WebBrowser control working inside of the browser.

Note: This will not work in Chrome, Safari, others (Only Internet Explorer).

You can also add html pages to your project and point the source to that file as well.

PostScript Vector Printing

In Silverlight 4, we had bitmap-based printing. This meant that every time a page was going to print that Silverlight 4 sent the bitmap representing the entire page to the printer. We quickly found out that this resulted in horrible performance for larger print jobs. Now in Silverlight 5 we have PostScript Vector printing. This provides us with a much faster solution. Let’s get started building a sample application that uses this features.

Let’s switch over to the MainPage.xaml and replace the Grid with the following code:

<StackPanel x:Name="LayoutRoot" Background="White" HorizontalAlignment="Center" VerticalAlignment="Center">

    <Button x:Name="basicVector" Click="basicVector_Click" />

    <Button x:Name="forceVector" Click="forceVector_Click" />

StackPanel>

We can navigate over to our MainPage.xaml.cs file and add in the following code snippet for our button event handlers:

private void basicVector_Click(object sender, RoutedEventArgs e)

{

    PrintDocument document = new PrintDocument();

  

    document.PrintPage += (s, ea) =>

    {

        StackPanel stPanel = new StackPanel();                

  

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

        {

            TextBlock tb = new TextBlock();

            tb.Text = "Basic Vector mode.";

  

            stPanel.Children.Add(tb);

        }

  

        ea.PageVisual = stPanel;

        ea.HasMorePages = true;

    };

  

    document.Print("Basic Vector Demo");

    

}

  

private void forceVector_Click(object sender, RoutedEventArgs e)

{

    PrintDocument document = new PrintDocument();

  

    document.PrintPage += (s, ea) =>

    {

        StackPanel stPanel = new StackPanel();

  

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

        {

            TextBlock tb = new TextBlock();

            tb.Text = "Forced Vector mode.";

  

            stPanel.Children.Add(tb);

        }

  

        ea.PageVisual = stPanel;

        ea.HasMorePages = true;

    };

  

    PrinterFallbackSettings settings = new PrinterFallbackSettings();

    settings.ForceVector = true;

    settings.OpacityThreshold = 0.7;

  

    document.Print("Forced Vector Print", settings);

}

In our first button, we have a basic PostScript Vector Printing job. We create a PrintDocument (which was also in SL4), then add a PrintPage with some basic text to it. We finally print the document using Vector printing with document.Print.

In our second button, we do the same thing but we call PrinterFallbackSettings and force the print job to print in Vector mode. We can also set the Opacity value by calling OpacityThreshold.

Tasks Parallel Library (TPL)

In short, TPL is to simply asynchronous methods. Silverlight 5 does not include the full TPL but it does provide Tasks and it’s related factories. Which is exactly what you want! Let’s get started.

We are going to use a sample XML file provided by Microsoft found here. Go ahead and download it and add it to your Web Project with the name of books.xml.

Next, Let’s go ahead and navigate over to our MainPage.xaml.cs file and add in the proper namespaces to use TPL. Next, we will add in the second code snippet:

using System;

using System.Linq;

using System.Net;

using System.Threading.Tasks;

using System.Windows;

using System.Windows.Controls;

using System.Diagnostics;

public MainPage()

{

    InitializeComponent();

    Loaded += new RoutedEventHandler(MainPage_Loaded);

}

  

void MainPage_Loaded(object sender, RoutedEventArgs e)

{

    string uri = "http://localhost:15863/books.xml";

  

    var request = HttpWebRequest.Create(uri);

  

    Task.Factory.FromAsync(

      request.BeginGetResponse, request.EndGetResponse, null)

      .ContinueWith(

        task =>

        {

            var response = (HttpWebResponse)task.Result;

            Debug.WriteLine("Content Type: " + response.ContentType);

            Debug.WriteLine("Content Length: " + response.ContentLength);

            Debug.WriteLine("Method: " + response.Method);

            Debug.WriteLine("Status Code: " + response.StatusCode);

            Debug.WriteLine("Status Description: " + response.StatusDescription);  

        });

}

Note: You will need to change the localhost port in the above code sample before proceeding.

Go ahead and run the application and then look at your Output window in VS2010. You should see the following information.

The thing to note here is Task.Factory.FromAsync. This creates a Tasks that represents a pair of begin and end methods that conform to the Asynchronous Programming Model Pattern.

Conclusion

At this point, we have taken a dive into all of the new features of Silverlight 5. Now that you are equipped with a solid understanding of what Silverlight 5 has to offer, you can begin to use this in your own applications. I want to thank you for reading this series and if you ever have any questions feel free to contact me on the various sources listed below. I also wanted to thank SilverlightShow.Net and Telerik for giving me the opportunity to share this information with everyone. I hope that you enjoyed this series and if you To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

10 Laps around Silverlight 5 (Part 9 of 10)

editorial@silverlightshow.net (Michael Crump ) — Tue, 06 Dec 2011 12:27:00 GMT

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

This article is Part 9 of the series “10 Laps around Silverlight 5.” If you have missed any other section then please see the Roadmap below.

More resources...

All SilverlightShow Ebooks

To refresh your memory on what Silverlight is:

Microsoft Silverlight is an application framework for writing Rich Internet Applications.

The run-time environment is available as a plug-in for most web browsers and works on a variety of operating systems including Windows, Mac and Linux.

To recap what we learned in the previous section:

We learned how you could specify a break point inside of a Binding Expressions in Silverlight 5. We also learned how you could use this same functionality inside of Silverlight 4 with the Silverlight 5 SDK installed.
We then created a sample application that contained a binding error and took a look at the output window to investigate it further. We were then able to determine the source of our error and correct it quickly.
We finished up with listing several productivity and performance improvements in Silverlight 5 that you may not be aware of.

In this article, I am going to discuss several new features/controls such as Double and Triple click support, PivotViewer and ComboBox Type-Ahead. Please review the Roadmap for the series before going any further.

The Roadmap for this Series

1) Introduction to SL5 – This post which provides a brief history of Silverlight and relevant links.

2) Binding- Ancestor Relative Source Binding and Implicit Data Templates.

3) Graphics –XNA 3D API and Improved Graphics Stack.

4) Media - Low-Latency Sound using XNA and Remote Control and Media Command (Keys) Support.

5) Text - Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions.

6) Operating System Integration - Part 1 - P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust.

7) Operating System Integration - Part 2 - Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness.

8) Productivity and Performance - XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time.

9) Controls [This post] - Double and Triple click support, PivotViewer and ComboBox Type-Ahead.

10) Other items - In-Browser HTML, PostScript and Tasks for TPL.

Double and Triple Click Support

One of the new features in Silverlight 5 is the ability to use Double and Triple Click Support. This functionality will tell you how many times the user has clicked the mouse button. The property is called ClickCount and resides in the MouseButtonEventArgs class. Let’s take a look at how to use this new feature.

Fire up a new Silverlight 5 project and give it any name that you want.

Switch over to the MainPage.xaml.cs and add the following code: (Note: You may not need the MainPage() Method section)

public MainPage()

{

    InitializeComponent();

}

  

private void textBlock1_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)

{

    textBlock1.Text = e.ClickCount.ToString();

}

Switch back over to the MainPage.xaml and add in the following code replacing the current Grid:

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

      <Border BorderBrush="Black" BorderThickness="1" Margin="52,49,68,74" CornerRadius="10">

          <TextBlock Height="152" HorizontalAlignment="Center" x:Name="textBlock1" Text="0" VerticalAlignment="Center" Width="244" MouseLeftButtonDown="textBlock1_MouseLeftButtonDown" Foreground="#FFFF2E2E" FontSize="96" TextAlignment="Center" />

      Border>

Grid>

If we go ahead and run the application then we will see the following application.

Go ahead and begin clicking inside of the border and you will see the number increase. If you wait a few seconds and click again then you will notice that it reset itself. You could easily add If..Then… statements to determine what click count number they are on. This may be helpful for a 35 click Easter egg. :)

PivotViewer

Microsoft’s Silverlight Team defines it as the following: The Silverlight PivotViewer makes it easier to interact with massive amounts of data on the web in ways that are powerful, informative and valuable. I couldn’t agree more. Let’s begin today by creating a SL5 application that uses the PivotViewer control and displays a collection of movies. (Classic example, eh?)

Please note that this sample barely scratches the surface of what you can do with the PivotViewer. I’ve included an official link by Microsoft at the bottom of this post for your reference.

Fire up a new Silverlight 5 project and give it the name PivotViewer.

Switch over to the MainPage.xaml.cs and add the following code:

using System;

using System.Linq;

using System.Windows;

using System.Windows.Controls;

using System.Collections.ObjectModel;

  

namespace PivotViewer

{

    public partial class MainPage : UserControl

    {

        private ObservableCollection Movies;

  

        public MainPage()

        {

            InitializeComponent();

            Movies = new ObservableCollection();

            for (Int64 i = 0; i < 500; i++)

            {

                Movies.Add(new Movie() { Title = "Ice Age" + i.ToString(), CountryOfOrigin = "USA", Description = "Set during the Ice Age.", Director = "Chris Wedge" + i.ToString(), Duration = 90, ReleaseDate = new DateTime(2002, 09, 03) });

    

            }

         }

  

        private void UserControl_Loaded(object sender, RoutedEventArgs e)

        {

            MoviePivot.ItemsSource = Movies;

        }

    }

}

We need to create a new class now named Movie. Inside of that class should look like the following:

using System;

  

namespace PivotViewer

{

    public class Movie

    {

        public string Title { get; set; }

        public int Duration { get; set; }

        public DateTime ReleaseDate{ get; set; }

        public string CountryOfOrigin { get; set; }

        public string Description { get; set; }

        public string Director { get; set; }

    }

}

Switch back over to the MainPage.xaml and add in the following code replacing everything:

<UserControl x:Class="PivotViewer.MainPage"

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

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

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

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

    xmlns:pivot="clr-namespace:System.Windows.Controls.Pivot;assembly=System.Windows.Controls.Pivot"

    Loaded="UserControl_Loaded"

    mc:Ignorable="d"

    d:DesignHeight="300" d:DesignWidth="400">

  

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

        <pivot:PivotViewer x:Name="MoviePivot"

                            AccentColor="LightGreen"

                            Background="LightGray"

                            ControlBackground="LightYellow"

                            SecondaryBackground="AntiqueWhite"

                            SecondaryForeground="Bisque"

                            SecondaryItemValueBackgroundColor="Chocolate" >

  

            

            <pivot:PivotViewer.PivotProperties>

                <pivot:PivotViewerStringProperty Id="FTitle" Options="CanFilter" DisplayName="Title" Binding="{Binding Title}" />

                <pivot:PivotViewerStringProperty Id="FDuration" Options="CanFilter" DisplayName="Duration" Binding="{Binding Duration}" />

                <pivot:PivotViewerStringProperty Id="FDirector" Options="CanFilter" DisplayName="Director" Binding="{Binding Director}" />

  

            pivot:PivotViewer.PivotProperties>

  

            

            <pivot:PivotViewer.ItemTemplates>

                <pivot:PivotViewerItemTemplate>

                    <Border Width="200" Height="200" Background="CadetBlue">

                        <StackPanel Orientation="Vertical">

  

                            <StackPanel Orientation="Horizontal">

                                <TextBlock Text="{Binding Title}" FontSize="16" Foreground="White" />

                                <TextBlock Text="(" FontSize="16" Foreground="White" />

                                <TextBlock Text="{Binding Duration}" FontSize="16" Foreground="White" />

                                <TextBlock Text=")" FontSize="16" Foreground="White" />

                            StackPanel>

                            <TextBlock Text="{Binding Director}" FontSize="16" Foreground="White" />

                            <TextBlock Text="{Binding CountryOfOrigin}" FontSize="16" Foreground="White" />

                        StackPanel>

                    Border>

                pivot:PivotViewerItemTemplate>

            pivot:PivotViewer.ItemTemplates>

        pivot:PivotViewer>

    Grid>

UserControl>

If we run our application and select a few items then we will see the following screen. As you can tell when the application loaded that it contained 500 items – Wow!

I’ve barely touched on the amount of things that you can do with PivotViewer. If you want to learn more than please visit the Silverlight site located here.

Combo-Box Type Ahead

Another new feature in Silverlight 5 is Combo-Box Type Ahead. This makes choosing items from a long list very simple. Let’s go ahead and build a sample application.

Fire up a new Silverlight 5 project and give it any name that want.

Switch over to the MainPage.xaml.cs and add the following code:

public MainPage()

{

    InitializeComponent();

     var lstDevelopers = new List<string>

           { "Michael Crump",

              "Pete Brown",

              "Victor G.",

              "Scott Hanselman",

              "Jesse Liberty",

              "Shawn Wildermuth",

              "Scott Gu",

              "Joel Cochran",

              "Kunal Chowdhurry" };

            cbDevelopers.ItemsSource = lstDevelopers;

}

Switch back over to the MainPage.xaml and add in the following code replacing the existing Grid:

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

       <ComboBox x:Name="cbDevelopers" Height="40" Width="150" Margin="20" />

Grid>

If we run our application and begin typing then we will see the ComboBox automatically highlights the row that matches our selection.

Conclusion

At this point, we have seen how you would use Double and Triple click support, PivotViewer and ComboBox Type-Ahead. In the next and final part of the series, I am going to take a look at several new features shipping with Silverlight 5 including : In-Browser HTML, PostScript and Tasks for TPL. Again, thanks for reading and please come back for the next part.

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

10 Laps around Silverlight 5 (Part 8 of 10)

editorial@silverlightshow.net (Michael Crump ) — Tue, 29 Nov 2011 12:18:00 GMT

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

This article is Part 8 of the series “10 Laps around Silverlight 5.” If you have missed any other section then please see the Roadmap below.

More resources...

All SilverlightShow Ebooks

To refresh your memory on what Silverlight is:

Microsoft Silverlight is an application framework for writing Rich Internet Applications.

The run-time environment is available as a plug-in for most web browsers and works on a variety of operating systems including Windows, Mac and Linux.

To recap what we learned in the previous section:

We learned how you could specify a default filename when using the SaveFileDialog prompt. We also discussed how you could run the application in elevated trust to prevent the security warning from being displayed.
We then took a look at 64-bit browser support that is included with Silverlight 5 and learned that if your user is using a 64-bit browser then they will be redirected to a location to download the Silverlight 5 x64 runtime.
We wrapped up a short section on new and improved power awareness for media applications.

In this article, I am going to discuss productivity and performance enhancements in Silverlight 5 including: XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time. Please review the Roadmap for the series before going any further.

The Roadmap for this Series

1) Introduction to SL5 – This post which provides a brief history of Silverlight and relevant links.

2) Binding- Ancestor Relative Source Binding and Implicit Data Templates.

3) Graphics –XNA 3D API and Improved Graphics Stack.

4) Media - Low-Latency Sound using XNA and Remote Control and Media Command (Keys) Support.

5) Text - Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions.

6) Operating System Integration - Part 1 - P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust.

7) Operating System Integration - Part 2 - Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness.

8) Productivity and Performance [This post] - XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time.

9) Controls - Double and Triple click support, PivotViewer and ComboBox Type-Ahead.

10) Other items - In-Browser HTML, PostScript and Tasks for TPL.

XAML Binding Debugging

XAML Binding Debugging, is one of the most important features in the Silverlight 5. We have all been stuck with Binding expressions at one point or another and wanted an easier way to debug them. Now anywhere that you see a {Binding} expression you can put a break point on it just like your typical C# code. Let’s take a look at a sample:

Fire up a new Silverlight 5 project and give it any name that you want.

Go ahead and add a new class to the project named Podcast.cs and add the following code.

public class Podcast

   {

       public string Description { get; set; }

       public DateTime ReleaseDate { get; set; }

       public Uri Link { get; set; }

  

       public Podcast(string description, DateTime releasedate, Uri link)

       {

           Description = description;

           ReleaseDate = releasedate;

           Link = link;

       }

   }

Let’s switch back over to the MainPage.xaml.cs and add the following code:

public MainPage()

{

    InitializeComponent();

    Loaded += new RoutedEventHandler(MainPage_Loaded);

}

  

void MainPage_Loaded(object sender, RoutedEventArgs e)

{

    this.DataContext =

        new Podcast("This Developer's Life - Criticism",

            new DateTime(2011, 4, 21),

            new Uri("http://thisdeveloperslife.com/post/2-0-1-criticism", UriKind.Absolute)

            );

  

}

Switch back over to the MainPage.xaml and add in the following code replacing the current Grid:

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

       <StackPanel Orientation="Vertical">

           <TextBlock Text="{Binding Description}" />

           <TextBlock Name="txtReleaseDate" Text="{Binding ReleaseDate}" />

           <HyperlinkButton Content="Listen to this Episode" NavigateUri="{Binding Lik}" TargetName="_blank" />

       StackPanel>

Grid>

While here, go ahead and put a break point on the “Hyperlink" button line, which you can do by clicking outside its margin as shown below:

Notice the Red Circle and the highlighted “Binding” word? The Visual Studio 2010 debugger will stop once the XAML parser hits that line.

Please note that if you try to put a breakpoint on any line outside of the “Binding” keyword, then you will get a message saying, “This is not a valid location for a breakpoint” at the bottom of your screen:

We are now ready to begin debugging, so, press “F5” on your keyboard to begin. You will notice that the Binding breakpoint was hit. If you examine your Locals window then you will see the following:

It looks like we have an error in our Binding statement that is telling us the property ‘Lik’ does not exist on the class called Podcast. If you continue running the application then you will quickly notice that the webpage launches but the “Listen to this Episode” hyperlink does not work.

If we take a quick look at our Podcast class then we will notice that the property is actually called Link. If we go back to our MainPage.xaml and change

   1: <HyperlinkButton Content="Listen to this Episode" NavigateUri="{Binding Lik}" TargetName="_blank" />

   1: <HyperlinkButton Content="Listen to this Episode" NavigateUri="{Binding Link}" TargetName="_blank" />

and run our application again it will work properly.

It is very easy to debug Binding expressions now with that feature. Another undocumented feature is that if you have Silverlight 5 installed then you can also debug your Silverlight 4 binding statements! Sweet!

Productivity and Performance Improvements

Silverlight 5 contains many additional performance improvements that you may not be aware of. I have decided to create a short list here:

Reduced network latency by using a background thread for networking.
Hardware acceleration is enabled in windowless mode with Internet Explorer 9.
XAML parser improvements that speed up startup and runtime performance.
Support for 64-bit operating systems as discussed in part 7 of this series.
Multi-core JIT for improved startup time.
Increased performance of hardware decoding and presentation of H.264 media for lower-power devices.
Text layout performance improvements

As you can see the Silverlight Team has been hard at work not only adding additional features to Silverlight 5 but improving performance all around.

Conclusion

At this point, we have seen how you would debug binding statements using Silverlight 5’s built-in XAML debugger. We also looked at several productivity and performance improvements in Silverlight 5. In the next part of the series, I am going to take a look at several new controls/features shipping with Silverlight 5 including : Double and Triple click support, PivotViewer and ComboBox Type-Ahead. Again, thanks for reading and please come back for the next part.

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

Silverlight and Sharepoint working together: a Silverlight menu for Sharepoint - Part 2

editorial@silverlightshow.net (Walter Ferrari ) — Mon, 28 Nov 2011 13:56:00 GMT

In the first part of the article I introduced the matter, i.e. adding a Silverlight menu in Sharepoint. The first solution presented, defined as “the client approach”, has a major defect: it cannot be used for anonymous-enabled sites. In this second part we will see another way (that I called the “server approach”) in order to build a Silverlight menu for Sharepoint that can be used also by anonymous users. To make this new approach clearer I will introduce another few general concepts regarding the Sharepoint platform. As previously, they will be marked with a specific icon and Sharepoint developers can skip these parts.

Don't miss...

($0.99)

All SilverlightShow Ebooks

The server approach

An alternative solution for the anonymous – enabled menu is illustrated in the picture below:

Why calling it “server approach”? Because the phase of retrieving the hierarchy of our Sharepoint site is made by code which is running on the server. And who is the owner of this code portion? The answer is: the web part hosting the Silverlight application. Let me take a while to recap some basic concepts I explained in my first article on this series Sharepoint and Silverlight working together. In that article we sectioned the structure of the Silverlight custom web part we are using here to inject the Silverlight application into a Sharepoint page. We have seen that it is a specialized Visual Studio template which helps us create a web part capable of hosting a Silverlight application. The Silverlight application itself is embedded in a

tag inside the custom control which represents the web part. This web part is defined as “sandboxed visual web part” i.e. a “Sharepoint 2010 Visual Web Part” with limited power.

A Silverlight developer could feel a bit bewildered when hearing about visual, sandboxed web parts. In the Sharepoint context, a Web Part is conceptually nothing other than an ASP.NET Web Part. It is an ASP.NET user control which acts as a black box that you can place in one of the zones allowed in the UI layout of a page. Although there is a specific namespace (Microsoft.WebPartPages.WebPart) for the web parts, it is used in rare cases. As usual you can build your own Web Part deriving from System.Web.Ui.WebControls.WebPart. Sharepoint 2010 introduced a few new project templates for Visual Studio 2010, one of these is called “Visual Web Part”. This template creates a ready-to-deploy Web Part with a built-in user control. Editing the user control in design mode or via code behind you can enrich your pages with new features.

The term “sandboxed” is used in Sharepoint 2010 to describe a restricted environment. A “sandboxed solution” is something that can have access only to a subset of the Sharepoint server object model and of the .NET 3.5 assemblies (btw Sharepoint 2010 does not use .NET 4.0) and that runs in a restricted code access security policy. Furthermore, server farm admins can regulate resource usage limits for these solutions. A Visual Web Part is not a sandboxed solution. That’s probably why in the Visual Studio Sharepoint Power Tools add-on a new project template called “Sandboxed Visual Web Part” has been added. A “Silverlight Custom Web Part” is a “Sandboxed Visual Web Part” hosting a Silverlight application, nothing more than that.

Coming back to the picture above, I put the retrieval of the hierarchy under the Sharepoint side because we will do it by invoking the Server Object Model in a code running on server side. After the hierarchy has been provided it is then put into a custom List (the basic data container of Sharepoint) using a nice technique called “Modified Preorder Tree Traversal” that we will see later. Finally, the custom List containing the menu hierarchy can be read by the Silverlight application using the Client Object model every time the cache expires. Why using a custom list? Because we can set anonymous access to this list. This allows a Silverlight application to read the List also in the case in which we are not logged in. Don’t forget that the Silverlight app uses the default credentials when it queries the server.

Retrieving the hierarchy of the site

There is more than one way to get the hierarchy of a Sharepoint site collection. You can use an existing Site Map provider or create your own or, as in this case, use a built-in Sharepoint control, i.e. the SPHierarchyDataSourceControl which provides hierarchical views of Sharepoint sites, lists, and folders. It is the same control used for the “tree view” navigation system mentioned in the first part of this article. Extracting the hierarchy from this control is a simple undertaking.

As shown in the code snippet below it is a matter of instantiating a new SPHierarchyDataSourceControl, setting some properties in order to define which categories of nodes to retrieve, obtaining a HierarchicalDataSourceView and performing a Select() over the view to finally have a IHierarchicalEnumerable collection of menu nodes.

private IHierarchicalEnumerable sitemapNodes;
…
SPHierarchyDataSourceControl HierarchyDataSC = new SPHierarchyDataSourceControl();

HierarchyDataSC.IncludeDiscussionFolders = true;
HierarchyDataSC.ShowDocLibChildren = true;
HierarchyDataSC.ShowFolderChildren = true;
HierarchyDataSC.ShowListChildren = true;
HierarchyDataSC.ShowWebChildren = true;

HierarchyDataSC.RootContextObject = "Web";
HierarchicalDataSourceView view = HierarchyDataSC.GetHierarchicalViewPublic("");

sitemapNodes = view.Select();

If you try to include the code above in your Silverlight Custom Web Part unfortunately it won’t compile. Why? Because as clarified in the previous paragraph the Web Part is a sandboxed We Part and this prevents you from using some assemblies, amongst them the one needed for the code above. You have two options to get out from the mud: one is to abandon the Silverlight Custom Web Part and use a normal Visual Web Part in the way I described in one of my previous articles entitled “Silverlight and Sharepoint 2010 a step forward: how to build a small Silverlight 4 utility to upload files in a List or Library of Sharepoint”, precisely in paragraph “Deploy the Silverlight application using a Visual WebPart”. The other is to modify the settings of the Silverlight Custom Web Part in an “unconventional” way, i.e. by making it become a not-sandboxed solution.

Deploy a Silverlight Custom Web Part as a not-sandboxed solution: a dirty trick

By default when using a Silverlight Custom Web Part, the property “Sandboxed Solution” of the project is set to true as in the picture below:

If you try to set this property to false and then to include the code above to retrieve the hierarchy, you will be able to build the solution but not to deploy it. The error message that will appear is the following:

where “MenuSCWP” is the name I used to replace the default name “SilverlightcustomWebPart1”. As you can see in the second-last picture this project item is in charge of transporting a “MasterpageGallery” module in Sharepoint. This module contains the xap file of our Silverlight application. If you open the file “Elements.xml” nested in the module you can confirm this statement:

"1.0" encoding="utf-8"?>
"http://schemas.microsoft.com/sharepoint/">
  "Menu4U" Url="_catalogs/masterpage/ClientBin/$SharePoint.Package.Name$">
    "Menu4U\Menu4UForSP.xap" Url="Menu4UForSP.xap" />

And now comes the trick to remove this obstacle, and I would like to warn you: it is a very dirty trick.

In Visual Studio right-click on the Silverlight custom Web Part item (I renamed it “MenuSCWP) as in the picture below:

Click on “Open Folder in windows Explorer” to open the folder. You should see a couple of subdirectories and a file named “SharePointProjectItem.spdata” as in the picture below:

Open the file. It should have a content similar to this one:

"1.0" encoding="utf-8"?>
"MicrosoftSilverlightCustomWebPart" SupportedTrustLevels="Sandboxed" SupportedDeploymentScopes="Site" xmlns="http://schemas.microsoft.com/VisualStudio/2010/SharePointTools/SharePointProjectItemModel">

Take a look at the “SupportedTrustLevels” attribute of the projectitem node: actually it is set as “Sandboxed”. Now write “FullTrust” instead, and save the file. Come back to Visual Studio and try to deploy the solution. If all the steps have been followed correctly, the solution will be deployed. Pay attention to the fact that when you close the solution and open it again in Visual Studio, the file is overwritten and you have to set the attribute again. It is not so annoying if you make a batch file or a vbscript that performs the replacement for you. You can also launch the execution of the script from the pre-build event.

Saving the hierarchy in a Sharepoint custom list: the modified preorder traversal tree

In the previous paragraph I explained the reason why I want to put the hierarchy into a Custom Sharepoint List: it can be read also by anonymous users. The problem is that a List in Sharepoint is basically a table with rows and columns, while the IHierarchicalEnumerable object that we have obtained represents a tree hierarchy. How to save a tree-hierarchy in a table then? After a moment of despair I recalled an old article entitled Storing Hierarchical Data in a Database that illustrated an algorithm called Modified Preorder Tree Traversal. The principal assumption of the algorithm is that each node in the hierarchy tree must have a left value and a right value. Then the tree is traversed assigning opportune values for left and right according to the rules shown in the flowchart below:

At a first glance it may look a bit complicated but if you try to put on paper a simple tree and assign the left and right values following the flowchart above, it will be a fun exercise. The following picture shows a hierarchy tree, a tree already numbered with the indication of the direction of traversing:

The nice thing of this approach is that after the hierarchy is put into a table you can retrieve nodes with simple queries. With reference to the picture above, if you want to retrieve the subtree starting from the node title “SITE AA” you can launch this query:

“SELECT * FROM tree_table WHERE left BETWEEN 3 AND 8 ORDER BY left ASC;

If you want all the tree simply write:

“SELECT * FROM tree_table WHERE left BETWEEN 1 AND 22 ORDER BY left ASC;

As for the code implementation, I created a class “MpttItem” representing a single node as below:

class MpttItem
{
    private string title;
    public string Title
    {
        get { return title; }
        set { title = value; }
    }

    private string type;
    public string Type
    {
        get { return type; }
        set { type = value; }
    }

    private string imageUrl;
    public string ImageUrl
    {
        get { return imageUrl; }
        set { imageUrl = value; }
    }


    private string serverRelativeUrl;
    public string ServerRelativeUrl
    {
        get { return serverRelativeUrl; }
        set { serverRelativeUrl = value; }
    }

    private string navigateUrl;
    public string NavigateUrl
    {
        get { return navigateUrl; }
        set { navigateUrl = value; }
    }



    private int left = 0;
    public int Left
    {
        get { return left; }
        set { left = value; }
    }

    private int right = 0;
    public int Right
    {
        get { return right; }
        set { right = value; }
    }

    private int id;
    public int ID
    {
        get { return id; }
        set { id = value; }
    }

    protected MpttItem parent;
    public MpttItem Parent
    {
        get { return parent; }
        set { parent = value; }
    }

    protected IHierarchyData iHierarchyItem;
    public IHierarchyData IHierarchyItem
    {
        get { return iHierarchyItem; }
        set { iHierarchyItem = value; }
    }

    
}

And then in the code behind the sandboxed (not-sandboxed) Web Part I stored each node in a List of MpttItem using a recursive function as below:

List menuRows;

[…]

menuRows = new List();
           
MpttItem mpttRootItem = new MpttItem()
{
    Parent = null,
    IHierarchyItem = null,
    Title = "root",
    Left = 1,
    Right = 0,

};
menuRows.Add(mpttRootItem);


foreach (object item in sitemapNodes)
{
    IHierarchyData menuNode = (IHierarchyData)sitemapNodes.GetHierarchyData(item);
    if (menuRows.Count == 1)
    {
        AddMenuRowsRecursive(null, menuNode, 2, 2);
    }
    else
    {
        int startIndex = menuRows[menuRows.Count - 1].Right + 1;
        AddMenuRowsRecursive(null, menuNode, startIndex, startIndex);
    }
}

menuRows.Sort(
    delegate(MpttItem p1, MpttItem p2)
    {
        return p1.Right.CompareTo(p2.Right);
    }
);
menuRows[0].Right = menuRows[menuRows.Count - 1].Right + 1;
menuRows.Sort(
    delegate(MpttItem p1, MpttItem p2)
    {
        return p1.Left.CompareTo(p2.Left);
    }
);


AddToSPList();

The recursive function is the following:

private int AddMenuRowsRecursive(MpttItem mpttParent, IHierarchyData currHIData, int leftIndex, int rootIndex)
{
    if (mpttParent == null && leftIndex > rootIndex)
        return 0; // elaboration completed

    string title = GetPropertyDescriptorValue(currHIData, "Name");

    Microsoft.SharePoint.Navigation.ISPHierarchyData currHIOtherData = (Microsoft.SharePoint.Navigation.ISPHierarchyData)currHIData.Item;
    
    // look if the current mpttItem was already elaborated
    MpttItem elaboratedItem = menuRows.Find(i => ( (i.IHierarchyItem == null || currHIData == null) ? false : i.IHierarchyItem.GetHashCode() == currHIData.GetHashCode()));

    IHierarchyData childHiData = GetFirstAvailableChild(currHIData);
    if (childHiData == null)
    {
        if (leftIndex > rootIndex && elaboratedItem == null /* && leftIndex < mpttParent.Left + 2*/)
        {
            // then it is a leaf
            MpttItem mpttItem = new MpttItem()
            {
                Parent = mpttParent,
                IHierarchyItem = currHIData,
                Title = title,
                Type = currHIData.Type,
                ServerRelativeUrl = currHIOtherData.ServerRelativeUrl,
                NavigateUrl = SPContext.Current.Web.Site.Url + currHIOtherData.ServerRelativeUrl,//currHIOtherData.NavigateUrl,
                ImageUrl = currHIOtherData.ImageUrl,
                Left = leftIndex,
                Right = leftIndex + 1
            };
            menuRows.Add(mpttItem);

            AddMenuRowsRecursive(mpttItem.Parent, mpttItem.Parent.IHierarchyItem, mpttItem.Right + 1, rootIndex);
            return 0;
        }
        else
        {
            if (mpttParent == null) 
                return 0;

            mpttParent.Right = leftIndex;

            if (mpttParent.Parent == null)
                return 0;
            AddMenuRowsRecursive(mpttParent.Parent, mpttParent.Parent.IHierarchyItem, mpttParent.Right + 1, rootIndex);
            return 0;
        }

    }
    else
    {
        // it is a branch

        if (elaboratedItem == null)
        {
            MpttItem mpttItem = new MpttItem()
            {
                Parent = mpttParent,
                IHierarchyItem = currHIData,
                Title = title,
                Left = leftIndex,
                Type = currHIData.Type,
                ServerRelativeUrl = currHIOtherData.ServerRelativeUrl,
                NavigateUrl = SPContext.Current.Web.Site.Url +  currHIOtherData.ServerRelativeUrl,//currHIOtherData.NavigateUrl,
                ImageUrl = currHIOtherData.ImageUrl,
            };
            menuRows.Add(mpttItem);
            AddMenuRowsRecursive(mpttItem, childHiData, mpttItem.Left + 1, rootIndex);
            return 0;
        }
        AddMenuRowsRecursive(elaboratedItem, childHiData, leftIndex, rootIndex);
        return 0;
    }

}

The AddToSPList() function performs the insertion of the nodes in a Sharepoint custom list which I called “MenuTable”:

private void AddToSPList()
{
    SPWeb mySite = SPContext.Current.Web;
    SPListItemCollection listItems = mySite.Lists["MenuTable"].Items;
    mySite.AllowUnsafeUpdates = true;

    // clean list
    PurgeList(listItems);

    foreach (MpttItem mpttItem in menuRows)
    {
        SPListItem item = listItems.Add();

        item["Left"] = mpttItem.Left;
        item["Right"] = mpttItem.Right;
        item["Title"] = mpttItem.Title;
        item["ImageUrl"] = mpttItem.ImageUrl;
        item["NavigateUrl"] = mpttItem.NavigateUrl;
        item["ServerRelativeUrl"] = mpttItem.ServerRelativeUrl;

        if (mpttItem.Parent != null)
        {
            item["ParentLeft"] = mpttItem.Parent.Left;
            item["ParentRight"] = mpttItem.Parent.Right;
        }
        else
        {
            item["ParentLeft"] = menuRows[0].Left;
            item["ParentRight"] =menuRows[0].Right;
        }

        item.Update();
    }

}

The source code

At this link you find the complete solution discussed in this article. It is not an optimized project but a starting point ready to be improved if you want to create your own Silverlight menu for Sharepoint. It does not contain any cache management either from server side or client side. It is left as an exercise for you. In order to put the menu in practice it is recommended to put it in a master page using Sharepoint Designer.

Summary

In this second part we have seen how to implement a Silverlight menu using a so called “server approach” where the retrieval of the hierarchy is made at the server side. We have learned a dirty trick to “un-sandbox” a Silverlight Custom Web Part and a way to retrieve the hierarchy. Then we have explored a fun method to save the hierarchy in a table so that it can be read by the Silverligt menu also in an anonymous context.

10 Laps around Silverlight 5 (Part 7 of 10)

editorial@silverlightshow.net (Michael Crump ) — Tue, 22 Nov 2011 10:53:00 GMT

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

This article is Part 7 of the series “10 Laps around Silverlight 5.” If you have missed any other section then please see the Roadmap below.

More resources...

All SilverlightShow Ebooks

To refresh your memory on what Silverlight is:

Microsoft Silverlight is an application framework for writing Rich Internet Applications.

The run-time environment is available as a plug-in for most web browsers and works on a variety of operating systems including Windows, Mac and Linux.

To recap what we learned in the previous section:

We spent some time building an application that uses P/Invoke or Platform Invocation to get familiar with Elevated Trust and Out of Browser applications. We also reviewed that P/Invoke allows managed code to call native code.
We then took a look at how to create a Silverlight 5 application that uses multiple windows that are separate from the main Silverlight window. We discussed how that if you close one of the newly spawned windows then it only closes that instance.
We wrapped up with creating an application that uses unrestricted file access to demonstrate creating a folder and placing a file inside of it with some content.

In this article, I am going to discuss a few more operating system integration features in Silverlight 5 including: Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness for Media Applications. Please review the Roadmap for the series before going any further.

The Roadmap for this Series

1) Introduction to SL5 – This post which provides a brief history of Silverlight and relevant links.

2) Binding- Ancestor Relative Source Binding and Implicit Data Templates.

3) Graphics –XNA 3D API and Improved Graphics Stack.

4) Media - Low-Latency Sound using XNA and Remote Control and Media Command (Keys) Support.

5) Text - Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions.

6) Operating System Integration - Part 1 - P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust.

7) Operating System Integration [This post] Part 2 - Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness.

8) Productivity and Performance - XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time.

9) Controls - Double and Triple click support, PivotViewer and ComboBox Type-Ahead.

10) Other items - In-Browser HTML, PostScript and Tasks for TPL.

Default Filename for SaveFileDialog

In previous version of Silverlight, you could not specify the default filename for the SaveFileDialog message. In Silverlight 5 you can very easily.

Fire up a new Silverlight 5 project and give it any name that you want. We are going to create a simple application that contains one button and when the user clicks it the SaveFileDialog will appear with a default filename.

Switch over to the MainPage.xaml and add in the following code:

<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center">

        <Button x:Name="btnSaveFile" Content="Save File Dialog" Click="btnSaveFile_Click"/>

StackPanel>

Let’s switch back over to the MainPage.xaml.cs and add the following code to our button event handler:

private void btnSaveFile_Click(object sender, RoutedEventArgs e)

       {

           var saveFileDialog1 = new SaveFileDialog

                                     {

                                         Filter = "JPeg Image|*.jpg|Bitmap Image|*.bmp|Gif Image|*.gif",

                                         DefaultFileName = "YouCanNowHaveADefaultFileName.jpeg"

                                     };

           saveFileDialog1.ShowDialog();

       }

If we run the application now, we will see the following prompt.

(Note: You could run this application in elevated trust to remove the security warning, see this post for details)

Go ahead and select OK and you will see the following screen:

You should notice that the File name field is filled in for us with a default save as type as Jpeg. Of course, if you didn’t want the user to see the security warning then you could run this application in elevated trust as mentioned under the image.

64-bit browser support

64-bit browser support is also new to Silverlight 5. If you have installed Windows 7 x64 then you already have a 64-bit version of Internet Explorer. You can find it by going to the “search program and files” prompt and typing Internet Explorer as shown below.

If you launch Internet Explorer x64 and visit a site built with Silverlight 5 then you will see the following message:

After you click on the hyperlink then it will take you to a page that says the following:

(Please note this message will change after the final version of Silverlight 5 is released.)

Don’t worry about this prompt, just go ahead and click “Install for Windows” and you will now be able to run Silverlight 5 applications inside of a browser running in 64-bit mode. Pretty sweet stuff!

Power Awareness for Media Apps

Silverlight 5 comes with an improved power awareness feature. When you are watching a video in Silverlight 5, the screensaver will be disabled (for example, it will not kick in and distract you from your movie). It also allows the computer to sleep when the video is not playing. This is all accomplished with no additional code! You just have to be using Silverlight 5.

Conclusion

At this point, we have seen how you would use specify a default filename for SaveFileDialog, we looked at 64-bit browser support and power awareness for media applications. We have also discussed a few other features in Silverlight 5. In the next part of the series, I am going to take a look at a few productivity and performance features including : XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time. Again, thanks for reading and please come back for the next part.

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

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.