.NET

Adventures in MVVM – CodeMash Schedule Application

Brian Genisio's House Of Bilz — Tue, 12 Jan 2010 02:59:13 GMT

So, I am getting myself ready to head out to Sandusy, Ohio for three days of nerdy fun at CodeMash. While I am there, I will be giving my “Introduction to the MVVM Pattern”. In preparation for this talk, I decided to create a new demo application. This application is a calendar and session list for the conference. It is not terribly fancy (I wish I had more time (or talent) to skin it better), but it highlights many of the concepts that I will be speaking about in my presentation.

The app is a Silverlight 3 project utilizing the Telerik Scheduler control. This particular control is rather rich, and I was excited to get my hands dirty with it. The ViewModel for the scheduler was primarily responsible for translating session data into something the Telerik control could consume. The app also includes a session list with a filter panel which is derived from the session data. This is where the majority of the MVVM code can be found. The ViewModels for the session list are responsible for dynamically creating and merging filter predicates based on the values in the session list.

You can play with the application at http://HouseOfBilz.net/CodeMash

CodeMashSessions Source Code: http://www.houseofbilz.net/codemash/CodeMashSessions.Source.zip

Twitter "Ball of Mud" vs MVVM Source Code: http://houseofbilz.net/codemash/Twitter-BallOfMud-vs-MVVM.zip

Slides from "An Introduction to the MVVM Pattern": http://houseofbilz.net/codemash/MVVM.ppt

Binding to Resources in Silverlight/WPF

Brian Genisio's House Of Bilz — Sun, 15 Mar 2009 14:15:08 GMT

This article is describing how to solve the problem in SIlverlight, but the problem can be solved in WPF using the exact same technique.

So, now it is time to internationalize our application. I want to use the built-in "resx" mechanism for i18n in .net, so I create myself a resource file and start adding strings to the table:

Visual Studio automatically generates the resource class for me, and I am ready to bind to the data in my XAML:

<UserControl.Resources>
    <l:i18n x:Key="i18n" />
</UserControl.Resources>

<StackPanel x:Name="LayoutRoot" Orientation="Horizontal">
    <TextBox />
    <Button Content="{Binding Path=SearchButton, Source={StaticResource i18n}}" />
</StackPanel>

But I run my application and I get this exception: Unhandled Error in Silverlight 2 Application AG_E_PARSER_BAD_TYPE. I get this error message because the resx file is set to create my resource class as an "internal" class. Essentially, the SIlverlight engine doesn't have permission to instantiate a new i18n object, and it dies.

Fortunately, in Visual Studio 2008, they have given us a way to solve this problem. In the Resx editor, you can change the protection of the class it generates from internal to public. So, I do exactly that:

Now my XAML should be able to bind to the resource, right? Wrong: Unhandled Error in Silverlight 2 Application AG_E_PARSER_UNKNOWN_TYPE. This time, it is complaining because the constructor to this public class that Visual Studio generated is internal! The class is public, but the constructor is internal, so the Silverlight/WPF engine still can't instantiate the object.

I searched the interwebs, and I'm not alone with this problem. Most people solve the problem by adding a custom build step that modifies the code. Some even suggest changing the constructor to public by hand every time you update the resource table. I am here to say: THERE IS A BETTER WAY! I just created a public class with a single property that exposes the class:

public class i18nPublic
{
    private readonly static i18n resources = new i18n();
    public i18n Strings { get { return resources; } }
}

By adding this class, I can make a slight modification to the resource type and the binding path and I am now binding directly to the resources.

<UserControl.Resources>
  <l:i18nPublic x:Key="i18n" />
</UserControl.Resources>

<StackPanel x:Name="LayoutRoot" Orientation="Horizontal">
    <TextBox />
    <Button Content="{Binding Path=Strings.SearchButton, Source={StaticResource i18n}}" />
</StackPanel>

My Silverlight 3 Wish List

Brian Genisio's House Of Bilz — Sat, 07 Mar 2009 09:31:34 GMT

I have been developing full time in Silverlight 2 for a few months now. I must say, it is the most fun environment I have ever programmed in. It has been an enabling technology in our product, and I am rather excited to see what comes next. If the pattern continues as I expect it probably will, we will hear all about the features of Silverlight 3 in a few weeks at Mix 09. I will not be attending this conference, but I fully expect to be watching the important sessions virtually. I am hoping for a lot. You see, as much as I like the SIlverlight framework, it is missing some significant features that I can really use.

So, I figured I would publish my Silverlight 3 wish list. Some of these things are more important than others, but all of them are things that would make my "Rich Internet Application" more rich. I don't want this list to sound like I am just a big complainer. I think I am exercising the framework pretty hard, and Microsoft can only make the framework better with this list.

MediaElement frame rate control: The Silverlight media element is missing the ability to control the frame rate. This keeps us from controlling the playback for slow-motion or fast-forward. I have to imagine that the sports domain wants this as well.

MediaElement loop control: The current media element does not support looping of video content. It can be programmed by hooking the "MediaEnded" event, putting the position at zero, and playing again, but this causes a noticeable pause. This pause keeps looping play from being fluid. It would be nice if the media element supported it directly.

Native video rendering: Silverlight 2 does not use any hardware capabilities for video playback -- it is all done in software. Therefore, the playback takes a lot of processor power. This is really noticeable when four videos are playing simultaneously. Any more on modern hardware is often choppy. I would like to be able to play as many as nine videos at once.

3D support: Similar to the previous wish, Silverlight 2 does not use the video hardware directly. This means that there is no 3D support. It would be nice to see some 3D capabilities in Silverlight 3 -- preferably handled by hardware.

Direct bitmap manipulation: Silverlight 2 does not support this, and there are certain types of effects and manipulations that are not possible in Silverlight. I would love to see some bitmap manipulation capabilities

Support for other data transports: Currently, only HTTP requests are made available through the SIlverlight plug-in. This limits the use of more sophisticated WCF bindings. At a very minimum, it would be nice to be able to use TCP bindings via WCF.

Better mouse support: Currently, we need to hack in right-click, double-click and scroll-wheel capabilities. It would be nice to have native support.

Support for drag-and-drop: This is another case where I have hacked something together, but it would be great if I were able to rely on the framework.

Native support for the MVVM pattern: As far as I have figured, the MVVM pattern is the most suitable pattern for most large-scale Silverlight development. It allows us to test the majority of our code and keep it out of the view. Unfortunately, I haven't found MVVM to be well supported in the framework.

Commands -- They gave us ICommand, but nothing else. I have hacked something in, but native support would be nice.
See what Silverlight.FX and Cliburn have done. Can we get something like this in the framework?
Some sort of "Inversion of Control" or similar decoupling support? Might MEF or Prism show up in SIlverlight 3?
Stand-alone binding -- As far as I can tell, binding is only available in controls. I can't write tests against controls. I often want to bind data in my model to my view model. I have written my own binder for this, but it would be nice to have some built-in support
Better property notification. INotifyPropertyChanged creates a lot of boiler-plate code in the view model. I have minimized this by using a "property bag", but some utilities that make view models easier to write would be nice.

Interprocess communication: I would like the ability to talk to other non-silverlight processes. This seems like a tall order, but I have some business cases for this.

That is all I have for now. I am sure there is more that I am not thinking of. I come across different needs every day. For most cases, I have been able to hack some sort of support in when I need it. In some cases, like the video playback support, I can't hack my wan out of the limitations.

This list looks like a lot now that I have written it down. I am very curious to know if I will be getting any of these features.

Ann Arbor .NET Developers Group Has New Leadership!

Brian Genisio's House Of Bilz — Thu, 12 Feb 2009 22:02:24 GMT

Last night, the Ann Arbor .Net Developers group held annual elections, and made new director appointments. The new leadership team is:

President: Jay Harris
Vice President: Scott Zischerk
Secretary: Darrell Hawley
Treasurer: Eric Bratton

Director of Programming: Mike Woelmer
Director of Membership: Dennis Burton
Director of Sponsorship: Brian Genisio (me!)

With my new role, I will be soliciting companies for sponsorship. This will require me to get out there a bit more than I am used to, which is something that I have been pushing myself to do for about a year now. I am excited to be a more significant part of the group, as this group means a lot to me. I can't say that I know that I will be good in this role, but what the heck? Lets give it a try.

Now, who wants to give me some money? :)

Drag and Drop with Silverlight

Brian Genisio's House Of Bilz — Wed, 11 Feb 2009 09:49:06 GMT

The Problem

I have been developing with Silverlight for a few months now, and I have really been enjoying myself. It has been the enabling technology my project and we have been extremely productive in the environment. Unfortunately, Silverlight is still in version 2.0 and there are some missing capabilities.

One such hole in the framework is "Drag and Drop". There is no support for it directly. There are several blog examples on the web, but I have yet to find a fully encapsulated, generic solution to the "Drag and Drop" problem. For instance, how soon after dragging do you really want to be dragging? You don't want to drag immediately, as that will affect normal clicking on an element. How do you handle drags from one distinct control to another that are not aware of each other? How do you clue the user in that a given control is droppable? How do you add animation to cue the user that the item is being dropped?

Introducing DragNDrop

To answer these questions, I created the DragNDrop class. It is a manager of sorts, and watches a "Drag Source" for the mouse down events. The "Drag Source" implements an interface and the "Drop Spot" implements a complimentary interface. This allows for the "Drag Source" and "Drop Spot" to be blissfully unaware of each other.

Usage

The assumption made with this class is that there is some sort of a payload. This payload is picked up from the "Drag Source" and dropped into the "Drop Spot". The "Drop Spot" can accept a payload of any types that it implements from any "Drag Source" that implements the complementary interface. Lets take a look at the interfaces:

public class DragNDrop<PayloadType>
{
    public interface IThumbnailDragSource
    {
        FrameworkElement DragCursor { get; }
        PayloadType Payload { get; }
    }
    
    public interface IThumbnailDropSpot
    {
        void DragDropEnter();
        void DragDropExit();  
        void ThumbnailDroping(PayloadType dataContext, FrameworkElement cursor, Point cursorPosition);
    }
}

For instance, if a "Drag Source" wanted to allow dragging with a string payload, it would implement DragNDrop<string>.IThumbnailDragSource. Any "Drop Spot" that wants to accept a string payload would implement DragNDrop<string>.IThumbnailDropSpot. The DragNDrop class is then constructed with an instance of the "Drag Source" and the DragNDrop class handles everything else.

In addition to the payload, the "Drag Source" needs to provide the DragNDrop class with the cursor that will be displayed and dragged across the screen. This can be anything; an image, a user control, a rectangle, etc.

The "Drop Spot" will be notified when the cursor is entering and exiting its space, so it can react appropriately. It will also be notified when the payload is dropped with the instance of the cursor and the absolute position. This is necessary in case the "Drop Spot" wants to animate the drop in any way.

The Demo

I created the Twitter Search Tool to prove out this concept. The idea is that search for a term and it returns a list of tweets. When you find a tweet that you like, you can drop it on to the second list to keep track of it. It is not the most functional app in the world, but it illustrates the usage of the DragNDrop class nicely. Take a moment to try it out.

Now that you have seen it in action, lets take a look at how I use the DragNDrop class. This application uses a small data structure called Tweet. It contains all of the information about a given tweet (user name, user image, text, etc). The Tweet is the payload.

In the Silverlight UI, I created a user control to represent each item in the list called ListItem. The XAML is available in the full source if you are curious.

public partial class ListItem : UserControl, DragNDrop<Tweet>.IThumbnailDragSource
{
    private readonly DragNDrop<Tweet> _dragNDrop;

    public ListItem()
    {
        InitializeComponent();

        _dragNDrop = new DragNDrop<Tweet>(this);
        _dragNDrop.DraggingEnabledDistance = 5.0;
    }

    public FrameworkElement DragCursor
    {
        get
        {
            return new Image
            {
                Width = TweetImage.ActualWidth,
                Height = TweetImage.ActualHeight,
                Source = TweetImage.Source,
                Opacity = 0.5
            };
        }
    }

    public Tweet Payload
    {
        get { return DataContext as Tweet; }
    }
}

This code is pretty straight-forward. The DragCursor returns a new image with the picture of the user. The payload is the actual Tweet. The constructor creates an instance of DragNDrop and passes itself in as the source. It also sets the DraggingEnabledDistance. This is the distance (in pixels) that the user must drag before the dragging really begins. The default is 10 pixels.

Next, lets take a look at the "Drop Spot" code. It is also a user control, TweetDropList, which includes a ListBox control. It also includes an opaque canvas that gives the effect of highlighting when it is made visible.

public partial class TweetDropList : DragNDrop<Tweet>.IThumbnailDropSpot
{
    private readonly ObservableCollection<Tweet> _savedTweets = new ObservableCollection<Tweet>();

    public TweetDropList()
    {
        InitializeComponent();
        DropList.ItemsSource = _savedTweets;
    }

    public void DragDropEnter()
    {
        Highlight.Visibility = Visibility.Visible;
    }

    public void DragDropExit()
    {
        Highlight.Visibility = Visibility.Collapsed;
    }

    public void ThumbnailDroping(Tweet dataContext, FrameworkElement cursor, Point cursorPosition)
    {
        DragDropExit();
        AnimateCursor(cursor, cursorPosition, () => _savedTweets.Add(dataContext));
    }
}

I have left out the AnimateCursor code, but it simply generates a storyboard on the cursor and quickly morphs it down to a size of zero. That code can be found in the source bundle. The rest of this implementation is extremely simple. DragDropEnter and DragDropExit simply hides and shows the highlight layer. ThumbnailDropping will remove the highlighting layer and animate the cursor to give the effect of the item being dropped. When the animation completes, the new tweet is added to the _savedTweets collection, which will cause the user control to display the new tweet.

Thats It!

I designed the DragNDrop class to be as simple to use as possible. I have been using a version of this class in my product and I have had great results. The "Drop Spots" can implement as many versions of IThumbnailDropSpot as it needs to allow different types of items to be dragged. The DragNDrop class can be instantiated as many times as necessary, for every "Drag Source".

Please play with this class and give me feedback. I'd love to hear how it is being used.

DragNDrop Twitter Demo
DragNDrop Twitter Demo Source
DragNDrop.cs
Extensions.cs (a handful of extension methods that DragNDrop uses)

Testing WCF Service Apps (part 4 of 4)

Brian Genisio's House Of Bilz — Tue, 06 Jan 2009 09:56:25 GMT

Previous Posts:
Part 0 of 4: Introduction
Part 1 of 4: Testing the Service
Part 2 of 4: Testing the Client
Part 3 of 4: Testing the Asynchronous Client

Functional Testing the WCF Application

In functional testing, the goal is to test as much of the application that you can to determine that it does what you want from a functional perspective. It differs greatly from unit testing in that a unit test is only concerned with an individual class. Functional tests are concerned with testing the interactions of the objects in the system from the user input to the user output.

I thought it would be easiest to draw out what the data mining application is doing in terms of data flow. This particular application is a data mining application which queries a service to pull out data that the user wants. In this case, the question that the user wants answered is "What recipes exist in the database that include a given ingredient?" The data flow goes like this:

The user types an ingredient into the console. The console launches our application and calls "Main" with the arguments that include the ingredient in question. The "Main" routine creates an IngredientFinder object which requests a list of all recipes known to the service. It does this by asking the service proxy which uses WCF to ask the actual RecipeService, which may exist anywhere on the planet. The actual RecipeService asks the Business Objects which in turn queries the database for all known recipes. The database returns the results to the Business Objects which in turn returns the results to the RecipeService. Those results travel through the WCF infrastructure back to the service proxy in the client. The IngredientFinder filters the recipes for the requested ingredient and returns the results to the "Main" method which then writes the results back to the console for the user to read.

From a testing perspective, the only code we are responsible for in this system is Main, IngredientFinder, RecipeService and Business Objects. The user and console are completely external to our application. The service proxy is auto-generated by Visual Studio and the WCF framework is part of the .NET framework. We do not need to test these parts. Finally, the database is also a Microsoft product (SQL Server) and we can trust that it works correctly as well. We need to eliminate all components in this system that we do not control, thus focus on testing the code in which we do control.

Eliminating the User and Console

Traditionally our "Main" method would instantiate our IngredientFinder (see part 1) with the service proxy, get the result and write it out to the console:

static void Main(string[] args)
{
    var finder = new IngredientFinder(new RecipeBoxServiceClient());

    foreach (RecipeData recipe in finder.GetRecipes(args[0]))
        Console.WriteLine(recipe.Title);

    Console.ReadKey();
}

The problem with this is that Console is a static class and cannot be replaced as-is. Instead, we need to extract this as an interface and pass the interface in:

public interface IConsoleOutput
{
    void WriteLine(string line);
    ConsoleKeyInfo ReadKey();
}

private class ConsoleOutput : IConsoleOutput
{
    public void WriteLine(string line) { Console.WriteLine(line); }
    public ConsoleKeyInfo ReadKey() { return Console.ReadKey(); }
}

By doing this, we can now replace the Console.WriteLine static method with a spy in our test (later). We will create a new static method named Execute which passes in the IConsoleOutput and IRecipeBoxService interfaces. Our new "Main" routine will look like this:

static void Main(string[] args)
{
    Execute(new ConsoleOutput(), new RecipeBoxServiceClient(), args);
}

public static void Execute(IConsoleOutput console, IRecipeBoxService service, string[] args)
{
    var finder = new IngredientFinder(service);

    foreach (RecipeData recipe in finder.GetRecipes(args[0]))
        console.WriteLine(recipe.Title);

    console.ReadKey();
}

Eliminating the WCF Infrastructure

Now that the user and console have been abstracted out, we can start thinking about testing the Execute method. The problem we have now is that IRecipeBoxService is an automatically generated interface within the client's namespace. We have an implementation of this interface in the service, but it is defined in the service's namespace. The two interfaces are not compatible. We want to eliminate the need for WCF, so we cannot use the generated proxy class. What we need here is a bridge class:

public class ServiceWrapper : DataMining.RecipeBoxService.IRecipeBoxService
{
    private readonly Services.IRecipeBoxService _source;

    public ServiceWrapper(Services.IRecipeBoxService source)
    {
        _source = source;
    }

    private static ToType TranslateData<FromType, ToType>(FromType source) where ToType : class
    {
        var serverSerializer = new DataContractSerializer(typeof(FromType));
        var clientSerializer = new DataContractSerializer(typeof(ToType));

        using (var stream = new MemoryStream())
        {
            serverSerializer.WriteObject(stream, source);
            stream.Flush();
            stream.Position = 0;

            return clientSerializer.ReadObject(stream) as ToType;
        }
    }

    public DataMining.RecipeBoxService.RecipeData[] AllRecipes()
    {
        var result = new List<DataMining.RecipeBoxService.RecipeData>();
        foreach (var data in _source.AllRecipes())
            result.Add(TranslateData<Services.DataContracts.RecipeData, DataMining.RecipeBoxService.RecipeData>(data));
        return result.ToArray();
    }

    ...
}

This class bridges the client interface over to the service interface. WCF interfaces are made up of Service Contracts and Data Contracts. The Service Contract is the functional interface where the Data Contract defines what the data looks like. The WCF framework uses the System.Runtime.Serialization.DataContractSerializer to transfer the data in plain-text. In this ServiceWrapper class, the TranslateData function uses the DataContractSerializer to serialize the data to and from the client and service data types. This class is the glue that replaces WCF from the testing process. In a sense, this class is a very simple implementation of the WCF concepts.

Putting it all Together

The only piece of functionality still out of our control is the database. I am going to replace the SQL Server with a temporal, in-memory database for testing. This post will not go into the details, but my previous post on Blah Blah Blah talks about how to do this. Now, our diagram looks shows a system where every piece of code is in our control:

Writing our Functional Tests

The only code we still need before we start writing functional tests is the ConsoleOutputSpy. It captures the output in a list of strings that we can verify against.

public class ConsoleOutputSpy : Program.IConsoleOutput
{
    public List<string> Output { get; private set; }
    
    public ConsoleOutputSpy()          { Output = new List<string>(); }
    public void WriteLine(string line) { Output.Add(line); }
    public ConsoleKeyInfo ReadKey()    { return new ConsoleKeyInfo(); }
}

Now that we have our console output spy, we can look at our test SetUp:

private ConsoleOutputSpy _consoleOutput;
private DataMining.RecipeBoxService.IRecipeBoxService _service;

[SetUp]
public void SetUp()
{
    _service = new ServiceWrapper(new RecipeBoxService(new MockBackEndConfiguration()));
    _consoleOutput = new ConsoleOutputSpy();
}

Finally, we can write our tests. This test will populate the mock database with four ingredients and three recipes. Only two of the recipes include the "Cheese" ingredient, so we can test that our data miner will return only those two recipes that contain "Cheese":

[Test]
public void SimpleTest()
{
    AddIngredients("Macaroni", "Cheese", "Bread", "Peanut Butter");
    AddRecipeToDatabase("Mac & Cheese", "Macaroni", "Cheese");
    AddRecipeToDatabase("Grilled Cheese", "Bread", "Cheese");
    AddRecipeToDatabase("Peanut Butter Sandwich", "Bread", "Peanut Butter");

    Program.Execute(_consoleOutput, _service, new [] {"Cheese"});

    Assert.That(_consoleOutput.Output.Count, Is.EqualTo(2));
    Assert.That(_consoleOutput.Output[0], Is.EqualTo("Mac & Cheese"));
    Assert.That(_consoleOutput.Output[1], Is.EqualTo("Grilled Cheese"));
}

Conclusion

This concludes my four-part series on testing WCF applications. I have covered unit testing the service, unit testing the client, unit testing an asynchronous client and finally, functional testing the entire application.

It is important for me to note that these techniques have served me very well in the real-world. I have a Silverlight application which communicates asynchronously with a back-end WCF service. These techniques have allowed us to write tests that cover our application from all aspects. The tests we have in place run extremely quickly and are robust because they do not rely on any services running on a separate machine.