SilverlightShow: Silverlight Community

Designer-friendly MVVM for XAML Windows Store applications

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

Introduction

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

Don't miss

All SilverlightShow Ebooks

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

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

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

A Word about MVVM

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

Goals of the Designer-friendly MVVM Helpers

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

For the project itself:

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

For the designer:

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

For the developer:

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

Using the Designer-friendly MVVM Helpers

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

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

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

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

The CallVMMethod Attached Property

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

Basic Example

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

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

   1:  <Page.DataContext>

   2:         <df:MainVM>df:MainVM>

   3:  Page.DataContext>

Here is the relevant code snippet from the ViewModel:

   1:  public string Message { get; set; }

2:

   3:  public void ShowMessage()

   4:  {

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

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

   7:      dialog.ShowAsync();

   8:  }

The UI for this sample looks like this:

And the XAML is:

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

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

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

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

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

Using from an ItemTemplate

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

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

   1:  public MainVM()

   2:  {

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

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

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

   6:  }

7:

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

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

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

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

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

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

   3:  DataTemplate>

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

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

   1:  public void StringSelected(string dataContext)

   2:  {

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

   4:      msgd.ShowAsync();

   5:  }

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

Method signatures

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

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

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

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

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

Adding more events

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

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

2:

   3:  "Click,RoutedEventHandler,RoutedEventArgs",

   4:  "DoubleTapped,DoubleTappedEventHandler,DoubleTappedRoutedEventArgs",

   5:  "DragEnter,DragEventHandler,DragEventArgs",

The T4 code generator will take care of the rest.

The EnumToVisualState Control

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

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

Configuration

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

public enum PanelState { Off, On }

…and use it in the ViewModel:

   1:  private PanelState _panel = PanelState.Off;

   2:  public PanelState Panel

   3:  {

   4:      get { return _panel; }

   5:      set

   6:      {

   7:          _panel = value;

   8:          if (PropertyChanged != null)

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

  10:      }

  11:  }

12:

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

  14:  {

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

  16:  }

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

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

   1:  <VisualStateManager.VisualStateGroups>

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

   3:          <VisualStateGroup.Transitions>

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

   5:                  <VisualTransition.GeneratedEasingFunction>

   6:                      <CircleEase EasingMode="EaseInOut"/>

   7:                  VisualTransition.GeneratedEasingFunction>

   8:              VisualTransition>

   9:          VisualStateGroup.Transitions>

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

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

  12:              <Storyboard>

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

  14:              Storyboard>

  15:          VisualState>

  16:      VisualStateGroup>

  17:  VisualStateManager.VisualStateGroups>

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

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

The control is invisible. It has three important properties:

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

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

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

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

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

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

Conventions

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

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

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

Callbacks

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

   1:  public void PanelTransitionComplete()

   2:  {

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

   4:      msgd.ShowAsync();

   5:  }

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

Initial State

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

Download

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

Summary

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

Windows 8 Development + Blendability

editorial@silverlightshow.net (Braulio Diez ) — Thu, 15 Nov 2012 13:50:00 GMT

Download the source code for this article

Introduction

Expression Blend is a “black unknown tool” for many XAML developers. Many geeks (including myself) tended to say things like “Hey ! I’m happy just coding XAML”, “This is for graphic designers”, “It doesn’t generate clean code”.

In this video article we are going to try to demystify this tool for developers, we will learn some basic features that will show us how we can boost our productivity. As a vehicle to explain the concepts and techniques here exposed we are going to write from scratch the following dummy puzzle app:

Don't miss...

All SilverlightShow Ebooks

Video: Win8 Puzzle App - Intro

Takeaways from this article:

How to create your UI using Expression Blend without having to manually code a single line of XAML.
How to assign data binding via properties tab (no more typo-bug when adding a binding).
How to display sample data to allow you fine tune your layout without having to run the app to check the visual aspect.
How to drop controls and customize them (ListView + GridView).
How to visually create and customize controls templates.
How to assign Converters via properties.

Step 1 – Creating the App + Display the list of pieces

In this step we will check how we can apply data binding and display sample data in design mode. We will start by creating the project, and adding a list with the pieces of the puzzle.

We are going to follow the next steps:

Create the project (we will use Visual Studio, we are geeks).
Create an entity that will identify a puzzle piece.
Create a ViewModel that will hold the list of pieces (we will add to it more properties and methods in later steps).
Drop a List View.
Assign Data Context… plus Design Data Context
Apply Data Binding to a control.
Modify items template.
Apply Data Binding to a control template.
Run the app same results as design.

Video: Win8 Puzzle App - CreatingProjectListView

Step 2 – Adding a canvas to build the puzzle

We are going to learn how to customize a GridView using the properties panel and define custom templates. In order to setup the puzzle canvas, we will drop a GridView control, establish the right size and aspect and setup the data binding.

Note: a GridView won’t be the ideal control to be used for a Puzzle Canvas, but I have rather chosen it to get us familiar with this standard control (the goal of the article is to let us learn about Win 8 + Blendability).

We are going to follow the next steps:

Add the plumbing in the ViewModel to hold the puzzle canvas info.
Drop a GridView.
Configure Items container to hold a 2x2 pieces canvas.
Configure the Items Template to be binded to a single puzzle slot + binding.

Video: Win8 Puzzle App - PuzzleCanvas

Step 3 – Drag & Drop Behavior

One cool feature that we get when we develop a Windows 8 app it’s the “AllowDrop” “CanDragItems” properties that are already included into the controls. In this snippet we will setup the drag & drop operations for different combinations of controls (puzzle list >> puzzle canvas, puzzle canvas >> puzzle list view, puzzle canvas >> puzzle canvas).

We are going to follow the next steps:

Create the ViewModel methods to update the puzzle canvas and pieces bucket.
Add Names for the controls (some code in the view going on).
Setup Drag & Drop list view.
Setup Drag & Drop elements of the GridView.
Drag from the Piece’s available list into the puzzle canvas.

Video: Win8 Puzzle App - Drag and Drop #1

Dragging and Dropping other cases

Drag & Drop puzzle canvas to puzzle canvas.
Drag & Drop puzzle canvas to piece’s list view

Video: Win8 Puzzle App - Drag and Drop #2

Step 4 – Notifications, Converters & Blend

In this final step, we will learn how automatically refresh the user interface when a property changes (via INotifyPropertyChange), and how to apply a converter without having to type a single line of code. We will add a boolean property that will notify the user interface when the puzzle has been solved ad we will map the original viewModel property value from bool to visibility (display or hide a textblock).

we are going to follow the next steps:

ViewModel, create a function to check if the puzzle is solved and expose it via property.
INotify Property Changed plumbing.
Adding a Textbox to notify the user… Visibility to Bool?
Adding a converter, assigning it via properties.

Video: Win8 Puzzle App - Converters

Summary

In this article we have learnt how we developers can take benefit of using Expression Blend, letting us design our user interface by dragging and dropping and having available test data in design mode. Most of the topics covered in this article can be applied to the newest Visual Studio 2012 IDE as well.

Windows 8 Metro Apps: The 8 Must-Know Tricks! Day 3

editorial@silverlightshow.net (Samidip Basu ) — Mon, 23 Jul 2012 11:59:00 GMT

This is Day # 3 in the Windows 8 development article series on common tips & tricks towards real-world Metro apps. We’ve gotten past our initial idea & layout hurdles and your first Windows 8 Metro app is slowly coming together. Time to give your Metro app some typical Windows 8 character & its own brand. Over the next several weeks, you’ll see 8 articles talk about some must-do things for Windows 8 Metro app developers. Simple & to the point, with some code examples on XAML/C# stack. Here’s the indexed list for the series:

Don't miss...

All SilverlightShow Ebooks

Day 1: Know the ecosystem; Start
Day 2: Layout, Navigation & Visual States
Day 3: Semantic Zoom
Day 4: Controls & Styling
Day 5: Search, Share & Settings Contracts
Day 6: Data Persistence & Application Life-Cycle Management
Day 7: Use of OData or Web Services
Day 8: Live Services integration

Day 3: Semantic Zoom

The Collections View:

Let’s take a good look at the Windows 8 Start screen; then at the Windows 8 Store Metro app. Also, try out some of the many RSS/news/aggregator type apps available now. Do you see a common trend? They all present a ton of information without making the end-user experience seem too busy. Just because we have a bigger form factor, does not mean that we will fill up all the available space with content. In Metro design language, white space is our friend – it provides for breathing room for a smooth UX. So, many of the Windows 8 Metro UIs which present a lot of content revert to using GridView type layouts: long list of well-spaced rectangles with inviting content & an overlay text at the bottom with some description. We usually get to pan around horizontally to discover more content. Let’s take our little demo SilverlightShow Article app as an example. This is the kind of UI you would see a lot when the data being presented is a collection of items:

This type of UI could also be generalized when presenting any type of repeated or similar controls in a Metro app. Say, you have a list of User Controls in your page, which is making for a busy UI. Or a BookShelf of items. Or a virtual Shopping Cart full of items, ready for review or checkout.

The Discoverability Problem:

As nice as it is to pan around for discoverability when content is presented as above, there is one little glitch. What if the collection of items being displayed is huge? Envision the above screen when bound to hundreds or more items in the collection. Even if we took the last 100 articles published by SilverlightShow, it would possibly take 20-25 horizontal swipes to get to the 100th article. One could argue that the collection of items could be grouped based on some parameter, as in the article topic above. But even with that, we are literally presenting a large number of items in each group, resulting in a lot of panning around to discover content. Clearly not optimal.

The Solution:

Windows 8 presents a new UX paradigm to get around the discoverability problem when presented with a large collection of items. Logically thinking would lead us to group the items into buckets, based on some criteria, so that it is a little easier to find a specific item. Now, if the data is being grouped in logical units, why not the UI? Check out the same screen of SilverlightShow articles above, this time grouped into article categories and only the high-level groups showing:

This is what Windows 8 calls Semantic Zooming. A new UX paradigm, particularly suited for touch-based PCs. How do we get from the busy layout to the zoomed-out view of grouped categories? Simple – Pinch in with two fingers on screen; Pinch out to go back to normal layout. In a PC with traditional keyboard & mouse setup, hold down CTRL key & scroll mouse wheel up/down or use CTRL plus +/- to achieve the same result. Semantic zoom is quite different from optical zoom; unlike changing magnification, it shows a different slice of grouped data.

So, it is pretty clear that Semantic Zoom uses data grouping into buckets & simply flips the view to alter the level of detail shown. This is visually delightful UX, if done right and aids big time towards discoverability of content. Zoom out to a high-level view, pick what interests you & dive back in exactly where you desire. In case you did not know & found your Windows 8 Start screen starting to get cluttered, just use Semantic Zooming to organize your Tiles. Each group can actually be named for easy of organization & personalization, as evident below:

Implementing Semantic Zoom:

So, enough descriptive talk; let’s see how we can enable Semantic Zooming in our applications. Let’s take the example of the SilverlightShow Article app and walk you through the few steps it takes to get this working.

First, the data. Your custom objects, of which you would have a collection of. Let’s define a simple class for articles:

public partial class SLShowArticle

{

    public int ArticleID { get; set; }

    public string ArticleName { get; set; }

    public string ArticleTopic { get; set; }

    public string AuthorName { get; set; }

  

    public DateTime PublishDate { get; set; }

    public string DisplayablePublishDate

    {

        get

        {

            return PublishDate.ToString("MM/dd/yyyy");

        }           

    }

}

Next is grouping. Remember we need to categorize our data in buckets for easy finding? So, let’s define our class to hold a collection of grouped articles:

public class SLShowGroupedArticles : BindableBase

{

    #region "Members"

  

    private string _SLShowArticleGroupName;

    private int _SLShowArticleGroupCount;

  

    private ObservableCollection _articleCollection;

  

    #endregion

  

    #region "Properties"

  

    public string SLShowArticleGroupName

    {

        get { return _SLShowArticleGroupName; }

        set { SetProperty(ref _SLShowArticleGroupName, value); }

    }

  

    public int SLShowArticleGroupCount

    {

        get { return _SLShowArticleGroupCount; }

        set { SetProperty(ref _SLShowArticleGroupCount, value); }

    }

  

    public ObservableCollection ArticleCollection

    {

        get { return _articleCollection; }

        set { SetProperty(ref _articleCollection, value); }

    }

  

    public string ImageURI

    {

        get

        {

            string imageUri = string.Empty;

            switch (SLShowArticleGroupName)

            {

                case "Windows 8":

                    imageUri = "/Assets/Windows8.png";

                    break;

                case "Interviews":

                    imageUri = "/Assets/Interview.png";

                    break;

                case "Windows Phone":

                    imageUri = "/Assets/WindowsPhone.png";

                    break;

                case "Silverlight":

                    imageUri = "/Assets/Silverlight.png";

                    break;

            }

  

            return imageUri;

        }

    }

  

    #endregion

  

    #region "Constructor"

  

    public SLShowGroupedArticles()

    {

        ArticleCollection = new ObservableCollection();

    }

  

    #endregion

}

Did you notice the use of BindableBase? This is nothing but an ObservableCollection wrapper that makes it even easier to mark properties for INotifyPropertyChanged event bubbling. This is just to take advantage of data-binding so that we can change the underlying collection and the UI updates itself. So, every article group is given a group name, a count for number of articles in the group, an ArticleCollection to actually hold the child articles and an ImageURI tied to the type of group. We’ll do all our data binding to the UI based on this class.

So, now that we have the containers laid out, let’s get the data. This is where you get to write your custom logic to build a collection of items. Get it from the web or read from some database – your needs dictate how the collection is hydrated. In our case, we’ll have a collection of latest articles from SilverlightShow. Next, let’s define a collection of grouped article sets to hold our categorized buckets of items and see how we actually group the articles:

// Defined for global access in app.

private ObservableCollection _articleCollection = new ObservableCollection();

private ObservableCollection _groupedArticleCollection;

  

public ObservableCollection ArticleCollection

{

    get { return _articleCollection; }

    set { _articleCollection = value; }

}

  

public ObservableCollection GroupedArticleCollection

{

    get

    {

        if (_groupedArticleCollection == null)

            _groupedArticleCollection = new ObservableCollection();

  

        // Put Articles into Grouped buckets based on Topic.

        var query = from individualArticle in ArticleCollection

                    orderby individualArticle.ArticleTopic

                    group individualArticle by individualArticle.ArticleTopic into g

                    select new SLShowGroupedArticles

                    {

                        SLShowArticleGroupName = g.Key,

                        SLShowArticleGroupCount = g.Count(),

                        ArticleCollection = new ObservableCollection(g.ToList())

                    };

  

        _groupedArticleCollection = new ObservableCollection(query.ToList());

  

        return _groupedArticleCollection;

    }

    set

    {

        _groupedArticleCollection = value;

    }

}

Simple LINQ, right? Now that we have grouped data, let’s hand it off to our UI as is. But how about the smooth interaction of zooming in & out? Thankfully, there is a Metro control that has all that built in. Enter the Semantic Zoom control! Works on GridView or ListView that is bound to grouped data. We need to do two little things – define the zoomed in & zoomed out view of the data; the control would take care of the rest. A smooth cross-fade and scale animation is used for the transition from one semantic zoom level to another. This is the default Windows touch behavior and cannot be customized. Essentially, this is what we need to fill in:

1:

2:

3:

4:

5:

6:

7:

8:

9:

10:

11:

Now, before we step into that, let's look at one other control, which doesn’t have an UI but is super helpful. That is the CollectionViewSource. A container to hold our grouped items collection. Here’s some code:



  

    

    

        x:Name="groupedItemsViewSource"

        Source="{Binding GroupedArticles}"

        IsSourceGrouped="true"

        ItemsPath="ArticleCollection"/>

  



Notice the ItemsPath .. it points to the same named collection of articles as in our SLShowGroupedArticles class. So, if this control is bound to the collection of grouped articles, it will keep track of each article group, as well as the articles inside each group. If this could be reused across pages, you could consider defining it in App.xaml for global accessibility. So, how do we feed data to this control?

protected override void OnNavigatedTo(NavigationEventArgs e)

{

    base.OnNavigatedTo(e);

  

    // Set the Data-Binding context to the Grouped Article collection.

    this.DefaultViewModel["GroupedArticles"] = ((App)Application.Current).GroupedArticleCollection;

  

    // Support zoomed-out semantics.

    var groupedArticles = groupedItemsViewSource.View.CollectionGroups;

    (Zoomer.ZoomedOutView as ListView).ItemsSource = groupedArticles;

}

As you can see, in the code behind & at run-time, we are handing off our data to the CollectionViewSource XAML control on the page and also to the zoomed-out view of the Semantic Zoom(Zoomer) . Also, notice the DefaultViewModel used in the hand-off? This little bit of magic comes as a benefit from the common LayoutAwarePage – take a peek in it to realize how every page is being wired up to have a default view model that acts as the DataContext for it’s UI. Next check the top of your XAML page, for a tiny bit of wire-up:



x:Name="pageRoot"

x:Class="SilverLightShowDemo.ArticleList"

DataContext="{Binding DefaultViewModel, RelativeSource={RelativeSource Self}}"

.....

..... />

Now, we are one step closer to using the grouped data in our Semantic Zoom control. First, let’s define the zoomed in view. Here’s some XAML:



    

        x:Name="itemGridView"

        AutomationProperties.AutomationId="ItemGridView"

        AutomationProperties.Name="Grouped Items"

        Margin="20,0,40,46"

        ItemsSource="{Binding Source={StaticResource groupedItemsViewSource}}"

        ItemTemplate="{StaticResource SLShow250x100ArticleTemplate}">

  

        

            

                "Horizontal"/>

            

        

        

            

                

                    

                        "1,0,0,6">

                            "Horizontal">

                                

                                "-" Style="{StaticResource SubheaderTextStyle}" VerticalAlignment="Top" Margin="5,0,5,0"/>

                                "{Binding SLShowArticleGroupCount}" Style="{StaticResource SubheaderTextStyle}" VerticalAlignment="Top"/>

                            

                        

                    

                

                

                    

                        "Vertical" Margin="0,0,100,0"/>

                    

                

            

        

    



Let’s highlight a few things. First, the GridView’s ItemSource is actually bound to our CollectionViewSource defined before. Group headers can be custom constructed in the GridView.GroupStyle. How about the actual binding & rendering of individual items? This is done in the ItemTemplate as usual and is defined in the StandardStyles.xaml file for consistency & reusability. Here’s what I use; notice how the template starts out as a copy of the default template, but everything is customizable:



"SLShow250x100ArticleTemplate">

    "Left" Width="250" Height="100">

        "#99FFDD" Opacity="1">

            "Vertical">

                "{Binding ArticleName}" Foreground="#6655FF" Margin="5,5,15,2" VerticalAlignment="Top" TextWrapping="Wrap"/>

                "{Binding ArticleTopic}" Foreground="Orange" Margin="5,0,15,10" VerticalAlignment="Top" FontSize="16"/>

            

        

        "Bottom" Background="{StaticResource ListViewItemOverlayBackgroundThemeBrush}" Height="30" Orientation="Horizontal">

            "{Binding AuthorName}" Foreground="{StaticResource ListViewItemOverlayForegroundThemeBrush}" Style="{StaticResource TitleTextStyle}" Margin="5,0,15,0"/>

            "{Binding DisplayablePublishDate}" Foreground="{StaticResource ListViewItemOverlaySecondaryForegroundThemeBrush}" Style="{StaticResource CaptionTextStyle}" TextWrapping="NoWrap" Margin="15,0,15,10"/>

        

    



And now, let’s define the zoomed-out view to show the group categories with overlay text:



     "Center" ItemTemplate="{StaticResource SLShow250x250ArticleTemplate}">

         

             

                 "Horizontal" VerticalAlignment="Center" Margin="30,0,0,0"/>

             

         

     



The ItemTemplate is again abstracted out to StandardStyles.xaml for reusability:



"SLShow250x250ArticleTemplate">

    "Left" Width="250" Height="250">

        "{StaticResource ListViewItemPlaceholderBackgroundThemeBrush}">

            "{Binding Group.ImageURI}" Stretch="UniformToFill" />

        

        "Bottom" Background="{StaticResource ListViewItemOverlayBackgroundThemeBrush}">

            "{Binding Group.SLShowArticleGroupName}" Foreground="{StaticResource ListViewItemOverlayForegroundThemeBrush}" Style="{StaticResource TitleTextStyle}" Height="60" Margin="15,0,15,0"/>

        

    



Voila! Your data is now grouped into buckets & semantic zoom control is data bound and ready to delight the end user.

Conclusion

That’s it for today. The crux of this article was to talk about the need for Semantic Zooming in Windows 8 Metro apps and how to implement one in your application. We ended with ways you could customize the data templates to give your semantic zooming it’s own brand for a delightful UX.

See you next time as we dive into some more controls & custom styling in Windows 8 Metro apps. Thanks for reading!

About Author

Samidip Basu (@samidip) is a technologist, gadget-lover and MSFT Mobility Solutions Lead for Sogeti USA working out of Columbus OH. With a strong developer background in Microsoft technology stack, he now spends much of his time in spreading the word to discover the full potential of Windows Phone/Windows 8 platforms & cloud-supported mobile solutions in general. He passionately helps run the Metro Developer User Group (http://themetrodeveloperusergroup.com/), labors in M3 Conf (http://m3conf.com/) organization and can be found with at-least a couple of hobbyist projects at any time. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com.

Windows 8 XAML Metro Apps with OData - Part 2

editorial@silverlightshow.net (Samidip Basu ) — Thu, 08 Dec 2011 10:57:00 GMT

So, you have heard the buzz about the brave new world of Windows 8 from MSFT’s BUILD Conference!

Don't miss...

All SilverlightShow Ebooks

May be you even attended the wonderful SilverlightShow webinar about “Getting Started with XAML Development in Windows 8” by Gill Cleeren. Ready to get your hands muddy? In this short 2-part article series, we talk about how to get started towards writing data-driven (specifically OData) Windows 8 Metro apps with XAML & C#. Here’s what we’ll cover:

Part 1 – Handling of OData from our XAML Metro App [Consumption & Updates to OData source]
Part 2 – How to make your XAML App a well-behaved Windows 8 citizen [Artwork, Snapped Views, Contracts, Application Bar etc]

As always, the demo solution, along with all code samples is available for download through the link below:

Download Source Code

Introduction

At the BUILD Conference in August 2011, Microsoft launched Windows 8 .. the next iteration of Windows. It isn’t a forked world between desktop & mobile/tablet Operating Systems; rather “One OS to rule them all..” which runs on variety of form factors with touch-based interaction being a first-class citizen. We could obviously talk a lot about Windows 8; but for the sake of the length of this post, let me refer you to 2 valuable resources:

BUILD Website @ http://www.buildwindows.com/. Great place to start would be the 5 Keynotes, followed by tons of recorded Session content.
Windows 8 Developer Home @ http://msdn.microsoft.com/en-us/windows/home. On this site is a link to download the Windows 8 Developer Preview – the latest Windows 8 bits along with Development tools. Also, as you get into serious Windows 8 Metro development, the samples from Microsoft & contributions from our fabulous community should be very valuable.

In Part 1 of this article series, we talked about how to get started with building a Windows 8 Metro App with XAML/C# and how to consume OData in our application. While we might have a functional data-driven application, we developers should strive to make our native applications feel at home in the target operating system. Windows 8 is Windows re-imagined with Metro UI, and as such, introduces some new paradigms that most Metro applications should adhere by. In this post, we talk about how to ensure our application does not produce a jarring UX for the Windows 8 user; in essence, how to make our application a well-behaved citizen in Window 8.

Prerequisites

To follow along or to try the Demo or build something similar yourself, you need the following:

Windows 8 Developer Preview running “on the metal” on some laptop/tablet.
Alternatively, you could also run Windows 8 in a VM (VirtualBox being the best fit at this time) or off a VHD.
Visual Studio 11 included as a part of Windows 8 Developer Preview. At this point, the templates to build Metro Apps aren’t available outside the Windows 8 bits.
Curiosity

The Application Bar

Remember our UI to show/manipulate our list of Team members? Here it is again:

You’ll notice that the main UI has been kept clean with minimal controls. You can obviously add much much more to utilize the real estate; but the point is, commonly used actions should be tucked away in what’s called the Application Bar at the bottom & also at the top. If you have a touch-enabled tablet or PC, you could get to the Application Bars in any Metro App by swiping a little from the top or bottom of the screen. If using Windows 8 in a traditional mouse/keyboard computer, we need to right-click in the App to bring up the Application Bars.

Please note that these Application Bars are optional – you can add an Application Bar at the bottom, top, both or none, as per your App’s needs. Commonly used App functionality tucked away in Application Bars like this just makes your App sit well with the rest of the Windows 8 OS & utilizes the UX the end-users are already used to.

Quick Trivia – Why do you think the Application Bar buttons are at either end & not at the center ?? The answer lies is some detailed research Microsoft conducted to figure out what portion of the tablet form-factor’s screen is most accessible with thumbs when holding the tablet in both hands. See the point now?

So, let’s take a look at what we had to do to build our Application Bar. The round Metro-looking icons are nothing but regular buttons with click-handlers behind them. Here’s how we add the Application Bars to our MainPage.xaml UI:

"TeamMetro.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"

mc:Ignorable="d"

d:DesignHeight="768" d:DesignWidth="1366">

  



"LayoutRoot" Background="Chocolate">

  

    // All the other content stuff ..

  

    

    "BottomAppBar" VerticalAlignment="Bottom" Height="100" Opacity=".8" IsPersistent="False" DismissMode="LightDismiss">

        

            

                "*"/>

                "Auto"/>

            

            "0" Orientation="Horizontal" HorizontalAlignment="Left" VerticalAlignment="Center">

                

                

            

            "1" Orientation="Horizontal" HorizontalAlignment="Right" VerticalAlignment="Center">

                

                

            

        

    

  

    "TopAppBar" VerticalAlignment="Top" Height="100" Opacity=".8" IsPersistent="False" DismissMode="LightDismiss">

        "20,0,0,0" VerticalAlignment="Center">

            "topBarText" Text="You can add stuff here as well .." FontSize="26" />

        

    

  

   

  



And here’s the button template defined in our App.xaml as a global resource. You could obviously have one template for all buttons and include any other styles you want re-used. If you overlook the story-board, each Application Bar is essentially an image icon inside an ellipse. Makes sense?

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

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

             x:Class="TeamMetro.App">

  

    

  

        

            

            

  

        

  

    

  



UI Modes

Windows 8, being a hybrid OS supporting multiple form factors, will have enough hardware horsepower to support true multi-tasking even in Metro UI mode.. And the additional real estate offered by tablets form factors means that people should be allowed to run multiple applications side by side. Yes, you can do that, unlike the competition

So, if are running Windows 8, try a few Metro Apps one after another .. and then swipe from left or hover mouse-cursor on left edge. What you should see pop-out is the last running application, which you can drag out onto the viewable area & also dock it. Accordingly, all Windows 8 Metro applications support three UI modes:

FullScreen – This is when the App has the full center-stage & nothing else is in the foreground.
Filled – This happens when a Metro App consumes about 75% of the screen real-estate and another App has been snapped to one side.
Snapped – This is the mode where the App in question is actually the one that has been snapped and has about 25% of screen real estate.

It is important to note that supporting these modes is very highly recommended for Metro Apps, lest you do not care about the UX when users snap your App. So, we have seen how our Demo application looks in full-screen mode; here’s how it would be if another application was snapped to the side:

And here’s how our App would look if snapped:

So, let’s see what one has to do to support this snapping behavior. First up, in our application, we need to notified as when these layout changes happen so we can take appropriate action. So, let’s subscribe, as below:

#region "Constructor"

  

public MainPage()

{

    InitializeComponent();

    

    // Subscribe to Layout changes.

    ApplicationLayout.GetForCurrentView().LayoutChanged += new TypedEventHandler(MainPage_LayoutChanged);

  

    // Other stuff.

}

  

#endregion

Did you notice the ApplicationLayout object? Yeah, we subtly tap into a WinRT namespace called using Windows.UI.ViewManagement and trust the OS to inform us about layout changes in current view.

And here’s how we respond to the change in Layout:

private void MainPage_LayoutChanged(ApplicationLayout sender, ApplicationLayoutChangedEventArgs args)

{

    if (args.Layout == ApplicationLayoutState.Filled || args.Layout == ApplicationLayoutState.FullScreen)

    {

        this.fullMode.Visibility = Windows.UI.Xaml.Visibility.Visible;

        this.snappedMode.Visibility = Windows.UI.Xaml.Visibility.Collapsed;

  

        this.BottomAppBar.Visibility = Windows.UI.Xaml.Visibility.Visible;

        this.topBarText.Text = "You can add stuff here as well ..";

    }

    else if (args.Layout == ApplicationLayoutState.Snapped)

    {

        this.fullMode.Visibility = Windows.UI.Xaml.Visibility.Collapsed;

        this.snappedMode.Visibility = Windows.UI.Xaml.Visibility.Visible;

  

        this.BottomAppBar.Visibility = Windows.UI.Xaml.Visibility.Collapsed;

        this.topBarText.Text = "Snapped Mode:";

    }

}

A few things happened .. so let’s dig in. For my demo application, I am not really limited in real estate in Filled mode .. so I treat that the same as in FullScreen mode. If however the App is snapped, we swap out controls for a more streamlined look. I chose to bind my results to 2 different ListBoxes in the UI that I toggle based on layout .. if you can have one Listbox & adjust through DataTemplates, that is totally desirable. So, here are my UI elements:

"Transparent" VerticalAlignment="Center" x:Name="fullMode">

"fullTeamList" Margin="40" ItemsSource="{Binding WCFTeam}" Foreground="Blue" Background="Transparent">

    

        

            "400,0,0,40" VerticalAlignment="Center" Orientation="Horizontal">

                "ninja.png" Height="75" Width="75"/>

                "{Binding Name}" Margin="10,0,0,0" FontSize="26" VerticalAlignment="Center"/>

                " -- aka " FontSize="22" VerticalAlignment="Center"/>

                "{Binding TwitterHandle}" Margin="10,0,0,0" FontSize="22" VerticalAlignment="Center"/>

            

        

    





  

"Transparent" VerticalAlignment="Center" Width="320" x:Name="snappedMode" Visibility="Collapsed">

    "snappedTeamList" Margin="5" ItemsSource="{Binding WCFTeam}" Foreground="Blue" Background="Chocolate">

        

            

                "10,0,0,40" VerticalAlignment="Center" Orientation="Horizontal">                            

                    "{Binding Name}" Margin="10,0,0,0" FontSize="26"/>

                

            

        

    



So, I chose to only display Team member names in Snapped mode and adjust the Application Bars accordingly. It is totally up to you & your application to decide on what information you want to display in Snapped mode .. I would guess people would go for either minimalistic views for social media type applications or dense views conveying a lot of information for sustained Snapped view usage. The point is this is totally customizable through the XAML UI .. so let’s make the most of it.

Contracts

Windows 8 introduces this concept of Contracts, which can be thought of as System Interfaces. You may also think of them as Let-Us-Not-Reinvent-The-Wheel mechanisms. If your App needs to let the user share something through Social media, why would you write interface code to post to Twitter/Facebook when another application in the system already knows how to do that? This also results in a consistent UX and less clutter in Apps. This concept of Contracts, when expanded to most common tasks, and the powerful WinRT APIs does give the developer a lot of flexibility. While there are lots of Contracts (details found on doing MSDN searches), let’s look at a couple of contracts which should highly recommended for most Metro Apps.

Sharing

The Share contracts enforces a requester-listener pattern .. one application says “I need to share this”, while another says “I know how to do that”. The application which actually implements the Share contract need to know how to receive data from other applications through the OS and share it through whatever medium the application is built to use.

For our demo application, we will not be actually implementing the Share contract; but do the much easier, frequently needed utilization of the Share pattern. What if we need to share some information about our Team members on social media .. can we get away with simply providing the data to share? Yes .. let’s see how.

First, if you need your application to share some information, please please please (3 times’ the charm ) do not add anything inside your App or the Application Bar to enable this. The key is consistency. You see, there are these shortcuts called Charms accessible to Windows 8 users. Set of quick access tasks accessible when touch-enabled user swipes from the right edge of screen or the mouse user hovers at the left lower corner. Here’s what the user sees:

So, what happens when we have a selected Team member selected & which we wish to share, and then we hit the Share Charm. Well, something like this:

What you see is the list of applications that have implemented the Share contracts .. in other words, declared to the OS that they can handle sharing of information from other Apps. Exactly, what we need! Now, let’s try TwitterRama which is a simple Twitter client for Windows 8 built by some very smart MSFT interns. This App clearly knows how to talk/post to Twitter .. so we may not need to integrate with Twitter API directly. Here’s what we get when we try to share through TwitterRama:

Did you notice that our App passed data to TwitterRama? Let’s see how we do that .. first, let us sign up for sharing by allowing the OS interfaces to request data from our application:

using Windows.ApplicationModel.DataTransfer;

  

#region "Constructor"

  

public MainPage()

{

    InitializeComponent();

  

    // Sign up to Share.

    var dataTransferManager = Windows.ApplicationModel.DataTransfer.DataTransferManager.GetForCurrentView();

    dataTransferManager.DataRequested += new TypedEventHandler(dataTransferManager_DataRequested);

}        

  

endregion

Next, when data is actually requested (this happens when the user hits the Share Charm), we get to respond to the event in our application and make up what data element to share. Here’s how:

private void dataTransferManager_DataRequested(DataTransferManager sender, DataRequestedEventArgs args)

{

    if (this.fullTeamList.SelectedItem != null)

    {

        // Set what to share.

        Team selectedMember = (Team)this.fullTeamList.SelectedItem;

        string textToShare = "Selected Team Member: " + selectedMember.TwitterHandle;

        args.Request.Data.Properties.Title = "Team Member Selection";

        args.Request.Data.SetText(textToShare);

    }

}

That’s it .. easy to share, right? You may learn more about the Share contract from this BUILD sessions HERE.

Implementing Contracts

Now, how would we go about actually implementing a Contract? Simple, most common ones are available in the “Add New Item” project wizard, as shown here:

Now, let us say our application has some interesting data/files to search on. So, if we implement the Search contract, the end user may search for our application’s data directly from Windows Search, even if our application is not running. The user gets to see our App in the list for Search & search query parameters get passed directly into our application. Here’s how:

If our application does implement the Search contract, the App Manifest file gets updated with Declarations .. others can be added from the same screen below along with implementation:

So, now when the user searches contextually within your application from Windows Search, your application gets to respond showing a custom Search results view. The basics of this are added as a SearchResultsPage.xaml when we add the Search contract, as displayed below:

And we get to respond to Search queries from the user within our view as follows:

public sealed partial class SearchResultsPage

{

    public SearchResultsPage()

    {

        InitializeComponent();

    }

  

    public void Activate(SearchActivatedEventArgs args)

    {

        var queryText = args.QueryText;

  

        // Application-specific searching logic.

        // Bind Search results to UI.

  

        // Display the results

        this.PreviousContent = Window.Current.Content;

        Window.Current.Content = this;

        Window.Current.Activate();

    }

}

Much more details about the Search contract can be found in this BUILD session recording HERE.

Artwork

Last but possibly the most important – let’s make nice looking Apps, shall we? Let’s take care of the user’s UX and they in turn, would take care of us developers, right? So, just like in Windows Phone, we developers need to put our Designer caps on, since graphics & artwork is of paramount importance. Let us follow Metro design guidelines to make our application feel right at home in Windows 8. Here’s our demo application on start screen:

Here are some things not to miss:

Inviting App logo on Start screen
Inviting & Contextual App logo in App Store, along with great screenshots & description
Branded Splash screen if using one as your App launches
Rich but minimal graphics & backgrounds in App
Maintain consistency
Enable Live Tiles with Push Notifications (topic for another post someday)
Contract implementations through consistent UI to keep inviting your users back into the App
Metro, Metro, Metro

Still waiting .. c’mon let’s get started! Let’s play a part in Windows re-imagined.

Summary

In this 2 part article, we talked about how to get started with Windows 8 Metro Apps with XAML/C# and we went on to consumption/updates of OData from a Windows 8 Metro application. In Part 1, we looked at a few techniques on how to do asynchronous programming in Windows 8 using the new C# 5.0 constructs of Async-Await. In Part 2, we talked about taking the first steps towards making your Metro Apps feel at home in the Windows 8 Operating System.

I would appreciate any comments or concerns or how things could be done better. Thanks for reading & happy coding.

Cheers SilverlightShow!

About the Author

Samidip Basu (@samidip) is a technologist & gadget-lover working as a Manager & Solutions Lead for Sogeti out of the Columbus Unit. Having worked on WP7 since CTP days, he now spends much of his time in spreading the word to discover the full potential of the Windows Phone platform & cloud-based mobile solutions in general. He passionately runs the Central Ohio Windows Phone User Group (http://cowpug.org/), labors in M3 Conf (http://m3conf.com//) organization and can be found with at-least a couple of hobbyist projects at any time. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com/.

Windows 8 XAML Metro Apps with OData - Part 1

editorial@silverlightshow.net (Samidip Basu ) — Wed, 07 Dec 2011 09:59:00 GMT

So, you have heard the buzz about the brave new world of Windows 8 from MSFT’s BUILD Conference! May be you even attended the wonderful SilverlightShow webinar about “Getting Started with XAML Development in Windows 8” by Gill Cleeren.

Don't miss...

All SilverlightShow Ebooks

Ready to get your hands muddy? In this short 2-part article series, we talk about how to get started towards writing data-driven (specifically OData) Windows 8 Metro apps with XAML & C#. Here’s what we’ll cover:

Part 1 – Handling of OData from our XAML Metro App [Consumption & Updates to OData source]
Part 2 – How to make your XAML App a well-behaved Windows 8 citizen [Artwork, Snapped Views, Contracts, Application Bar etc]

As always, the demo solution, along with all code samples is available for download through the link below:

Download Source Code

Introduction

We could obviously talk a lot about Windows 8; but for the sake of the length of this blog post, let me refer you to 2 valuable resources:

BUILD Website @ http://www.buildwindows.com/. Great place to start would be the 5 Keynotes, followed by tons of recorded Session content.
Windows 8 Developer Home @ http://msdn.microsoft.com/en-us/windows/home. On this site is a link to download the Windows 8 Developer Preview – the latest Windows 8 bits along with Development tools. Also, as you get into serious Windows 8 Metro development, the samples from Microsoft & contributions from our fabulous community should be very valuable.

Also, check out the overall technology stack in Windows 8 below: [Source: Doug Seven’s Post]

A lot has been written in the past few months about Win RT & the development stack in Windows 8 .. simple web searches should get us lots of resources. For this article & the demo app, we will stick to the managed world of XAML UI & C# code running on .NET 4.5 on top of Win RT. There might be some rough edges .. but we are all trying to learn, right?

Prerequisites

To follow along or to try the Demo or build something similar yourself, you need the following:

Windows 8 Developer Preview running “on the metal” on some laptop/tablet.
Alternatively, you could also run Windows 8 in a VM (VirtualBox being the best fit at this time) or off a VHD.
Visual Studio 11 included as a part of Windows 8 Developer Preview. At this point, the templates to build Metro Apps aren’t available outside the Windows 8 bits.
Curiosity

The Data

Let’s try building a data-driven Metro App, shall we? For Demo purposes, I’m going to use a simple relational DB called “Demo” hosted in SQL Azure with just one table called “Team”, as shown below with schema/data:

So essentially, we want to keep track of Team Members with Names & TwitterHandles. How can we get this data easily into a Windows 8 Metro App? Why off course, OData !!

You may learn more about OData from http://www.odata.org/. I already have an OData Service built on top of our DB to expose the Team table data as an OData feed for consumption. Need to expose your data as OData? – Check out Michael Crump’s great series on Producing & Consuming OData in Silverlight & Windows Phone Applications.

Also, remember my article on Connecting Azure & Windows Phone through OData ? In that article, we talked about consuming OData from the same SQL Azure DB Table & also easily performing CRUD operations against data source through OData from a Windows Phone application. So essentially, we want to take the Windows Phone Demo application handling OData & port it over to being a Windows 8 Metro App in XAML & C#. You’ll soon realize that while we have to accommodate the UI having a lot more real estate in Windows 8, a lot of the coding artifacts are very similar or can be reused in the Windows 8 world with minor changes. If you have done Windows Phone Development, you should feel right at home in doing XAML Metro Apps!

So, here’s the OData service endpoint which provides access to our Table data in AtomPub (default) or JSon format:

The Metro App

So, now that we have a data source & an OData service on top of it exposing the data, let’s see how we may consume it in a Windows 8 Metro App. Let’s fire up Visual Studio 11 & make our appropriate selections as below:

The above selection gets us into a mode for building Metro Apps with XAML UI & C# code in a managed runtime. Just like in Windows Phone, the templates provided are your friends, as they get us a long way towards achieving Metro UI look & feel in our applications. For our demo, we shall choose to start with an empty application canvas & focus on fetching data into our app.

Now, since we have an OData service, it’ll be nice to Add a Service Reference to the service in our project so that we know the backend entities & can refer to them in code. Ouch – too soon The automatic proxy building against an OData service by adding a Service Reference isn’t quite ready in the Windows 8 tooling yet! So, we revert to the old-school way of adding our service reference into the project:

DataSvcUtil.exe /uri:Your_OData_Endpoint/out:TeamModel.cs /Version:2.0 /DataServiceCollection

As you could see, we used the DataSvcUtil tool (tucked away in your .NET Framework folder) to generate a proxy class which has all the entity bindings .. now we could simply drop the generated file into our project. Our project structure looks something like this .. the “Package.appxmanifest” file quite simply houses all your App configuration:

The UI

Don’t you wish you were working with a Team where every member is a Ninja? Well, let’s say that’s the case & we shall shoot for our Metro App UI to be something simple, like this:

The above screenshot is our Demo app running in the normal full-screen immersive UI mode. Notice how it is completely Chrome-free & puts content first. Just because we can clutter the UI with all kinds of controls, doesn’t mean that we should, right?

So, in our app, there is one & only XAML page that does the above rendering, that being MainPage.xaml. Here’s the XAML that drives the UI:

"TeamMetro.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"
    
 mc:Ignorable="d"
    
 d:DesignHeight="768" d:DesignWidth="1366">
    
  
    
 
    
 "LayoutRoot" Background="Chocolate">
    
     
    
     "Transparent" VerticalAlignment="Center" x:Name="fullMode">
    
     "fullTeamList" Margin="40" ItemsSource="{Binding WCFTeam}" Foreground="Blue" Background="Transparent">
    
         
    
             
    
                 "400,0,0,40" VerticalAlignment="Center" Orientation="Horizontal">
    
                     "ninja.png" Height="75" Width="75"/>
    
                     "{Binding Name}" Margin="10,0,0,0" FontSize="26" VerticalAlignment="Center"/>
    
                     " -- aka " FontSize="22" VerticalAlignment="Center"/>
    
                     "{Binding TwitterHandle}" Margin="10,0,0,0" FontSize="22" VerticalAlignment="Center"/>
    
                 
    
             
    
         
    
     
    
     
    
  
    
    
    
  
    


So, we essentially defined a ListBox & we are expecting it to be bound to some collection of Team members with appropriate property values. Did you notice that except for a few namespaces, the XAML markup is very similar to what we are used to seeing in Windows Phone & Silverlight applications? This is what should make you feel right at home .. there are off course, some Windows 8 specific UI controls, which can cover in a subsequent blog post.

Another point to note is that the XAML markup for Windows 8 Metro apps can be borrowed to a large extent if you have existing Windows Phone or Silverlight applications. In fact, if you have a a Windows Phone app in the Marketplace and simply want to port to over to the Windows 8 App Store, there are a fixed set of guidelines to do so, as explained here. However, we might need to be wary of a plain port-over & the UX of our Metro apps, since the Windows 8 tablet form factor will have substantially more real estate, which should absolutely be utilized. In our demo app, you see a simple list of data items consuming OData; while ok for a demo (see I excuse myself ), you ideally want to provide your users with a richer experience.

Fetching the Data

Now, this will be very interesting. One of the buzz terms with Windows Phone/Silverlight and now heavily so with Windows 8 is “fast & fluid” – which essentially means that your App may be doing some expensive operation; but to the end user interacting through Touch, it should always seem responsive. Asynchronous Programming is certainly not new & Windows Phone development very much enforces that; however, it may be a little painful at times, specially if you are marshaling data between threads or writing callback after callback.

Win RT enforces that any operation that might take more than 50 ms be done asynchronously, and this off course, extends to every web request our app might make. So, we are looking to fetch the OData feed asynchronously without blocking the UI thread.

Now, C# 5.0 running on .NET 4.5 framework tries to make it easy for us developers to do asynchronous programming through Async-Await patterns, so that we can get around not writing callback after callback or have to deal with thread marshaling. This however is a wider topic than this post – so please allow me to point you to some resources that should help understand this better:

I was intrigued about Asynchrony and wrote a lengthy post; if interested, you’ll find it HERE. So, let’s look at a few ways we can fetch data:

The Pure HTTP Way

In this approach, we make a basic HTTP Get call to our OData service endpoint & fetch data as Atom. This is simple, but we would have to manually parse the response to pluck out the data contents for binding to UI. Here’s some sample code .. watch the use of async-await to achieve asynchrony:

private async void LoadTeamThruXML()
    
{
    
    // Get Atom over HTTP.
    
    var client = new HttpClient();
    
    Uri teamDataURI = new Uri("Your_OData_Endpoint");
    
  
    
    try
    
    {
    
        HttpResponseMessage response = await client.GetAsync(teamDataURI);
    
  
    
        string xmlResponse = response.Content.ReadAsString();
    
        XDocument xDoc = XDocument.Parse(xmlResponse);
    
  
    
        // Do appropriate parsing.
    
        // LINQ to XML.
    
        IEnumerable teamCollection = from teamMember in xDoc.Descendants("Entry")
    
                                           select new Team
    
                                           {
    
                                               Name = teamMember.Element("Name").ToString(),
    
                                               TwitterHandle = teamMember.Element("TwitterHandle").ToString()
    
                                           };
    
  
    
        // Bind to UI.
    
    }
    
    catch (Exception ex)
    
    {
    
        // Oopsie
    
    }
    
}

The Threaded Way

One important aspect about Asynchrony is that it does not always mean multi-threading, as in parallelism. All the goodness of the Task Parallel Library is now built in and as we await on a Task, the underlying implementation may or may not spin up a new thread based on computing cycles needed. The point is, you should not have to care as a developer. However, if using Task.Factory, you are essentially carrying out synchronous operations on a worker thread without blocking the UI. So, here’s another way to fetch data .. notice how we can return a strongly-typed collection of Team members:

private async void LoadTeamThruOData()
    
{
    
    var client = new Demo(new Uri("Your_OData_Endpoint"));
    
    
    
    var results = await Task>.Factory.StartNew(() => FetchOData());
    
  
    
    // This fires only after we have a response back. 
    
    this.ParseAndBindData(results);
    
}
    
  
    
private IEnumerable FetchOData()
    
{
    
    Demo client = new Demo(new Uri("Your_OData_Endpoint"));
    
    return client.Teams.Execute();
    
}

Wrapped APM Way

Asynchronous Programming Model (APM) is the traditional way of doing asynchrony through BeginXX/EndXX patterns; but this lead us to write a lot of callbacks. In the new world, APM calls can be wrapped inside an Async-Await pattern to make asynchronous requests. Let’s look at some code:

private async void LoadTeamThruOData()
    
{
    
    var client = new Demo(new Uri("Your_OData_Endpoint"));
    
   
    
    var results = await Task>.Factory.FromAsync(client.Teams.BeginExecute(AnotherEndContinuation, client), ContinuationDelegate);
    
  
    
    // This fires only after we have a response back. 
    
    this.ParseAndBindData(results);
    
}
    
  
    
Func> ContinuationDelegate = EndContinuation;
    
private static IEnumerable EndContinuation(IAsyncResult result)
    
{
    
    Demo client = (Demo)result.AsyncState;            
    
    return client.Teams.EndExecute(result);
    
}
    
  
    
private static void AnotherEndContinuation(IAsyncResult result)
    
{
    
   // Do nothing here.
    
}

Now, the above code might look a little clunky, but the wrapping of the APM methods can be done through an Extension method to make reuse easier. Eventually with future updates, if we have a method Foo in our custom WCF Service, proxy integration should generate three method endpoints – BeginFoo, EndFoo & FooAsync. It is the last that we shall use comfortably with Async-Await patterns.

Data Updates?

So, by now we know how to fetch OData into a Windows 8 Metro app using XAML/C# and bind the results to a simple list. But what if we wanted to perform updates against the data source? That is absolutely possible since we are dealing with an OData service here. Unless blocked at the service side, OData will support full CRUD operations through the DataServiceContext & DataServiceCollection classes.

Now, let’s think about the UI for second. Just because we can put buttons & controls for data updates all over, doesn’t mean that we should. Common tasks should be presented in a minimalist fashion & accessible when needed. Accordingly, we revert to using the Windows 8 Metro Application Bar to add some metro buttons for allowing data manipulation. Let’s shoot for a UI like below .. we shall talk more about the Application Bar in the next article:

So, what happens when the user hits the Application Bar buttons? Simple – just like in Windows Phone, you can have event handlers assigned to each. Let’s see how we may delete a record & have it reflected in the OData data source, that is our Table data in SQL Azure. Here’s some code:

private void DeleteButton_Click(object sender, RoutedEventArgs e)
    
{
    
    if (this.fullTeamList.SelectedItem != null)
    
    {
    
        Team selectedTeamMember = (Team)this.fullTeamList.SelectedItem;
    
                        
    
        // LINQ to Context.
    
        var client = new Demo(new Uri("Your_OData_Endpoint"));
    
        var teamMemberToDelete = (from TeamMember in client.Teams
    
                                  where TeamMember.Name == selectedTeamMember.Name
    
                                  select TeamMember).First();
    
  
    
        // Delete backend entity.
    
        client.DeleteObject(teamMemberToDelete);
    
        client.BeginSaveChanges(new AsyncCallback(SaveDoneCB), client);               
    
    }
    
}
    
  
    
private void SaveDoneCB(IAsyncResult asyncResult)
    
{
    
    // Any error handling.
    
}

What about adding/editing records? Exactly the same way. Off of our “client” object above (which is in essence the DataServiceContext), you’ll see methods like AddObject & UpdateObject to insert/manipulate table records and then you simply need to call SaveChanges asynchronously to update the backend DB. You’ll see some sample code in the downloadable solution; but why not give it a shot yourself? You can get a lot of hints about how to perform CRUD operations against OData from a Windows Phone application from mine & Michael Crump’s articles HERE & HERE. So, go ahead & throw in a fresh XAML page to capture inserts/edits & fire away .

Summary

In this article, we talked about how to get started with Windows 8 Metro Apps with XAML/C# and we went on to consumption/updates of OData from a Windows 8 Metro application. We looked at a few techniques on how to do asynchronous programming in Windows 8 using the new C# 5.0 constructs of Async-Await. In the next part of article, we shall talk about taking the first steps towards making your Metro Apps feel at home in the Windows 8 Operating System.

I would appreciate any comments or concerns or how things could be done better. Thanks for reading & happy coding.

Cheers SilverlightShow!

About the Author

10 Laps around Silverlight 5 (Part 8 of 10)

editorial@silverlightshow.net (Michael Crump ) — Tue, 29 Nov 2011 12:18:00 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.

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

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 [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.

OData caching in Windows Phone

editorial@silverlightshow.net (Samidip Basu ) — Wed, 23 Nov 2011 03:53:00 GMT

OData seems to have a lot of promise in simplifying data access across multiple platforms by using fundamental technologies of HTTP and Atom/JSon. Using an OData source for data consumption/updates in your Windows Phone application?

Don't miss...

All SilverlightShow Ebooks

In this short article, we take a quick look at a data caching strategy in our Windows Phone applications while using an OData data source. While we talk about a Windows Phone solution in particular, these concepts are perfectly applicable when using OData on other mobile platforms.

As always, the demo solution, along with all code samples is available for download through the link below:

Download Source Code

Introduction

The Open Data Protocol (OData) is an HTTP-based protocol for querying and updating a data source. Based on the platform or type of application we are building, we have the option of using either Atom or JSon as our feed protocol of choice and then utilize support for filtering, sorting & paging in our application. Want to learn more? http://www.odata.org/is a great place to start. OData has now built up a nice ecosystem around it’s support, with proxy-building libraries in a variety of platforms; and it obviously lends itself very nicely to usage from mobile applications.

Also, just about any data source that .NET runtime can connect to, can be exposed as an OData feed. It is essentially a two-step process: First – put Entity Framework type Object Relational Mapping (ORM) on top of our data source, in particular the ADO.NET Entity Data Model; and Second – put a WCF Data Service on top of the data entities to expose a read-only/updateable feed for the data. Want to try it yourself? Michael Crump’s “Producing & Consuming OData..” series here is a great start. Want to leverage OData as you augment your mobile application with cloud support? My last two articles here & here should be decent starting points.

The Demo

One of the best ways to learn more about OData is to start playing with a live OData service. And what better example than that of Netfllix .. we all love movies, right? Now, Netflix worked with MSFT to expose their entire Movie/Shows catalog as a live OData feed, one that you can hit through the URL below:

http://odata.netflix.com/v2/Catalog/

Once we look up the catalog, we can see all the supported HTTP endpoints to get various information. Head over to the official Netlfix documentation here to learn more about the supported Metadata, filters & formats. For our demo purpose, we shall choose to do a very simple lookup against the Netflix OData catalog .. just to get a list of Genres. Take a guess how many Genres Netflix knows? – Close to 400 !!

So, we make a simple HTTP Get request through our browser to the following URI to get a list of Genres, in default Atom format. Since this is not huge amount of data, there is no continuation token & we get the whole catalog of Genres back in one request:

http://odata.netflix.com/v2/Catalog/Genres

So, let’s build a simple Windows Phone application which consumes the Netflix OData feed & pulls up the list of Genres programmatically. We begin with the default template of a Windows Phone application with a portrait page. One of the first things we do is to add a reference to the root of the Netflix OData service, so that the proxies are built & we can refer to the Netflix entities in our code. Here’s how & the resulting project structure:

Next, let’s add some code to our MainPage.xaml’s code-behind file so we can load the list of Netflix Genres:

using NetflixODataService; 

  

DataServiceCollection Genres { get; set; }

DataServiceContext context = new DataServiceContext(new Uri("http://odata.netflix.com/v2/Catalog/"));

  

public MainPage()

{

  InitializeComponent();

  this.LoadAndStoreGenres();

}

  

  

public void LoadAndStoreGenres()

{

    // Instantiates our collection.

    this.Genres = new DataServiceCollection(context);

  

    // Base HTTP endpoint or custom query goes here.

    Uri uriQuery = new Uri("/Genres()", UriKind.Relative);

  

    // Asynchronously load the result of the query.

    this.Genres.LoadAsync(uriQuery);

  

    this.Genres.LoadCompleted += (sender, args) =>

    {

        if (args.Error == null)

        {

            // Databind.

            this.genreList.ItemsSource = this.Genres;

    };

}

Now, let’s dig in, since a few interesting things happened. First, we added the reference to the Netflix Service namespace and utilized a special collection class called DataServiceCollection. A DataServiceCollection “represents a dynamic entity collection that provides notifications when items get added, removed, or when the list is refreshed.” So essentially, this has the features of an ObservableCollection built-in & the INotifyPropertyChanged interface makes sure that any UI bound to such a collection is informed of changes on bound property values in the collection. In addition, the DataServiceCollection has been optimized to be the representation of an OData HTTP endpoint collection and supports features like query collections, continuation tokens & tracking changes in the collection. Find out more about the DataServiceCollection here.

Also, we used a DataServiceContext which pointed to the root of the Netflix OData feed as the base context, beyond which we can do our queries/filtering/sorting. Also, once we knew exactly the query to request (in our simple demo – “/Genres()”), we used a LoadAsync() method off of our DataServiceCollection. This, behind the scenes, wraps up our query into an HTTP request to the OData service and does so without blocking the all-important UI thread. When the remote server responds, a LoadCompleted event triggers to allow us to handle the response & bind to our UI, thus automatically marshaling data back to the UI thread.

Now, how do we display the list of Genres we are fetching? Through a very simple XAML UI as below:

"15,0,15,10" x:Name="genreList">

    

        

            "0,0,0,17" Width="432">

                "{Binding Name}" TextWrapping="Wrap" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

            

        

    



So, we simply want to display a list of Genres as “Name” as we get back from Netflix. With just the little code above added to our MainPage.xaml page, we can have our application fetch & display Genres as follows. Please note that is for demo only .. so no fancy progress bars, which you might want to add to indicate to the user that some web request is being served.

The Problem

Now, consider this .. let’s say the source of the OData feed does not change very often or you want this demo Netflix application to work in offline mode, after the data has been fetched at least once. Both of these indicate that we should figure out a way to not make the HTTP Get request to the OData source every time! So, the first time we fetch the data, we have to cache it in the application’s Isolated Storage, to be read on subsequence application runs until something triggers a refresh of the data feed.

So, common sense suggests that we try to put the whole Genres DataServiceCollection in Isolated Storage & rehydrate our entity objects on successive needs for the data. Here’s the problem though – you will get strange error if you simply try to put the DataServiceCollection in Isolated Storage. Something along the lines of :

"An item could not be added to the collection. When items in a DataServiceCollection are tracked by the DataServiceContext, new items cannot be added before items have been loaded into the collection."

So, what’s happening? The problem is that DataServiceCollection was not designed for serialization/deserialization. When we use the DataServiceCollection, the collection is responsible for tracking all the objects that it contains. Because the collection also has a reference to the DataServiceContext, it notifies the DataServiceContext of all changes to the collection and the entities in the collection. This means that we can just add,remove and update objects in the collection and when we want to persist the changes, we call SaveChanges() on the DataServiceContext. This is the crux of the problem, since Isolated Storage requires the entities to be serialized, which triggers the object being updated events. If we create a new DataServiceCollection() (constructor without parameters), it creates the collection in so called auto-tracking mode. That is the collection has tracking turned on, and in order for tracking to work correctly, we must call Load on it (this will add items and connect the collection to the right DataServiceContext which will track the items). This behavior is by design.

Oops! So, is there no way to store away a DataServiceCollection for re-use? Thankfully – Yes!

The Solution

A new class called DataServiceState has been added to keep track of the state of a DataServiceCollection & it’s backend DataServiceContext. The DataServiceState simply knows how to serialize/deserialize a typed DataServiceContext with one or more DataServiceCollection objects. Essentially, during serialization through an explicit static Serialize() method, the whole DataServiceCollection is flattened into a string that is the XML serialized representation of the stored objects, along with support for nested collections.

Shall we see this in action? In our case, we have a DataServiceCollection that we would serialize & store in Isolated Storage for future use. Also, we would add a boolean flag to indicate whether we have cached data vs when we would have to refetch. So, in our case, the moment we receive a response to our query to fetch Genres, we would serialize the collection into Isolated Storage. You may switch around where you do this for cleaner code .. but here’s the demo code that shows serialization:

public partial class MainPage : PhoneApplicationPage

{

    #region "Data Members"

  

    DataServiceCollection Genres { get; set; }

    DataServiceContext context = new DataServiceContext(new Uri("http://odata.netflix.com/v2/Catalog/"));

  

    public bool AppHasFeed { get; set; }

  

    #endregion

  

    #region "Constructor"

  

    public MainPage()

    {

        InitializeComponent();

  

        if (IsolatedStorageSettings.ApplicationSettings.Contains("AppHasFeed"))

        {

            AppHasFeed = (bool)IsolatedStorageSettings.ApplicationSettings["AppHasFeed"];

        }

  

        if (!AppHasFeed)

        {

            this.LoadAndStoreGenres();

        }

        else

        {

            this.HydrateFromIso();

        }

    }

  

    #endregion

  

    #region "Methods"

  

    public void LoadAndStoreGenres()

    {

        // Instantiates our collection.

        this.Genres = new DataServiceCollection(context);

  

        // Base HTTP endpoint or custom query goes here.

        Uri uriQuery = new Uri("/Genres()", UriKind.Relative);

  

        // Asynchronously load the result of the query.

        this.Genres.LoadAsync(uriQuery);

  

        this.Genres.LoadCompleted += (sender, args) =>

        {

            if (args.Error == null)

            {

                // Databind.

                this.genreList.ItemsSource = this.Genres;

  

                // Set & store the flag indicating we have fetched data once.

                AppHasFeed = true;

  

                if (IsolatedStorageSettings.ApplicationSettings.Contains("AppHasFeed"))

                    IsolatedStorageSettings.ApplicationSettings.Remove("AppHasFeed");                        

                

                IsolatedStorageSettings.ApplicationSettings.Add("AppHasFeed", AppHasFeed);

                

  

                // Serialize our collection.

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

                GenresCollection["Genres"] = this.Genres;

                string GenresDataFeed = DataServiceState.Serialize(context, GenresCollection);

  

                // Store flattened data in Isolated Storage.

                if (IsolatedStorageSettings.ApplicationSettings.Contains("Genres"))

                    IsolatedStorageSettings.ApplicationSettings.Remove("Genres");

  

                IsolatedStorageSettings.ApplicationSettings.Add("Genres", GenresDataFeed);                    

            }

        };

    }

    #endregion

}

So, our boolean flag “AppHasFeed” indicates whether we have fetched the Genre collection at least once .. in your actual use, you may choose to implement an explicit way to refresh the data feed. Back in our case, if we don’t have any data, we make the one-time asynchronous request to fetch OData as Atom. Next, we utilize the DataServiceState class to serialize the entire DataServiceCollection of Genres with respect to its DataServiceContext and store the resulting string XML into Isolated Storage as a key-value pair. Voila, now we are storing state and caching OData inside our application!

One thing to note is that in our demo case, we simply put the whole DataServiceCollection in Isolated Storage for future use. If you do not want that level of persistence & are dealing with temporary data, there is a way out as well. The same techniques of serialization of a DataServiceCollection apply perfectly well when storing the resulting string in PhoneApplicationService.Current.State, in case you simply want the data to be available in case your application is tombstoned & you want you data entities to be rehydrated without making a fresh HTTP request.

So, in the code above, we saw how to serialize & store a DataServiceCollection in Isolated Storage. But we also need the same data to be deserialized & re-hydrating our data entities if we are not making another fresh request. So, in our case, if the AppHasFeed flag indicates that we have fetched data already, we simply use the following deserialization technique:

public void HydrateFromIso()

{

    if (IsolatedStorageSettings.ApplicationSettings.Contains("Genres"))

    {

        // Fetch flattened data & rehydrate object model.

        string GenresDataFeed = IsolatedStorageSettings.ApplicationSettings["Genres"].ToString();

        DataServiceState state = DataServiceState.Deserialize(GenresDataFeed);

        Dictionary<string, object> collections = state.RootCollections;

  

        // Hydrate our DataServiceCollection.

        this.Genres = collections["Genres"] as DataServiceCollection;

  

        // Databind.

        this.genreList.ItemsSource = this.Genres;

    }

}

So essentially, we deserialize the string XML from Isolated Storage through the static Deserialize() method to re-instantiate a DataServiceState. Once done, the RootCollections property holds the individual DataServiceCollection entities, which we can use to re-hydrate our data model. Easy? Again, where I do this in code is questionable, but this is for the sake of keeping the demo simple. You should be able to take the concept & add code to your application as & when needed to cache/uncache OData collections.

So, after you add the above code, go ahead & run the Netflix Demo again, but this time after turning off all network connectivity for emulator or Windows Phone device. You’ll see that we have been able to serialize/deserialize the fetched OData collection and now our applications works perfectly fine in offline mode, on successive attempts!

Summary

In this article, we talked about consumption of OData from a Windows Phone application and the subsequent serialization/deserialization of data collections. These techniques should help in building lean applications which are careful about misuse of the user’s bandwidth in fetching the same data over & over again. So, what are you waiting for? Expose just about any data store as an OData feed, put appropriate security on the data & consume it responsibly from multiple mobile platforms!

I would appreciate any comments or concerns or how things can be done better. Thanks for reading & happy coding.

Cheers SilverlightShow!

About the Author

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.

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.

10 Laps around Silverlight 5 (Part 6 of 10)

editorial@silverlightshow.net (Michael Crump ) — Tue, 15 Nov 2011 08:15: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 6 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.

More resources...

All SilverlightShow Ebooks

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 spend the entire “lap” discussing improvements in text in Silverlight 5.
We discussed Linked and Multi-Column Text and where it might be useful in your next Silverlight application.
We also looked at character spacing, open-type font. pixel snapped text and TextOptions.

In this article, I am going to discuss several new operating system integration features in Silverlight 5 including: P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust. 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 [This post] - 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 - In-Browser HTML, PostScript and Tasks for TPL.

P/Invoke or Platform Invocation

Before we dive into an example. Let’s first answer the question, What is it? Platform Invocation Services, commonly referred to as P/Invoke, is a feature of Common Language Infrastructure implementations, like Microsoft's Common Language Runtime, that enables managed code to call native code.

*Reference to Wiki

This feature is new to Silverlight 5 and we will take a look at how to use it in your own applications.

In order to create a new P/Invoke application in Silverlight 5, we will need to enable “Require elevated trust” in Silverlight 5. We can also use the functionality in-browser or out-of-browser. Let’s begin.

Fire up a new Silverlight 5 project and right click on our project and select Properties. Put a check in “Enable running application out of the browser” as shown below.

After you put a check in “Enable running application out of the browser”, go ahead and click the button. Now put a check in “Require elevated trust when running outside the browser”.

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

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

    <Button Height="23" HorizontalAlignment="Left" Margin="169,132,0,0" VerticalAlignment="Top" Width="75" x:Name="btnclick" Content="click" Click="click_Click" />

Grid>

This simply puts a button on our page that when the user clicks it the pc will make a beep sound.

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

using System;

using System.Runtime.InteropServices;

  

namespace PInvoke

{

    public class PlatformInvokeTest

    {   

        [DllImport("kernel32.dll")]

        public static extern bool Beep(int frequency, int duration);

 

     

        public static void PlaySound()

        {

            Random random = new Random();

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

            {

                Beep(random.Next(10000), 100);

            }

        }

  

    }

}

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

private void click_Click(object sender, RoutedEventArgs e)

{

    PlatformInvokeTest.PlaySound();

}

If we run the application now, we will hear our PC beep many times. There are many other thing you can do with P/Invoke such as Detecting if the user inserted a USK Key into their computer, opening the run dialog box and much much more! Very cool stuff!

Multiple Window Support

With Silverlight 5, we now have the ability to spawn multiple windows from an Out-of-Browser application with elevated trust with just a couple of lines of code.

A few things to note about Multiple Window Support though:

If the main window closes, then all spawned windows close.
You need to be running your application “Out-of-Browser” as well as in Elevated Trust mode.

If you followed the P/Invoke guide before then you will need to do the same thing for Multiple Window Support. That is, make this an out-of-browser application and add Elevated Trust.

After that is complete then go ahead and double click on your MainPage.xaml.cs file and add the following code:

public MainPage()

{

    InitializeComponent();

    Loaded += new RoutedEventHandler(MainPage_Loaded);

}

  

void MainPage_Loaded(object sender, RoutedEventArgs e)

{

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

    {

        new Window()

           {

               Height = 400,

               Width = 600,

               Top = 24,

               Left = 30,

               Title = "Silverlight Show New Window",

               Content = new Button() { Content = "Can be any Framework Element" },

               Visibility = Visibility.Visible

           };

    }

   

}

This application will spawn 5 windows when you run it. Below is a sample screenshot from the application with 2 additional windows showing. The other windows are closed for demonstration purposes.

Unrestricted File System Access in Full Trust

Have you ever wanted to write a file anywhere on a users computer in earlier versions of Silverlight but found out that you couldn’t? Well in Silverlight 5 you can.

Just like the earlier samples make this an out-of-browser application and add Elevated Trust. (See the P/Invoke demo at the beginning of this article for a quick-how to.)

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

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

    <Button Height="23" HorizontalAlignment="Left" Margin="169,132,0,0" VerticalAlignment="Top" Width="75" x:Name="btnclick" Content="click" Click="click_Click" />

Grid>

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

private void click_Click(object sender, RoutedEventArgs e)

{

    // Create a Directory on the Root of C

    var tempDirectory = @"c:\michaelcrump";

    if (!Directory.Exists(tempDirectory))

    {

        Directory.CreateDirectory(tempDirectory);

    }

  

    // Give it a FileName

    var filename = string.Format("slshowrocks.txt");

    var fullPath = System.IO.Path.Combine(tempDirectory, filename);

  

    // Write Something in the File!

    using (FileStream fs = File.Create(fullPath))

    using (StreamWriter sr = new StreamWriter(fs, Encoding.UTF8))

    {

        sr.WriteLine("Hello World");

    }

}

This will create a directory on our C:\ called michaelcrump. Then it will create a file named “slshowrocks.txt” and give it some content. If you run the application and click on the button then you should have the new folder/file created on your root hard disk.

If Visual Studio 2010 is complaining of any missing namespaces then just make sure you add the following:

using System.IO;

using System.Text;

Very easy to accomplish and it is not limited to writing files. You can also read files from anywhere on the hard disk! In the next part of this series, we will look at letting the user specify the location of the saved file.

Conclusion

At this point, we have seen how you would use P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust in your Silverlight 5 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 more new operating system features including : Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness. 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 5 of 10)

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

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 5 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 discussed the new media features included with Silverlight 5.
We looked at using Low-Latency Sound with XNA SoundEffect and SoundEffectInstance classes.
We also learned how to use remote control and media command (keys) support.

In this article, I am going to discuss the new text improvements in Silverlight 5 including: Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions. 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 [This post] - 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 - In-Browser HTML, PostScript and Tasks for TPL.

Linked and Multi-Column Text

We will use an example that I’ve demonstrated in the past that many have found helpful. The Linked and Multi-Column Text feature enables the text of a RichTextBlock control to overflow from one into the next. Multiple RichTextBlockOverflows can be chained together to spread text across a layout. Let’s go ahead and take a look at a screenshot of a RichTextBlock with a RichTextBlockOverflow working together.

As you can see from this screenshot, we had a RichTextBlock in the upper left and its content overflowed onto the RichTextBlockOverFlow #1, #2 and #3. You can think of this as something that is similar to a newspaper article. As the browser expands or contracts the content fills the available area.

Let’s check out the code that made it happen:

<Grid x:Name="LayoutRoot"

        Background="White">

      <Grid.ColumnDefinitions>

          <ColumnDefinition Width="0.415*" />

          <ColumnDefinition Width="0.168*" />

          <ColumnDefinition Width="0.418*" />

      Grid.ColumnDefinitions>

      <Grid.RowDefinitions>

          <RowDefinition Height="0.373*" />

          <RowDefinition Height="0.143*" />

          <RowDefinition Height="0.483*" />

      Grid.RowDefinitions>

      <Rectangle Fill="Blue"

                 Margin="0,1"

                 Stroke="Black"

                 Grid.Row="1"

                 Grid.ColumnSpan="3" />

      <Rectangle Fill="Blue"

                 Margin="-1,0,1,0"

                 Stroke="Black"

                 Grid.RowSpan="3"

                 Grid.Column="1" />

      <RichTextBlock x:Name="rtb1"

                   Margin="0,0,5,3"                     

                   OverflowContentTarget="{Binding ElementName=rtb2}"

                     

                 >

          <Paragraph>

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

  

          Paragraph>

      RichTextBlock>

      <RichTextBlockOverflow x:Name="rtb2"

                           Grid.Row="2"

                           OverflowContentTarget="{Binding ElementName=rtb3}"

                           

                           />

      <RichTextBlockOverflow x:Name="rtb3"

                           Grid.Column="2"

                           OverflowContentTarget="{Binding ElementName=rtb4}"

                           />

  

      <RichTextBlockOverflow x:Name="rtb4"

                           Grid.Column="2"

                           Grid.Row="2"

                           />

  

  

  Grid>

The key thing to remember here is that a RichTextBlock contains OverflowContentTarget which will allow you to bind to a special control called RichTextBlockOverflow.

NOTE: Post-beta, Microsoft changed this to use the non-editable RichTextBlock instead of RichTextBox. So a word of warning, many post-beta demos of this functionality on the web will no longer work. Good thing you are reading this guide, right? =)

Character Spacing

The TextBox and TextBlock controls provides a way to control the spacing of letters inside the text very easily. Let’s go ahead and take a look at a screenshot of the various character spacing inside of a TextBlock.

Let’s look at the code:

<Grid x:Name="LayoutRoot" >

      <StackPanel>

          <TextBlock CharacterSpacing="1000" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

          <TextBlock CharacterSpacing="500" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

          <TextBlock CharacterSpacing="250" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

          <TextBlock CharacterSpacing="100" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

          <TextBlock CharacterSpacing="-100" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

      StackPanel>

  Grid>

As you can see, we just set the CharacterSpacing property of the TextBlock control. Please note that you may use a negative number to “squish” text together.

Open-Type Font

Silverlight 5 provides many new options for the Typography class inside of a TextBlock. They have so many improvements that the best way to see everything is to explore the class. Let’s look at two new features:

ContextualAlternates - Gets or sets a value that determines whether custom glyph forms can be used based upon the context of the text being rendered.
StylisticSets - Gets or sets a value that indicates whether a stylistic set of a font form is enabled. (20 StylisticSets are available)

Let’s look at a sample that uses ContextualAlternates and StylisticSets.

The code looks like the following:

<TextBlock FontSize="80"

           FontFamily="Gabriola" 

           Text="Michael Crump"                   

           Typography.ContextualAlternates="True"

           Typography.StylisticSet5="True" />

Pixel Snapped Text and TextOptions

Silverlight 5 provides many new options for the TextOptions property inside of a TextBlock.

TextFormattingMode – Gets the TextFormattingMode for the element
TextHintingMode – Gets or sets a value that indicates whether text rendering is optimized for readability or animation.
TextRenderingMode - Sets the TextRenderingMode for the element. 4 options are available: Aliased, Auto, ClearType and Grayscale.

Let’s look at a sample that uses all of them together (Display, Fixed and Aliased). It may be hard to see in this demo, so try this one in your own application.

The code looks like the following:

<TextBlock FontSize="30" Text="The quick brown fox jumps over the lazy dog"

               TextOptions.TextFormattingMode="Display"

               TextOptions.TextHintingMode="Fixed"

               TextOptions.TextRenderingMode="Aliased" />

Conclusion

At this point, we have seen how you would use Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions in your Silverlight 5 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 the new operating system integrations including : P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust. 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 4 of 10)

editorial@silverlightshow.net (Michael Crump ) — Tue, 01 Nov 2011 17:58:00 GMT

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 4 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:

To recap what we learned in the previous section:

We briefly discussed what XNA is.
We looked at the templates available for new XNA Silverlight 5 projects.
We dissected the 3D XNA Template to learn more about it’s makeup.
Pointed out where other sample projects for XNA were located on your hard disk.

In this article, I am going to discuss media features such as low-latency sound using features right out of XNA. We will also discuss Remote Control and Media Command (Keys) support using Silverlight 5. 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 [This Post] - 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 - In-Browser HTML, PostScript and Tasks for TPL.

Let’s Begin with Low-Latency Sound using XNA SoundEffect

A new addition to Silverlight 5 is the ability to play low-latency sounds using the XNA SoundEffect class. This is very useful for kiosk or even games that need to play a certain sound over and over. In Silverlight 5, this is much easier than before (where people used various MediaElement hacks). You can now simply borrow the SoundEffect / SoundEffectInstance class from XNA.

Start with a new Silverlight 5 Project

Launch Visual Studio 2010 and select File –> New Project. Then select Silverlight –> Silverlight Application –> Give it a name and hit OK.

On the New Silverlight Application Screen, you will see under “Options” that you may select which version of Silverlight that you want to use. We will select Silverlight 5 for this option. If you don’t see Silverlight 5 as an option then follow the guide here.

The first thing you are going to want to do is to find a .wav file on the net that is PCM-encoded. They are very easy to find with a quick Google search. I am not going to include one for copyright reasons.

Now, right-click your Silverlight 5 project and select “Add”, then “Existing Item.” You can also easily access this screen by hitting “Shift-Alt-A” together. Navigate to wherever you downloaded the .wav file and select the file.

At this point, make sure the .wav file has a build action set to “Content”, as shown below.

Once this is complete, we will need to make a minor adjustment to our MainPage.xaml file to include a button to play the file for this demo.

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

       <Button Content="Button" Height="23" HorizontalAlignment="Left" Margin="0,277,0,0" Name="btnPlaySound" VerticalAlignment="Top" Width="75" Click="btnPlaySound_Click" />

Grid>

The only thing that we added to our MainPage.xaml file was a button inside of the Grid that has an event handler when the user clicks the button.

We can navigate over to our MainPage.xaml.cs file and add the following code snippet:

private void btnPlaySound_Click(object sender, RoutedEventArgs e)

{

    var soundStream =

            Application.GetResourceStream(

                new Uri("stereol.wav", UriKind.RelativeOrAbsolute));

  

    var effect = SoundEffect.FromStream(soundStream.Stream);

  

    SoundEffectInstance engineInstance = effect.CreateInstance();

  

    engineInstance.IsLooped = true;

    engineInstance.Pitch = -1.0f;

    engineInstance.Volume = 0.75f;

  

    engineInstance.Play();

}

In this code snippet, we are using several new features. Let’s examine the code snippet line by line:

Lines 3-5 creates our resource stream from the wav file that added earlier.
Lines 7-9 is initializing the SoundEffectInstance class that is going to perform special effects for the .wav file.
Lines 11-13 is creating a looped wav file that sets the pitch and the volume.
Lines 15 simply plays the files.

Don’t forget to add the proper namespace and reference to your project.

 1: using Microsoft.Xna.Framework.Audio;

If you load the application now, you will hear your .wav file being played over and over again. The pitch and volume has also been adjusted. Easy enough!

Let’s move onto Remote Control and media keys support.

Remote Control and Media Command (Keys) Support

One of the new improvements in Silverlight 5 is the ability to support Remote Control and Media Commands from various hardware manufactures. Below is a sample keyboard and remote control that has buttons for features such as (fast forward, stop, play, rewind, etc). Now we are able to make use of those buttons in Silverlight 5 with a few lines of code.

Let’s get started.

Launch Visual Studio 2010 and select File –> New Project. Then select Silverlight –> Silverlight Application –> Give it a name and hit OK.

The first thing you are going to want to do is to find a .wmv file that you can use for this application. I decided to use the wildlife.wmv file available on every Windows 7 PC. Just like before, I am not going to include it due to copyright reasons.

Now, right-click your Silverlight 5 project and select “Add”, then “Existing Item.” You can also easily access this screen by hitting “Shift-Alt-A” together. Navigate to wherever you downloaded the .wmv file and select the file.

At this point, make sure the .wmv file has a build action set to “Content”, as shown below.

Once this is complete, we will need to make a few minor adjustment to our MainPage.xaml file to play a video.

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

       <MediaElement x:Name="videoPlayer"

                 Source="/Wildlife.wmv" />

       

       <TextBlock x:Name="txtMediaKey" Foreground="Red" HorizontalAlignment="Right" VerticalAlignment="Bottom" Margin="5" FontSize="20" />

  

       <Button x:Name="FullScreen" 

           HorizontalAlignment="Left" VerticalAlignment="Bottom"

           Content="Go Full Screen" Margin="5" Click="FullScreen_Click" />

Grid>

We added the following items to our MainPage.xaml file:

MediaElement control – This will play the video and give us the ability to stop/start/pause the video using the Media Controls on our keyboard/remote control.
TextBlock control – To display which MediaCommand code is being executed. (Excellent for debugging)
Button control – To toggle between FullScreen mode.

We can navigate over to our MainPage.xaml.cs file and add the following code snippet:

public MainPage()

{

    InitializeComponent();

    this.MediaCommand += new MediaCommandEventHandler(MainPage_MediaCommand);

}

  

private void MainPage_MediaCommand(object sender, MediaCommandEventArgs e)

{

    

    txtMediaKey.Text = e.MediaCommand.ToString();

  

    switch (e.MediaCommand)

    {

        case System.Windows.Media.MediaCommand.Play:

            videoPlayer.Play();

            return;

        case System.Windows.Media.MediaCommand.Pause:

            videoPlayer.Pause();

            return;

        case System.Windows.Media.MediaCommand.Stop:

            videoPlayer.Stop();

            return;

        case System.Windows.Media.MediaCommand.TogglePlayPause:

            if (videoPlayer.CurrentState == MediaElementState.Paused ||

              videoPlayer.CurrentState == MediaElementState.Stopped)

                videoPlayer.Play();

            else if (videoPlayer.CurrentState == MediaElementState.Playing)

                if (videoPlayer.CanPause)

                    videoPlayer.Pause();

            return;

        case System.Windows.Media.MediaCommand.IncreaseVolume:

            videoPlayer.Volume += 5;

            return;

        case System.Windows.Media.MediaCommand.DecreaseVolume:

            videoPlayer.Volume -= 5;

            return;

        case System.Windows.Media.MediaCommand.ChannelUp:

            // Channel up

            return;

        case System.Windows.Media.MediaCommand.ChannelDown:

            // Channel down

            return;

        default:

            return;

    }

}

  

private void FullScreen_Click(object sender, RoutedEventArgs e)

{

    Application.Current.Host.Content.IsFullScreen = !Application.Current.Host.Content.IsFullScreen;

}

Let’s examine the code snippet line by line:

Line 4 creates our MediaCommand event handler. This is going to hook up to our media commands case statement.
Line 10 will simply display which MediaCommand the user has pressed into a TextBlock on the right hand side of the screen. This is useful for debugging applications that use the Media Features in Silverlight 5.
Lines 12-44 is our switch statement that will trigger the respective action on the MediaElement control.
Lines 48-51 will simply check to see if the screen is in FullScreen mode and toggle it accordingly.

Note: I didn’t list all of the MediaCommand enums that are available. You can review a complete list here.

If we run the application our video starts playing:

If we hit the “Play/Pause” media button on our keyboard (If your hardware supports it) then you will see the video is now paused and the word “TogglePlayPause” is located in the bottom right hand corner of our screen.

If you hit other media keys then the MediaElement will respond accordingly. You can even try out your WMC remote control if you have one available.

Please note: If you ever have an issue with the keys responding, then switch to FullScreen mode (by clicking the button) and try again. I’ve found several instances where the Silverlight application loses focus.

Notice how easy it was to add support for Media Keyboards and Remotes? Silverlight is already known for having a excellent media player and this just enhances it even more!

Conclusion

At this point, we have seen how you would use Low-Latency Sound using XNA and Remote Control and Media Command (Keys) Support in your Silverlight 5 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 the new text improvements in Silverlight 5 including: Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions. 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.

WP7 for iPhone and Android Developers - MVC and MVVM

editorial@silverlightshow.net (Kevin Hoffman ) — Thu, 01 Sep 2011 13:41:00 GMT

Don't miss...

($2.99)

All SilverlightShow Ebooks

So far in this series of articles, we have been taking topics that might be second nature to iOS developers and relating them to the relatively new feature set found in the Windows Phone 7 SDK. Typically this involves talking about a few classes and code samples as they might appear in iOS and then relating them to classes with a similar purpose in the WP7 SDK.

This article focuses more on a set of design patterns to illustrate that patterns themselves are universal and the code used to implement them is secondary to the pattern and its purpose. In this article we’ll take a look at the Model – View – Controller pattern and a variant of it, the Model-View-ViewModel pattern.

In a typical data-bound user interface you generally have a view composed of controls and these controls are usually bound to some underlying source of data. For example, if you have a customer edit form you might have controls like text fields for editing the customer’s name and address and other types of controls for editing additional customer data. The model in this scenario might be an object called Customer (which could be a regular Objective-C or C# object or it could have been served up by a database access library or an Object-Relational Mapper).

If this were an iOS application you might have created a class called CustomerEditViewController which inherits from UIViewController. The view is actually a view hierarchy composed of controls that allow a user to edit customers. Because iOS doesn’t actually support bindings the way the full desktop version of Cocoa does (or WP7 for that matter) the controller has to do an awful lot of work to react to user input and manually force values into control properties.

A typical Model-View-Controller interaction looks like the following diagram:

In a bindings-capable environment, the model is bound to the view and the model is loaded and updated by the controller. Additional properties of the view are dealt with by the controller and user interaction events are passed on to the controller for handling.

This works out pretty well in many scenarios and it’s original goal of separating concerns to make our applications easier to maintain and debug is still valid. Unfortunately what happens quite often is that with the MVC pattern we only have a single model. In order to keep bindings working, we end up making changes to the model to accommodate things that only have relevance in the UI. For example, we might add an isSelected property to the Customer class so that we can modify the background color of currently selected customers or, we’ll add a CurrentCustomer object to some other model and use that to help our UI maintain navigational consistency.

In a typical iOS scenario, we might have a UITableViewController subclass. This class is responsible for handing instances of custom view cells to the UI subsystem. It performs the customization of these cells by pulling information from a model.

What we really need are two different types of models. The first type is a model that represents the actual source of data which will more than likely be some kind of POCO (Plain-Old C# Object) that came from a database, an XML file, a Web Service, or somewhere else. The second type of model is a model whose properties and behaviors are designed specifically to support the view with which the user interacts. This type we call a View Model, and it is part of a variant of the MVC pattern called Model-View-ViewModel.

In a Model-View-ViewModel pattern, we take advantage of the fact that virtually all aspects of our user interface can be controlled via data binding. We wouldn’t really need to add the complexity of this pattern to our iOS applications because we don’t have bindings support but it comes in extremely handy when building large Windows Phone 7 applications.

Notice that this pattern doesn’t actually have a controller – there is no single over-arching all-powerful class that is responsible for coordinating everything. This takes a little getting used to at first, but, once you’ve gotten into the habit of building highly data-bound UIs in Windows Phone 7, the use of MVVM seems like a natural evolution.

As mentioned, MVVM is a pattern, it is a way of doing things and, as such, there is no single right way of doing it. For example, one thing people strive for in MVVM is to have as little code in a view’s code-behind as possible (it’s really not possible to avoid this entirely). If you ask folks building MVVM applications today about code-behind, you will probably start an argument.

One concept that is especially hard for iOS developers to let go of is the idea of the controller. If you find yourself writing code that looks like this:

myControl.Text = myModel.Property;

Then you need to stop right there – this isn’t MVVM. Your view needs to be bound to a view model and the properties of the various controls and sub-controls should all be set via bindings and converters wherever possible. The trick with MVVM is figuring out how your view needs to get instances of view models. You can do this by creating factory methods, or you can use a view model locator, which is a static helper class responsible for doling out instances of view models to views.

Take a look at the following XAML, which illustrates how you might create a single customer view that is bound to a view model object:

"MyApp.CustomerPage"

  ...

  DataContext="{Binding Customer,Source={StaticResource Locator}}">

  ...



Basically what we’re saying is that there is a view model object called Customer to which this entire page is bound. This is also a very common practice with MVVM – try and make the binding as wide in scope as possible. It might be hard at first, but try and match your view models directly to pages and user controls. The benefit of having a view model in addition to a data-centric model is that you can have multiple view models for a single model, with each view model tailored specifically for a given control or page.

Inside our App.xaml we can declare a global resource that points to the view model locator:

<Application.Resources>

 <vm:ViewModelLocator x:Key="Locator" />

Application.Resources>

Here “vm” is the namespace prefix of the CLR namespace where we have our view model locator defined. This class really just has public properties on it that allow our XAML to obtain instances of view models. This is also unfamiliar territory for iOS developers and developers who traditionally follow a more MVC style. Instead of having a controller object that knows about the view and knows about the model that is responsible for hooking the two up, the view declares its intent via bindings. In the sample case, the view says that it should be bound to a view model called Customer which can be found on the view model locator class. The view model locator is responsible for instantiating the view model. During this instantiation, the view model also typically has an initialization method which is called directly or indirectly (again, this is a source of difference and debate depending on how you decide to implement your MVVM pattern).

So the flow of control and instantiation might go something like this: Customer View Page –> Locator –> Customer View Model –> Customer Model (database or web service source).

The UI intentionally has absolutely no idea how the bound data is actually persisted on disk (or in the cloud). All it cares about is how the data is represented visually to the user and made available for interaction – this is the job of the view model. Many of the tasks we traditionally keep in controllers, such as responding to user input and manipulating model values, all take place within the view model whenever possible.

At first you might be thinking that MVVM seems a lot more complicated than just having code-behind in your WP7 views that manipulates controls directly, especially when this looks a lot like the code you may have been writing in iOS. For really small applications, this may be true. However, once you start writing applications that have several pages and these pages have multiple controls, different states, and need to respond to when users navigate to and away from those pages and finally when you try and attach an asynchronous data source (such as web services in the cloud) to your application – the small increase in complexity of code is well worth it in the long run.

Bindings is only a small part of MVVM, it is far more than that. Let’s take another very common scenario – navigating between pages. In iOS, you might write code in a method that is invoked when a user selects a row in a table view. Here, you might create an instance of the view controller responsible for the next screen and then pop it into the stack via the navigation controller. If this view controller needs a model in order to prep the UI, the parent controller is often responsible for creating an instance of this model, loading it from some source, and then passing it as a parameter to the child controller.

With MVVM we do things a little differently. A user might tap a button which results in the execution of a Command object that is actually a property of the view model (view models encapsulate both behavior and data!). As a result of this execution, a message might be broadcast indicating that Customer 123 has been selected. The CustomerViewModel class is listening for such a message. When it receives this message, it loads Customer 123 from disk, populates all of its properties accordingly, and then tells the WP7 navigation system to navigate to the CustomerView.xaml page. As you can see, the “concerns” here are even more separate than in MVC – the parent controller doesn’t actually know what happens when someone selects a customer and many proponents of MVVM argue that it shouldn’t. The view model that backs the view that should appear upon selecting a customer is responsible for listening for the event (or events, and this is key to re-usability) that trigger the appearance of that view.

It might seem like a minor detail but if you go back into an application written MVC style a few months after writing it – it could take you a very long time to figure out all of the different paths through an application. If you’re looking at an MVVM view model, then a quick glance at the message subscribers on that model will tell you exactly the list of actions that can cause that view to appear.

In this article I’ve tried to explain the basics of the MVVM pattern and how it differs from the MVC pattern that iOS developers are familiar with. I have deliberately avoided talking about any one MVVM implementation because the decision as to which MVVM library you use (or whether you roll your own) is entirely up to you.

MVVM isn’t limited to just Windows Phone 7, and there are implementations on just about every platform you can imagine. For Windows Phone 7, the library that I have used most often is MVVM Lite. If you don’t feel like writing your own view model locator classes, your own pub/sub messaging system, and your own command helpers, then using a library like MVVM Lite will save you a lot of time and effort.

At one point, the installation process for MVVM Lite was so cumbersome that many people just wrote their own stuff rather than attempting the install. Recently, they have released an automated installer that makes adopting MVVM Lite much easier. You can find the code for MVVM Lite, the downloader, and related documentation here: http://mvvmlight.codeplex.com/.

In closing, iOS developers are very used to having to manually fetch objects from a data source via a controller and then, using that same controller, instantiate custom views and set view properties and manually build view hierarchies programmatically. Using the MVVM pattern on Windows Phone 7 allows developers to take full advantage of bindings, resource dictionaries, templating, and the flexibility of Xaml-based object hierarchies. As an iOS developer if you ever find yourself writing code like this:

myControl.Text = myModel.TextProperty;

Then you should take a step back and see if the MVVM pattern and possibly an MVVM toolkit might help you.

Getting ready for Microsoft Silverlight Exam 70-506 (Part 4)

editorial@silverlightshow.net (Gill Cleeren ) — Mon, 07 Feb 2011 00:57:00 GMT

SilverlightShow and Gill Cleeren start a series of materials aimed at helping you get prepared for taking Microsoft Silverlight Exam 70-506. Through this series we will try to structure the resources available on the internet, grouping them by topic covered in the exam. Any feedback would be much appreciated! Thanks!

More resources...

($9.99)

All SilverlightShow Ebooks

This article is Part 4 of the series on Microsoft Silverlight Exam.

We are making great progress in our Silverlight Exam series, we are now in the fourth part already. A quick look back on the previous parts shows that we started with a deep look at the layout and UI-related material. In the second part, we looked at enhancing the UI using features such as the Visual State Manager. In the previous part, the focus was mainly on the coding part, including topics such as dependency properties, the ICommand interface and working asynchronously with services.

This fourth part will focus on a very important aspect: data. Not a single business application works without data and since one of the focus areas of Silverlight of LOB development, Silverlight is well-equipped to handle data. In this part, we’ll look at data binding, which is something you have to understand deeply. The data binding system is very powerful and enables the MVVM pattern. When working with data (mainly the input process), data needs to be validated as well. Silverlight 4 brings some new options, enabling a much cleaner way to perform validation on inputted data.

For your convenience, the following list contains links to the other parts of the article series which have been finished already:

Laying Out a User Interface (15%)
Enhancing the User Interface (14%)
Implementing Application Logic (16%)
Working with Data (17%) –> this part
Interacting with a Host Platform (11%)
Structuring Applications (13%)
Deploying Applications (13%)

Part 4: Working with data

As mentioned in the intro, many developers are using Silverlight to build business applications. And of course, business apps need to work with data: displaying data, accepting data input, validating input etc. While all this is very well possible to code manually (using code that looks like MyTextBlock.Text = person.FirstName), it’s prone to errors and gets tedious to write quickly. It’s certainly not the most exciting code to write, I think you’ll agree with me on that.

Introducing data binding. It’s easily the most important topic to really grasp when learning Silverlight. The concept of data binding basically comes down to a construct that allows binding – or linking – properties of controls to properties of objects. Instead of having to write all that code manually however, the data binding engine takes a lot of the load out of our hands and lets us create binding from XAML. The data binding engine found in Silverlight is brought in from WPF. WPF’s version has still some more options, but the difference is getting smaller with every new release of Silverlight. Conceptually, data binding is nothing really new. We can do data binding in ASP.NET or WinForms as well; however the model in Silverlight (and WPF of course) is much more loosely coupled.

Not only is data binding important to build data-driven applications, it’s also the concept that makes MVVM (Model-View-ViewModel) possible. If you know your way around the pattern, you’ll quite easily understand that the View is bound to an instance of the ViewModel (in other words, an instance of the ViewModel is set as the DataContext for the View). The ViewModel exposes properties and commands to which the elements in the View can bind. For example, a List exposed on the ViewModel can be the source for a data binding on the View. Commands (which we explored in part 3) are exposed as public properties as well and using the Command property on some controls (in Silverlight 4 only on ButtonBase and controls driving from ButtonBase), we can bind an action in the ViewModel to an event in the View. As you’ll understand, the MVVM pattern really builds on the concepts introduced by data binding.

Implement data binding

In this section, we’ll look at all concepts that are linked to data binding. Many of these are closely related, so you’ll learn about them in one go I assume.

I did a webinar with SilverlightShow where we look at many data binding topics. You can watch it on-demand from here: http://www.silverlightshow.net/shows/SilverlightShow-Webinar-Data-Binding-in-Action-by-Gill-Cleeren.aspx

If you want to read more on data binding itself, take a look at the following links:

In the following links and topics, we’ll look at some specifics from data binding:

Setting the data context
We all know that XAML is a hierarchy. The concept of the data context is built on this. Let me explain.
When creating a simple data entry form (for example to gather person data), we can use data binding. All the TextBox instances where data can be entered need to know to which property on a bound object (a Person instance) they are bound. We could do this by specifying on each TextBox the name of the property. While this is possible, it would actually be a lot of work and would perhaps take away some of the benefit we get from using data binding.
The DataContext allows us to define a common source on a higher level in the XAML tree. So, assume all the TextBox instances are children of a Grid, we can set the DataContext of the Grid to be the Person object. When no source is defined on the binding expression, the data binding engine will start searching (using a process referred to as XAML tree walking) up the XAML tree to find a non-null data context. Once found, the object is used as the source for the binding.
The DataContext is often used in MVVM to set a ViewModel instance as the source for the View.
Binding data sets to controls
Next to binding a single object to form, we often want to bind a list of items to a list control such as a ListBox. Silverlight’s data binding engine is perfectly capable of this as well. The ItemsSource property on these controls is our friend here and be used for this exact purpose. By default however, we won’t get a good visual representation of the bound data: an item will be shown using its ToString() implementation. That’s often not what we want though. Two solutions exist. The first one is using the DisplayMemberPath property of the ItemsControl class. This property allows us to specify which property of the bound item should be used for display (for example FirstName). The second solution is using a DataTemplate, a piece of XAML that’s generated for each item in the List. We looked at DataTemplates in part 3 of this series.
Binding elements to other elements
Most of the time, you’ll be binding properties of controls to properties of data objects. Silverlight also supports bindings between two controls. The best example to understand this is probably binding the Value property of a Slider to the Text property of the TextBlock.
- http://www.silverlightshow.net/news/Mini-Tutorial-Element-Binding-.aspx
- http://www.snowball.be/CommentView,guid,4c4eb74a-7dd6-42d9-a414-9d09bdf9414b.aspx
Implementing INotifyPropertyChanged
Something we haven’t talked about yet in the data binding engine is the automatic synchronization between source and target control. The data binding engine makes it possible to update the control in the UI when the source value changes. This is only supported if the source class implements the INotifyPropertyChanged interface however. Basically what happens is that when we bind to an object that implements this interface, Silverlight will listen for an event – the PropertyChanged event – being raised from the object. When this event is raised, Silverlight will update the UI accordingly. Note that this only works if the binding is a OneWay or a TwoWay binding!
Implementing ObservableCollection
Similar to the INotifyPropertyChanged but then for collections is the INotifyCollectionChanged interface. This can be used to notify the UI about changes in a collection (items being added or removed). This interface is more complicated however and therefore, a special collection type implementing this interface exists, namely the ObservableCollection. When we use this collection, we’ll see the UI stay in sync with the collection if items are added or removed from the collection.
- ObservableCollection on MSDN: http://msdn.microsoft.com/en-us/library/ms668604(v=vs.95).aspx
- http://weblogs.asp.net/joelvarty/archive/2008/11/17/silverlight-databinding-the-observable-collection.aspx
Setting binding modes
Binding modes allow us to specify in what direction the data flows. By default the data flows from the source object to the target control. There are however two options: OneWay and OneTime. OneWay allows updating the UI when the source changes (only works if the source implements INotifyPropertyChanged however). OneTime can be used if you don’t need the synchronization.
A third mode, TwoWay, allows data to flow in 2 directions: source to target and target to source. This way, we can use data binding also to capture user-entered values.
Setting a fallback value
If the data binding expression fails, your application won’t explode! On the contrary, you probably won’t even get any feedback in the UI about it failing. One mechanism to make things easier here is using a fallback value. This value is displayed when the binding fails for any reason.
- http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.fallbackvalue(v=vs.95).aspx
- http://www.snowball.be/Silverlight+Advent+Calendar+December+4th+Replacing+Converters+With+New+Data+Binding+Features.aspx

Format data

By default, a data binding sets the value of a property from an object as the value for control property, such as a DateTime value for a TextBlock. We however have options to hook into this process. One solution is using a Converter (see further), an easier solution is using a formatting expression on the binding.

Formatting string values in data binding
By using the StringFormat property of a data binding expression, we can specify how the value for a binding should be formatted. Several formatting strings exist, including currency and date formatting.
Formatting culture-specific string values
- http://timheuer.com/blog/archive/2010/08/11/stringformat-and-currentculture-in-silverlight.aspx

Value Converters

Converters are a great way to do anything with a value before it’s used in the data binding itself. Instead of just using the value in its original format, we can apply a conversion on it. It’s a hook in the data binding process, but it goes further than the StringFormat can go. The latter can just apply conversions on a string, while a converter can apply any transformation.

A converter is nothing more than a class that implements the IValueConverter interface. This interface defines two methods: Convert and ConvertBack. When using a converter on a data binding, the Convert method is automatically invoked when the data flows from the source to the target. Similarly, the ConvertBack is called when data is sent from the target to the source (so when the user can enter data). In the Convert, we can for example add a currency sign to an amount to have it properly displayed. In the ConvertBack, we can remove that currency sign again to be able to save the amount back to a property on the source.

An important feature is that there can be a difference in types between the “input” and “output” of a converter. For example, we can bind an amount (of type int) to a Background property if we apply a converter that checks if the value is greater than zero and returns a green Brush if true and a red one if false.

Learn more about converters using the following links:

Creating a value converter / Referencing a value converter
Passing parameters

Implement data validation

When using TwoWay bindings, we are basically opening up the application for users to enter data. Of course, not all users “behave” like we’d like them to: users will make errors when entering data that could cause problems in our data model. Values that are larger than a specific maximum, a string where an integer is expected… they are all common things we get to deal with in our applications.

To counter this, we obviously have to fall back on the concept of validation. Before the entered data goes back to the source object, we can have Silverlight run validation code that checks if the value is according to one or more validation rules.

In Silverlight 2, the available options for data binding weren’t that rich. With every release, some new options have been added. The most important one however was added with the release of version 4, where 2 new interfaces were added: IDataErrorInfo and INotifyDataErrorInfo. The first one you may know for regular .NET, the second one enables asynchronous validation in Silverlight. This is something we’ll often need: not all validation can be done purely on the client but has to call back to the server-side. A good example is checking the uniqueness of a chosen username: this is typically a check that has to be ran on the database (therefore on the server-side). Since this needs to be done using a service call that runs asynchronously, the INotifyDataErrorInfo comes in handy when we have to wait for a validation result coming back from a service call.

To learn more about data validation, take a look at the following links:

Implementing the IDataErrorInfo interface
Implementing the INotifyDataErrorInfo interface
Implementing data binding errors
In this SilverlightShow article, I explain the several properties of validation: http://www.silverlightshow.net/items/The-validation-story-in-Silverlight-Part-1.aspx
- NotifyOnValidationError
  NotifyOnValidationError enables us to pass errors in the hierarchy
- ValidatesOnExceptions
  If our setters throw an exception within the setter, we can catch this if we set the ValidatesOnExceptions to true.
  - ValidatesOnExceptions on MSDN: http://msdn.microsoft.com/en-us/library/system.windows.data.binding.validatesonexceptions.aspx
  - http://www.arrangeactassert.com/validation-in-silverlight-and-wpf-using-validatesonexceptions/
- ValidatesOnDataErrors
  If we want to use IDataErrorInfo as our validation mechanism, we have to set ValidatesOnDataErrors to true.
  - ValidatesOnDataErrors on MSDN: http://msdn.microsoft.com/en-us/library/system.windows.data.binding.validatesondataerrors(v=vs.95).aspx
- ValidatesOnNotifyDataErrors
  If we want to use INotifyDataErrorInfo as our validation mechanism, we have to set ValidatesOnNotifyDataErrors to true.
  - ValidatesOnNotifyDataErrors on MSDN: http://msdn.microsoft.com/en-us/library/system.windows.data.binding.validatesonnotifydataerrors(v=vs.95).aspx

Summary

In this part, we focused on the very important aspect of working with data and learning the data binding mechanism. We also looked at ways to alter the data binding process using converters and we also saw the many ways we can do validation in Silverlight 4, depending on the needs of our application.

In the next art, we’ll be looking at how we can work together with the host platform, including COM, out-of-browser applications and working with the DOM of the surrounding page.

About Gill

Gill Cleeren is Microsoft Regional Director (www.theregion.com), Silverlight MVP (former ASP.NET MVP), INETA speaker bureau member and Silverlight Insider. He lives in Belgium where he works as .NET architect at Ordina. Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd Berlin 2010, TechDays Belgium, DevDays NL, NDC Oslo Norway, SQL Server Saturday Switserland, Spring Conference UK, Silverlight Roadshow in Sweden… He’s also the author of many articles in various developer magazines and for SilverlightShow.net. He organizes the yearly Community Day event in Belgium.

He also leads Visug (www.visug.be), the largest .NET user group in Belgium. Gill recently published his first book: “Silverlight 4 Data and Services Cookbook” (Packt Publishing). You can find his blog at www.snowball.be.

Twitter: @gillcleeren

Getting ready for Microsoft Silverlight Exam 70-506 (Part 3)

editorial@silverlightshow.net (Gill Cleeren ) — Tue, 01 Feb 2011 03:39:00 GMT

More resources...

($9.99)

All SilverlightShow Ebooks

This article is Part 3 of the series on Microsoft Silverlight Exam.

In the previous parts of this series on getting yourself ready for the Silverlight exam, we mainly looked at UI related items. In the very first part, we looked at how Silverlight could help with layout, navigation, media and the core controls. In part 2, we focused on the many features Silverlight has on board to create better user interfaces, such as the Visual State Manager, styling, templating and animations.

This third part is going to be more aimed at the code-side of things. We’ll start our journey by looking at specifics of Silverlight such as routed events (these also exist in WPF by the way and asynchronous communication with services. We’ll look at dependency and attached properties as well, these are very important to a deeper understanding of Silverlight. We’ll look at the ICommand interface as well, which forms the base of commanding support for the MVVM-pattern in Silverlight. As you can see, we’ll be spending more time looking at C# code this time!

For your convenience, the following list contains links to the other parts of the article series which have been finished already:

Laying Out a User Interface (15%)
Enhancing the User Interface (14%)
Implementing Application Logic (16%) -> this part
Working with Data (17%)
Interacting with a Host Platform (11%)
Structuring Applications (13%)
Deploying Applications (13%)

Part 3: Implementing Application Logic

Do you remember the name WPF/E (the E stands for Everywhere)? It was the name Silverlight was known by before it got its final name. The reason I bring this up here is that it shows that Silverlight has inherited from WPF (Windows Presentation Foundation). The original name gives this away. Much of the core development platform we have today in Silverlight found its origin in Silverlight. Things like dependency properties and attached properties were introduced in WPF and later were ported into Silverlight. Some of these implementations are identical in the 2 technologies, others are somewhat trimmed down in Silverlight. Still, the development model available in Silverlight is solid and ready to build all types of applications on. Let’s dive into writing some code for Silverlight applications!

Handle events

Working with events in Silverlight is not very different from any other technology (note that we’re not looking at MVVM/commanding here yet). When we have some control in the designer, we can select it and select an event in the event window. Visual Studio will generate the event handler for us then as well as generate the event on the control in XAML. Not very different from ASP.NET or WinForms indeed! We can also choose to attach the event handler in code-behind using a delegate or even a lambda expression.

Silverlight has the notion of routed events. An event raised on a control nested within another control will bubble into the parent control so this parent can handle the event. This model is easy because Silverlight promotes nesting. This way, a TextBlock and an Image inside of a container (such as a Grid), all nested within a Button, will raise the click event to the Button, instead of us having to wire the event for the Button and its children manually.

To learn more about event handling, take a look at the following links:

Handling routed events / Bubbling events:
Bubbling of an event is a type of a routed event. At the time of writing, there’s only support for bubbling events in Silverlight. WPF also supports tunneling. Bubbling can be seen as a way to send an event higher in the hierarchy. Hence the name bubbling: it will bubble up in the XAML tree. Tunneling, which is only available for WPF, does the opposite, drilling down so to say in the XAML tree.
- Routed events in Silverlight 3: http://msdn.microsoft.com/en-us/library/cc189018(v=vs.95).aspx (contains information on AddHandler as well)
- http://www.silverlightshow.net/items/Routed-Events-in-Silverlight.aspx
- http://www.silverlightshow.net/news/Training-Session-on-Silverlight-Routed-Events.aspx
- Interesting thread on the Silverlight forums: http://forums.silverlight.net/forums/p/153909/343601.aspx
- http://www.silverlightshow.net/items/More-on-Routing-and-Bubbling.aspx
- http://www.kirupa.com/net/event_bubbling_tunneling.htm
- http://rongchaua.net/blog/silverlight-routed-event/
Implementing AddHandler:
Using the AddHandler, we can add an event handler for a routed event to the handler collection of an element.
- http://msdn.microsoft.com/en-us/library/ms598899(v=vs.95).aspx

Consume services asynchronously

Services are a vital building block for Silverlight applications. As business applications become more and more the focus of where Silverlight is going, data is needed in any app. Since out-of-the-box, Silverlight has no support for client-side database (I specifically said out-of-the-box, since there are some custom implementations such as Sterling database but these are not the focus for the exam), it has to access services for its data needs. Client-side databases would not be the solution for all problems either: if we build a shopping website in Silverlight, no developer would get it in his mind to transfer the entire product database to the client (let’s hope so at least!).

Luckily, Silverlight is well-equipped for working with all kinds of services. ASMX, WCF, REST, POX and RSS pose no problem for Silverlight. We can easily say that today, the default for building new services should be WCF or REST. However, if you have an existing implementation (legacy) in ASMX (plain web services), there’s no problem to consume these from a Silverlight environment.

When working with WCF or ASMX services, Visual Studio helps us out by generating a proxy class when adding a reference to the service. This proxy will make the actual calls to our service. This is not different from adding service references in other .NET technologies.

One big difference however is the fact that all communication happens asynchronously in Silverlight. No service can be communicated with in a synchronous manner. This would, while the Silverlight application waits for a response, lock the UI thread and therefore also the browser. Even in WCF RIA Services, where the async behavior is somewhat abstracted away, the communication still happens asynchronously.

(Shameless plug: in my book Silverlight 4 Data and Services Cookbook (Gill Cleeren – Kevin Dockx, Packt Publishing 2010), we have a very deep coverage of all things happening around accessing services).

Let’s look at some important information regarding working with services from Silverlight.

Creating and adding service references / Handling asynchronous completed events
Configuring service endpoints
- http://wildermuth.com/2008/11/08/Controlling_Service_References_in_Silverlight_2
- http://timheuer.com/blog/archive/2010/04/05/managing-service-references-in-silverlight-applications-for-different-environments.aspx
Handling service exceptions
- http://msdn.microsoft.com/en-us/library/ee844556(v=vs.95).aspx
- http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2#WCFSilverlightHandlingFaults
Handling timeouts

Work with background threads

Threading is the ability to push some long running task to a separate thread. By default, all the work is done on the single UI thread in Silverlight. If we launch for example a calculation that takes several seconds to complete in the main thread, the UI will be blocked and won’t be accepting any input until it has finished the calculation. By creating a separate thread to execute the work on, the UI thread won’t be blocked and the user can keep working with the application in the meantime. This is similar to what happens when connecting with a service: there’s also a time-consuming task that would block the UI if invoked synchronously.

Silverlight has a threading stack on-board. While it doesn’t contain all threading options available in the full .NET framework, there’s more than enough for scenarios where Silverlight is to be used. Silverlight also contains the BackgroundWorker class which makes working with threads easier.

One important thing concerning threading is that all code that executes on a separate thread has no access to the UI elements. It’s therefore not possible to write code in a callback that does something with a UI element (such as setting the Text of a TextBlock). There’s a workaround though in the form of the Dispatcher.BeginInvoke(), to which we can pass code that will be executed on the UI thread.

To learn more about threading, take a look at the following links and articles:

Spawning a background thread to execute code
- Thread class on MSDN: http://msdn.microsoft.com/en-us/library/system.threading(v=VS.95).aspx
- BackgroundWorker on MSDN: http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker(v=VS.95).aspx and http://msdn.microsoft.com/en-us/library/cc221403(VS.95).aspx
- http://10rem.net/blog/2010/04/23/essential-silverlight-and-wpf-skills-the-ui-thread-dispatchers-background-workers-and-async-network-programming (also contains overview of the BackgroundWorker class)
- http://www.silverlight.net/learn/videos/silverlight-videos/using-multiple-threads-with-the-backgroundworker/ (video)
Returning data to the UI thread by using the dispatcher object
The Dispatcher allows to pass code to execute on the UI Thread. Without this, we wouldn’t be able to change anything on the UI elements from a background thread.
Implementing the DispatcherTimer
The DispatcherTimer is a Timer which is integrated in the Dispatcher queue. It should be your default when using any timer in a Silverlight application.
- DispatcherTimer class on MSDN: http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatchertimer(v=vs.95).aspx
- http://blogs.silverlight.net/blogs/msnow/archive/2009/11/09/69731.aspx

Working with Dependency Properties

When I teach a Silverlight class, one of the hardest things to explain I think are dependency properties. Not because they’re that hard, certainly not. The thing is that dependency properties make something you know (the regular property system) to a new level. However, they do relieve us from writing a lot of code ourselves.

Dependency properties are the enabler for data binding, styling and animations. Without them, we would have to write a lot more code to get these things working. Most properties on UI objects in Silverlight (the FontSize property on a TextBlock, the Width property of a Rectangle…) are dependency properties, so in most cases, you’ve used them without even knowing it! When you start writing your own controls, you’ll need to start creating them as well, if you want your control to be able to take part in data binding, styling… It’s certainly recommended to do so, since other users of your custom-built controls will expect your controls to behave just like the default controls of Silverlight.

Let’s take a look at working with dependency controls:

Creating dependency properties / Specifying dependency property metadata / Getting and setting dependency property values
Creating dependency properties is more complicated than writing regular properties. You have to declare the DP by registering it with the dependency property system (on the DependencyObject). Optionally, you have to write code in a PropertyChangedCallback that will trigger when the value changes. Finally, you have to write a public wrapper for your DP. You won’t be accessing the value of the DP directly: you’ll always use this wrapper which internally uses the GetValue/SetValue defined on the DependencyObject class. These methods will retrieve the exact value of the DP at the given time, taking into account all the current influences taking place on the value and their priorities.
The topic of dependency properties in Silverlight is inherited from WPF. There’s a lot of interesting material on DPs in WPF as well from the following links:

Interacting with attached properties

Attached properties are properties defined on one control but used on a different control. Confused? Let me explain it with a simple example. Take the Row property on a Grid control. When we want to place a TextBlock in row #3 inside a Grid, we specify the Grid.Row property to have the value 3. However, the TextBlock does not have a “Grid.Row” property defined. Instead, the Grid has the Row property defined as an attached property. The attached property is defined as a global property, so that other control can use it. Most attached properties are defined on containers (Grid, Canvas…). This is because there needs to be some “communication” between the child control and the parent control. However, this is not required: your own control can too define attached properties if needed.

To learn more about attached properties, take a look at the following articles:

Setting attached properties in XAML
- http://www.silverlightshow.net/items/Attached-Properties-in-Silverlight.aspx
- http://msdn.microsoft.com/en-us/library/cc265152(v=vs.95).aspx
Getting and setting attached properties programmatically

Implementing ICommand

The MVVM pattern is something you’ve surely heard about already. The ViewModel (aka View-Model-ViewModel) pattern promotes separation of concerns. The ViewModel is an abstraction of the View: the View mostly XAML-only and it’s the place where the designer is focusing on. The ViewModel contains state and operations for the View. State can be seen as properties, operations are commands. The View falls back on the concepts of data binding and the DataContext to bind to an instance of the ViewModel.

When executing an action in the UI, for example clicking a Button, we think of adding an event handler and writing some event handling code in the code-behind. MVVM promotes commanding, which comes down to writing a public command in the ViewModel and binding to this instance in the View. When the command fires, the related code in the ViewModel gets executed. Therefore, we don’t write an event handler, instead we create a command instance and the ViewModel and bind to it.

Commanding is possible in Silverlight 4 because of the introduction of the ICommand interface. When creating a command implementation, we have implement the ICommand interface. Once we have our implementation, we can instantiate it, expose it as a public property on the ViewModel and bind to it in the View. In Silverlight 4, commanding is only supported on the ButtonBase class though. (Note: in many cases, we don’t implement the ICommand ourselves but we’ll use an existing implementation such as RelayCommand of MVVM Light or DelegateCommand from Prism).

The following articles can helpful when exploring the ICommand interface:

General implementation of ICommand:
Implementing an ICommand
- http://www.orktane.com/Blog/post/2009/03/09/I-Command-Silverlight.aspx
Binding to an ICommand:
- http://www.dotnetfunda.com/articles/article859-command-binding-in-silverlight-4-stepbystep-.aspx
Passing a parameter
- http://www.silverlightshow.net/news/ICommand-in-Silverlight-4-.aspx
- http://geekswithblogs.net/HouseOfBilz/archive/2009/05/22/adventures-in-mvvm-ndash-commands-in-silverlight.aspx

Summary

In this part, we prepared ourselves for the code-side of Silverlight. Not everything is XAML so there are some really important things to understand that you need to know in this area. Aspects such as Dependency Properties, Attached Properties and the ICommand interface are tools you’ll surely want in your Silverlight toolbox!

In part 4, data will be our focus, when we look at things like data binding and validation.

About Gill

Twitter: @gillcleeren

A classic memory game: Part 2 - The game logic, connecting the ViewModel and the View

editorial@silverlightshow.net (Levente Mihály ) — Fri, 21 Jan 2011 09:54:00 GMT

This article is compatible with the latest version of Silverlight.

Don't miss...

Show more books

This article is Part 2 of “A classic memory game”.

The series is about building the following classic memory game in Silverlight, and porting it to Windows Phone 7. In the first article we started a new MVVM Light project, created the controls and designed the game-states. Now it’s time to put some code behind the game, and finish it.

Here’s the game itself and you can download the source code here.

The Game Logic

MVVM Light template

The MVVM Light project template contains a ViewModelLocator and a MainViewModel in the ViewModel folder. The ViewModelLocator’s job is to hold a reference of the ViewModels and to create them when needed. In the App.xaml there’s an instance of the ViewModelLocator, so the Views can bind to the ViewModel via this instance.

App.xaml:

<Application.Resources>

   <ResourceDictionary>

    <vm:MemoryViewModelLocator x:Key="Locator"

        d:IsDataSource="True" />

   ResourceDictionary>

Application.Resources>

MainPage.xaml:

<UserControl.DataContext>

   <Binding Path="Main" Source="{StaticResource Locator}"/>

UserControl.DataContext>

Model

To represent the cards, we have a MemoryCard class with the following properties:

the ID specifies which image is on the card
the Upside property indicates if a card is showing it’s face or back
the Solved property is set true once the card and its pair are found

The MemoryCard class implements the INotifyPropertyChanged interface. Classes that implement this interface must have an event delegate PropertyChangedEventHandler. Raising this event enables the View (that’s the MainPage.xaml) to track changes. So we need to raise this event when setting the Upside and the Solved properties. The ID won’t change in a MemoryCard’s lifetime so we don’t need to do anything there.

Here’s the Upside property and the raisePropertyChanged method.

/// 

/// The  property's name.

/// 

public const string UpsidePropertyName = "Upside";

private bool _upside = false;

/// 

/// Gets the Upside property.

/// Changes to that property's value raise the PropertyChanged event. 

/// 

public bool Upside

{

  get

  {

   return _upside;

  }

  set

  {

   if (_upside == value)

   {

     return;

   }

  _upside = value;

  // Update bindings, no broadcast

  raisePropertyChanged(UpsidePropertyName);

 }

}

public event PropertyChangedEventHandler PropertyChanged;

private void raisePropertyChanged(string propertyName)

    if (PropertyChanged != null)

        this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

The game logic

The logic is simple. In the MainViewModel’s constructor we’re setting up two timers (DispatcherTimers), one to turn back cards after a while and one for tracking the elapsed time. In the Start method we load the selected number of cards (based on the difficulty) and reset the score and start the elapsed timer.

We have a few properties to store the state of the game. The most important one is the list of the cards (MemoryCardList). The MainViewModel derives from BaseViewModel that means we don’t have to explicitly implement the INotifyPropertyChanged interface because it’s already implemented in the base class as well as the RaisePropertyChanged method.

Here’s the LoadCards method:

public void LoadCards()

{

    int cardCount = 0;

    switch (Difficulty)

    {

        case Difficulties.Easy:

            cardCount = 8;

            CardSize = 100;

            break;

        case Difficulties.Normal:

            cardCount = 10;

            CardSize = 78;

            break;

        case Difficulties.Hard:

            cardCount = 15;

            CardSize = 62;

            break;                

    }            

    // clear

    MemoryCardList.Clear();

    // add cards

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

    {

        MemoryCardList.Add(new MemoryCard(i)

        {

            Upside = false

        });

        MemoryCardList.Add(new MemoryCard(i)

        {

            Upside = false

        });

    }

    // shuffle them

    var rand = new Random();

    for (int i = MemoryCardList.Count - 1; i > 0; i--)

    {

        int n = rand.Next(i+1);

        var temp = MemoryCardList[i];

        MemoryCardList[i] = MemoryCardList[n];

        MemoryCardList[n] = temp;

    }

    IsGameEnded = false;

}

Note that we are adding two cards with the same ID at a time in the loop so we can pair them. After adding the cards we shuffle them. One last thing to explain: the CardSize specifies the actual size (width and height) of the cards in the View as we have smaller cards when there more. Keeping the CardSize in the ViewModel is not very elegant, it should belong to the View, I’ll probably refactor it.

The heart of the game is the OnSelectionChanged method. First we count the upside cards, if it’s two (which is actually one plus the newly flipped) we compare the IDs. If there’s a match they are solved. We have to check if there are any unsolved cards there to track the end of the game. If two cards are already upside showing their front, the newly selected would be the third card to show it’s front, so we have to flip back everything. Here’s the code:

public void OnSelectionChanged(MemoryCard lastCard)

{

    int upsideNo = MemoryCardList.Count((m) => m.Upside);            

    if (upsideNo == 1)

    {

        // one is upside + lastCard is 2, check IDs

        MoveCounter++;

        var upsideCard = MemoryCardList.First((m) => m.Upside);

        if (upsideCard.ID == lastCard.ID)

        {

            if (MemoryCardList.Count((m) => !m.Solved) == 2)

            {

                _elapsedTimer.Stop();

                EndGame();

            }   

            upsideCard.SetSolved();

            lastCard.SetSolved();

            PairCounter++;                                     

            return;

        }

        if (!_timer.IsEnabled)

        {

            _timer.Start();

        }

    }                

    else if (upsideNo == 2)

    {

        // two is already upside, hide them, lastCard will be the only upside

        _timer.Stop();

        hideCards();

    }            

}

Connecting the ViewModel and the View

After building the project the MainViewModel properties should show up in Blend’s databinding windows. We bind the MemoryCardList to the ListBox’s ItemSource. Click on the little square next to the ItemSource, choose DataBinding and select the MemoryCardList in the DataContext tab.

Now the ListBox will always display the cards in the ViewModel’s MemoryCardList property.

Converters

Blend’s databinding window shows only the compatible types by default. That means for example an IsVisible property type of bool won’t show up (by default) when you try to bind it to any element’s Visibility property, because the Visibility is type of a Visibility enum. Here enters the IValueConverter interface. When you build a class implementing this interface, you can pass it to the binding to have the data converted to compatible type.

A classic example is the VisiblityConverter for the Solved property (so it’s working the opposite way), note that only one way is implemented, we won’t need the ConvertBack:

public class VisibilityConverter : IValueConverter

{

    #region IValueConverter Members

    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

    {

        if (value == null) return Visibility.Visible;

        if ((bool)value) return Visibility.Collapsed;

        else return Visibility.Visible;

    }

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

    {

        throw new NotImplementedException();

    }

    #endregion

}

After build, you can set it up in Blend for the MemoryCard’s Solved property. Edit the CardList’s ItemTemplate, select the ToggleButton and bind the Visibility property:

Switch to all properties, select the Solved property, open the dropdown at the bottom of the window, and select the VisibilityConverter as Value converter.

You can bind the Checked property to the Upside property without a converter, because both of them are a type of bool.

Sometimes we need the ValueConverter in both ways, and sometimes we need additional parameters. To set the difficulty I needed both. There is a RadioButton for each difficulty, and we have one Difficulty property in the ViewModel type of an enum. So to make it work I needed to pass which RadioButton is the target. Here’s the code for the DifficultyConverter:

public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

{

    if (System.Convert.ToString(value).Equals(System.Convert.ToString(parameter)))

    {

        return true;

    }

    return false;

}

public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

{

    if (System.Convert.ToBoolean(value))

    {

        return Enum.Parse(typeof(Difficulties), System.Convert.ToString(parameter), true);

    }

    return null;

}

And here’s the Binding for the Easy difficulty to the button’s Checked property:

Another converter was needed for displaying the images based on the ID. The ImageConverter takes the ID and converts it to an ImageSource by resolving a naming convention.

Formatting text

Converters are often used to format text, for example converting a number to string in a desired format. Silverlight 4 however introduced the StringFormat extension. Unfortunately I couldn’t find any Blend support here, so we have to dive into code to make it working. The following code formats the move counter to a 2-digit style:

You can find a good summary about StringFormat on DesignerSilverlight.

CallDatacontextMethodAction

We have to connect not just the data in the ViewModel to the View, but user-actions too. The standard way for the View to notify the ViewModel that something is happened is by commands. A simpler and more designer friendly approach is the CallDatacontextMethodAction behavior by András Velvárt. You might have already read the article about it: A Designer-friendly Approach to MVVM.

After adding it to the project and building it we can add it to our Start button to call the Start method on the ViewModel.

Delaying an action

For the MemoryCard I had to delay the effect of setting the Solved property to true. What happened is by setting the card to solved it immediately disappeared, even before the control would arrive to the Checked state. This was clearly not okay, the player couldn’t see the card before it was marked as solved and disappeared. That’s why I introduced the SetSolved method that starts a timer and only after 1.5 seconds sets the Solved property to true thus making the card disappear.

The Messenger class

The ViewModel sends a signal to the View once all of the cards are collected by using MVVM Light Messenger class. The View then moves into the EndState:

Messenger.Default.Register<string>(this, (msg) =>

    if (Constants.EndGameMessage == msg)

        VisualStateManager.GoToState(this, EndState.Name, true);

});

The Messenger is used in the MemoryCard class as well. When the card is flipped it notifies the MainViewModel and that is when the OnSelectionChanged method runs, which is the heart of the game.

Summary

In this article we inspected the development aspects of a game leveraging on MVVM using bindings, visual states, transitions and behaviors. Expression Blend turned out to be a really powerful tool as for the whole game we needed only little coding.

In the final article of the series I will port this game to Windows Phone 7, exploring performance optimizations, phone-specific UI, and tombstoning. Don’t hesitate to drop a comment if you have questions or want to see something specific in the next article.

About the Author

My name is Levente Mihaly. I've entered the .NET world in 2006, and after graduating at Budapest University of Technology (Msc in Computer Science) I started working as a .NET software developer. After meeting technologies like WinForms and ASP.NET, Silverlight quickly became my favourite platform from the early Silverlight 2 beta stages. I was always interested in mobile development and now I'm very happy since with Windows Phone 7 I can easily expand my knowledge to the mobile world. Nowadays beside following Silverlight I'm focusing on WP7 in my free time. I'm also the runner-up of the 2010 Silverlight ecoContest. You can reach me on twitter (@leventemihaly).

The validation story in Silverlight (Part 2)

editorial@silverlightshow.net (Gill Cleeren ) — Mon, 06 Dec 2010 04:15:00 GMT

This article is compatible with the latest version of Silverlight.

Don't miss...

($0.99)

All SilverlightShow Ebooks

This article is Part 2 of the series “The validation story in Silverlight”.

In the previous part of this series, we looked at the basic validation options we have available Silverlight (since version 3). The problem with the solutions we looked at is that they are mostly based on client-side validations. As you saw, the validation code, such as the attributes, assumes that all our validation needs are fulfilled with these attributes. In many cases, we’ll need to go to the server for a specific business rule.

For example, we need to check if a user name already exists. We can’t solve that on the client, because for this, we’ll need to perform a call to the database over a service. When the service returns, it’s possible that the validation has failed. The object enters a non-valid state and we should be able to notify our UI about that. If you’re like me, you don’t want to write all that code yourself, so we have to put our hopes in the Silverlight framework to handle this in some way.

The good news is that Silverlight 4 added support for this and more. More specifically, support was added for the IDataErrorInfo and the INotifyDataErrorInfo interfaces. We’ll start by looking at these in this article. Furthermore, we’ll take a look as well at how we can change the default looks of the validation: it’s very likely your application will use some other way of notifying the user that the value of a field is not correct.

We use the same solution as with part 1, however, some more code was added. The code can be downloaded here.

Hello IDataErrorInfo

First things first: let’s take a look at the definition of the interface.

public interface IDataErrorInfo

    string Error { get; }

    string this[string columnName] { get; }

The Error property can be used to return error information about the object itself. In some cases, this is not used however and can be set to Null. Note that in data binding, this property is never called, so it’s only useful in custom error reporting.

public string Error

get

        return null;

More important is the indexer. It can be used to write business rules for the different properties of the object. The columnName parameter refers to the name of the property and based on that name, we can trigger validation logic. The following snippet shows how we can use this indexer.

public string this[string columnName]

get

        switch (columnName)

            case "FirstName":

                if (string.IsNullOrEmpty(FirstName))

                    return "First name can't be empty";

                else if (FirstName.Length > 50)

                    return "First name should be less than 50 characters";

                break;

            case "LastName":

                if (string.IsNullOrEmpty(LastName))

                    return "Last name can't be empty";

                else if (LastName.Length > 50)

                    return "Last name should be less than 50 characters";

                break;

           case "Age":

               if (Age < 0)

                   return "Age can't be negative";

               else if (Age > 120)

                   return "You are too old";

               break;

           default:

               break;

        return null;

Using the switch block, we check which property value needs to be validated. While in this sample, all logic ends up in this one location, it’s very well possible to extract this into a separate validation object, perhaps even containing some reusable (read: standard methods such as checking for string length).

Now when data binding to an object that implements this interface, the same type of error messages are created for us in the UI. We do need to make one very important change: set the ValidateOnDataErrors property to true. This is a signal for the data binding engine that the object we are binding to implements the interface.

<TextBox Name="FirstNameTextBox" Text="{Binding FirstName,     Mode=TwoWay, ValidatesOnDataErrors=True, NotifyOnValidationError=True}"

/>

If needed, we can apply both ValidatesOnExceptions and ValidatesOnDataErrors at the same time. However, if an exception occurs, the ValidatesOnDataErrors will never get called.

While this is a clean way of performing validation, it still is aimed at simple, client-side only validation, that doesn’t solve the problem outlined earlier: performing a validation that involves asynchronous validations on the server. The interface has some other problems as well. For example, it’s not possible to return more than one exception per property (while this can be the case in real world objects). The interface does not support returning anything but a string (so no custom Exception types).

To solve this, the INotifyDataErrorInfo comes in handy.

The INotifyDataErrorInfo interface

Next to the IDataErrorInfo, with Silverlight 4 came the INotifyPropertyChanged. Let’s start by looking at the interface definition.

public interface INotifyDataErrorInfo

    bool HasErrors { get; }

    event EventHandler ErrorsChanged;

    IEnumerable GetErrors(string propertyName);

public sealed class DataErrorsChangedEventArgs : EventArgs

    public DataErrorsChangedEventArgs(string propertyName);

    public string PropertyName { get; }

Two things should pop out. First, notice the GetErrors, returning an IEnumberable. This makes it possible to have more than one exception on a single property. Next, the ErrorsChanged event can be used where we need to notify that the errors on the object have somehow changed (that is, after the return of an async call). Because of this, it’s easy to see that this interface is a perfect fit for Silverlight!

Below is the new Person class (relevant part) with this interface applied.

public class NotifyDataErrorInfoPerson: INotifyDataErrorInfo, INotifyPropertyChanged

    private string _firstName;

    private string _lastName;

    private int _age;

    private Dictionary<string, List> _errors;

    public event EventHandler ErrorsChanged;

    public event PropertyChangedEventHandler PropertyChanged;

...

    private void NotifyErrorsChanged(string propertyName)

        if (ErrorsChanged != null)

            ErrorsChanged(this, new DataErrorsChangedEventArgs(propertyName));

    Dictionary<string, List> Errors

get

            if (_errors == null)

                _errors = new Dictionary<string, List>();

            return _errors;

    bool INotifyDataErrorInfo.HasErrors

get

            return (Errors.Where(error => error.Value.Count() > 0).Count() > 0);

    IEnumerable INotifyDataErrorInfo.GetErrors(string propertyName)

        if (!Errors.ContainsKey(propertyName))

            Errors.Add(propertyName, new List());

        return Errors[propertyName];

public class CustomValidationException

    public int ErrorLevelId { get; set; }

    public string Message { get; set; }

Several things are important in this class now. First, notice we have included a Dictionary>. The CustomValidationException is a custom class, containing some more info that just a string. The Dictionary itself is added to keep track of all errors on the properties. Indeed, for each property, we create a new KeyValuePair where the Key is the property name and the Value is a List, making it possible to have more than one error per property. Next, notice the use of the ErrorsChanged event. We will raise this event whenever there’s a change in the errors on any property.

Let’s now use this async validation. A new property was added, UserName. Usernames need to be unique, but we can’t check that on the client (sending down all already taken usernames would be silly): we need to make a call to a service. In this case, the service is performing a hardcoded check for the username:

[OperationContract]

public bool CheckUserNameUnique(string userName)

    if (userName == "gillcleeren")

        Thread.Sleep(3000);

        return false;

    return true;

Note that the Thread.Sleep(3000) was added to better see the async behavior.

In the setter of the UserName, we now call this service.

public string UserName

get

        return _userName;

set

        _userName = value;

        NotifyPropertyChanged("UserName");

        CheckUserNameUnique();

private void CheckUserNameUnique()

    UserValidatorService.UserValidatorServiceClient proxy =

        new UserValidatorService.UserValidatorServiceClient();

    proxy.CheckUserNameUniqueCompleted +=

        new EventHandler

            (proxy_CheckUserNameUniqueCompleted);

    proxy.CheckUserNameUniqueAsync(UserName);

Nothing special here, this service call will be triggered whenever a new value is entered into the field. In the callback, we handle the response of the server: we check if the response is false. If so, we create a new CustomValidationException instance that we add in the List for the key “UserName” in the errors dictionary. If the response is true, the error should be removed from the List again.

void proxy_CheckUserNameUniqueCompleted(object sender, UserValidatorService.CheckUserNameUniqueCompletedEventArgs e)

    bool result = e.Result;

    CustomValidationException exc;

    if (e.Error != null || !e.Result)

        if (result == false)//we have a failing unique constraint

            exc = new CustomValidationException();

            exc.ErrorId = FAILING_UNIQUE_ERROR_ID;

            exc.ErrorLevelId = 100;

            exc.Message = "This username not unique";

            //add error for the property in the dictionary

            CreatePropertyErrorList("UserName");

            //there is no error in the collection with the specified ID

            if (_errors["UserName"].SingleOrDefault(c => c.ErrorId == exc.ErrorId) == null)

                _errors["UserName"].Add(exc);

            NotifyErrorsChanged("UserName");

    else if (e.Result)

        CreatePropertyErrorList("UserName");

        exc = _errors["UserName"].SingleOrDefault(c => c.ErrorId == FAILING_UNIQUE_ERROR_ID);

        if (exc != null)

            _errors["UserName"].Remove(exc);

        NotifyErrorsChanged("UserName");

Whenever something changes in the collection of errors (here it happens asynchronously, and you’ll see this very well because of the Thread.Sleep() we added earlier), we call the NotifyErrorsChanged method, which in turn calls the ErrorsChanged event.

private void NotifyErrorsChanged(string propertyName)

    if (ErrorsChanged != null)

        ErrorsChanged(this, new DataErrorsChangedEventArgs(propertyName));

In the binding expression, we need to tell Silverlight it has to watch for the ErrorsChanged event being thrown from the bound source object by specifying the ValidatesOnNotifyDataErrors=true.

<TextBox Name="UserNameTextBox" Text="{Binding UserName, Mode=TwoWay,     ValidatesOnNotifyDataErrors=True, NotifyOnValidationError=True}"

/>

The result is, of course, similar:

Customizing the error display

Up until here, we have always used the default way of displaying errors on fields: the red popup containing the error message. It’s very well possible that this default is not a good fit for your application, so we need to change it. The good news is that this validation popup is part of the control template: several controls have a VisualStateGroup called VadiationStates that dictates how the control will look in Valid, InvalidFocused and InvalidUnfocused. InvalidFocused by default shows the red Border, the red triangle in the top right corner and the red popup. InvalidUnfocused hides the popup.

Let’s change this default look. Start by opening the project in Expression Blend 4. Right-click on the UserNameTextBox and select Edit Template --> Edit a copy. Give it a name, for example CustomValidationTemplate. Blend will now enter the template editing mode.

Take a look at the Objects and Timeline window. As the last element in the list, you can see the ValidationErrorElement, the red Border, containing a few other elements, such as the small red triangle appearing when an error is displayed. In the States window, note the ValidationStates stategroup with the above mentioned states.

Since I’m no designer, my custom template may look at bit basic: we will at a red * when the field goes into the invalid state. To do so, make sure the Base state is selected and add a TextBlock in the template, containing the *. In this Base state, set its Opacity to 0.

Now for both the InvalidFocused and InvalidUnfocused, set the Opacity of the TextBlock to 100 and (for demo purposes) set the Opacity of the ValidationErrorElement to 0.

Now run the application again and we can see the custom validation template in action.

Summary

This concludes the overview of validation options currently available in Silverlight 4. The most fundamental option is of course the INotifyDataErrorInfo, which is due to its support for async validation a perfect fit for Silverlight. Validation in Silverlight is ready for real world scenarios!

About the author

Gill Cleeren is Microsoft Regional Director (www.theregion.com ), MVP ASP.NET, INETA speaker bureau member and Silverlight Insider. He lives in Belgium where he works as .NET architect at Ordina. Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF. He also leads Visug (www.visug.be), the largest .NET user group in Belgium. He’s also the author of “Silverlight 4 Data and Services Cookbook”, published by Packt Publishing. You can find his blog at www.snowball.be .

The validation story in Silverlight (Part 1)

editorial@silverlightshow.net (Gill Cleeren ) — Fri, 03 Dec 2010 00:59:00 GMT

This article is compatible with the latest version of Silverlight.

Don't miss...

($0.99)

All SilverlightShow Ebooks

Show more books...

This article is Part 1 of the series “The validation story in Silverlight”.

If one feature is important when it comes to building line-of-business applications, it certainly is validation of business rules. At all levels throughout the application, we need to validate that the data that is entered by the users to verify that it meets the requirements. Some basic validation can be done by the database itself, but most (and in many cases, all) data that it trying to make its way to the database should be validated up front in order not to end up with corrupted data within the data store.

If we think of validation in the ASP.NET world, we can identify 2 places where validation is needed. First, we try validating user input using JavaScript on the client-side (perhaps using one of the built-in validation controls). This ensures quick feedback to the user, preventing him from having to wait for a post-back to the server in which we can do server validation of the data. However, we can’t just rely on the fact that JavaScript is enabled (and therefore risk that users can go around our validation rules) so server-side validation is needed as well. The latter of course requires us to post back to the server, after which we can send back the errors to the user, if any, for example using a validation summary.

When doing validation in Silverlight, things are a bit different. Because everything runs on the client and we want to give the user the richest experience on that client, we need to make sure that validation that we build in, adds to that rich experience as well. Immediate feedback where possible is one of the things that comes to mind: we don’t want the user to have to wait for validation to happen on the server. Instead, where possible, we want to display validation messages as soon as the user leaves the field or clicks on a button.

The validation story in Silverlight up until version 4 was somewhat lacking in features. While Silverlight 3 had some options available, they were not really enough for real-world applications. That changed with Silverlight 4, mainly because of the introduction of 2 new interfaces, namely the IDataErrorInfo and the INotifyDataErrorInfo. The first one may sound familiar as it already exists for WinForms validation. The latter will be helpful in situations where we need to perform calls to the server and return asynchronous validation results.

This is a two-part article. The code for this first part article exists of some samples that we are using to explain the features and can be downloaded here.

Overview of the validation options in Silverlight 4

As mentioned in the previous paragraph, Silverlight 3 had limited options to validate user input whereas Silverlight 4 added to this quite a lot. To start, here’s a brief overview of the options we have at our disposal today:

Type

Property

Throw exceptions in your setters

Enable ValidatesOnExceptions

IDataErrorInfo

Enable ValidatesOnDataErrors

INotifyDataErrorInfo

Enable ValidatesOnNotifyDataErrors

If you want the errors to be passed on in the hierarchy

Enable NotifyOnValidationError

We’ll start this overview by looking at the “throwing exceptions” option (that is, the Silverlight 3 option).

Silverlight 3 validation options

Validation in Silverlight 3 is limited to working with 2 properties on a data binding expression: ValidatesOnExceptions and NotifyOnValidationErrors.

When we apply ValidatesOnExceptions, when we try to update a value using data binding (that is, a TwoWay binding, since we are pushing data from the target control to the source property), Silverlight will check if any exceptions are being thrown, for example trying to enter a string into a numeric field. If an exception happens, Silverlight’s data binding engine will create ValidationError and add this error to the Validation.Errors collection of the target control (that is the UI element we are applying the binding on). If we want to receive notifications that these exceptions occurred, we need to set NotifyOnValidationErrors to true as well.

Let’s look at the obligatory “Binding to a Person object” person to show this type of validation. The Person class itself has just two string and one integer properties.

public class SimplePerson

    private string _firstName;

    private string _lastName;

    private int _age;

    public string FirstName

get

            return _firstName;

set

            if (value.Length == 0)

                throw new Exception("First name length can not be 0");

            _firstName = value;

    public string LastName

get

            return _lastName;

set

            if (value.Length == 0)

                throw new Exception("Last name length can not be 0");

            _lastName = value;

    public int Age

get

            return _age;

set

            _age = value;

Note that the FirstName and LastName throw an error if the value entered by the user is an empty string. The parameter for the Exception is the error message we want to show to the user. The Age property, since it’s of type int, will throw an error if we try to enter a string.

The data binding expressions are now defined with the above mentioned properties, as can be seen in the code below.

<TextBox Name="FirstNameTextBox" Text="{Binding FirstName, Mode=TwoWay,     ValidatesOnExceptions=True, NotifyOnValidationError=True}"

/>

<TextBox Name="LastNameTextBox" Text="{Binding LastName, Mode=TwoWay,     ValidatesOnExceptions=True, NotifyOnValidationError=True}"

/>

<TextBox Name="AgeTextBox" VerticalAlignment="Top" Text="{Binding Age, Mode=TwoWay,     ValidatesOnExceptions=True, NotifyOnValidationError=True}"

/>

This results in Silverlight automatically showing the default behavior for an exception being raised:

This default look is implemented within the control template on most controls within Silverlight. We’ll look later how we can override this and apply our own type of look and feel for this error reporting.

Adding attributes

If we have to write Exceptions ourselves for all validation, this can become quite a cumbersome task. To solve this somewhat, it’s possible to include attributes on the properties. These validation attributes include most common types of validation, including Required fields and StringLength. When applying these, the validation engine will work in the exact same way, as can be seen below. First, the updated Person class.

[Required]

[StringLength(50)]

public string FirstName

get

        return _firstName;

set

        if (_firstName != value)

            _firstName = value;

[Required]

[StringLength(50)]

public string LastName

get

        return _lastName;

set

        if (_lastName != value)

            _lastName = value;

[Range(1, 120)]

[Required]

public int Age

get

        return _age;

set

        if (_age != value)

            _age = value;

If we try our exact same sample again now, we’ll notice that the binding won’t display an error, even though we have applied the attributes. Instead, we need to trigger the validation to happen. We can do this using the ValidationContext.ValidateProperty, passing in the name of the property we want to validate. By applying this in the setters of the properties, we can use it to trigger all attributes to be validated.

[StringLength(50)]

public string FirstName

get

        return _firstName;

set

        if (_firstName != value)

            Validator.ValidateProperty(value, new ValidationContext(this, null, null)

                { MemberName = "FirstName" });

            _firstName = value;

[Required]

[StringLength(50)]

public string LastName

get

        return _lastName;

set

        if (_lastName != value)

            Validator.ValidateProperty(value, new ValidationContext(this, null, null)

                { MemberName = "LastName" });

            _lastName = value;

[Range(1, 120)]

[Required]

public int Age

get

        return _age;

set

        if (_age != value)

            Validator.ValidateProperty(value, new ValidationContext(this, null, null)

                { MemberName = "Age" });

            _age = value;

Custom rules

One attribute deserves some special attention: the CustomAttribute. Using this attribute, we can define custom methods to perform more advanced business rule validation. It accepts two parameters by default: the type that contains the validation methods and the validation method you want to use on the property. Let’s look at an example on the Age property (agreed, the rule can be done using the Range attribute as well, but I hope you get the point). Note that the method returns a ValidationResult. If everything runs fine, we return ValidationResult.Success; otherwise, we create a new ValidationResult, passing in the custom message we want to display. Note also that it’s easy to localize these error messages here to return translated strings for the exceptions.

public class CustomAgeValidator

    public static ValidationResult ValidateAge(int age)

        if (age < 120 && age > 0)

            return ValidationResult.Success;

        else if(age < 0)

            return new ValidationResult("You can't have a negative age!");

        else

            return new ValidationResult("You are too old!!");

The CustomAttribute can now be used as such:

[Required]

[CustomValidation(typeof(CustomAgeValidator), "ValidateAge")]

public int Age

get

        return _age;

set

        if (_age != value)

            Validator.ValidateProperty(value,

                new ValidationContext(this, null, null) { MemberName = "Age" });

            _age = value;

And here we see the custom validator in action, including the custom error message:

Summarizing all errors with the ValidationSummary

Instead of displaying errors only on the fields, a separate control can help us displaying all errors on a central location: the ValidationSummary. This control, which lives in the System.Windows.Controls namespace, will display object and property errors in a list (each item in this list is of type ValidationSummaryItem and can be template).When clicking on an item, the ValidationSummary control will try to apply focus on the control that caused the error, giving the user a better experience when fixing errors in a form. For the control to pick up on the errors, the NotifyOnValidationErrors should be set to true. This causes the binding to raise a notification event for the failing validation.

The code does not need a lot of changes. In fact, we can just add the ValidationSummary and it will work as expected.

<TextBox Name="FirstNameTextBox" Text="{Binding FirstName, Mode=TwoWay,     ValidatesOnExceptions=True, NotifyOnValidationError=True}"

/>

<TextBox Name="LastNameTextBox" Text="{Binding LastName, Mode=TwoWay,     ValidatesOnExceptions=True, NotifyOnValidationError=True}"

/>

<TextBox Name="AgeTextBox" VerticalAlignment="Top" Text="{Binding Age, Mode=TwoWay,     ValidatesOnExceptions=True, NotifyOnValidationError=True}"

/>

<sdk:ValidationSummary Grid.Row="3" Grid.ColumnSpan="2">sdk:ValidationSummary>

Summary

With that, we have seen the basic validation capabilities of Silverlight. As mentioned, these are where Silverlight 3 leaves of and honestly, we need more. All what is explained here of course works in the latest version as well. On top of that, Silverlight 4 added some nice features. In the second part, we’ll look at some more advanced concepts, such as the IDataErrorInfo.

WCF RIA Services Part 6 - Validating Data

editorial@silverlightshow.net (Brian Noyes ) — Thu, 26 Aug 2010 06:06:00 GMT

Watch recordings of Brian's WCF RIA Services webinars:

Querying & Updating Data From Silverlight Clients with WCF RIA Services (Feb 03, 2011)
WCF RIA Services Validation (Mar 17, 2011)
Secure and Personalize Your Silverlight App with WCF RIA Services (May 26, 2011)
WCF RIA POCO Domain Services (Sep 29, 2011)

Don't miss...

All SilverlightShow Ebooks

This article is Part 6 of the series WCF RIA Services.

Introduction

In Part 5 I discussed metadata classes and shared code, and one of the example uses of metadata classes I showed was using a [Required] validation attribute to cause some validation on both the client and server side. In this article, I will dive into more depth on the various ways you can validate data using WCF RIA Services. I’m going to look at four ways of validating input data:

Using built-in validation attributes from the System.ComponentModel.DataAnnotations namespace
Using custom validation attributes to invoke custom logic on the server and client side for cross property validation
Using server side validation when changes are submitted to the back end
Doing asynchronous validation using a domain service invoke operation

To demonstrate these things in the application context that I have been building up over the last 5 articles, I needed to add some more functionality. That functionality included some small schema changes to the database, so a new database creation script is included with the download code to create an appropriate database schema with some minimal sample data to be able to run the application. Because I am continuing to keep the focus on WCF RIA Services capabilities and not on general Silverlight display functionality, the display of some of the validation errors in the sample is necessarily crude to keep the changes to the app to a minimum and to keep the article length digestible.

The new functionality includes the ability to add customers (and there are a couple defined in the DB script so you don’t have to add any to get started), as well as select a customer associated with a given Task. There are validations associated with the definition of a Customer, as well as for creating time entries associated with a task that has a customer, described in more detail later in the article.

The finished code for this article can be downloaded here.

Data Annotation Validation Attributes

As mentioned last time, WCF RIA Services has rich built-in support for the validation attributes in the System.ComponentModel.DataAnnotation namespace. These attributes include the ability to specify simple forms of validation on entity properties by adding an attribute to an entity property. If your entity model is one where you cannot modify the properties directly (such as the code generated entities of Entity Framework), you can place the validation attributes on the properties of your metadata class. Those validation attributes will be used for server side validation by WCF RIA Services, and they will also be used client side because the client generated entities will have those attributes on their properties.

The available validation attributes include:

Required
StringLength (added by Entity Framework for string fields and therefore generated on the client)
Regular Expressions
Range (for numeric inputs)

There are a few others in the namespace that you might want to look into that purely affect display, but I won’t go into details of those in this article.

To apply them when using an entity framework model, you again just add them to the properties of your metadata class.

The generated client code will include those defined in your metadata class, as well as any defined on the model entities themselves, such as the [StringLength] attributes added by Entity Framework for string fields in the database.

As an example of using one of these attributes, a Customer has a Phone property that is a string, but needs to follow a proper format for a phone number. A regular expression is a great way of checking this kind of thing. So the metadata class for my Customer entity type includes the following attribute on the Phone property:

 [MetadataTypeAttribute(typeof(Customer.CustomerMetadata))]

 public partial class Customer

     internal sealed class CustomerMetadata

...

         [RegularExpression(@"^\D?(\d{3})\D?\D?(\d{3})\D?(\d{4})$", ErrorMessage="...")]

         public string Phone { get; set; }

...

You can see the only challenge in using the regular expression validation is in coming up with the right regular expression. The one I am using here allows several formatting variants of US phone numbers (3 digits, 3 digits, 4 digits with variations on delimiters in between).

Just by having that attribute on the server entity or its metadata class, it shows up on the code generated client entity. Additionally, the WCF RIA Services Entity base class that is added to the client entity has an implementation of INotifyDataErrorInfo that uses the data annotation attributes to perform validation when data bound in the UI. So just by adding these attributes with appropriate error messages, you get validation indications for the user like shown below.

The error message shown on the Phone input TextBox happens automatically when the focus leaves the control. In the sample code, I used a behavior to cause the binding to update on each keystroke to get more immediate feedback to the user. The error message shown is the one specified in the server side attribute. You can also see that I added a ValidationSummary control to the form. That is to display when there is more than one validation error on the form at a time, which will come into play in the next section.

Custom Validation Attributes

In addition to the pre-built validation attributes discussed in the last section, there is a [CustomValidation] attribute in the data annotations namespace that allows you to point to a static method you can define to perform any kind of custom logic you need to validate when a property is set. That may involve doing some calculation or conditional logic, but ultimately you are deciding whether the newly input values are valid. Keep in mind that if you put these attributes on the server side entity or its metadata class, you will need to ensure that the code defined in the custom validation will be able to execute on both the client and server side. So you would not want to put code in there that does a look up against the database for example. I’ll show examples of how to deal with that kind of validation in the next two sections.

One place custom validations come in very handy is for cross-property validations. When the validity of one property’s value depends on the value of another property on the same object, or possibly the values of some of the child objects or a parent object, you can accommodate this fairly easily using custom validation.

In the Customer class for the sample, I added a contrived property called HasPhone. The simple idea here is that if HasPhone is set to true, then a valid phone number should be supplied. If HasPhone is set to false, no phone number should be supplied. This validation should be triggered whenever either property is modified, and both properties can be displayed as having a validation error when they are out of sync. You can see this in action below. Notice that both input controls (Phone TextBox and HasPhone CheckBox) are indicating a validation error, and there are two errors shown in the ValidationSummary control.

To support this, you first define the validation method that you want to point to from the [CustomValidation] attribute. That method has to have a particular signature, specifically it must be public, return a ValidationResult, and take in a value and a ValidationContext. If you are doing two properties with different types on the properties like I am here, you can break it down into two methods with each value having the appropriate type, even if they share some validation code:

 public class CustomerPhoneValidator

     public static ValidationResult CrossValidatePhoneWithHasPhone(string newPhone, ValidationContext context)

         Customer customer = context.ObjectInstance as Customer;

         if (customer == null) return ValidationResult.Success;

         bool hasPhone = customer.HasPhone;

         string phone = newPhone;

         return ValidatePhoneAndHasPhone(hasPhone, phone);

     public static ValidationResult CrossValidateHasPhoneWithPhone(bool newHasPhone, ValidationContext context)

         Customer customer = context.ObjectInstance as Customer;

         if (customer == null) return ValidationResult.Success;

         bool hasPhone = newHasPhone;

         string phone = customer.Phone;

         return ValidatePhoneAndHasPhone(hasPhone, phone);

     private static ValidationResult ValidatePhoneAndHasPhone(bool hasPhone, string phone)

         if (hasPhone && string.IsNullOrWhiteSpace(phone))

             return new ValidationResult(@"If the customer has a phone, the number must be specified",

                 new string[] { "HasPhone", "Phone" });

         else if (!hasPhone && !string.IsNullOrWhiteSpace(phone))

             return new ValidationResult(@"If the customer does not have a phone, the number should not be specified",

                 new string[] { "HasPhone", "Phone" });

         else

             return ValidationResult.Success;

You can see that I have two validation methods, one for the boolean HasPhone property and one for the string Phone property. Other than the type of the value, the signature of the methods is the same. You can see that the ValidationContext argument that is passed to your method allows you to get a reference to the whole object that the property being validated is on, allowing you to get to other properties on that object. At the point where your validation method is being called, the target property (i.e. Phone) has not been set on the object itself yet. The value being passed in to your validation method is the proposed new value, and it is up to your method to decide whether to allow it to be set or not. If you are fine with the value being set, you just return a ValidationResult.Success value. If you do not like the value, then you can return a ValidationResult with an error string populated and optionally a string array containing all of the property names affected by the error. This is how you can address cross-property validation scenarios like the one here. If no phone or an invalid phone number is supplied, I can check to see if the HasPhone property is set to true. If so, both Phone and HasPhone are in error because they have to agree with respect to their supplied values.

To apply the custom validation to a property, you just use a [CustomValidation] attribute:

 [MetadataTypeAttribute(typeof(Customer.CustomerMetadata))]

 public partial class Customer

     internal sealed class CustomerMetadata

...

         [CustomValidation(typeof(CustomerPhoneValidator),"CrossValidatePhoneWithHasPhone")]

         [RegularExpression(@"^\D?(\d{3})\D?\D?(\d{3})\D?(\d{4})$", ErrorMessage="...")]

         public string Phone { get; set; }

         [CustomValidation(typeof(CustomerPhoneValidator), "CrossValidateHasPhoneWithPhone")]

         public bool HasPhone { get; set; }

...

In this case I have a separate attribute for the regular expression and the cross-property validation for demonstration purposes. That will result in two different errors at times. For a more user friendly experience, as long as you are writing custom validation logic for a property tied in with the [CustomValidation] attribute, you might want to move that format validation inside the custom validation logic so that you only return one error at a time from a single control value.

Server-Side Validation

Some kinds of validation are not appropriate to do on the client side. You may have data you need to look up on the back end that you don’t want to expose to the client that will drive the decision of whether a given chunk of data is valid or not. For the sample application, I added the ability to look up a customer status on a customer when a task is saved. If the customer status (which I don’t want exposed to the client so that it doesn’t get inadvertently displayed in the client) is marked as “DeadBeat” status, then I want to limit the number of billable hours I accrue for that customer. So at the point where I go to save a task on the back end, I need to look up the customer status and see how many hours have been added to the modified Task as child TimeEntries and decide whether to accept that task for update. If I don’t want to accept it, I can throw a ValidationException from the update method, and validation errors will be added to the entity in the client application and can be displayed in various ways.

To facilitate this scenario, it did require a change to my object model. I talked briefly about the [Composition] attribute in the last article. In order to have the TimeEntries sent down with the Task even if they have not changed themselves (such as when a customer has just been assigned to the Task), I needed to switch to having the TimeEntries collection on the Task be a [Composition] relationship. When you do that, the TimeEntries become wholly owned by their parent Task, and you don’t submit updates to individual time entries the way the application was doing in the last couple articles. Now you just get updates to tasks, and those changes might involve changes to the discrete properties of the task, the assignment of a related customer (which is not a Composition relationship because customers can be independently queried and updated) or the addition/removal/change of a time entry within the child TimeEntries collection of the Task. You can check out the UpdateTask method in the domain service to see the way this altered the coding patterns. Basically you have to do some state detection yourself and call the appropriate parts of the data access API (Entity Framework in this case) to manage the inserts/updates/deletes of your child objects in a composition relationship.

By going with a composition relationship, though, now all the child TimeEntries are sent down with a modified task and you can evaluate the package as a whole for server side validation. So the update and insert methods for Tasks call a helper method that first does the server side validation:

 private void ValidateCustomerHours(Task task)

     if (task.CustomerId.HasValue)

         int customerId = task.CustomerId.Value;

         bool timeAllowed = IsTotalTimeAllowed(customerId, task.TotalTime);

         if (!timeAllowed)

             throw new ValidationException(

                 "You cannot enter more than 10 hours per billing cycle for this customer.");

 [Invoke]

 public bool IsTotalTimeAllowed(int customerId, TimeSpan totalTime)

     Customer relatedCustomer = ObjectContext.Customers.Where(c => c.CustomerId == customerId).FirstOrDefault();

     if (relatedCustomer != null && relatedCustomer.Status == "Deadbeat"

         && (totalTime > TimeSpan.FromHours(10)))

         return false;

     return true;

If I wrote the client so that it did not validate the max hours for a customer on the client side before sending the task to the back end for updating or inserting, this code would be invoked and would throw the ValidationException back to the client. On the client side, WCF RIA Services would add a ValidationError to the Task and it could be displayed by the build in validation mechanisms of Silverlight Controls.

Async Validation through Invoke Methods

When it comes to validation, it is generally better to let the user know as early as possible when they have entered invalid data instead of waiting until a later point such as when they have tried to send that invalid data to the back end for persistence. A decent way to do this in WCF RIA Services is to use an [Invoke] method on your service. In addition to the CRUD methods you can expose on a WCF RIA Service, you can also add arbitrary methods that you mark with an [Invoke] attribute. These too will be exposed as service methods to the client and will show up on the corresponding domain context. They can pass different types than the main entities that the domain service is managing as entities, but there is a restricted set of types that you can pass as parameters and return types. The WCF RIA Services enumerates the types that can be used as parameters and return types on domain service methods.

To support more immediate feedback to the user for the case of entering too many hours for a customer with bad status, I added the IsTotalTimeAllowed method that you can see in the code snippet in the previous section. That method is being used both internally by the server side validation, and can be called directly from the client as well. In the client side view model, at the point where the user has entered a new time entry, I can make a call to that service method to check whether the new time entry will exceed the max allowed hours.

 TimeEntry entry = popup.DataContext as TimeEntry;

...

 if (SelectedTask.CustomerId.HasValue)

     TasksDomainContext context = new TasksDomainContext();

     Actionbool>> action = delegate(InvokeOperation<bool> op)

...

         if (entry != null) SelectedTask.TimeEntries.Add(entry);

...

};

     context.IsTotalTimeAllowed(SelectedTask.CustomerId.Value,

         SelectedTask.TotalTime + (entry.EndTime - entry.StartTime), action, null);

As you can see, the invoke method shows up on the domain context as a normal async service method. You can pass a callback delegate of type InvokeOperation, where T is the return type of the invoke method, and that callback will be invoked when the async call is complete. You get the same thread marshalling back to the UI thread that you do with Load and SubmitChanges operations, so you don’t have to do any thread marshaling yourself.

You can see the full implementation with some (crude) user prompting in the sample application in the download code.

Summary

The built in validation support in WCF RIA Services is one of the more compelling features that makes me want to use WCF RIA Services for most data-oriented situations in Silverlight. The ease of using data annotation attributes to express simple validation rules or custom validation attributes to tie in more complex validations covers a large number of validation scenarios nicely. Add to that the ability to invoke whatever logic you need from your domain service CRUD methods and Invoke methods on the back end and you have a nice end to end solution for handling validation. The fact that WCF RIA Services takes care of adding the validation errors to the entities on the client side and implements INotifyDataErrorInfo on those entities to participate nicely with the data binding features of Silverlight just rounds it all out into a very powerful part of WCF RIA Services.

The complete code for this article can be downloaded here.

About the Author

Brian Noyes is Chief Architect of IDesign, a Microsoft Regional Director, and Connected System MVP. He is a frequent top rated speaker at conferences worldwide including Microsoft TechEd, DevConnections, DevTeach, and others. He is the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding in Windows Forms 2.0. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on twitter @briannoyes.

WCF RIA Services Part 4 - Integrating with the Model-View-ViewModel Pattern

editorial@silverlightshow.net (Brian Noyes ) — Tue, 03 Aug 2010 02:51:00 GMT

Watch recordings of Brian's WCF RIA Services webinars:

Querying & Updating Data From Silverlight Clients with WCF RIA Services (Feb 03, 2011)
WCF RIA Services Validation (Mar 17, 2011)
Secure and Personalize Your Silverlight App with WCF RIA Services (May 26, 2011)
WCF RIA POCO Domain Services (Sep 29, 2011)

Don't miss...

All SilverlightShow Ebooks

This article is Part 4 of the series WCF RIA Services.

Introduction

The Model-View-ViewModel pattern (MVVM) is a very popular approach for building more loosely coupled Silverlight and WPF applications. I won’t attempt to full define and explain the pattern here, but will give a quick explanation of what it is about and why you would want to use it. At a high level, MVVM is an alternative or evolution of MVC and MVP patterns, but taking full advantage of the rich data binding, commands, and behaviors that we have available to us in Silverlight and WPF. The view model’s primary responsibility is to offer up state to the view in the way the view wants to see it. It exposes properties that the view can easily bind to that let the view display the data it needs and to also hook up commands and behaviors that point back to the view model to invoke interaction logic that the view model encapsulates. The view model is all about containing and manipulating the data that the view needs and providing the interaction logic to support the view. The view model acts as a translator from the complex world of the overall application model to the specific set of data that a single view needs, structured in the way the view needs to display it. Structurally, you typically set the view’s DataContext equal to an instance of the view model so that the view can easily bind to the exposed properties of the view model. There are many ways to get this hook up done.

The motivations for using it include the fact that it allows you to work on the view and the view model mostly in isolation, facilitating developer/designer workflow. Additionally, by separating your interaction logic into the view model, you can more easily unit test that logic because it is not tightly woven with the UI itself. And finally, the pattern just provides a clean separation of responsibility so the view can just be about the structure and visual behavior of what you see on the screen, and the view model can just be about the data and logic surrounding the data that the view needs to support it. For more in depth coverage, I recommend you read Josh Smith’s excellent article on MVVM, as well as the guidance being developed by the Microsoft patterns & practices Prism team in Prism 4 at http://prism.codeplex.com/. Prism 4 is due out in the September/October timeframe but there are already public drops in the downloads section on CodePlex.

So now let’s see how MVVM fits with WCF RIA Services. The starting point code for this article will be the sample code from Part 3 of the series, which you can download here. You can download the finished code for this article here.

Step 1: Factor out a view model

In the last article’s version of the TaskManager application, I was already starting to have a fair amount of code building up in the code behind of the view (the MainPage user control), even with such a simple application. The first step is to factor that code out into a view model. Create a new class named TasksViewModel in the project. Often a good way to get started defining your view model is to analyze the view and determine what properties would be needed to support it. The image below shows the form as it is currently defined. To clean things up a bit, I’ve replaced the two TextBoxes for date input at the top with DatePickers, removed the unused properties on the Task from the DataGrid, and reordered the columns to look a little better.

By looking at the UI design, you can identify 6 properties the view model should expose to support this view: two DateTime properties for lower and upper dates for a search; three commands to support searching by date, adding a task, and saving changes; and one Tasks collection. In its simplest form, that would look like this:

 public class TasksViewModel

 {

     public DateTime LowerSearchDate { get; set; }

     public DateTime UpperSearchDate { get; set; }

     public ICommand SearchByDateCommand { get; set; }

     public ICommand AddTaskCommand { get; set; }

     public ICommand SaveChangesCommand { get; set; }

     public IEnumerable Tasks { get; set; }

 }

However, you generally need to implement INotifyPropertyChanged on your view model which requires the expanded syntax for each property so that the UI can stay fresh through its data bindings if the bound property on the view model changes, so each property definition should look more like this in its full form, except possibly the private set properties that the view model sets once and does not change.

 public class TasksViewModel : INotifyPropertyChanged

 {

     public event PropertyChangedEventHandler PropertyChanged = delegate { };

     DateTime _LowerSearchDate;

     public DateTime LowerSearchDate

     {

         get

         {

             return _LowerSearchDate;

         }

         set

         {

             if (value != _LowerSearchDate)

             {

                 _LowerSearchDate = value;

                 PropertyChanged(this, new PropertyChangedEventArgs("LowerSearchDate"));

             }

         }

     }

To support the ICommand properties, you will need a decent command implementation. I’ve included a simple RelayCommand implementation, but normally in real projects I use the DelegateCommand from Prism.

A view model is all about managing the data needed by a view, and a DomainContext in RIA Services is all about providing and tracking changes to the data, so a simple approach to using RIA Services with MVVM is to simply use a DomainContext within your view model.

 TasksDomainContext _Context = new TasksDomainContext();

 public TasksViewModel()

 {

     SearchByDateCommand = new RelayCommand<object>(OnSearchByDate);

     AddTaskCommand = new RelayCommand<object>(OnAddTask);

     SaveChangesCommand = new RelayCommand<object>(OnSaveChanges);

     Tasks = _Context.Tasks;

     if (!DesignerProperties.IsInDesignTool)

     {

         _Context.Load(_Context.GetTasksQuery());

     }

 }

Here I have made the TasksDomainContext a member of the view model, and initialized the commands in the constructor to point to methods within the view model. The Tasks property exposed by the view model just holds a reference to the Tasks entity collection exposed by the domain context, which will raise INotifyCollectionChanged events to keep the view fresh when the collection changes, which will happen on the initial load, when you add Tasks, and when SubmitChanges completes and has updated entities from the back end. Notice the use of the DesignerProperties.IsInDesignTool property to prevent calling Load in the designer, which would break it.

Next is to move the methods that were in the code behind of MainPage into the view model. I’ve cleaned them up a bit in the process too. Note that the search method now leverages the deferred execution I talked about in Part 3, making the GetTasksByStartDate domain service method unnecessary since the client can specify that search expression itself. I’ve also moved the creation of a new Task into a simple popup ChildWindow so you can actually edit the values. Note the commend in the code below – showing a dialog from a view model is really a no-no, just doing it here because the focus is on RIA Services, not on full MVVM patterns.

 private void OnSearchByDate(object param)

 {

     _Context.Tasks.Clear();

     EntityQuery query = _Context.GetTasksQuery();

     LoadOperation loadOp = _Context.Load(query.Where(t => t.StartDate >= LowerSearchDate && t.StartDate <= UpperSearchDate));

 }

 private void OnAddTask(object param)

 {

     // Generally don't want to do this for testability reasons

     // Simplification because MVVM structuring is not the focus here

     // See Prism 4 MVVM RI for a cleaner way to do this

     AddTaskView popup = new AddTaskView();

     popup.DataContext = new Task();

     popup.Closed += delegate

     {

         if (popup.DialogResult == true)

         {

             Task newTask = popup.DataContext as Task;

             if (newTask != null) _Context.Tasks.Add(newTask);

         }

     };

     popup.Show();

 }

 private void OnSaveChanges(object param)

 {

     _Context.SubmitChanges();

 }

At this point you have you have a functioning view model, now I’ll clean up the view to work with the view model.

Step 2: Hook up the view to the view model

From Part 1, the view was using the DomainDataSource that was generated from the drag and drop. If you want a clean MVVM design, you will unfortunately have to pass on using DomainDataSource. That object is effectively putting state management and query logic into the XAML itself, which violates the clean separation of responsibilities followed in MVVM.

So basically I took the existing view, deleted out the DomainDataSource, and added appropriate bindings to each of the controls to bind to the exposed view model properties as shown below. For a top level view like this, constructing the view model in the XAML to set it as the data context is a simple way to get the view’s data context set to an instance of the view.

 <UserControl x:Class="TaskManager.MainPage" ...>

     <UserControl.DataContext>

         <local:TasksViewModel/>

     UserControl.DataContext>

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

         <sdk:DataGrid ItemsSource="{Binding Tasks}" .../>

         <Button Command="{Binding SearchByDateCommand}" .../>

         <Button Command="{Binding AddTaskCommand}" ... />

         <Button Command="{Binding SaveChangesCommand}" ... />

         <sdk:DatePicker SelectedDate="{Binding LowerSearchDate}" ... />

         <sdk:DatePicker SelectedDate="{Binding UpperSearchDate}" ... />

     Grid>

 UserControl>

Lastly, remove all the code from the code behind of the view, since it is no longer being used (all the button click handlers were removed in the process of hooking of the commands with bindings to the view model properties).

 public partial class MainPage : UserControl

 {

     public MainPage()

    {

         InitializeComponent();

     }

 }

Summary

The simplest way to use WCF RIA Services with the MVVM pattern is to stop using the DomainDataSource in your views and to use a domain context as the repository of data for your view models. You can still leverage the drag and drop Data Sources window features, you just have to do a little clean up to delete off the DomainDataSource after the drop and touch up the bindings a little.

There are two downsides to the approach as I have shown it here: testability and separation of concerns. One of the benefits of the MVVM pattern is supposed to be unit testability. But with a concrete type dependency on the domain context type in your view model, you are out of luck for mocking out that dependency. There are two approaches possible to address this:

Use dependency injection to provide the domain context to the view model, and create a mock DomainClient and pass it to the DomainContext. This allows your view model to keep using the full functionality of the DomainContext, but you are able to mock out the calls to the service underneath the DomainContext. This approach is outlined in this post. I’ll be providing an example in Part 8 of this series, which is focused on testability.
Factor out the DomainContext to a repository service that defines an interface similar to the DomainContext API and consume that from the view model. This would allow you to mock your repository service that contains the domain context. It would also address the separation of concerns problem, because then you would be separating the implementation choice of using RIA Services from the view model, which should really be separated. However, you would give up a lot of flexibility in the view model and it would not be an easy repository implementation.

Neither of these approaches is particularly easy. I’ll cover them in more detail later in part 8, and may blog some more on this topic as well. That’s all for now. You can download the finished code for this article here. See you next time.

About the Author

Data Driven Applications with MVVM Part III: Validation, Bringing the UI Closer

editorial@silverlightshow.net (Zoltan Arvai ) — Thu, 17 Jun 2010 07:29:00 GMT

Don't miss...

This series is now available as a fully offline resource:

($0.99)

All SilverlightShow Ebooks

This article is compatible with the latest version of Silverlight.

Introduction

In this short series of articles I’ll cover what MVVM is and how to use it in practice, how to solve issues when applying this pattern and how to take advantage from it.

In the previous articles we created a simple master details scenario with the MVVM pattern. We used mock and live data sources with WCF, we created unit tests, we used Messaging from the MVVM Light Toolkit.

By now, we have an application that communicates with a server, and we know how to send data back to a server. This raises another questions like, are we sending back valid data?

Validation in MVVM

Let’s think about this a little bit. How and what do we want to validate? Let’s see. We have an Author, a Title, and a Price. Well we can set the price property to a negative value, which is probably not a valid scenario. In Silverlight 3 we can do validation in property setters. What we basically do is throwing exceptions in the setter if the value is not valid. This kind of validation has two problems.

You throw exceptions to validate in property setters…. well… yeah…
You can’t support full entity validation. You need to do workarounds to support that scenario.

Well, in Silverlight 4 we have an IDataErrorInfo interface, that supports validation, without throwing exceptions. Also you can centralize your validation rules.

Let’s validate the Price property! If the price is lower than zero, then this value is invalid.

 //Modify the BookDetailsViewModel class to implement IDataErrorInfo

 public class BookDetailsViewModel : ViewModelBase, IDataErrorInfo

 //Implement IDataErrorInfo

 public string Error

 {

     get { return null; }

 }

 public string this[string columnName]

 {

     get 

     {

         if (columnName == "Price")

         {

             //We have a validaton error

             if (Price < 0) return "Price must be positive";

         }

         //Everthing is okay

         return null;

     }

 }

Also you have to modify the binding for the textbox displaying the price. You need to add the ValidatesOnDataErrors=True option, to enable the use of IDataErrorInfo based validation.

 <TextBox Grid.Column="1" TextWrapping="Wrap" Grid.Row="2" d:LayoutOverrides="Height" 

          VerticalAlignment="Center" Margin="15,0"

          Text="{Binding Price, Mode=TwoWay, ValidatesOnDataErrors=True}"/>

You can create you own validation handler classes and centralize the validation logic as much you want. However this kind of validation supports synchronous validation only. Which means, the binding happens, the validation happens and that’s it. If there is a later change in the validation state, this scenario cannot be applied. Let me give you an example. You have the Title property. Let’s assume we have an Update operation. When we update a book, we have to make sure, that the new title we enter is not the same as any other title. The title should be unique (well not in real life, but right now it does :D). You can’t validate this one on the client side! You have thousands of books in the database. You have to run a check against a huge amount of data and it might take more than a second. Which means that when the user sets the title property, we should let him do it. But immediately we should run an asynchronous check to validate the title. If the check’s result is that the title entered is not valid, then we have to indicate it somehow.

Also what if I need more detailed error report, not just a simple string? What if a change in a property changes another property bound to the UI and now the other property’s value is invalid? I should indicate it somehow.

IDataErrorInfo does not support these scenarios. Fortunately there is an other interface that supports all these scenarios. It’s called INotifyDataErrorInfo.

This is a little bit more complex, so let’s go step by step.

 public interface INotifyDataErrorInfo

 {

     bool HasErrors { get; }

     event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

     IEnumerable GetErrors(string propertyName);

 }

There are two very important members here The ErrorsChanged event, and the GetErrors method!

GetErrors() returns a list of errors of a specific property, it can be a list of strings, or a list of custom objects, it’s up to us. The ErrorsChanged event should be raised whenever a new validation error should be added, or a validation error should be removed. How you handle the validation errors’ list is pretty much up to you.

Let’s implement it. However this will need a lot of additional code that is not specific to a certain ViewModel, so most of the code, I’ll put into an extended ValidatingViewModelBase class which implements INotifyDataErrorInfo interface and inherits ViewModelBase.

First I’ll need a list that can contain the errors for each property.

 public class ValidatingViewModelBase : ViewModelBase, INotifyDataErrorInfo

 {

     //Key is propertyName, value is list of validation errors

     protected Dictionary<string, List<string>> errorList = new Dictionary<string, List<string>>();

The key of the dictionary is the name of the property. The Value is a list of errors represented by simple strings.

I have an error if I have something in the Values inner collection.

 public bool HasErrors

 {

     get

     {

         //If there is any validation error

        return errorList.Values.Count > 0;

    }

 }

Now I need to implement the GetErrors() method:

 /// 

 /// Gets the list of validation errors for a property

 /// 

 /// Name of the propety

 public System.Collections.IEnumerable GetErrors(string propertyName)

 {

     CheckErrorCollectionForProperty(propertyName);

     //return related validation errors for selected property.

     return errorList[propertyName];

 }

 protected void CheckErrorCollectionForProperty(string propertyName)

 {

     //First time to get the validation errors of this property.

     if (!errorList.ContainsKey(propertyName))

     {

         errorList[propertyName] = new List<string>();

     }

 }

The CheckErrorCollectionForProperty() method’s responsibility is to check whether the property is already registered in the error collection. If not, than it should do it, and assign an empty string list as a value, to store the list of validation errors. The GetErrors() method now returns with the list of errors associated with the property name.

Now we need ways to add and remove validation errors.

 /// 

 /// Add a validation error to a property name.

 /// 

 /// Name of the property

 /// The validation error itself

 protected void AddError(string propertyName, string error)

 {

     CheckErrorCollectionForProperty(propertyName);

     errorList[propertyName].Add(error);

     RaiseErrorsChanged(propertyName);

 }

 /// 

 /// Remove a specific validation error registered to a property name.

 /// 

 /// Name of the property

 /// The validation error itself

 protected void RemoveError(string propertyName, string error)

 {

     if (errorList[propertyName].Contains(error))

     {

         errorList[propertyName].Remove(error);

         RaiseErrorsChanged(propertyName);

     }

 }

 /// 

 /// Notifies the UI of validation error state change

 /// 

 /// The name of the property that is validated

 protected void RaiseErrorsChanged(string propertyName)

 {

     if (ErrorsChanged != null)

     {

         ErrorsChanged(this, new DataErrorsChangedEventArgs(propertyName));

     }

 }

The Add method makes sure that there is a list associated with the property name, then adds the error string to this collection. One last thing to do there, is to notify the UI, that something has changed related to the validation error of this property.

The Remove method removes the specific error from the error collection.

The infrastructure is ready by now, we can use it. The BookDetailsViewModel now inherits the ValidatingViewModelBase class.

 public class BookDetailsViewModel : ValidatingViewModelBase, IDataErrorInfo

 {

     public string Title

     {

         get

        {

             return book.Title;

         }

         set

         {

             book.Title = value;

             RaisePropertyChanged("Title");

             ValidateTitle(value);

         }

     }

     //Validate Title Property

     private void ValidateTitle(string title)

     {

         //Check server side data for validation result

        bookDataSource.CheckIfTitleAvailable(this.BookID, title);

     }

     //Callback from the server validation process

     void bookDataSource_CheckIfTitleAvailableCompleted(object sender, CheckIfTitleAvailableCompletedEventArgs e)

     {

         //Validation Logic

         if (!e.IsAvailable)

         {

             //Invalid

             AddError("Title", "The Book with that title already exits!");

         }

         else

         {

             //Valid

             RemoveError("Title", "The Book with that title already exits!");

         }

     }

In the setter of the Title property I call the ValidateTitle() method. The validate Title uses the bookDataSource, to check on the server if the title is available for this item, or another book already has it. (I made minor changes, to enable an extra WCF service operation. You can check it in the VS solution posted with this article).

Now in the completed event handler I check if the title is available. If not, then I call the previously created AddError() method. If it’s available, I call the RemoveError() method. This is happening absolutely asynchronously. The AddError() and the RemoveError() methods raise the ErrorsChanged event, so the UI gets notified also asynchronously about the change in the state of the validation.

We have to indicate on the binding, that we are using this kind of validation mechanism. This is done through the ValidatesOnNotifyDataErrors=True option

 "1" TextWrapping="Wrap" d:LayoutOverrides="Height" 

          VerticalAlignment="Center" Margin="15,0" 

          Text="{Binding Title, Mode=TwoWay, ValidatesOnNotifyDataErrors=True}"/>

That’s it, you have asynchronous validation across tiers.

Bringing the UI and the ViewModels more closely

If you start to work with MVVM, you can get the taste of it very soon. You’ll really like it, but even in the beginnings there will be battles, you’ll have to fight. The problem will emerge mostly in the area of integrating the ViewModel with the specific View more closely. For example, how do you plan to display messages, or dialog boxes? What if you want to do something in the ViewModel as soon as a Storyboard ends? This is the area where behaviors, actions, and triggers can help you a lot.

For me, among many others, there are two very important and useful behavior to use with MVVM, which I’d like to introduce you now.

1. The EventToCommand behavior.

What if, I don’t want to click the load data button in my application? What if I want to load the data as soon as the application starts. (I know what is in your mind right now, please don’t ever put code in the ViewModel’s constructor that calls a real data source (WCF Service, etc…) That would make blendability a nightmare). The EvenToCommand behavior located in the MVVM Light Toolkit can help you a lot. You can attach it to a control, tell which event you are waiting for, and as soon as that event fires, the associated command object gets invoked.

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

     <i:Interaction.Triggers>

         <i:EventTrigger EventName="Loaded">

            <GalaSoft_MvvmLight_Command:EventToCommand Command="{Binding LoadBooksCommand}"/>

        i:EventTrigger>

     i:Interaction.Triggers>

As soon as the Grid’s Loaded event happens, the LoadBooksCommand gets invoked.

2. The VSMChangerBehavior

Imagine you have a special menu, panel, whatever. In some cases it’s visible, in some cases it’s not. Very easy you say, let’s create a bool property in the ViewModel, and use a converter to convert the bool value to Visibility for the UI. That definitely works. But you just tied the hands of your designer. What if his plan is to slide the panel in and out for the true and false values? What you should really do, is to define Visual States for the Visible and NonVisible states and use the VisualStateManager to move from one state to the other. Now the designer can do whatever he wants in these Visual States. What a big difference in flexibility, huh? But now you have a problem. You have a bool value, or an enum in the ViewModel. Now you have to write code on the UI, to check these states. Or let the view model “know” about the view and control it like a Controller. This is not something you want. This is where the VSMChangerBehavior created by Andras Velvart can help you out. You define states (by convention) for you enums, and let the VSMChangerBehavior do the transitions automatically, as the properties in the ViewModel change.

If you want to know more about this behavior, go and visit silverlightshow.

There are a lot of other behaviors / actions you should be familiar with, like GoToStateAction, CallMethodAction, ControlStoryboardAction, DataStateBehavior. These can help you a lot.

Final thoughts

Also there are other concepts you should consider, like I prefer to manage an IsBusy property in the ViewModel, so I have the option to indicate the user if there is something going on behind. Or for your collections you should implement paging using a PagedCollectionView class. To make your application and your components really flexible and loosely coupled, you might want to get familiar with MEF (for extensibility) or Unity (IoC container). So there is still a long way to go, but I hope these 3 articles are enough to get you started.

Today MVVM is close to be called a mature pattern. Let me rephrase it. A well supported pattern. I think if it comes to business application development, this pattern definitely should be used. Silverlight 4 is now a very good platform on which you can develop Line of Business Applications.

Download the source code

Data Driven Applications with MVVM Part II: Messaging, Unit Testing, and Live Data Sources

editorial@silverlightshow.net (Zoltan Arvai ) — Wed, 16 Jun 2010 07:29:00 GMT

Don't miss...

This series is now available as a fully offline resource:

($0.99)

All SilverlightShow Ebooks

This article is compatible with the latest version of Silverlight.

Introduction

In this short series of articles I’ll cover what MVVM is and how to use it in practice, how to solve issues when applying this pattern and how to take advantage from it.

In the previous article we discussed what MVVM is and why it matters. In this article we’ll try to benefit from the pattern and talk about the issues you have to battle through when working with MVVM. Our sample application was able to pull some data from a model, and display it on the screen in a master-detail fashion.

Now what we want is to add extra functionalities to our application, like being able to remove an item by clicking on a remove button, located next to each item in the ListBox.

Adding Remove functionality – Messaging

So here is the deal. I want to place a button displaying an X, next to each of the books in the ListBox. When I click on the remove button, the associated Book gets deleted! However this seems a very straightforward task, you’ll see very shortly, that it isn’t. Let’s think this trough a bit.

We want to call a remove operation when we click the remove button. The remove button is in the DataTemplate, its DataContext is a BookDetailsViewModel instance. If I want this functionality, the Remove button’s command property should be bound to a RemoveBookCommand defined in the BookDetailsViewModel class. This means that I’ll have to write a Remove() method in this class. Right now the BookDetailsViewModel class represents the necessary data of a single book. This seems problematic. Why? Because when I remove an item:

I need to persist the changes in the data store.
I need to refresh my ListBox containing all those books!

Let’s see the first. I’m going to need a reference to the DataSource, so I can persist the changes in the data store. I don’t have this reference right now. I can add it though, however it seems a bit strange yet, since removing an item from a list is not the responsibility of that single item. You remember the single responsibility principle? Are you sure this should be controlled by the BookDetailsViewModel class? Yeah, I don’t think so either.

What about the second one? On the BooksView UserControl, I need to refresh the ListBox, which has its ItemsSource property set to the Books property, defined in the BooksViewModel. I don’t have a reference to that ViewModel in my BookDetailsViewModel! I could add it, but then again, the single responsibility principle. Not to mention that it would increase complexity AND here is what really is a problem, it would increase the level of dependency between the ViewModels. However doing this is not illegal, but it’s definitely not something I would like to do.

Also I could add a third problem, which right now does not concern us, but it could definitely be an issue. Maybe another part of the application, another ViewModel wants to know if an item gets removed by the application. Maybe an other module!

If we want to address this issue, we immediately try to think of some sort of a static or singleton solution. Don’t think too much, we have a solution prepared for us. The MVVM Light Toolkit, which we used in our base application, provides us a Messenger class. This is a singleton object and you can use it to send messages for different subscribers.

From any ViewModel, you can subscribe for a specific type of message. If someone sends that specific type of message, everybody who subscribed for that type of message will receive it. You can send very simple type of messages, like a string, or GenericMessages. However I prefer to create a custom message class for every single message type / case.

So here is what I want. I will send a message from the BookDetailViewModel, and tell the world that this specific item should be removed, and let the rest of the world worry about it! :)

Let’s add the extras to the BookDetailsViewModel. First let’s create the RemoveBookMessage class:

 namespace MVVMProductsDemo.Messages

 {

     public class RemoveBookMessage : MessageBase

     {

        public BookDetailsViewModel Book { get; set; }

        public RemoveBookMessage(BookDetailsViewModel bookToRemove)

        {

            this.Book = bookToRemove;

       }

    }

 }

Now let’s add commanding and message sending to the BookDetailsViewModel class:

 private RelayCommand removeBookCommand;

 public RelayCommand RemoveBookCommand

 {

     get { return removeBookCommand; }

 }

 public void RemoveBook()

 {

     Messenger.Default.Send(

         new RemoveBookMessage(this));

 }

 //This one goes in the constructor

 removeBookCommand = new RelayCommand(RemoveBook);

Now everybody, who wants to know about the book removal, should subscribe! Let’s change the BooksViewModel’s constructor!

 public BooksViewModel(IBookDataSource bookDataSource)

 {

     this.bookDataSource = bookDataSource;

     if (bookDataSource != null)

     {

        bookDataSource.LoadBooksCompleted += new EventHandler(bookDataSource_LoadBooksCompleted);

        bookDataSource.RemoveBookCompleted += new EventHandler(bookDataSource_RemoveBookCompleted);

     }

     loadBooksCommand = new RelayCommand(LoadBooks);

     Messenger.Default.Register(this, RemoveBook);

 }

As you can see the Register() method needed a parameter of type Action. This is point to a callback method that runs when a message is received.

 public void RemoveBook(RemoveBookMessage message)

 {

     //Remove item from collection!

     Books.Remove(message.Book);

     //Remove item from data store

    bookDataSource.RemoveBook(message.Book.BookID);

 }

 void bookDataSource_RemoveBookCompleted(object sender, OperationEventArgs e)

 {

     if (e.Error != null)

     {

         //Do dg.

         return;

     }

 }

So now, our ViewModels are ready. Also the IBookDataSource provides a way to remove the item from the data store. We just need to modify a view. In some scenarios you’d want to defined a separate UserControl as a special view, and use it as a DataTemplate. However that is not necessary. We can just create a simple ItemTemplate here.

Let’s change the ListBox in the BooksView.xaml:

 <ListBox x:Name="lboxBooks" HorizontalAlignment="Left" Margin="8,8,0,29" Width="129" ItemsSource="{Binding Books}" 

              SelectedItem="{Binding SelectedBook, Mode=TwoWay}">

     <ListBox.ItemTemplate>

         <DataTemplate>

             <StackPanel Orientation="Horizontal">

                 <Button Content="X" Command="{Binding RemoveBookCommand}" Width="20"/>

                 <TextBlock Text="{Binding Title}" Margin="8,0,0,0"/>

             StackPanel>

         DataTemplate>

     ListBox.ItemTemplate>          

 ListBox>

As you can see, by clicking the button, you’ll invoke the RemoveBookCommand, which will invoke the RemoveBook() method, which sends a RemoveBookMessage. On the other side the subscribers for this specific type of message will handle it accordingly. Remove it from the collection and the data store as well. However Messaging is mostly useful when communicating between different modules. So if you use it between different ViewModels, be careful, not to overuse it, since it can lead to a “what the hell is happing right now” situation.

By now we have tons of functionality! I’m getting worried about later changes to this code base. Will my application still work, if I do minor changes? This is where Unit Testing can help you a lot! I told you, MVVM architecture is really testable. So let’s write some unit tests!

Unit testing MVVM

Well Silverlight Unit Test projects are not default in Visual Studio 2010. It’s part of the Silverlight Toolkit. So if you want to do unit testing, you should download it from here. After you install the toolkit, you’ll have a new project type called Silverlight Unit Test Application. The Project Template will add a new page (or web project) for the unit tests. In the Unit Test project you’ll have to reference both the Model and the Demo Project.

There is a couple of things worth mentioning here. Most of the ViewModels work asynchronously, so we have to keep that in mind, when writing tests! In order to support this scenario, we’ll use a special base class for our TestClass, called SilverlightTest. Our TestMethod will be decorated with the AsynchronousAttribute so the framework knows how to handle it. We’ll use our mock data sources (since we don’t use real data sources in unit tests). To handle asynchronous callbacks we’ll use the EnqueueXXX methods. Let’s create a test for the LoadBook operation.

 namespace MVVMProductsDemo.UnitTests

 {

     [TestClass]

     public class Tests : SilverlightTest //Note that the base class is SilverlightTest

    {

         [TestMethod]

         [Asynchronous] //Indicate that this test will include asynchronous operations

         public void LoadBook()

         {

             //Flag to indicate that the async operation is done

             bool isAsyncOperationCompleted = false;

             //Use the mock data source

             IBookDataSource dataSource = new MockBookDataSource();

             BooksViewModel viewModel = new BooksViewModel(dataSource);

             //If the books are loaded set the completed flag to true!

             dataSource.LoadBooksCompleted += (s,e) => isAsyncOperationCompleted = true;

             //Call method

             EnqueueCallback(viewModel.LoadBooks);

             //Wait for flag to be true!

             EnqueueConditional(() => isAsyncOperationCompleted);

             //If async operations is done, check for the valid conditions!

             EnqueueCallback(() => Assert.IsTrue(viewModel.Books.Count > 0, "Books count is zero!"));

             //Indicate that test is complete

             EnqueueTestComplete();

         }

     }

 }

As you can see we created a flag (isAsnycOperationCompleted) to indicate whether the asynchronous operation is completed or not. Then we’ll configure our BooksViewModel to use the MockBookDataSource class. When the LoadBooksCompleted event raises, we should set the flag to true. Now we’ll call the LoadBooks() method using EnqueueCallback, and wait until it completes (see EnqueueConditional). After that we can check whether we have any BookDetailsViewModel instance loaded into the Books property. Finally we have to indicate that the Test is complete by now (EnqueueTestComplete). If we don’t do that, the test will run forever. You can run the test by starting the generated Test Page.

There you go. We just tested our ViewModel. Of course more extensive testing is necessary to make sure, you release a high quality product! Using this approach you can test the UI as well by instantiating the View UserControls, however I prefer to stick with testing the ViewModels and only do UI testing where it is absolutely necessary.

Changing to Live, WCF-based Data Source

So far we’ve used a mock data source object in our application. It’s time to move to a “real” data source, provided by a WCF Service. Let’s think the basics through. Changing to a live data source should not be that big of a problem. I could write a LiveDataSource class, that works well with a WCF proxy, to communicate with the server side! What about my entities? Right now I have this Book class on the client side. One thing I could do, is adding this Book class to the server side as well. Another approach could be to create an extra transformation layer on the client side, to convert the data received from the server side, to our Book entity. What I’m going to do here, is to create a separate Model project for my entities for the server side, and I’m going to add the Book class file in the silverlight project as a LINK.

I’m going to have to set up it’s default namespace to the same as on the client side. (In this case I have to delete the Web substring.)

Now I can add the Book class as a link.

Now we can reference this project in our Web application / WCF Service project. We can implement our Silverlight-enabled WCF Service. Also I have to add a couple of attributes to my Book class so it can we serialized with WCF. These are the DataContract and DataMember attributes.

 [DataContract(Namespace="MVVMProductsDemo.Model")]

 public class Book

 {

     [DataMember]

     public int BookID { get; set; }

     [DataMember]

    public string Title { get; set; }

     [DataMember]

     public string Author { get; set; }

     [DataMember]

     public decimal Price { get; set; }

 }

Here is the WCF Service implementation:

 [ServiceContract(Namespace = "")]

 [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

 public class BookService

 {

     [OperationContract]

     public IEnumerable LoadBooks()

     {

         List bookList = new List();

         bookList.Add(

             new Book

             {

                 BookID = 1,

                 Author = "Tom Clancy",

                 Title = "Rainbow Six",

                 Price = 29.99m

             });

         bookList.Add(

             new Book

             {

                 BookID = 2,

                 Author = "Tom Clancy",

                 Title = "Executive Orders",

                  Price = 19.99m

             });

         bookList.Add(

             new Book

             {

                  BookID = 3,

                  Author = "John Grisham",

                  Title = "The Partner",

                  Price = 22.99m

             });

         return bookList;

     }

 }

The next step is to implement the LiveBookDataSource class and use this WCF Service to get the data. We should not forget, that calls to the WCF service will be asynchronous.

I’m going to need to do a little restructuring. I want to keep my model project for entities only, so I’m going to create a separate project for my data sources and I’m going to move all my data source classes and interfaces to this project. I’m going to reference my model project here and also add a service reference to my WCF Service, and tell the proxy generation tool to use existing types in my referenced assemblies, instead of generating its own Book classes.

Let’s see the LiveBookDataSource implementation details.

 public class LiveBookDataSource : IBookDataSource

 {

     #region IBookDataSource Members

     public void LoadBooks()

    {

         BookServiceClient client = new BookServiceClient();

         client.LoadBooksCompleted += new EventHandler(client_LoadBooksCompleted);

         client.LoadBooksAsync();

     }

     void client_LoadBooksCompleted(object sender, LoadBooksCompletedEventArgs e)

     {

         IEnumerable books = e.Result;

         if (LoadBooksCompleted != null)

         {

             //Error is null if nothing went wrong

             LoadBooksCompleted(this, new BooksLoadedEventArgs(books) { Error = e.Error });

         }

     }

     public void RemoveBook(int bookID)

     {

         //Remove book through WCF

     }

     public event EventHandler LoadBooksCompleted;

     public event EventHandler RemoveBookCompleted;

     #endregion

 }

As you can see, LoadBooks() calls a WCF LoadBooksAsync operations. When the operation ends, we get notified through an event, then we pass this data back to our caller, through an event.

Now that we have a live data source, we can change the mock implementation in the Application_Startup method. Also you have to move the ServiceReference.ClientConfig xml file in the DataSources project to the Silverlight application project, since the running application is going to look for those settings there.

 //Change this Line

 IBookDataSource dataSource = new MockBookDataSource();

 //To this line

 IBookDataSource dataSource = new LiveBookDataSource();

Now we can run our application. There you go, now we are on live data source!

Summary

What do we have right now? We have learned a new concept called Messaging that helps us communicating between different modules or view models if that’s necessary. Also we created a unit test to make sure that we know if later changes have any kind of effect on our codebase. We learned that Silverlight is special, so we need to write Asynchronous unit tests. The Unit Testing Framework in the Silverlight Toolkit comes to the rescue. Finally we changed our mock data source to a wcf data source and shared entities between the client and the server.

We still need to discuss some issues, like how Validation works, or how we can respond in the view model to UI specific events, or how states can be managed from the ViewModel.

If you are interested, read Part 3.

Download the source code

Data Driven Applications with MVVM Part I: The Basics

editorial@silverlightshow.net (Zoltan Arvai ) — Tue, 15 Jun 2010 07:27:00 GMT

Don't miss...

This series is now available as a fully offline resource:

($0.99)

All SilverlightShow Ebooks

This article is compatible with the latest version of Silverlight.

Introduction

In this short series of articles I’ll cover what MVVM is and how to use it in practice, how to solve issues when applying this pattern and how to take advantage from it.

What is MVVM and why you need it

Do you know the feeling, when you start to develop an application, and in the first couple of days you feel good because you made a really good progress? Do you know the feeling, when after a couple of days, you feel that your design is not that best and when you have to modify a little code, you are afraid of the effect it might have on other parts of you code? The first sign of a bad design is when applying a hack is easier than to implement it the proper way. At the end of the week you already have spaghetti code. You have logic that is not testable, it is very tightly coupled with the UI. You cannot make just “minor” changes without taking risks. If someone wants to understand your code, it takes days or weeks to figure out how it works.

This is where MVVM comes into play. MVVM stands for the Model – View – ViewModel pattern. It’s originated from MVC and is specific to WPF and Silverlight. The three most important things that MVVM can offer you:

Testable code
UI is loosely coupled with related logic
Maintainable code

Basic concepts in MVVM

The Layers:

1. The View

The View is your User Interface. It’s basically xaml. The view does not interact directly with the model. It does not contain any kind of non-UI related logic. Be aware, don’t be fooled by demo codes and presentations. Sometimes you also have C# code in your code-behind, not just xaml. Sometimes you just cannot get around it. Don’t feel bad about it. There is nothing wrong writing UI related code in the view’s code-behind, after all it’s probably view specific. However sometimes you can write or find workarounds for these cases, in form of Behaviors and Triggers.

2. The Model

The Model can contain entities, DTOs, data source and proxy objects, repositories. It largely depends on what kind of application you are writing. For example if you have a WCF service on the server (above the service layer you may have many other layers, like Business Logic Layer and Data Access Layer, etc.) you will need client side objects to interact with the services. You will need DataContracts (you can transfer data with these objects) and proxy objects to invoke operations. These can be part of your model. I like to refer to the model as the entry point to the rest of the application. The Model and the View DOES NOT know each other, they do not communicate directly.

3. The ViewModel

The ViewModel’s responsibility is to get the necessary data from the model and expose it for the view. Through the view, the user can enter data and trigger actions (commands), so the ViewModel has to interpret this input and the commands, and invoke the appropriate operations on the model and also pass the necessary data.

Interaction between the Layers:

The ViewModel communicates with the Model through an interface. (It’s highly recommended to use interfaces instead of actual implementation). The Model should not know the ViewModel. We try to keep the dependencies low and avoid tightly coupled scenarios.
The communication between the View and the ViewModel is where it gets more interesting. Thanks to the brilliant binding mechanism in Silverlight and WPF the view can get and pass data to and from the ViewModel without actually referencing it.
For example if you have a list of products in the ViewModel and the ViewModel itself is the DataContext of your View, a ListBox defined in your view can DataBind to those product entities. So the Binding mechanism provides this kind of flexibility in this specific pattern.

Let’s see it in action!

MVVM in practice

Well, if you decide to use the MVVM pattern, you’ll see that there are many things that needs to be implemented over and over again. So after a while you may want to develop you own MVVM assisting framework / library to help you along with forthcoming projects. Luckily enough, there are very good solutions out there. The two most famous ones are the MVVM Light Toolkit by Laurent Bugnion, and the Composite Application Library (aka Prism) by the Patterns and Practices Team of Microsoft. However both products are very popular and support MVVM, their main concepts are pretty different. While the MVVM Light Toolkit focuses solely on the MVVM architecture, the Composite Application Library’s main focus is on supporting composite scenarios. Prism supports building Modular applications and also happens to support the MVP architecture. (MVP is like MVVM, but in MVP, the Presenter (ViewModel in our terms) may interact with the View through a well-defined interface directly)) So in our example we will use the MVVM Light Toolkit. (also available, for WPF 3.5, 4.0, Silverlight 3.0, 4.0 and WP7) You can download it from here.

Our demo application will load Books in a ListBox. The selected product’s details will be displayed in a details panel. Also we’ll have remove buttons, so when we click on one, the selected product will be deleted.

So I’m just going to create a simple Silverlight 4.0 project. (Please note, that if you install the MVVM Light Toolkit, you’ll also get Visual Studio Project templates. I’m just going to use the dlls here only)

As you can see I’ve created separate folders for my ViewModels and my Views. I have a Master View this is the BooksView UserControl, and a details view, the BookDetailsView UserControl. Also I’ve created a separate Model Project, let’s see that first.

1. The Model Project

Book.cs – This is an entity class, that represents a Book object. It’s very simple does not contain any special code:

 namespace MVVMProductsDemo.Model

 {

    public class Book

    {

        public int BookID { get; set; }

        public string Title { get; set; }

        public string Author { get; set; }

        public decimal Price { get; set; }

    }

 }

IBookDataSource.cs – This is an interface that specifies how the ViewModel will interact with the Model.

 namespace MVVMProductsDemo.Model

 {

     public interface IBookDataSource

     {

         void LoadBooks();

         void RemoveBook(int bookID);

         event EventHandler LoadBooksCompleted;

         event EventHandler RemoveBookCompleted;

     }

 }

As you can see, the interface implies that access to the DataSource will be asynchronous. Well, in Silverlight, mostly this is the case. I have two operations. One to load books, and another one to remove a book. I get notified of the results of the operations by events. Below there is an example of the BooksLoadedEventArgs

 namespace MVVMProductsDemo.Model

 {

     public class BooksLoadedEventArgs : OperationEventArgs

     {

         public IEnumerable Books { get; set; }

         public BooksLoadedEventArgs(IEnumerable books)

         {

            this.Books = books;

         }

     }

 }

Now all I have to do is to actually implement the interface and provide a DataSource implementation. Well for this article a mock (fake) data source is perfect. Not to mention that I plan to use that for testing as well!

 namespace MVVMProductsDemo.Model

 {

     public class MockBookDataSource : IBookDataSource

     {

         List bookList = new List();

         public MockBookDataSource()

         {

            bookList.Add(

                 new Book

                 {

                     BookID = 1,

                     Author = "Tom Clancy",

                     Title = "Rainbow Six",

                     Price = 29.99m

                 });

            bookList.Add(

                 new Book

                 {

                     BookID = 2,

                     Author = "Tom Clancy",

                     Title = "Executive Orders",

                     Price = 19.99m

                 });

            bookList.Add(

                 new Book

                 {

                     BookID = 3,

                     Author = "John Grisham",

                     Title = "The Partner",

                     Price = 22.99m

                 });

         }

         #region IBookDataSource Members

         public void LoadBooks()

         {

             if (LoadBooksCompleted != null)

             {

                 LoadBooksCompleted(this, new BooksLoadedEventArgs(bookList));

             }

         }

         public void RemoveBook(int bookID)

         {

             Book bookToDelete = bookList.Single(p => p.BookID == bookID);

             bookList.Remove(bookToDelete);

             if (RemoveBookCompleted != null)

                 RemoveBookCompleted(this, new OperationEventArgs());

       }

        public event EventHandler LoadBooksCompleted;

        public event EventHandler RemoveBookCompleted;

        #endregion

     }

 }

As you can see I load some fake books and provide an implementation for LoadBooks and RemoveBook.

2. The ViewModels

ViewModelBase and Property Change Notifications

Let’s get back to the ViewModels. So I have to provide a special model class for my view to display products, load products and handle item selection. This is the BooksViewModel class. The BooksViewModel inherits from ViewModelBase defined in the MVVM Light Toolkit. For data binding to work properly, we need property change notification. ViewModelBase implements the INotifyPropertyChanged interface and provides a protected RaisePropertyChanged method, that we can use to propagate property change notification towards the UI.

Books Collection

The BooksViewModel class exposes a Books property of type ObservableCollection. This property serves as the ItemSource of the ListBox. But why not ObservableCollection? The answer is simple, I have three reasons:

I want to bind to details panel’s (BookDetailsView) DataContext to the SelectedItem of the ListBox. But if I have Books in the ListBox instead of BookDetailsViewModel instances I cannot do this simply since the DataContext should be a BookDetailsViewModel, not a Book instance.
In the ListBox I might want to define a DataTemplate. In the template I might want to add a button that corresponds to an action defined in the BookDetailsViewModel.
I really want to keep the dependency of the book object very low in my ViewModels. Who knows, maybe I will have to replace it.

 private ObservableCollection books;

 public ObservableCollection Books

     get { return books; }

     set

     {

         books = value;

         RaisePropertyChanged("Books");

     }

 }

Selected Book

Also I have a SelectedBook property of type BookDetailsViewModel. I’m planning to bind the ListBox’s SelectedItem to this property and also the BookDetailsView’s DataContext should be read from this property. Why not use direct UI to UI binding? I have many reasons:

Most of the time different parts of my application is likely to react if a selected item changes. Not just the UI, other components as well.
I' want to modify the selected book from code as well. The UI needs to reflect those changes!
The designer might screw this one up :)
etc…

So basically I need control over the SelectedItem, in this case the SelectedBook. This is why I’m going to do a two-way binding for the ListBox’s SelectedItem and a one-way binding for the BookDetailsView’s DataContext.

 private BookDetailsViewModel selectedBook;

 public BookDetailsViewModel SelectedBook

 {

     get { return selectedBook; }

     set

     {

         selectedBook = value;

        RaisePropertyChanged("SelectedBook");

     }

 }

Loading Books

I can access the DataSource through IBookDataSource, an instance that I get through the BooksViewModel constructor. The DataSource is event-based so I just have to subscribe the the loaded event.

 IBookDataSource bookDataSource;

 public BooksViewModel(IBookDataSource bookDataSource)

 {

     this.bookDataSource = bookDataSource;

     if (bookDataSource != null)

    {

         bookDataSource.LoadBooksCompleted += new EventHandler(bookDataSource_LoadBooksCompleted);

     }

 }

I also create a LoadBooks() method that loads the books from the DataSource;

 public void LoadBooks()

 {

     bookDataSource.LoadBooks();

 }

 void bookDataSource_LoadBooksCompleted(object sender, BooksLoadedEventArgs e)

 {

     if (e.Error != null)

     {

         //Do dg.

         return;

     }

     List loadedBooks = new List();

     foreach (var book in e.Books)

     {

         loadedBooks.Add(new BookDetailsViewModel(book));

     }

     Books = new ObservableCollection(loadedBooks);

 }

As you can see after we check a possible error, we refresh the Books Collection. Transformation in necessary into ViewModels since the EventArgs returns IEnumerable list.

One final step for this View Model. When the user clicks the load button, the ViewModel should get the books. Now we are not binding a simple data property to a simple dependency property like a TextBox.TextProperty. Now we are binding an event to an operation. Of course this is just not possible, we need an extra object, what is called a command. Different MVVM libraries use different names for these commands, like DelegateCommand, ActionCommands or RelayCommands. All of them implement the ICommand interface and this is what matters here. We have RelayCommands in the toolkit. You can bind commands as properties. So all I have to do is to expose a LoadBooksCommand

 private RelayCommand loadBooksCommand;

 public RelayCommand LoadBooksCommand

 {

     get

    {

         return loadBooksCommand;

     }

 }

 //This line goes to the contructor

 loadBooksCommand = new RelayCommand(LoadBooks);

What did we here? We specified that if a LoadBooksCommand gets invoked than we should call the LoadBooks() method! The buttons have a Command property which is a dependency property. We can directly bind that property to this LoadBooksCommand. Also note, that the second parameter the the RelayCommand’s contstructor is another delegate. Here you can enter a function that checks whether the command in question can actually be executed. If not, then the associated control’s IsEnabled property is set to false. (And this is why I don’t like it. Once more we tie the hands of the designer)

BookDetailsViewModel

The last ViewModel in our case is just a representation of the Book class for now. But that’ll change later!

 namespace MVVMProductsDemo.ViewModels

 {

     public class BookDetailsViewModel : ViewModelBase

     {

         Book book;

         public BookDetailsViewModel(Book book)

         {

             this.book = book;

         }

         public string Title

         {

             get

             {

                 return book.Title;

             }

             set

             {

                 book.Title = value;

                 RaisePropertyChanged("Title");

             }

         }

         public string Author

         {

             get

             {

                 return book.Author;

             }

             set

             {

                 book.Author = value;

                 RaisePropertyChanged("Author");

             }

         }

         public decimal Price

         {

             get

             {

                 return book.Price;

             }

             set

             {

                 book.Price = value;

                 RaisePropertyChanged("Price");

             }

         }

     }

 }

There we go. We’re done. Remember that I wrote always things like, the user does this or that, that we have a ListBox, and details etc… I never said anything about a concrete UI or layout. Let’s create it now!

3. The Views

Let’s start with the details view. How do we display one item.

So this is what we want to create and bind. Here is the code:

 <UserControl x:Class="MVVMProductsDemo.Views.BookDetailsView"

     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"

     mc:Ignorable="d"

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

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

         <Grid.RowDefinitions>

             <RowDefinition Height="0.117*"/>

             <RowDefinition Height="0.107*"/>

             <RowDefinition Height="0.117*"/>

             <RowDefinition Height="0.66*"/>

         Grid.RowDefinitions>

         <Grid.ColumnDefinitions>

             <ColumnDefinition Width="0.345*"/>

             <ColumnDefinition Width="0.655*"/>

         Grid.ColumnDefinitions>

         <TextBlock Margin="10,0,0,0" TextWrapping="Wrap" d:LayoutOverrides="Width, Height" HorizontalAlignment="Left" VerticalAlignment="Center" Text="Title:"/>

         <TextBlock Margin="10,0,0,0" TextWrapping="Wrap" Grid.Row="1" d:LayoutOverrides="Width, Height" HorizontalAlignment="Left" VerticalAlignment="Center" Text="Author:"/>

         <TextBlock Margin="10,0,0,0" TextWrapping="Wrap" Grid.Row="2" d:LayoutOverrides="Width, Height" HorizontalAlignment="Left" VerticalAlignment="Center" Text="Price:"/>

         <TextBox Grid.Column="1" TextWrapping="Wrap" d:LayoutOverrides="Height" VerticalAlignment="Center" Margin="15,0" Text="{Binding Title, Mode=TwoWay}"/>

         <TextBox Grid.Column="1" TextWrapping="Wrap" Grid.Row="1" d:LayoutOverrides="Height" VerticalAlignment="Center" Margin="15,0" Text="{Binding Author, Mode=TwoWay}"/>

         <TextBox Grid.Column="1" TextWrapping="Wrap" Grid.Row="2" d:LayoutOverrides="Height" VerticalAlignment="Center" Margin="15,0" Text="{Binding Price, Mode=TwoWay}"/>

     Grid>

 UserControl>

As you can see we did simple two-way bindings like {Binding Title, Mode=TwoWay}.

The BooksView UserControl is where it gets interesting:

And here is the xaml:

 <ListBox x:Name="lboxBooks" HorizontalAlignment="Left" Margin="8,8,0,29" Width="129" ItemsSource="{Binding Books}" 

          SelectedItem="{Binding SelectedBook, Mode=TwoWay}" DisplayMemberPath="Title"/>

 <Button Command="{Binding LoadBooksCommand}" x:Name="btnLoad" Content="Load Books" HorizontalAlignment="Left" 

         Margin="8,0,0,3" VerticalAlignment="Bottom" Width="129"/>

 <local:BookDetailsView x:Name="bookDetails" Margin="154,8,8,29" DataContext="{Binding SelectedBook}"/>

So we have a ListBox with and ItemsSource bound to the Books property, and the SelectedItem bound two-way to the SelectedBook property. Right now we are not using any DataTemplates yet, this is why the DisplayMemberPath is set to Title (not Book.Title, its BookDetailsViewMode.Title!!!)

The Button has the Command property bound to the LoadBooksCommand so when the user clicks it, it gets invoked. And finally a complete view (a user control) is placed here, this is the BookDetailsView. It’s DataContext is bound to the SelectedBook. So whenever that property changes, the Details will reflect the changes.

4. Wiring Up

Okay so we have the Views and ViewModels but we lack the wire up at the beginning? I told you I don’t want to reference the ViewModel from View. (If you do, that’s not a big problem, many MVVM implementation does that.) But I prefer to do this one more level above, in the application class:

 private void Application_Startup(object sender, StartupEventArgs e)

 {

     BooksView view = new BooksView();

     IBookDataSource dataSource = new MockBookDataSource();

     BooksViewModel viewModel = new BooksViewModel(dataSource);

    view.DataContext = viewModel;

     this.RootVisual = view;

 }

As you can see, this is the place where I specify the actual implementation details for the IBookDatasource. This is the place where I could change it to a live data source. And here is the wire up. I specify the DataContext of the BookView as a BooksViewModel instance. That’s it.

If we run the application now, it just works!

Summary

Okay, what do we have so far? We have a Maintainable, Testable and pretty loosely coupled solution. Also we can easily create different views, for the same data and functionality!

Where do we go from here? We need advanced functionalities, like Removing or Updating an item, we need to battle the problems we face, when implementing these additions, like notifying other views / ViewModels if something changes. We need to create unit tests to make sure, changes in the code does not ruin the application. We need to change to a live data source from the mock one, and of course, we need validation support both on the server and the client!

Well, if you’re interested, read Part 2!

Download the source code

Red-To-Green scale using an IValueConverter

editorial@silverlightshow.net (Marcel du Preez ) — Tue, 15 Jun 2010 01:20:00 GMT

This article is compatible with the latest version of Silverlight.

Introduction

Recently I have been working on a project, where a certain task's completion needs to be visually indicated in some graphic way. I settled on creating a style for the ProgressBar control, with a changing background color depending on the current value of the ProgressBar.

HSV (Hue-Saturation-Value)

From Wikipedia :

"HSL and HSV are the two most common cylindrical-coordinate representations of points in an RGB color model, which rearrange the geometry of RGB in an attempt to be more perceptually relevant than the cartesian representation."

HSV is a different way of representing a color (as opposed to RGB, where R indicates a value from 0 to 255 that "controls the amount of red", G for green and B for Blue). Have a look at the link above for an in-depth discussion.

I'll be using HSV to do my color change. By keeping the Saturation and Value values constant, and changing the Hue based on my progress, the color will change between Red, Orange, Yellow and finally Green.

IValueConverter

IValueConverter is an interface that can be implemented in WPF/Silverlight to provide a declarative way to convert properties from one datatype to another. I'll be using it to convert from my current progress (a int value between 0 and 100) and a Brush, which is what my ProgressBar expects as a background.

Create a class, and have it implement the IValueConverter interface, as below :



public

class RedToGreenScaleConverter : IValueConverter

{

#region IValueConverter Members

public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

{

return new SolidColorBrush(ColorFromHSV((double)value, 1, 1));

}

public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture {

return null;

}

#endregion

}

IValueConverter implements two methods : Convert, and ConvertBack. The titles should be self-explanatory. In ConvertBack, I return a null value (I don't want to convert a Brush to an int in my application). In Convert, I return a new SolidColorBrush, which I need to provide with one argument : a Color.

The Color is returned from a custom method call ColorFromHSV. It calculates the RGB values for specific H, S and V values (which are provided as arguments) :

private static Color ColorFromHSV(double hue, double saturation, double value)

{

int hi = (int)(Math.Floor(hue / 60)) % 6;

double f = hue / 60 - Math.Floor(hue / 60);

value = value * 255;

int v = (int)(value);

int p = (int)(value * (1 - saturation));

int q = (int)(value * (1 - f * saturation));

int t = (int)(value * (1 - (1 - f) * saturation));

if (hi == 0)

return Color.FromArgb(255, (byte)v, (byte)t, (byte)p);

else if (hi == 1)

return Color.FromArgb(255, (byte)q, (byte)v, (byte)p);

else if (hi == 2)

return Color.FromArgb(255, (byte)p, (byte)v, (byte)t);

else if (hi == 3)

return Color.FromArgb(255, (byte)p, (byte)q, (byte)v);

else if (hi == 4)

return Color.FromArgb(255, (byte)t, (byte)p, (byte)v);

else

return Color.FromArgb(255, (byte)v, (byte)p, (byte)q);

}

This code was adapted from here.

ProgressBar Style

To implement this in a ProgressBar, I needed to create a new style. Using Expression Blend, add a ProgressBar to your control/window/page, right-click on it in the Objects and Timeline window, select Edit Templates and Edit a Copy... :

This will generate a Style for a ProgressBar in the location you specify, based on the current style. Because I had no style specified, the default style is returned.

The style consists of a lot of XAML... but the part I'm interested in is called "Indicator", a rectangle. This rectangle contracts/expands depending on the Value property of the ProgressBar. I'll be changing it's Fill property, but first, a namespace declaration :

xmlns:converters="clr-namespace:ConverterDemo"

and a reference to my converter in the Resources section

<Window.Resources>

<converters:RedToGreenScaleConverter x:Key="redGreenScale" />

Window.Resources>


and finally, changing the Fill property : 

<Rectangle x:Name="Indicator" Fill="{TemplateBinding Value, Converter={StaticResource redGreenScale}}"/>

[Update] : Thanks to Waqas for pointing out that the previous code snippet only works in WPF. For it to work in Silverlight, you need to use a RelativeSource Binding, as follows :


 <Rectangle x:Name="Indicator" 

            Fill="{Binding RelativeSource={RelativeSource TemplatedParent}, 

                  Path=Value, 

                  Converter={StaticResource redGreenScale}}" 


[Another update] : You can also use the Progressbar’s Foreground property with the RelativeSource Binding… eliminating the need for the template :


 <ProgressBar Foreground="{Binding RelativeSource={RelativeSource Self}, 

              Path=Value, 

              Converter={StaticResource redGreenScale}}"


This piece of code says that the Fill property should be set to the value of the ProgressBar's Value property (via TemplateBinding, check Bea Stollnitz's blog for a simple explanation), converted by using the RedToGreenScaleConverter. So, everytime the ProgressBar's value changes, that value will be converted to a Color by the converter.
Result
This is what the ProgressBar looks like at the indicated values :



Ciao! 

Marcel du Preez 

marcel@inivit.com



ModalDialogs, IEditableObject and MVVM in Silverlight 4
editorial@silverlightshow.net (Pencho Popadiyn ) — Tue, 11 May 2010 10:47:00 GMT
This article is compatible with the latest version of Silverlight.





1. Introduction
I recently found myself in the following situation. My boss came to me and asked me: “Dude, we have a big Silverlight project, performing a great number of CRUD operations. We need to find a unified way of showing Modal Dialogs in a MVVM manner, without using any code in the View. The logic of showing dialogs must reside in the ViewModel, not in the code-behind. Also do you remember our previous WinForms projects? There are several pretty useful classes, such as BindingSource and DataRowView, implementing BeginEdit, EndEdit and CancelEdit functionality out of the box. We need to bring this functionality in our Silverlight projects, however, this time on business objects level. It must be ready till tonight, otherwise you won’t get salary at the end of the month!!!” 
Knowing my boss, the last sentence must have been a joke, or at least I hope to be a joke :) After working a few hours on the problem, I found a solution, which makes me feel pretty happy. That’s why I decided to share it with you guys.

2. Modal Dialogs and MVVM
So here is the general idea. First, we need to find a way to show modal dialogs. Fortunately, Silverlight 3 and Silverlight 4 provide us with ChildWindow. Of course, with the same success you can use dialogs (windows) provided by any third-party component vendor. However, the most important question is how to use a Modal Dialog inside the ViewModel and in the same time to remain decoupled. One of the most important OOP principles – The Dependency Inversion Principle teaches us to depend on abstractions not on concrete implementations. When we have static dependencies in our code, we can break them by using either an interface or a base class. Additionally, according to the MVVM pattern, the ViewModel doesn’t have to know about the View. Definitely we need an interface. Here it is:

So we need a DialogResult to determine whether the OK or Cancel button is clicked. We need to have the possibility to Close and Show the dialog; to be notified when the dialog is closed, in order to perform the subsequent actions. And finally, let’s take a look at the Content property. It is a little bit more special. Why? The answer is that there are two possible solutions of the current problem. In the first one, we can exchange the Content property with DataContext property. Or in other words, we need to create a new modal dialog for each entity. After that we just set the target entity to the dialog’s DataContext, like on the image below.

The second solution requires some additional work. Instead of having a separate child window for each entity, you could use UserControls. After that, you just set the UserControl to the dialog’s Content property.

Personally I prefer the second one, and namely it is demonstrated in this demo. However, the first one is also “playable”. Here is the IModalView interface. It is a quite simple, and provides a way to set the DataContext property of the UserControl, as well as to be notified when OK or Cancel button is pressed.

Finally, we need to bring in another level of abstraction on the scene. The final piece is the glue between the ModalDialog, the ModalView, and the ViewModel. This is the IModalDialogWorker interface. It provides only one method for showing dialogs and completely hiding the details of the implementation.

As you can see, when you show modal dialogs, you have to pass implementations of IModalDialog and IModalView interfaces, a dataContext (this is the currently edited entity – e.g. Person, Customer, Employee, etc). Finally, you need to pass an action that is invoked when the dialog is closed. The last parameter is optional (e.g. you can use that method to show custom MessageBox dialogs). Via the IModalDialog’s DialogResult property, you can obtain the dialog result.
The ModalDialogWorker implementation is quite simple. It is just a matter of coding, here it is:


public class ModalDialogWorker : IModalDialogWorker

{

    public void ShowDialog( IModalDialog modalDialog, IModalView modalView, T dataContext, Action onClosed )

    {

        if ( modalDialog == null )

            throw new ArgumentNullException( "modalDialog", "Cannot be null" );

        if ( modalView == null )

            throw new ArgumentNullException( "modalView", "Cannot be null" );

 

        EventHandler onDialogClosedHandler = null;

        EventHandler onViewClosedHandler = null;

 

        if ( onClosed != null )

        {

            onDialogClosedHandler = ( s, a ) =>

            {

                modalDialog.Closed -= onDialogClosedHandler;

                onClosed( dataContext );

            };

 

            onViewClosedHandler = ( s, a ) =>

            {

                modalDialog.Closed -= onDialogClosedHandler;

                modalView.Closed -= onViewClosedHandler;

                modalDialog.DialogResult = a.DialogResult;

                //modalDialog.Close();

                onClosed( dataContext );

            };

 

            modalDialog.Closed += onDialogClosedHandler;

            modalView.Closed += onViewClosedHandler;

        }

 

        modalDialog.Content = modalView;

        modalView.DataContext = dataContext;

        modalDialog.ShowDialog();

    }

}


Now let’s see how to create IModalDialog and IModalView implementations. The ModalDialog is very simple. You just have to derive from ChildWindow and implement the IModalDialog interface.


public class ExtendedChildWindow : ChildWindow, IModalDialog

{

    public void ShowDialog()

    {

        this.Show();

    }

}


Note that the ExtendedChildWindow dialog is universal, you just have to set its content property with the concrete XXXModalView. For example, if you want to create a control for editing Person objects, you need to create a new UserControl and implement IModalView interface.


public partial class EditPersonControl : UserControl, IModalView

{

    public EditPersonControl()

    {

        InitializeComponent();

    }

 

    public event EventHandler Closed;

 

    protected virtual void OnClosed( ModalViewEventArgs e )

    {

        if ( this.Closed != null )

            this.Closed( this, e );

    }

 

    private void btnOkClick( object sender, RoutedEventArgs e )

    {

        this.OnClosed( new ModalViewEventArgs( true ) );

    }

 

    private void btnCancelClick( object sender, RoutedEventArgs e )

    {

        this.OnClosed( new ModalViewEventArgs( false ) );

    }

}


The only things you should do in the code-behind is to mark the control as IModalView implementation; to set the DialogResult to true, if user clicked OK, and to false if user clicked Cancel. Note that this is done in the code-behind because it is not part of the business logic, but of the UI logic.

The key moments in the ModalDialogWorker are these three lines of code:


modalDialog.Content = modalView;

modalView.DataContext = dataContext;

modalDialog.ShowDialog();



3. “M” for Mighty
The question remains how to inject the IModalDialog, IModalVIew and IModalDialogWorker implementations into the ViewModel.

Fortunately, we have MEF in our tool belt. You need to mark all composable parts with the Export attribute and to specify contracts.

On the other side of the channel, the ViewModel, you have to specify the Imports. After that, using the ModalDialogWorker is just a piece of cake.


private void OnEditPersonCommandExecute()

{

    this.ModalDialogWorker.ShowDialog(

        this.ModalDialog, this.EditPersonControl, this.SelectedPerson, p =>

        {

            if ( this.ModalDialog.DialogResult.HasValue &&

                this.ModalDialog.DialogResult.Value )

            {

                // OK

            }

            else

            {

                // Cancel

            }

        } );

}


Of course you could use any other discovering patterns.
4. Generic Implementation of IEditableObject
The next important bunch of questions is: What happens when the user edits objects? What should happen when he/she presses the OK or Cancel button? How to commit the changes? How to restore the original state of the object?
We need to commit or rollback changes through the BeginEdit, EndEdit and CancelEdit methods. That is easy. We can use IEditableObject interface. The most important problem is how to keep a snapshot of the object’s state. To address this bullet, we can use the Memento pattern. The function of the Memento pattern is to capture and externalize an object’s internal state so that the object can be restored to this state later, without violating encapsulation.

Well having this in mind, let’s create a new generic class named Memento.


public class Memento

{

    private Dictionaryobject> storedProperties = new Dictionaryobject>();

 

    public Memento( T originator )

    {

        this.InitializeMemento( originator );

    }

 

    public T Originator

    {

        get;

        protected set;

    }

 

    public void Restore( T originator )

    {

        foreach ( var pair in this.storedProperties )

        {

            pair.Key.SetValue( originator, pair.Value, null );

        }

    }

 

    private void InitializeMemento( T originator )

    {

        if ( originator == null )

            throw new ArgumentNullException( "Originator", "Originator cannot be null" );

 

        this.Originator = originator;

        IEnumerable propertyInfos = typeof( T ).GetProperties( BindingFlags.Public | BindingFlags.Instance )

                                        .Where( p => p.CanRead && p.CanWrite );

 

        foreach ( PropertyInfo property in propertyInfos )

            this.storedProperties[ property ] = property.GetValue( originator, null );

    }

}


The code is quite simple. First you are passing the originator (this is the object we want to track). In the InitializeMemento method, you are taking the internal state. All properties and their values are stored in a simple Dictionary.


this.Originator = originator;

IEnumerable propertyInfos = typeof( T ).GetProperties( 

                                BindingFlags.Public | BindingFlags.Instance )

                                .Where( p => p.CanRead && p.CanWrite );

 

foreach ( PropertyInfo property in propertyInfos )

    this.storedProperties[ property ] = property.GetValue( originator, null );


Finally, in the RestoreState method, we are taking the original values and restoring the object’s initial state.


public void Restore( T originator )

{

    foreach ( var pair in this.storedProperties )

    {

        pair.Key.SetValue( originator, pair.Value, null );

    }

}


The last piece of the puzzle is the Caretaker. The Caretaker is a simple wrapper. It implements the IEditableObject interface and has a reference to the generic Memento. This is the place where the magic happens. However, the code is even simpler than the code for Memento.


public class Caretaker : IEditableObject

{

    private Memento memento;

    private T target;

 

    public T Target

    {

        get

        {

            return this.target;

        }

        protected set

        {

            if ( value == null )

            {

                throw new ArgumentNullException( "Target", "Target cannot be null" );

            }

 

            if ( Object.ReferenceEquals( this.Target, value ) )

                return;

 

            this.target = value;

        }

    }

 

    public Caretaker( T target )

    {

        this.Target = target;

    }

 

    public void BeginEdit()

    {

        if ( this.memento == null )

            this.memento = new Memento( this.Target );

    }

 

    public void CancelEdit()

    {

        if ( this.memento == null )

            throw new ArgumentNullException( "Memento", "BeginEdit() is not invoked" );

 

        this.memento.Restore( Target );

        this.memento = null;

    }

 

    public void EndEdit()

    {

        if ( this.memento == null )

            throw new ArgumentNullException( "Memento", "BeginEdit() is not invoked" );

 

        this.memento = null;

    }

}


Now, you are free to use the Caretaker in the following manner:


Caretaker editableObject = new Caretaker( this.SelectedPerson );

editableObject.BeginEdit();

//.....

this.SelectedPerson.Name = "Pesho";

// Commit Changes

editableObject.EndEdit();

// -or CancelChanges

// editableObject.CancelEdit();


Let’s go back to our PersonViewModel, and update the OnEditPersonCommandExecute method:


private void OnEditPersonCommandExecute()

{

    Caretaker editableObject = new Caretaker( this.SelectedPerson );

    editableObject.BeginEdit();

 

    this.ModalDialogWorker.ShowDialog(

        this.ModalDialog, this.EditPersonControl, this.SelectedPerson, p =>

        {

            if ( this.ModalDialog.DialogResult.HasValue &&

                this.ModalDialog.DialogResult.Value )

            {

                editableObject.EndEdit();

            }

            else

            {

                editableObject.CancelEdit();

            }

        } );

}


5. Final Words
You can download the source code from here.
The other goodies: Note that the whole business logic is located in the ViewModel. No actions in the code-behind. Also pay attention to the fact that at each point the ViewModel deals with interfaces, no concrete implementations. This is important, because it is not recommended to have a reference in the ViewModel to ChildWindow (for example). I am a big fan of MEF, that’s why I am using it wherever this is possible. However, marking the concrete implementations with the Export attribute doesn’t obligate you to use MEF for parts discovering. You are free to use any other pattern (approach). Finally, using DelegateCommand – this is standard, no need of explanation.
And the online demo. Select a person from the datagrid. Press the Edit button, a new modal dialog appears. This is happening thanks to the three interfaces presented in the article. Make some changes to the current Person object. Click either the OK or Cancel button. The changes are committed, or respectively rejected. This is happening thanks to the generic implementations of the IEditableObject and the Memento pattern.









So, that’s it. I know the problem for performing CRUD operations in Silverlight/WPF is not so simple and I hope that the code here will be useful for you. Feel free to experiment with it. If you have any idea for further improvements or questions, I will be happy if you share it with us.