unfold

Impressions of MIX 2011

2011-04-13T10:24:00.001-07:00

Bing sent me to MIX as an attendee this year and so far it has been a blast. It’s great to be able to listen to customer concerns and take the temperature of a technology by checking out how many people show up to a talk. Most of all it’s fun to talk to the people who own the technologies I care about (especially the developers). It’s also nice to occasionally get props for my contributions to Silverlight even though I’ve since left the team.

The feedback from customers continues to be concern about the future of Silverlight and all I can do is reference the blog post “Standards-based web, plugins, and Silverlight.” It also appears that many developers are somewhat wary of exploring HTML5. It’s my feeling they might be more enthusiastic if the toolset were comparable to what Microsoft currently offers to Silverlight developers. In a perfect world the release of IE9 would be accompanied by a Javascript unit testing framework built into Visual Studio, comprehensive Blend support for HTML5, SVG, and jQuery templates, a Visual Studio update providing ES5 intellisense support, a jQuery plug-in for data-binding, and support for writing server-side code using the IE9 Javascript engine. Instead web developers got yet another templating engine for ASP.NET MVC (Razor) which - although very nice – doesn’t really solve any new problems.

One of the key reasons our developers are so loyal is that we provide them with such excellent tooling for our platforms. IE9 has some great debugging and diagnostic tools but that’s not enough. Developers need development tools and libraries that will fill the gaps they’ll encounter when they leave the warm embrace of the CLR and enter the realm of the browser. The Javascript version of Reactive Extensions is a good start.

I know the transition from Silverlight to HTML5 can be painful as I made the switch myself when I joined the Bing team. The good news - and it’s something I think we can do a better job of emphasizing - is that by cobbling together frameworks like jQuery, jQuery templates, and Knockout.js it’s possible to follow a development model similar to Silverlight and consequently achieve similar levels of productivity.

Looking forward to tomorrow’s talks!

Crockford on Javascript

2010-05-27T17:43:00.001-07:00

The web would be a better place if everyone watched “Douglas Crockford on Javascript”, a highly entertaining and informative series of lectures on the state of Javascript and the web. With wit and refreshing candor he catalogs what is right and wrong with Javascript and provides the historical context to help viewers understand (where possible) how we got here. You’ll almost certainly want to buy his book “Javascript: The Good Parts.” The title alone is a nice taste of Crockford’s plain-spoken style. :-)

I’ve left the Silverlight team

2010-04-04T13:10:00.001-07:00

I recently left the Silverlight team. Silverlight is a great team to work for and I have tremendous confidence in the continued success of the product. However at this point in my career platform development doesn’t appeal to me very much. I’d rather be much higher up in the stack working on user-facing technology. To that end I’ve joined a research team that’s developing semantic web technology for Bing (among other things).

Unfortunately this will mean that I won’t be able to blog as much about what I’m doing because most of my work will be under NDA. I can say that it is very exciting though! If there’s one thing Microsoft does better than anyone it’s funding and productizing research (although there’s still room for improvement).

Working for the Silverlight team has been a real thrill. It was great to be able to fight for and contribute features to the platform that I cared about. I’m proud to have been a part of Silverlight 4 and I can’t wait to use it on my new team.

A Modest Proposal: Pretty XSL

2010-04-02T01:11:00.001-07:00

I’ve got a question for the authors of the popular MVC frameworks: What’s with all the custom view languages? ASP.NET MVC uses ASPX files for their views. Rails uses Ruby of course. MonoRail has its own NVelocityViewEngine which has a python-like syntax. Of course these frameworks allow you swap out these view engines. However in my experience developers tend to default to using the one that ships with the framework.

Why not use XSL?

The technical benefits of using XSL are compelling:

1. Use Less Bandwidth

Every major browser is capable of XSL transformations on the client. After the XSL and CSS files have been cached by the browser an application server becomes responsible only for sending data and managing any application state. This translates to massive bandwidth savings.

2. Enforce Model/View Separation

When it comes to view languages smarter is not better. The more powerful a view language, the easier it is to inadvertently blend concerns. XSL is a dumb language that is pure by design. It’s like a technical straightjacket, sending a clear message to current and future developers about exactly what type of tasks are allowed to be performed.

3. W3C Standard

‘Nuff said.

4. Great tooling.

Some .NET developers may be unaware that it’s possible to step through XSL transformations in Visual Studio. The experience is roughly on par with stepping through C# code in an ASPX.

Syntax Matters

Given all these benefits why do so many developers choose a different view language? Here’s my theory: XSLT is ugly. Anyone who has used XSL knows that its signal-to-noise ratio is abysmal. Therefore propose a solution: The W3C should create PXSL (“Pretty Extensible Stylesheet Language”). PXSL is a hypothetical non-XML language that compiles into XSL. A stripped down version of Windsor’s NVelocityEngine or something similar could easily be compiled into XSL.

#foreach($person in $people)
#beforeall
       <table>
               <tr>
               <th>Name</th>
               <th>Age</th>
               </tr>
#before
                  <tr
#odd
                       Style='color:gray'>
#even
                       Style='color:white'>

#each
                       <td>$person.Name</td>
                       <td>$person.Age</td>

#after
                  </tr>

#between
                  <tr><td colspan='2'>$person.bio</td></tr>
#afterall
       </table>
#nodata
       Sorry No Person Found
#end

Some might think such an endeavor trivial or misguided. I disagree. There’s a relevant precedent to consider here. Turtle (Terse RDF Triple Language) is a non-XML language for describing XML RDF graphs that has been submitted to the W3C. Although it hasn’t yet been accepted as a standard it enjoys great tooling support and is widely used. Although it is no more or less expressive than RDF it’s practical syntax is so compelling that it has found a foothold in the industry.

Use XML Where it Makes Sense

Whenever a new technology is introduced we hear a lot about its supposed benefits. Some of these benefits pan out and some don’t. One of the touted benefits of XML was that it was supposed to be human-readable. While definitely an improvement on binary, many XML formats (ex. SOAP) are so complex that sifting through them in a text editor is very difficult in practice. To increase productivity we are increasingly hiding XML from developers with designers, code generators, and configuration utilities. XML is a very mature data interchange language but there’s no reason to force developers to work with it directly. A little syntax goes a long way.

Why We Still Rely on Dynamic Casts

2010-03-03T08:12:00.001-08:00

*I recently updated this post as it was rather unclear. By instance members I meant fields and properties, but it was pointed out that MTC was already supported on instance methods which are of course instance members.

The year is 2010. I program in C#, a modern and (ostensibly) strongly-typed programming language with generics. So why do I find it so difficult to write a program that doesn’t rely on dynamic casts?

Conventional wisdom is that reliance on dynamic casting is usually the sign of a poorly-designed framework. While this is true very often the root cause of suboptimal framework design is the inability of the programming language to express certain concepts. Its my aim to show you that with a simple programming language feature we can largely free our programs of dynamic casts. In the process I also intend to challenge conventional notions about good interface design.

Why We Need Dynamic Casts: A Typical Example

Let’s take a look at a class that must rely on dynamic casts to do its job.

public class CollectionSynchronizer<T>
{
    public ICollection<T> SourceCollection { get; set; }     
    public ICollection<T> TargetCollection { get; set; }
    
    // Implementation omitted
}

This CollectionSynchronizer listens to changes in a source collection and synchronizes its contents with a target collection. Over the classes lifetime its SourceCollection property might be set to a variety of different concrete collection classes that implement ICollection and INotifyCollectionChanged. The CollectionSynchronizer class has to rely on a dynamic cast because it must cast its source collection from an ICollection to an INotifyCollectionChanged interface in order to detect any changes to it.

public class CollectionSynchronizer<T>
{
    private ICollection<T> sourceCollection;
    
    public ICollection<T> SourceCollection
    {
        get 
        {
            return sourceCollection;
        }
        set
        {
            sourceCollection = value;
            INotifyCollectionChanged notifyCollectionChanged = sourceCollection as INotifyCollectionChanged;
            if (notifyCollectionChanged != null)
            {
                notifyCollectionChanged += SourceCollectionChanged;
            }
        }
    }
    
    private void SourceCollectionChanged(object source, NotifyCollectionChangedEventArgs args)
    {
        // synchronize changes with target collection.
    }
    // snip...
}

The SourceCollection property cannot be strongly-typed as INotifyCollectionChanged because INCC contains no members for retrieving the objects already present in the collection (INCC doesn’t inherit from IEnumerable). As a result of being weakly-typed this API is not discoverable to the class consumer - who might inadvertently assign a regular collection to the SourceCollection property and then wonder why the target collection was not getting updated.

“Isn’t INCC just a poorly designed interface? Shouldn’t it derive from IEnumerable.”

No. The architects made the right decision when they decided not to derive INCC from IEnumerable. I’ll explain why later. First I’ll demonstrate how we can get rid of this dynamic cast using a hypothetical language feature that is more flexible than interface inheritance and has fewer drawbacks.

Multiple Type Constraints

Ask yourself this question: Why can’t properties and fields be more than one type? At first this question might seem heretical at best and nonsensical at worst. Is such a thing even possible? Well it turns out that this feature - which I’ll refer to as Multiple Type Constraints (MTC) - is not only possible to implement, but very useful.

Let’s take a look at a revised version of our CollectionSynchronizer class that uses MTC (WARNING: the following code does NOT compile)...

public class CollectionSynchronizer // No generic type but...
{
    // ...we're using a generic type in a property definition
    public TCollection SourceCollection { get; set; } 
        where TCollection : ICollection, INotifyCollectionChanged
        
    public ICollection TargetCollection { get; set; }
    
    // Implementation omitted
}

Now objects assigned to the SourceCollection property are not restricted to being a single type but are instead constrained to be multiple types. If C# were capable of compiling the code above we could write code like this*:

var sourceCollection = new ObservableCollection<Customer>();

// No generic type needed on the class
var synchronizer = new CollectionSynchronizer();

synchronizer.SourceCollection = sourceCollection;
synchronizer.TargetCollection = myListBox.Items;

// Adding an item to the source collection,
// and consequently the ListBox items
sourceCollection.Add(new Customer());

// Now we can change the type of SourceCollection
// to another collection that implements 
// ICollection and INotifyCollectionChanged.
sourceCollection.SourceCollection = new MyCustomCustomerCollection();

*Some folks pointed out in the comments that you could use a generic method setter with type constraints to write the same code as I’ve written above. While this is true it would mean that I couldn’t set this property via XAML.

The point I’m trying to make is that if a programming language supports multiple inheritance it should support multiple type constraints. C# does support MTC today, but not on properties and fields. This causes problems. I’ll explain further but first a small tangent…

Interface Inheritance is Harmful

I submit that the ability to inherit one interface from another has no place in a programming language. Now I suspect you’d probably like some sort of justification for cutting a feature that pretty much every modern statically-typed, object-oriented programming language supports.

Tough. You’ve got it backwards. Language features are expensive and risky propositions and therefore it’s the advocate’s responsibility to justify their inclusion - not the other way around. So let’s ask the question…

Why Inherit?

There are two reasons to use inheritance:

Share implementation
Polymorphism

Obviously we can’t share implementation code by inheriting one interface from another because interfaces don’t contain any implementation code. That only leaves polymorphism.

Polymorphism seems like a good reason to enable interface inheritance. After all we can use interface inheritance to create a version of the CollectionSynchronizer class that doesn’t require a dynamic cast.

// Create new interface that inherits from two others
interface IObservableCollection: ICollection, INotifyCollectionChanged
{
}

public class CollectionSynchronizer // No generic type but...
{
    // Now we don't need generic constraints!
    public IObservableCollection SourceCollection { get; set; }         
    public ICollection TargetCollection { get; set; }
    
    // Implementation omitted
}

There’s just one problem with this approach: There aren’t any collections that implement IObservableCollection because we just invented it. There’s no way of getting existing classes you don’t own to retroactively implement an interface. Even though the set of types in System.Collections.ObjectModel.ObservableCollection’s type hierarchy are a superset of the types in our IObservableCollection interface we can’t polymorph over both types. Your IObservableCollection interface also won’t be compatible with semantically identical interfaces distributed by third parties. This example demonstrates the inflexibility of interface inheritance.

The key takeaway here is that if a language supports MTC then interface inheritance is useless because MTC is a more flexible mechanism for achieving polymorphism. In this context it makes sense to do away with interface inheritance because this feature encourages developers to build bigger, more coupled interfaces.

The Case For Small Interfaces

The larger an interface the more likely it is to be broken. A broken interface is a big problem because interfaces don’t version. It’s impossible to add, remove, or otherwise change members of an interface without breaking existing code.

One strategy for avoiding the embarrassment and pain of deprecation is to design many, small interfaces. If we design interfaces that do one thing and do it well as well as avoid creating large interfaces indirectly via inheritance we minimize the damage caused by deprecation.

The strategy of designing many small interfaces is only viable with MTC. The fact that MTC is missing from properties and fields is a blind spot. Nowadays systems are increasingly being built with declarative languages like XAML which are oriented around property getters and setters.

An Ideal Candidate for Language Inclusion

Property type constraints are an evolutionary concept, not a revolutionary one. Its already possible to build methods that specify multiple type constraints (via generics constraints). MTC could be added to properties and fields by reusing the existing generic constraint syntax used for methods.

Tools/Designers would also benefit from multiple-type constraints on properties. For example if a method was constrained to be both INotifyCollectionChanged and ICollection then the intellisense listing could include types that implement both.

Under the hood things get a little more complicated. Just like generics, MTC is an ideal candidate for inclusion in IL. Any approach that reduces MTC types to object types or uses some other form of erasure would share the same drawbacks as generic type erasure. I don’t pretend making the necessary changes to the platform will be easy, but I think it is worth the effort.*

*Update: Someone pointed out to me that this may actually be supported already because properties are just get/set method pairs under the hood. Haven’t tried to write the IL myself. Anyone know for sure?

The Way Forward

Multiple inheritance creates a combinatorial explosion of potential new types (ex. IObservableCollection, IObservableStack, IObservableEnumerableQueue, etc). MTC is an important tool for managing this complexity. Programming languages that provide multiple inheritance without also allowing for multiple type constraints are not strongly-typed in practice. Not allowing for constraints on properties and fields is an oversight that should be rectified.

Check me out on Channel 9 Talking about Rx and the Silverlight Toolkit

2009-12-22T17:56:00.001-08:00

Have a look.

The Joy of Rx: Rx Released!

2009-11-17T15:23:00.001-08:00

Rx has been released. Enjoy.

Silverlight Toolkit Drag Drop (Part 2): Customizing Drag and Drop Behavior

2009-10-23T01:11:00.000-07:00

In part 1 you were introduced to the new Silverlight DragDropTarget controls. In addition to being powerful these controls are very flexible, allowing developers to customize almost every single aspect of their behavior. In order to understand how to customize these controls you must first understand how they communicate. The good news is that DDT’s communicate via a WPF-compatible implementation of the drag/drop events!

A WPF-Compatible (mostly) Implementation of Drag and Drop

The Silverlight Toolkit Drag and Drop Framework is a compatible subset of WPF’s drag and drop methods and events – with a few small exceptions. The diagram below demonstrates how DDTs are layered on top of this WPF-compat framework. DDTs use these events and methods to communicate with each other.

The fact that the Silverlight Toolkit contains a full implementation of WPF’s drag and drop stack gives the developer tremendous flexibility. They can…

Use DDTs.
Communicate with and customize DDTs by handling the drag and drop events.
Choose not to use DDTs and use the WPF-compat API’s to initiate and manage their own drag operations.
Add native drag and drop support to their custom controls by implementing the IAcceptDrop interface.
Create new DDTs for existing controls by creating a class that inherits from DragDropTarget.

Differences between Silverlight Toolkit and WPF Drag and Drop API’s

Different Namespaces

The most obvious difference between the Silverlight implementation of drag and drop and that of WPF is that the Silverlight drag and drop objects are located in the Microsoft.Windows namespace rather than in the System.Windows namespace. When writing drag and drop code it’s good practice to insert the following code in your source file:

#if SILVERLIGHT
using Microsoft.Windows;
using SW = Microsoft.Windows;
#else
using SW = System.Windows;
#endif

Using an alias for the namespace with the drag/drop objects ensures that you can write code that can be easily ported to WPF or a future version of Silverlight with core-level drag/drop support. All of the code samples in this series of blog posts assume that you’ve defined the alias “SW” as Microsoft.Windows in Silverlight and System.Windows in WPF.

Starting a Drag Operation

Keep in mind that if you intend to use a DDT you don’t need to know how to do this because DDT’s automatically initiate drag operations when an item is dragged. However if you want to initiate a drag operation yourself you’ll need to know about some subtle (but necessary) differences between the Silverlight’s and WPF’s DoDragDrop methods.

In WPF the DoDragDrop method blocks until the drag operation completes. In Silverlight there are no blocking UI methods so it is necessary to listen for a DragDropCompleted event if you want to perform an operation when a drag completes.

It is still possible to write cross-platform code if you use the following pattern:

// Define an action to be executed when the drag completes.
Action<SW.DragDropEffects> dragDropCompleted =
    effects => 
    {
        Console.WriteLine(string.Format(“Drag finished: {0}”, effects)));
    };
    
#if SILVERLIGHT

// Create a handler for the DragDropCompleted event which invokes the action.
EventHandler<DragDropCompletedEventArgs> dragDropCompletedHandler = null;
dragDropCompletedHandler =
    (sender, args) => 
    {
        // Detach the handler so that this action is only executed once.
        SW.DragDrop.DragDropCompleted -= dragDropCompletedHandler;
        dragDropCompleted(args.Effects);
    };

// Attach the handler to the DragDropCompleted event.
SW.DragDrop.DragDropCompleted += dragDropCompletedHandler;

// Begin the drag operation.
SW.DragDrop.DoDragDrop(
    sourceControl, 
    data, 
    SW.DragDropEffects.All, 
    SW.DragDropKeyStates.LeftMouseButton);    

#else

// If WPF then just begin the drag operation.
SW.DragDropEffects effects = 
    SW.DragDrop.DoDragDrop(
        sourceControl, 
        data, 
        SW.DragDropEffects.All);
        
// Code blocks until drag is finished...
dragDropCompleted(effects);

#endif

Note that in addition to being asynchronous the Silverlight version of DoDragDrop accepts an additional parameter: the initial DragDropKeyStates. In the example below this is SW.DragDropKeyStates.LeftMouseButton.

SW.DragDrop.DoDragDrop(
    sourceControl, 
    data, 
    SW.DragDropEffects.All, 
    SW.DragDropKeyStates.LeftMouseButton);

In Silverlight (unlike WPF) it is not possible to sample the mouse state. Therefore the developer must track the state of the mouse keys and pass it to DoDragDrop. This is straightforward if, as is commonly the case, the drag operation begins with a mouse click.

button.MouseLeftButtonDown += 
    (sender, args) =>
    {
        SW.DragDrop.DoDragDrop(
            button, 
            "Some text to transfer", 
            SW.DragDropEffects.All,
            SW.DragDropKeyStates.LeftMouseButton);
    };

Although the DragDropKeyStates enumeration is a flags enum which includes members that track keyboard states there is no need to include these. The DoDragDrop method will sample the keyboard and update the value when invoked.

Listening to Drag Source and Drag Target Events

In WPF there are two ways to attach a handler to an event. The first is to attach a handler to the event on the UIElement and the second is to attach a handler to the attached event object:

// Works in WPF.
myButton.DragOver += 
    new SW.DragEventHandler((o, a) => Console.Write(“button dragged over.”));

// Works in WPF and Silverlight Toolkit Drag Drop Framework.
myButton.AttachEvent(
    SW.DragDrop.DragOverEvent, 
    new SW.DragEventHandler((o, a) => Console.Write(“button dragged over.”),
    false);

Silverlight Toolkit’s Drag and Drop Framework supports the latter approach for all drag target and source events. By using AttachEvent and RemoveEvent you can write code that will work on WPF and Silverlight. For more information on attached events see the Attached Events Overview on MSDN.

Note: DDTs implement the familiar WPF events so you don’t need to use the more verbose attached event approach when you’re working with them.

// DragDropTarget's have the WPF events.
myListBoxDragDropTarget.DragOver += 
    new SW.DragEventHandler(
        (o, a) => Console.Write(“DDTs make everything easier!”));

Indicating that an Element Can Accept a Drop Operation

In WPF all UIElements have an AllowDrop property which determines whether they will receive drag/drop events. As it isn’t possible to add properties to existing types the Silverlight Tookit implementation of drag and drop uses an AllowDrop attached property on the static DragDrop object:

WPF

<Rectangle AllowDrop="True" />

Silverlight

<Rectangle 
    xmlns:msWindows="clr-namespace:Microsoft.Windows;assembly=System.Windows.Controls.Toolkit" 
    mswindows:DragDrop.AllowDrop="True" />

Customizing DragDropTarget Behavior

DDT’s do their best to determine the allowed effects of a drag operation by examining the bound collection and the items inside of them. For example if a DDT’s control is bound to a ReadOnlyCollection or an array then the allowed effects of a drag will not include DragDropEffects.Move and the allowed effects of a drop will be DragDropEffects.None. By default a DDT never sets the allowed effects of a drag to DragDropEffects.Copy because there is no generic way of cloning an item in Silverlight (ICloneable does not exist). But what if we wanted the effect of a drop to be a Copy operation?

Let’s say we have two DDT’s, one containing a ListBox and the other containing a DataGrid.

<StackPanel Orientation="Horizontal">
    <controlsToolkit:ListBoxDragDropTarget x:Name="listBoxDragDropTarget"  HorizontalContentAlignment="Stretch" VerticalContentAlignment="Stretch">
        <ListBox x:Name="listBox" VerticalAlignment="Stretch" SelectionMode="Extended"  Height="300" >
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <Image Source="{Binding Image}" />
                        <TextBlock Text="{Binding Name}" VerticalAlignment="Center" Margin="4,0,0,0" />
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
            <ListBox.ItemsPanel>
                <ItemsPanelTemplate>
                    <StackPanel Orientation="Vertical" />
                </ItemsPanelTemplate>
            </ListBox.ItemsPanel>
        </ListBox>
    </controlsToolkit:ListBoxDragDropTarget>
    <dataToolkit:DataGridDragDropTarget x:Name="dataGridDragDropTarget" msWindows:DragDrop.AllowDrop="true"  HorizontalContentAlignment="Stretch" VerticalContentAlignment="Stretch">
        <data:DataGrid x:Name="dataGrid" AutoGenerateColumns="False"  Height="300" >
            <data:DataGrid.Columns>
                <data:DataGridTextColumn Binding="{Binding Name}" Header="Name" />
                <data:DataGridTextColumn Binding="{Binding Reputation}" Header="Reputation"  />
                <data:DataGridTextColumn Binding="{Binding GamerScore}" Header="GamerScore" />
            </data:DataGrid.Columns>
        </data:DataGrid>
    </dataToolkit:DataGridDragDropTarget>
</StackPanel>

Each control is bound to an collection of Gamer instances.

class Gamer {
    public string Name {get; set}
    public double Reputation {get; set}
    public int GamerScore {get;set;}
    
    // Our custom copy method.
    public Gamer Clone()
    {
        return 
            new Gamer 
            {
                Name = this.Name,
                Reputation = this.Reputation,
                this.GamerScore = this.GamerScore
            };
    }
}

// snip...

// No need to use an ObservableCollection.  We don't
// want items removed from the ListBox.
listBox.ItemsSource = 
    new []
    {
        new Gamer 
        { 
           Name = "Mark Rideout",
           Reputation = 82.234,
           GamerScore = 23432
        },
        // etc.
   };

// Using an observable collection ensures that changes
// to the items source collection will be reflected 
// in the grid immediately.
dataGrid.ItemsSource =
    new ObservableCollection<Person>();

When the user drags Gamers from the ListBox to the DataGrid we’d like to add a copy of the Gamer object to the DataGrid rather than add a reference to the object in the ListBox to the DataGrid’s bound collection (the default action). In order to ensure that when an item is dragged from a ListBox the allowed effect is DragDropEffects.Copy rather than DragDropEffects.Link we set the ListBoxDragDropTarget’s AllowedSourceEffects property.

listBoxDragDropTarget.AllowedSourceEffects = SW.DragDropEffects.Copy;

Since the DataGridDragDropTarget doesn’t know how to handle a Copy operation we need to handle its Drop event.

using System.Collections.ObjectModel;

// snip...
dataGridDragDropTarget.Drop += 
    (sender, args) =>
    {
        // Only handle this event if it's a copy.  If the event is not handled
        // the DDTs base implementation of Drop will execute.
        if ((args.AllowedEffects & SW.DragDropEffects.Copy) == SW.DragDropEffects.Copy)
        {
            IList<Person> dataSource = dataGrid.ItemsSource as IList<Person>;
            
            // Retrieve the dropped data in the first available format.
            object data = args.Data.GetData(args.Data.GetFormats()[0]);
            
            // The data is the ItemDragEventArgs that was created by the DDT when
            // the drag started.  It contains a SelectionCollection.
            // SelectionCollection's are used by DDTs because they can transfer 
            // multiple objects.  The fact that they store the indexes of the 
            // objects within the source collection also makes reordering items
            // within a source possible.
            ItemDragEventArgs dragEventArgs = data as ItemDragEventArgs;
            SelectionCollection selectionCollection = dragEventArgs.Data as SelectionCollection;
            if (selectionCollection != null)
            {
                IEnumerable<Gamer> gamers = selectionCollection.Select(selection => selection.Item).OfType<Gamer>();
                if (gamers.Any())
                {
                    foreach(Gamer gamer in gamers)
                    {
                        // Invoke our custom Clone method to make a copy.
                        dataSource.Add(gamer.Clone());
                    }
                    args.Effects = SW.DragDropEffects.Copy;
                    args.Handled = true;                
                }
            }
        }
    };

Now when we drag items from our ListBox to our DataGrid we will get copies of the Gamer objects and the ListBox’s contents will be unchanged.

There are many more extensibility points in DDT’s. I encourage you to take a close look at the events and properties. I think you’ll be impressed by how flexible these controls are.

Powerful and Flexible

By now it should be clear that the Silverlight Toolkit Drag and Drop Framework is more than a few DDTs that add drag and drop behavior to a certain Silverlight controls. It is also a rich set of WPF-compatible events and methods that can be used with any Silverlight control - including your own!

Next time: Adding Drag and Drop support to your custom controls!

New with the Silverlight Toolkit: Drag and Drop Support for all your Favorite Controls! (Part 1)

2009-10-19T18:18:00.000-07:00

One of the highest voted requests on the Silverlight Toolkit CodePlex page is drag and drop support for the TreeView control. The good news is the Toolkit team listened and has not only delivered Drag and Drop for the TreeView, but they’ve added support for all the major Silverlight controls! In the October Toolkit refresh you’ll find controls which add Drag and Drop support to all of your favorite controls – no code required!

Introducing The Drag/Drop Target Controls

A DragDropTarget is a Content Control that adds default drag and drop actions to the control nested inside of it. DragDropTarget’s provide the following functionality:

1. Initiates a drag operation when an item container is dragged.

2. Displays a snapshot of the the item container by the mouse while it is being dragged.

3. Handles drag target events and specifies which drag operations are possible by examining the item source bound to the nested control.

4. If an item is dropped onto the drag drop target, it is added to the nested control if the nested control is bound to an ObservableCollection (or any collection that implements INotifyCollectionChanged and contains the same type of items as the item that was dropped).

5. Where possible, scrolls vertically and horizontally when an item is dragged near the edge of the control.

This release of the toolkit introduces the following implementations:

ListBoxDragDropTarget
TreeViewDragDropTarget
DataGridDragDropTarget
DataPointSeriesDragDropTarget

ListBoxDragDropTarget

In this example we have a ListBox created in XAML and bound to an observable collection.

<ListBox x:Name=”myListBox />

To add drag and drop functionality to our ListBox we nest it inside of the ListBoxDragDropTarget control…

<toolkit:ListBoxDragDropTarget
  xmlns:toolkit="System.Windows.Controls.Toolkit"
  xmlns:mswindows="Microsoft.Windows"
  mswindows:DragDrop.AllowDrop=”True”>
     <ListBox x:Name="myListBox">
         <ListBox.ItemsPanel>
            <ItemsPanelTemplate>
                <StackPanel />
            </ItemsPanelTemplate>
        </ListBox.ItemsPanel>
     </ListBox>
</toolkit:ListBoxDragDropTarget>

…and that’s it! Now we can drag items to and from our ListBox.

If the SelectionMode of the ListBox is set to Multiple or Extended it is also possible to drag and drop several items at once.

“Why did you need to specify the ItemPanelTemplate?”

The ListBoxDragDropTarget cannot reorder items in a ListBox when it is virtualized because it cannot conclusively determine the index of each item. Therefore we replace the default Panel (VirtualizedStackPanel) with a normal StackPanel. If you don’t need to enable the reordering items within the ListBox then it isn’t necessary to specify the ItemPanelTemplate.

TreeViewDragDropTarget

The TreeViewDragDropTarget is used the same way as the ListBoxDragDropTarget.

<controlsToolkit:TreeViewDragDropTarget msWindows:DragDrop.AllowDrop="true"  HorizontalContentAlignment="Stretch" VerticalContentAlignment="Stretch">
    <controlsToolkit:TreeViewDragDropTarget.Resources>
        <win:HierarchicalDataTemplate x:Key="hierarchicalTemplate" ItemsSource="{Binding Reports}">
            <StackPanel Orientation="Horizontal">
                <Image Source="{Binding Image}" Width="16" Height="16" />
                <TextBlock Text="{Binding Name}" VerticalAlignment="Center" Margin="4,0,0,0" />
            </StackPanel>
        </win:HierarchicalDataTemplate>
    </controlsToolkit:TreeViewDragDropTarget.Resources>
    <controls:TreeView ItemTemplate="{StaticResource hierarchicalTemplate}" Height="300" >
    </controls:TreeView>
</controlsToolkit:TreeViewDragDropTarget>

Note that there is no need to specify the ItemPanelTemplate because in Silverlight the TreeView is not virtualized.

The TreeViewDragDropTarget provides all the functionality you’ve come to expect from Windows Explorer (and more).

During a drag operation parent’s expand when hovered over after a short delay
Dragging a parent into itself is forbidden
The ability to drag above, below, and into a node is supported

All of these actions can be overridden or cancelled using the events.

DataGridDragDropTarget

Using the DataGridDragDropTarget is straightforward:

<dataToolkit:DataGridDragDropTarget msWindows:DragDrop.AllowDrop="true"  HorizontalContentAlignment="Stretch" VerticalContentAlignment="Stretch">
    <data:DataGrid x:Name="dataGrid" AutoGenerateColumns="False"  Height="300" >
        <data:DataGrid.Columns>
            <data:DataGridTextColumn Binding="{Binding Name}" Header="Name" />
            <data:DataGridTextColumn Binding="{Binding Reputation}" Header="Reputation"  />
            <data:DataGridTextColumn Binding="{Binding GamerScore}" Header="GamerScore" />
        </data:DataGrid.Columns>
    </data:DataGrid>
</dataToolkit:DataGridDragDropTarget>

Like the ListBoxDragDropTarget, multiple selection is supported. However the DataGridDragDropTarget has some limitations due to the fact that it is not an ItemsControl and it is virtualized, specifically that reordering items within a DataGrid is not supported.

DataPointSeriesDragDropTarget

The DataPointSeriesDragDropTarget supports all of the series that ship with Silverlight Charts. However it is used slightly differently than other DragDropTargets. Instead of wrapping the individual series it is necessary to put the entire Chart in the DragDropTarget.

<chartingToolkit:DataPointSeriesDragDropTarget msWindows:DragDrop.AllowDrop="true" HorizontalContentAlignment="Stretch" VerticalContentAlignment="Stretch">
    <chartingToolkit:Chart x:Name="chart" Background="White">
        <chartingToolkit:ColumnSeries IndependentValueBinding="{Binding Name}" DependentValueBinding="{Binding Reputation}" Title="Reputation" />
        <chartingToolkit:PieSeries IndependentValueBinding="{Binding Name}" DependentValueBinding="{Binding GamerScore}" Title="Gamer Score" />
    </chartingToolkit:Chart>
</chartingToolkit:DataPointSeriesDragDropTarget>

“What if a Chart contains multiple series?”

The DataPointSeriesDragDropTargets allows diambiguation between the series by detecting drop operations on the legend. In other words, items can be dropped both onto the surface of a series or its legend items. In the example below the Chart contains two series: a Pie series and a column series. Items can be dragged from a list box into the column series by dropping the items on the column series’ legend item.

It’s also easy to drag items between series, either by dropping data directly onto a series data point or onto their legend item entries.

A Labour of Love

Silverlight Drag and Drop support is a personal, off-hours project that I’ve been working on sporadically for the last few months. I thought it would be a productive way of learning Rx, the new reactive programming framework for .NET. When I approached the Toolkit team and asked if they would ship it they agreed. Of course, having formerly worked for the Toolkit team creating the Silverlight Chart control, ISM, and the Rating control I had some pretty good contacts ;-).

Next time: Overriding the Default Actions of DragDropTargets

The Joy of Rx: Building an Asynchronous API with Rx and IQueryable (Updated)

2009-08-01T18:13:00.001-07:00

Updated: One of our architects expressed concerns about my original solution to this problem because it required a down-cast to IObservable. In the process of explaining to him why this was unavoidable I figured out that it was, in fact, avoidable. :-) I've since updated this article with a much more elegant solution.

The IObservable interface is a true Microsoft innovation and a very significant discovery. Although we've known for a long time that iteration could be done either via push or pull we hadn't figured out how to do push iteration in a composable way until IObservable came along. It's interesting to speculate about how the .NET framework might've been designed differently if IObservable had been present alongside IEnumerable in .NET 1.0. Here are a few questions that haunt me...

Rather than introduce the redundant concept of an event into the CLR would we have used properties of type IObservable instead?
Would all asynchronous API's return an IObservable rather than use one of any number of other patterns.
Would the "yield" keyword in C# work for methods that return IObservable as well as those that return IEnumerable?
Would the ItemsSource property of the Silverlight/WPF ItemsControl (which most data controls derive from or are modeled after) be of type IObservable (or object) rather than IEnumerable?

There's no way of knowing for sure but I like to think the answer to these questions is "yes." There is yet another question worth asking now with the benefit of hindsight:

If IObservable had been in BCL all along would IQueryable inherit from IObservable as well as IEnumerable (or neither)?

Probably. The most common use of IQueryable is to execute query logic on a remote machine. Because they take a relatively large amount of time it makes sense to make remote calls asynchronously and expose a non-blocking interface. Ideally IQueryable wouldn't inherit from either IObservable or IEnumerable. Instead it probably should've had its own implementation of the query operators and provided two conversion methods: ToEnumerable and ToObservable. Unfortunately this would be a breaking change at this point and is therefore highly unlikely to happen.

"Okay, okay. You're bumming me out. How can I traverse an IQueryable asynchronously?"

Before we take a look at an example it might be helpful to have a look at the first part of the excellent "Building a Linq IQueryable Provider" series on the Wayward Weblog. I'm going to use the code in that article as a starting point.

Asynchronously Querying Yahoo Finance

Yahoo Finance has a REST service that returns stock history in a CSV file. We'd like to be able to query for stocks using an API like this:

YahooFinance service = new YahooFinance();

IQueryable stockInfos =
    from stock in service.Stocks
    where stock.Name == "MSFT"
    where stock.Date > new DateTime(1999, 1, 1)
    select stock;

First we'll create a simple C# class which will wrap the REST service and expose an asynchronous API. To build it we'll use the GetDownloadString extension method we introduced to WebClient in my last Rx post.

public class YahooFinanceStockService
{
    private WebClient client = new WebClient();
    const string uriFormat = "http://ichart.finance.yahoo.com/table.csv?s={0}&a={1}b={2}&c={3}&d={4}&e={5}&f={6}&g=d&ignore=.csv";

    public IObservable<StockInfo> GetStockInfo(string name, DateTime from, DateTime to)
    {
         return
            client.GetDownloadString(
                new Uri(
                    string.Format(
                        uriFormat,
                        name,
                        from.Day,
                        from.Month,
                        from.Year,
                        to.Day,
                        to.Month,
                        to.Year)))
                .SelectMany(
                    text =>
                        (
                        // retrieve each line in the CSV file
                        from line in
                            text
                                // remove trailing line break at end of file
                                .Trim()
                                .Split('\n')
                                // skip header line
                                .Skip(1)
                        let fields = line.Split(',')
                        select
                            new StockInfo
                            {
                                Name = name,
                                Date = DateTime.Parse(fields[0]),
                                Open = double.Parse(fields[1]),
                                High = double.Parse(fields[2]),
                                Low = double.Parse(fields[3]),
                                Close = double.Parse(fields[4]),
                                Volume = int.Parse(fields[5]),
                                AdjustedClose = double.Parse(fields[6])
                            }
                        ).ToObservable());
    }
}

Next we'll create a YahooFinanceQueryProvider that derives from the QueryProvider class introduced in the Wayward Weblog series. The query provider interprets the query expression, makes one or more calls to the service's GetStockInfo method, and returns a single IObservable when its Execute method is called.

public class YahooFinanceStocksQueryProvider : QueryProvider
{
    private YahooFinanceStockService service = new YahooFinanceStockService();

    public override string GetQueryText(Expression expression)
    {
        return "YahooFinance.Stocks";
    }

    public override object Execute(Expression expression)
    {
         /* Normally this would contain generic logic to
          * parse the query and make the appropriate call to the
          * service.  That's outside of the scope of this article so
          * we'll just make a call to the service with constant data. */
        return service.GetStockInfo("MSFT", new DateTime(1999, 1, 1), DateTime.Now);
    }
}

Now that we have a query provider let's create a query object that we can expose. We'll start with the Query class from the Webward Weblog series but we'll make a few small changes:

We'll rename the class from Query to ObservableQuery.
In addition to IQueryable our ObservableQuery class will also implement IObservable.
If the ObservableQuery object is traversed synchronously (foreach) we'll convert the IObservable object returned by the query provider to an IEnumerable.

    public class ObservableQuery<T> : IQueryable<T>, IQueryable, IEnumerable<T>, IEnumerable, IOrderedQueryable<T>, IOrderedQueryable, IObservable<T>
    {
        internal QueryProvider provider;

        internal Expression expression;

        // snip...

        public IEnumerator<T> GetEnumerator()
        {
            return ((IObservable<T>)this.provider.Execute(this.expression)).ToEnumerable().GetEnumerator();
        }

        public IDisposable Subscribe(IObserver<T> observer)
        {
            return ((IObservable<T>)this.provider.Execute(this.expression)).Subscribe(observer);
        }
    }

"Hold on a second. Why bother to change the query provider to return an IObservable when we can just do the reverse? We could just convert the IEnumerable to an IObservable if our Query object was traversed asynchronously?"

We don't want to do this because converting an asynchronous operation to an IEnumerable uses a precious resource: a thread. Let's say our query provider makes several calls to our web service, one for each stock in the query. We would hope that it would make these calls concurrently. If the query provider had to return an IEnumerable it would need to block and wait for the results from the worker threads. If we turn around and immediately convert that IEnumerable into an IObservable a thread is completely wasted. Therefore to conserve threads we should avoid converting an IObservable to an IEnumerable until we absolutely have to.

Now we're ready to write the Yahoo Finance class that we will query against.

public class YahooFinance
{
    public YahooFinance()
    {
        this.Stocks = new ObservableQuery<StockInfo>(new YahooFinanceStocksQueryProvider());
    }

    public ObservableQuery<StockInfo> Stocks { get; internal set; }
}

Now if we wrote a query against our Yahoo Finance class and compiled the code we would get the compiler error "Multiple Implementations of the Query Pattern were found for the source type." The C# compiler would be confused because ObservableQuery implements both IEnumerable and IObservable and it wouldn't know which set of extension methods to invoke. The answer is to implement the query pattern for our concrete ObservableQuery class because the compiler will always choose the methods from the most derived class.

public static class ObservableQuery
    {
        public static ObservableQuery<T> Where<T>(this ObservableQuery<T> q, Expression<Func<T, bool>> predicateExpression)
        {
            MethodInfo method = typeof(ObservableQuery).GetMethods().Where(m => m.Name == "Where" && m.GetParameters().Length == 2).First();
            method = method.MakeGenericMethod(new Type[] { typeof(T) });

            var expression = 
                Ex.Call(method, q.expression, predicateExpression);
            return new ObservableQuery<T>(q.provider, expression);
        }

        public static ObservableQuery<R> Select<T,R>(this ObservableQuery<T> q, Expression<Func<T, R>> predicateExpression)
        {
            MethodInfo method = typeof(ObservableQuery).GetMethods().Where(m => m.Name == "Select" && m.GetParameters().Length == 2).First();
            method = method.MakeGenericMethod(new Type[] { typeof(T), typeof(R) });

            var expression =
                Ex.Call(method, q.expression, predicateExpression);
            return new ObservableQuery<R>(q.provider, expression);
        }

        // etc, etc, etc...
    }

Every time an ObservableQuery extension method is called we append the method call to the expression created so far! In cases where a method accepts a function as a parameter (ex. Select, Where, OrderBy) we accept an expression of that function type instead. This ensures that we don't lose any of the information about the query expression as we're building it. The end result of our query is an ObservableQuery that knows exactly what expression it must execute.

Asynchronously Iterating our Observable Query

Query expressions against an ObservableQuery return a new ObservableQuery - which is an IObservable. Iterating its results is just a matter of subscribing to it.

YahooFinance service = new YahooFinance();

IQueryable stockInfos =
    from stock in service.Stocks
    where stock.Name == "MSFT"
    where stock.Date > new DateTime(1999, 1, 1)
    select stock;

stockInfos.Subscribe(stock => Debug.WriteLine(stock));

On the other hand if we want to traverse the results synchronously we can use foreach...

foreach(StockInfo stock in stockInfos)
{
    Debug.WriteLine(stock);
}

Asynchronous Queryable Services

That's it. Hopefully existing query providers will be updated to use this approach so that they can support asynchronous iteration.

The Joy of Rx: The Event-based Async Pattern vs. IObservable

2009-07-30T10:32:00.001-07:00

In part 1 we talked about how to convert events to IObservables. However Rx isn't just about querying events, it's also about querying asynchronous operations.

There are two common asynchronous patterns in the .NET framework: the event-based asynchronous pattern and Begin/EndInvoke. Currently MSDN recommends using the event-based asynchronous pattern where possible. This recommendation may or may not change when IObservable is released with .NET 4.0. I want to make clear that the opinions expressed in this post are my own personal views and are not consistent with official MSDN guidance.

Don't use the event-based asynchronous pattern. Or if you must use the event-based asynchronous pattern be sure to also provide a Begin/EndInvoke version of the API that uses IAsyncResult. Why? Because the event-based asynchronous pattern is deeply flawed. To understand why let's examine a typical piece of code that uses the event-based asynchronous pattern.

Guid token = Guid.NewGuid();
var webClient = new WebClient();
// We need to refer to the identifier within the body
// of the method so we must first initialize it to null.
// This means we can't use type inference to avoid
// having to clutter our code with this absurdly long 
// (and entirely unnecessary) delegate type.
DownloadStringCompletedEventHandler handler = null;
handler = (o, a) =>
{
   if (((Guid)a.UserState) != token)
      return;

   // unhook from the event so that we don't keep firing
   // after we've gotten our data asynchronously.
   webClient.DownloadStringCompleted -= handler;
   if (a.Error != null)
   {
       // Handle exception.  This may include throwing but
       // we may also have to invent some method of manually 
       // propagating it if we don't have the knowledge to 
       // handle it at this point and we are in the middle of several 
       //other asynchronous operations.
   }
   if (!a.Cancelled)
   {
      Debug.WriteLine(string.Format("The downloaded HTML is {0}.", a.Result));
   }
}
// Notice that the only link between the method and the event that returns
// its data is a simple naming convention.  There's no way to know for _sure_
// which event will return a method's data.
client.DownloadStringCompleted += handler;
client.DownloadStringAsync(new Uri("http://www.jeffwilcox.com"), token);

A thoroughly awful piece of code no? The good news is that by adding an extension event to the WebClient class we can wrap the event-based asynchronous pattern in an IObservable. Using Rx works around all of the the issues pointed out in the comments above.

Of course it's rather cumbersome to create a new class that inherits from IObservable whenever we need to return the result of an asynchronous operation. It also seems a little silly given that IObservable only has one method: Subscribe. Given this fact it's helpful to create an AnonymousObservable class which accepts an action and invokes it when the Subscribe method is called.

    internal class AnonymousObservable<T> : IObservable<T>
    {
        private Func<IObserver<T>, IDisposable> subscribeAction;

        public AnonymousObservable(Func<IObserver<T>, IDisposable> subscribeAction)
        {
            this.subscribeAction = subscribeAction;
        }

        public IDisposable Subscribe(IObserver<T> observer)
        {
            return subscribeAction(observer);
        }
    }

Now that we've got our handy, reusable AnonymousObservable class we're ready to create our GetDownloadString extension event.

public static class WebClientExtensions
    {
       // No need to put Async in the method title, it's implicit given that
       // an observable is being returned.
        public static IObservable<string> GetDownloadString(this WebClient client, Uri address)
        {
            // Delay action by nesting it in an observable.
            // Nothing should ever happen until a client subscribes to the
            // observable, just as nothing should happen until an 
            // IEnumerable is traversed.
            return new AnonymousObservable<string>(
                observer =>
                {
                    // Several downloads may be going on simultaneously.
                    // The token allows us to establish that we're retrieving
                    // the right one.
                    Guid token = Guid.NewGuid();

                    var stringDownloaded =
                        Observable.FromEvent<DownloadStringCompletedEventArgs>(client, "DownloadStringCompleted")
                            // Confirm its our download using captured state variable
                            .Where(evt => ((Guid)evt.EventArgs.UserState) == token)
                            .Take(1);        //implicitly unhooks handler after event is received

                    bool errorOccurred = false;
                    // Subscribe to the IObservable.  Under the hood Rx
                    // creates an anonymous observer class that invokes
                    // the three actions passed to the Subscribe method.
                    IDisposable unsubscribe = 
                        stringDownloaded.Subscribe(
                            // OnNext action
                            ev => 
                            {
                                // Propagate the exception if one is
                                // reported.  After this, all observers
                                // will continue to propagate this
                                // exception via the OnError method call
                                // until it is caught.
                                if (ev.EventArgs.Error != null)
                                {
                                    errorOccurred = true;
                                    observer.OnError(ev.EventArgs.Error);
                                }
                                else if (!ev.EventArgs.Cancelled)
                                {
                                    observer.OnNext(ev.EventArgs.Result);
                                }
                            },
                            // OnError action (propagate exception)
                            ex => observer.OnError(ex),
                            // OnCompleted action
                            () =>
                            {
                                // No need to call OnCompleted if 
                                // there has been an exception.
                                // It is implicit that there will 
                                // be no more data.
                                if (!errorOccurred)
                                {
                                    observer.OnCompleted();
                                }
                            });
                    client.DownloadStringAsync(address, token);
                    return unsubscribe;
                });
        }
    }

Granted converting the event-based asynchronous pattern to IObservable requires a little bit of code, but the complexity is pushed onto the library developer. Look at how easy it is to consume the IObservable API.

var webClient = new WebClient();
webClient
   .GetDownloadString(new Uri("http://www.jeffwilcox.com"))
   .Subscribe(html => Debug.WriteLine(html));

No need to fuss with event argument objects. The IObservable/IObserver objects take on the concerns of cancelling and propagating exceptions. The developer is given exactly what he or she expects: an asynchronously downloaded string containing the contents of a web page.

Building Complex Queries by Combining Asynchronous Operations

Now that we've got our handy GetDownloadString extension method we can build some pretty complex queries with it. Let's use it to download the HTML from the first ten results pages of a Bing search at once.

public static class EnumerableExtensions
{
    // This is a very handy extension method missing from Linq.
    public static IEnumerable<T> Iterate<T>(T initalValue, Func<T, T> next)
    {
        yield return initalValue;
        while (true)
        {
            initalValue = next(initalValue);
            yield return initalValue;
        }
    }
}
    // snip...

var client = new WebClient();
var uri = "http://www.bing.com/search?q=Rx+framework&first={0}&FORM=PERE3";
var pageSize = 10;
var resultIndices = EnumerableExtensions.Iterate(1, prev => prev + pageSize).Take(10);
var pageDownloads =
    resultIndices
       .Select(
           resultIndex =>
               client
                   .GetDownloadString(new Uri(string.Format(uri, resultIndex)))
                   // append the result index to the results so we can sort by it later
                   .Select(html => new { ResultIndex = resultIndex, Html = html }))
       // Merge all of the observables into one so that we can subscribe to all of
       // them simultaneously.
       .Aggregate(
           (simultaneousDownloads, currentDownload) =>
               Observable.Merge(simultaneousDownloads, currentDownload));

var concatenatedHtml =
    pageDownloads
        // Convert to a blocking enumerable.  It makes no sense for 
        // IObservable to have a GroupBy or OrderBy method because 
        // both these methods must block until all the data is received.
        // However all of the downloads will begin simultaneously when
        // we traverse the IEnumerable
        .ToEnumerable()
        // Order by the result index
        .OrderBy(pageDownload => pageDownload.ResultIndex)
        // Grab the HTML
        .Select(pageDownload => pageDownload.Html)
        // Concatenate the HTML strings
        .Aggregate((accumulatedHtml, html) => accumulatedHtml + html)
        // Grab the first (and only) result.
        .First();

Pretty slick right? There's only one problem. This code doesn't work :-(. It will block forever. The problem is that the event-based asynchronous pattern always returns on the thread it originates from and that thread is blocked by the call to GetEnumerator().

In the past returning on the UI thread was convenient because developers didn't have to worry about cross-thread accesses. With Rx hopping threads is so easy that cross-thread access isn't much of a concern.

var uiContext = SyncrhonizationContext.Current;
AsyncAction.Post(uiContext).Subscribe(() => Debug.Write("Now I'm back on the UI thread!"));

Unfortunately the fact that the event-based async pattern hops the the UI thread makes it much more difficult to compose a set of asynchronous operations together and block on the result. This is why it's important to always provide a Begin/End Invoke version of your event-based, asynchronous API's.

WebClient doesn't provide a Begin/End overload for DownloadStringAsync so to work around the blocking problem we'll have to create an non-blocking OrderBy method for IObservable.

    public static class ObservableExtensions
    {
        public static IObservable<T> OrderBy<T, R>(this IObservable<T> that, Func<T, R> keySelector)
        {
            return new AnonymousObservable<T>(
                observer =>
                {
                    var orderBySubject = new OrderBySubject<T, R>(keySelector);
                    var unsubscribe = orderBySubject.Subscribe(observer);
                    that.Subscribe(orderBySubject);

                    return unsubscribe;
                });
        }

        public class OrderBySubject<T,R> : Subject<T>
        {
            private Func<T,R> keySelector { get; set; }

            public OrderBySubject(Func<T, R> keySelector)
            {
                this.keySelector = keySelector;
            }
            List<T> list = new List<T>();
            public override void OnNext(T value)
            {
                list.Add(value);
            }
            public override void OnCompleted()
            {
                foreach (var item in list.OrderBy(keySelector))
                {
                    base.OnNext(item);
                    base.OnCompleted();
                }
            }
        }
    }

Now we can rewrite the code above asynchronously.

// snip...
var concatenatedHtml =
    pageDownloads
        // Order by the result index
        .OrderBy(pageDownload => pageDownload.ResultIndex)
        // Grab the HTML
        .Select(pageDownload => pageDownload.Html)
        // Concatenate the HTML strings
        .Aggregate((accumulatedHtml, html) => accumulatedHtml + html)
        // Write the first (and only) result.
        .Subscribe(html => Debug.Write(html));

Of course I could've avoided the blocking problem by using the WebRequest object because it has Begin/End methods. However the point of this article was to show that although the event-based asynchronous pattern can be converted to an IObservable the abstraction leaks.

Think Ahead When Designing Asynchronous APIs

If Rx is embraced (which I expect it will be) existing event-based asynchronous APIs will be more cumbersome to work with than those written using the alternative Begin/End Invoke pattern. I ask developers to consider this when designing asynchronous APIs today.

The Joy of Rx: Extension Events

2009-07-30T01:45:00.001-07:00

Based on the logs it seems there is tremendous interest in Rx, the new .NET 4.0 interfaces that allow you to query events and asynchronous operations. I can't say I'm surprised. In my opinion Rx is the big story of .NET 4.0. I've been developing software using Rx for months now and I thought I'd share some tips and tricks that I've picked up with the community. You can get the Sivlerlight version of Rx from the binaries folder in the Silverlight Toolkit sources.

Converting Events to IObservables

One of the cumbersome things about Rx development is that events must be converted to IObservable's before they can be queried. Rx provides a static FromEvent method to help with the conversion:

var mouseMove = Observable.FromEvent<MouseEventArgs>(Application.Current.RootVisual, "MouseMover");

mouseMove.Subscribe(() => Debug.WriteLine("the mouse has been moved.");

Unfortunately putting event names (or any identifiers for that matter) in strings breaks our refactoring tools. Rx does provide another overload which accepts two actions, one that attaches the handler and another that detaches it...

class MyClass
{
   public EventHandler<RoutedEventArgs> MyEvent;
}

var myClass = new MyClass();
var myClassEvent = Observable.FromEvent<RoutedEventArgs>(handler => myClass.MyEvent += handler, handler => myClass.MyEvent -= handler);
mouseMove.Subscribe(() => Debug.WriteLine("the mouse has been moved.");

...but not only is this overload rather more verbose, it only works if the delegate type of your event is the generic EventHandler<T>. Unfortunately most events use custom delegate types because in .NET 1.0 generics did not exist.

**Updated: There is an overload which I missed that accepts the delegate type:

var myButton = new Button();
var myButton = Observable.FromEvent<RoutedEventHandler, RoutedEventArgs>(handler => myClass.Click += handler, handler => myClass.Click -= handler);

So what's the best way of exposing events as IObservables?

Extension Events

If you're doing Rx development in C# it's good practice to create extension methods for each event you would like to query. You can think of these methods as extension events. To demonstrate let's create a static class with extension methods that expose the events on Silverlight/WPF's UIElement class as IObservables.

    internal static class UIElementExtensions
    {
        public static IObservable<Event<MouseButtonEventArgs>> GetMouseLeftButtonDown(this UIElement that)
        {
            return Observable.FromEvent<MouseButtonEventArgs>(that, "MouseLeftButtonDown");
        }

        public static IObservable<Event<MouseButtonEventArgs>> GetMouseLeftButtonUp(this UIElement that)
        {
            return Observable.FromEvent<MouseButtonEventArgs>(that, "MouseLeftButtonUp");
        }

        public static IObservable<Event<MouseEventArgs>> GetMouseLeave(this UIElement that)
        {
            return Observable.FromEvent<MouseEventArgs>(that, "MouseLeave");
        }

        public static IObservable<Event<MouseEventArgs>> GetMouseEnter(this UIElement that)
        {
            return Observable.FromEvent<MouseEventArgs>(that, "MouseEnter");
        }
    }

Unfortunately our event names are stored in strings, but at least they are in one place. Now that we've created extension methods that expose IObservables we can create more complex events by sequencing these primitive events.

Sequencing Events

The most exciting thing about Rx is that it enables you build complex events from a sequence of primitive events. Let's create an observable that fires when the sequence of keys "a", "b", "c" is pressed:

// create an event that listens for key presses and returns the
// key pressed.
IObservable<Key> keyPress = 
   Observable.FromEvent<KeyEventArgs>(Application.Current.RootVisual, "KeyUp")
      .Select(ev => ev.EventArgs.Key);

// Create a helper function for creating observables that fire
// when a specific key is pressed.
Func<Key, IObservable<Key>> pressedIs = 
   key => keyPress.Where(pressedKey => pressedKey == key);

// Create a helper function for creating observables that fire
// when a key other than a specific key is pressed.
Func<Key, IObservable<Key>> pressedIsNot = 
   key => keyPress.Where(pressedKey => pressedKey != key);

IObservable<Unit> abcPressed =
   // Always listen for a key press "A" because it is the start of the sequence.  
   // Each time the "A" key is pressed we being matching  the sequence again.
   from firstKeyPressEvent in pressedIs(Key.A)
   // After "A" is pressed when only want to wait for a single "B" key press.
   // If any other key is pressed we start at the beginning and wait for "A"
   from secondKeyPressEvent in pressedIs(Key.B).Take(1).Until(pressedIsNot(Key.B))
   // After "B" is pressed when only want to wait for a single "C" key press.
   // If any other key is pressed we start at the beginning and wait for "A"
   from thirdKeyPressEvent in pressedIs(Key.C).Take(1).Until(pressedIsNot(Key.C))
   // I could return the string "abc" here but we know what exactly what keys    
   // were pressed because this event is so specific.  I really don't have anything
   // to return but all queries must return something.  In cases like this we return the 
   // Unit value.  It's like returning null, but it has a type and can't cause a null
   // reference exception.
   select new Unit();

abcPressed.Subscribe(()=> Debug.WriteLine("ABC was pressed."));

Just as in Linq to Objects, multiple uses of the "from" keyword are translated into nested calls to the SelectMany extension method. The abcPressed query above could also be coded this way:

IObservable<Unit> abcPressed =
   pressedIs(Key.A)
      .SelectMany(
         firstKeyPressEvent => 
            pressedIs(Key.B).Take(1).Until(pressedIsNot(Key.B))
               .SelectMany(
                  secondKeyPressEvent => pressedIs(Key.C).Take(1).Until(pressedIsNot(Key.C))))
      .Select(_ => new Unit());

Building a "Click" Extension Event

Now that we know how to sequence events let's use Rx to add a "Click" extension event to all instances of UIElement - a class from which all Controls inherit. The sequence of events that constitute a click event are a little more complex than one might think. In a nutshell we consider a click event on UIElement "A" has occurred if we match this sequence of events...

1. MouseLeftButtonDown over UIElement "A"

2. MouseLeftButtonUp over UIElement "A"

...or this sequence of events...

1. MouseLeftButtonDown over UIElement "A"

2. MouseLeave UIElement "A"

3. MouseEnter UIElement "A"

4. MouseLeftButtonUp over UIElement "A"

...but NOT this sequence of events:

1. MouseLeftButtonDown over UIElement "A"

2. MouseLeave UIElement "A"

3. MouseEnter UIElement "B"

3. MouseLeftButtonUp over UIElement "B"

3. MouseLeftButtonDown over UIElement "B"

2. MouseLeave UIElement "B"

3. MouseEnter UIElement "A"

4. MouseLeftButtonUp over a UIElement "A"

Let's add a GetClick extension event to the UIElementExtensions class we defined earlier.

public static IObservable<Event<MouseButtonEventArgs>> GetClick(this UIElement that)
{
    return
        that
        // wait for any mouse left down event
            .GetMouseLeftButtonDown()
            .SelectMany(
                mouseLeftButtonDownEvent =>
                    // then wait for a single mouse left up event
                    that
                        .GetMouseLeftButtonUp()
                        .Take(1)
                        .Until(
                            // We want to merge two different stop conditions...
                            Observable.Merge(
                                // stop listening if the mouse goes outside
                                // the silvleright plug-in
                                Application.Current.RootVisual.GetMouseLeave()
                                    // We return unit so that we have the
                                    // same type as the other observable
                                    // we want to merge with
                                    .Select(_ => new Unit()),
                                // stop listening if the mouse goes outside the
                                // element and the mouse is released.
                                that
                                    .GetMouseLeave()
                                    .SelectMany(
                                        mouseLeaveEvent =>
                                            // stop waiting for a mouse left up event
                                            // if the mouse leaves the element and the
                                            // button is released.
                                            // By listening for the event at the Root
                                            // Visual we ensure that we will get all
                                            // MouseLeftButtonUp events because this
                                            // event bubbles up.
                                            Application.Current.RootVisual
                                                .GetMouseLeftButtonUp()
                                                .Take(1)
                                                // Return unit so that we can merge
                                                .Select(_ => new Unit())
                                                // don't cancel if the mouse enters
                                                // the element over which the mouse
                                                // was depressed.
                                                .Until(that.GetMouseEnter())))));
}

That's it! Now every single instance of UIElement has a Click event we can subscribe to:

var rectangle = new Rectangle { Width = 100, Height = 100, Fill = new SolidColorBrush(Colors.Red) };

rectangle.GetClick().Subscribe(() => Debug.WriteLine("The rectangle was clicked.");

More Reliable Code, and Less of It

Rx allows you to write complex, asynchronous code declaratively. If you master it you'll never have to explicitly unhook a handler from an event again. You also wont ever have to maintain an error-prone collection of state variables in order to ascertain whether a sequence of events has occurred in a particular order.

*Edit: Here's the code!

Introducing Rx (Linq to Events)

2009-07-22T14:01:00.001-07:00

It’s the most wonderful time of the year: a new version of the Silverlight Toolkit has been released alongside Silverlight 3. This release of the Toolkit has a lot of goodies including a new TreeMap control, a Rating control (written by yours truly), and a useful collection of extensions methods for TreeView. That said this post is not really about the Toolkit. Buried deep in the bin folder of the Silverlight Toolkit Unit Tests is a hidden gem: The Rx Framework (System.Reactive.dll). If you glanced quickly you’d miss it altogether but it’s one of the most exciting additions to the .NET framework since Linq.

Stating the Obvious: Asynchronous Programming is Hard

Developers tend to avoid asynchronous programming if possible because it makes our programs non-deterministic and obscure our code’s intent in a sea of callbacks. However the truth is that asynchronous programming has become an essential part of application development. Client apps have always needed to use asynchronous methods to keep the user interface responsive. As a matter of fact Silverlight developers don’t have any choice in the matter because Silverlight doesn’t include any blocking IO calls. Connected apps also need to take advantage of asynchronous programming to improve scalability. Mashups, apps cobbled together from web services, often need to retrieve data from multiple sources in a particular order.

Clearly we need to write asynchronous code to create modern, connected applications, but how to do it in such a way that our code remains clear and maintainable?

Introducing the Rx Framework

The IEnumerable Interface

We’re all familiar with the IEnumerable interface. Almost every collection implements it and we use it every time we write a foreach. Most of us are also pretty comfortable using Linq to query IEnumerables. Linq is a series of extension methods used to manipulate sequences. Here’s a simple example:

int[] numbers = new int[]{20,31,5,16,22};
IEnumerable<int> numbersSmallerThan20 = numbers.Where(number => number < 20);

The resulting numbersSmallerThan20 sequence looks like this when visualized:

5, 16, break

In addition to finite sequences it can sometimes be useful to create sequences that never end. Take this method that returns an infinite sequence of integers:

IEnumerable<int> NaturalNumbers()
{
     int number = 0;
     while(true)
    {
        yield return number;
        number++;
    }
}

When visualized this sequence looks like this:

0,1,2,3,4,5,6…

Enumerable’s are sequences of data that we pull from a data source. We don’t always pull data though. Often it is pushed onto us and we must react appropriately. This is called “Reactive Programming.”

Reactive Programming

Reactive programs are ubiquitous. We use reactive programming every time we register a handler with an event or a specify a call back for an asynchronous operation. In this example I register a handler for the mouse move event of a button. The handler prints out the location of the mouse when it is called.

button.MouseMove += (o, mouseEventArgs) => Debug.Writeline(“You moved the mouse to {0}”, mouseEventArgs.GetPosition(button));

Every time the mouse event is fired our callback method is invoked and we are passed some information about the event.

“You moved the mouse to 20,3”

“You moved the mouse to 33,12”

“You moved the mouse to 44,18”

Another form of reactive programming is running an asynchronous method and passing it a callback method to invoke when it’s finished. This is how we keep our programs responsive during long-running operations. Here’s an example:

DownloadFile(“http://www.jeffwilcox.com”, (byteArray) => Debug.WriteLine(“This file is {0} bytes long.”, byteArray.Length);

When this method finishes downloading a file it passes the data to our callback function giving us the following result:

“This file is 12323 bytes long.”

We’re all used to doing reactive programming by specifying methods that are called at unpredictable times, but what if there was a different way to think about reactive programming? What if we thought of each piece of data passed to a reactively-called method as an item in a sequence?

Events and Callbacks are Sequences of Data!

The data passed to event handlers and callbacks can be thought of as sequences of data that are “pushed” at you rather than “pulled.” Every time an event is fired we get “pushed” a new piece of data: the EventArgs. Similarly when a callback is invoked it is typically “pushed” the result of the asynchronous method. You can think of an event as a sequence of EventArgs that never ends just like the NaturalNumbers sequence. If you were to visualize the mouse move event as a sequence it would look like this:

new MouseEventArgs(new Point(20,3)), new MouseEventArgs(new Point(33,12)), new MouseEventArgs(new Point(44,18))…

Similarly the asynchronous DownloadFile method can be viewed as a “push” sequence of data with only one entry:

new byte[]{23,211,33,23…}, break

The Rx team has discovered that pull sequences and push sequences are “dual.” That is to say, any operation you can perform on “pull” sequences can also be performed on “push” sequences. This is quite a revelation. To put things in perspective it’s been 13 years since Design Patterns was published and we’ve only now realized that the Observable pattern and the Iterator pattern are actually the same pattern.

Although reactive “push” sequences are fundamentally the same as “pull” sequences the IEnumerable interface can’t be used for reactive sequences because it blocks. We need a new interface with non-blocking methods that correspond exactly to the blocking methods on IEnumerable. We need…

The IObservable/IObserver Interface

Despite the fact that they may look somewhat different on the surface the IObservable/IObserver pair of interfaces are the non-blocking equivalents of IEnumerable/IEnumerator.

To help you understand how they are equivalent let’s take a look at a simple example of traversing a pull sequence. You enumerate an IEnumerable by requesting an IEnumerator. As you call MoveNext the IEnumerator “pulls” data from the IEnumerable, usually by invoking its methods.

IEnumerator<int> numberEnumerator = new int[]{1,2,3};
while(numberEnumerator.MoveNext())
{
     Debug.WriteLine(“{0}”, numberEnumerator.Current);
}

Debug.WriteLine(“all done.”);

This prints:

1
2
3
all done.

To traverse an IObservable you go through the same actions as an IEnumerable but in reverse. You create an IObserver, give it to an IObservable, and the IObservable “pushes” data into the IObserver by invoking its methods. When an IObservable invokes the “OnNext” method on an Observer it is equivalent to an IEnumerable method using the yield keyword to give information to an IEnumerable. Similarly when an IObservable invokes the “OnCompleted” method on an Observer it is equivalent to an IEnumerable using the break keyword to indicate that there is no more data.

Let’s define a NumbersObserver which converts a “pull” sequence of numbers into a “push” sequence as well as an observer that listens to our NumbersObserver and prints its contents.

internal class AnonymousDisposable : IDisposable
{

    internal Action Action {get; internal set;}

    void IDisposable.Dispose()
    {
        this.Action();
    }
}

class NumbersObservable : IObservable<int>
{
    public NumbersObservable(IEnumerable<int> numbers)
    {
        this._numbers = numbers;
    }

    private IEnumerable<int> _numbers;

    public IDisposable Subscribe(IObserver<int> observer)
    {
         foreach(int number in _numbers)
        {
             observer.OnNext(number);
        }
        observer.OnCompleted();

        return new AnonymousDisposable { Action = () => { ; // do nothing because we’ve already called OnCompleted() } }; 
    }
}

class DebugObserver : IObserver<int>
{
    public void OnNext(int value)
    {
        Debug.WriteLine(“{0}”, value);
    }

    public void OnCompleted()
    {
        Debug.WriteLine(“all done.”);
    }

    public void OnError(Exception ex)
    {
        Debug.WriteLine(“Whoops exception, I’d better throw.”)
        throw ex;
    }
}

Now let’s use these classes to create a “push” version of our “pull” example:

new NumbersObservable(new[]{2,3,4}).Register(new DebugObserver());

This prints…

1
2
3
all done.

“Whoa, whoa! Isn’t this pretty complicated?”

Don’t worry. This example above is just to demonstrate the interplay between the interfaces. Most of the time you won’t have to implement your own Observable or Observer. Rx includes lots of methods for constructing observables and observers. Using Rx extension methods I can rewrite the code above like so:

new[]{1,2,3}.ToObservable().Subscribe(number => Debug.WriteLine(“{0}”, number));

“What’s with the IDisposable object?”

The IDisposable object is returned by an Observable when you register an observer with it. When you invoke the Dispose method on the registration object the observer will stop listening to the observable for data. This is the active equivalent of passively not calling MoveNext() anymore in the middle of a sequence. Rather than invoke the Dispose method directly you will most often have it invoked for you by Rx. In the following example the TakeWhile method will invoke Dispose under the hood to detach from an observable as soon as a number larger than 10 is returned.

var numbersSmallerThanTen = Enumerable.Range(0,100).ToObservable().TakeWhile(x => x <= 10);

Here’s an example of invoking Dispose explicitly to detach from an event which has been converted to an Observable:

// Use an Rx method to convert an event to an Observable
IObservable<Event<MouseEventArgs>> mouseMoveEventObservable = Observable.FromEvent<MouseEventArgs>(myControl, “MouseMove”);

// register a handler with the event using an overload that accepts a lambda instead of an Observer
IDisposable registration = mouseMoveEventObservable.Subscribe(mouseMoveEvent => Debug.Write(“The mouse was moved.”));

// stop listening to the event
registration.Dispose();

“What about the OnError method? I don’t see an equivalent for that in IEnumerable or IEnumerator either.”

When errors occur in asynchronous operations the exception must be passed to the callback method so that the callback method can handle it. That’s why this method exists in IObservable but seems to have no equivalent in IEnumerable. In IEnumerable it is implicit because you can use try/catch.

Linq to IObservable

Now that we understand that an IObservable is just a “push” version of IEnumerable it just be obvious that all of the familiar Linq methods apply to it. In fact it is equally appropriate to use query syntax on “pull” sequences and “push” sequences. Both are queries in the strictest sense and the fact that a sequence is push or pull is orthogonal. Let’s analyze a typical Linq query:

IEnumerable<Point> points =
     from x in Enumerable.Range(0, 2)
     from y in Enumerable.Range(0, 2)
     select new Point(x,y);

A verbal description of this query might be:

“For each x in the sequence [0 to 1] get each y in the sequence [0 to 1] and create a new point for each pair of values.”

The result of course is:

0,0
0,1
1,0
1,1

Now let’s contrast this with an Rx query that creates a dragging event for a Silverlight/WPF control:

IObservable<Event<MouseEventArgs>> draggingEvent =
     from mouseLeftDownEvent in control.GetMouseLeftDown()
     from mouseMoveEvent in control.GetMouseMove().Until(control.GetMouseLeftUp())
     select mouseMoveEvent;

A verbal description of this query might be:

“For each mouse left down event, get each mouse move event and return it until the next mouse left up event occurs.”

As you can see, using “from” allows us to declaratively sequence events. The alternative would be to create a state machine, setting a flag when the mouse button is pressed and then behaving differently when the mouse is moved and that flag is set. With Rx the code for the drag event is self-contained and involves no variable mutation.

With Linq to IEnumerable we transform and combine sequences of data to create a sequence containing exactly the data we need. Then we traverse that sequence and do something with the data. With Linq to IObservable we can transform and combine events and async callbacks to create the precise event we’re interested in. Then we register a handler and do something with the data.

Silverlight Toolkit Unit Test Code Written with Rx

The Silverlight Toolkit team is using Rx to write reliable, event-based asynchronous tests. This is essential as the elements in a control’s visual tree are created asynchronously, forcing us to wait for an event in order to confirm they were created appropriately. Let’s take a look at a test for Rating that uses Rx.

This test ensures that the Actual Value of a RatingItem is %100 when its parent Rating is %100. This is tricky because when you change the value of rating it animates to the new value using an internal storyboard. I have to wait for ActualValue to be animated to the Value property before I examine the RatingItem.

The test creates a Rating control, places it on screen, and waits for LayoutUpdated to ensure that the rating items are generated. Then it asynchronously sets the value of rating to 1.0. As the ActualValue of the Rating changes, the various RatingItems will have their ActualValue’s set accordingly depending on their index. The test needs to wait until the Rating’s ActualValue reaches Value before checking to make sure the ActualValue of the last rating item is 1.0.

Rating rating = new Rating();
IObservable<Unit> test =                             // Unit is an object that represents null.
    ObservableExtensions
        .DoAsync(() => TestPanel.Children.Add(rating))
        .WaitFor(TestPanel.GetLayoutUpdated())     // Extension method GetLayoutUpdated converts the event to observable
        .DoAsync(() => rating.Value = 1.0)        // Calls the Ignite EnqueueCallback method
        .WaitFor(                                 // waits for an observable to raise before going on
            // listen to all the actual value change events and filters them until ActualValue reaches Value
            rating                          
            .GetActualValueChanged()        // extension method that converts ActualValueChanged event to IObservable
            .SkipWhile(actualValueChangedEvent => actualValueChangedEvent.EventArgs.NewValue != rating.Value))
        // check to make sure the actual value of the rating item is set appropriately now that the animation has completed
        .Assert(() => rating.GetRatingItems().Last().ActualValue == 1.0) // crawls the expression tree and makes a call to the appropriate Assert method

Test.Subscribe(() => TestPanel.Children.Remove(rating));    //run the test and clean up at the end.

The code above uses a variety of extension methods we built to manipulate observable objects. You can use these libraries in your own unit tests by downloading the Silverlight Toolkit sources.

Always Useing IObservable for New Asynchronous APIs

The IObservable/IObserver interfaces are in .NET framework 4.0. ~~I want to stress that IObservable is the new asynchronous programming pattern in .NET.~~ ~~It supplants the Begin/EndInvoke pattern as well as the event-based asynchronous pattern~~. Simple run of thumb: if the method is asynchronous, return an IObservable. *

*A correction here. It is still perfectly acceptable to use Begin/End Invoke or the event-based asynchronous pattern. Large portions of the framework use these patterns and will continue to do so for the sake of consistency.

Exposing IObservable is like putting lighting in a bottle. Developers can open it up and get access to a galaxy of Linq methods they can use to combine and sequence them with other IObservables. My hope is that eventually API’s exposing IObservable will be just as common as those exposing IEnumerable.

Erik Meijer Strikes Again

Rx is the brainchild of Erik Meijer, the father of Linq and recent recipient of the Outstanding Technical Leadership award at Microsoft. Erik is the reason I chose to work for Microsoft. With the introduction of Rx and his work on Linq and Haskell he has profoundly changed the way I approach software development twice in four years – an incredible feat. Thanks to Meijer, Microsoft does a better job than anyone of taking bleeding-edge functional programming research and productizing it. The Rx team also includes my favorite blogger, Wes Dyer whose blog posts opened my eyes to what an incredibly versatile language C# is.

After using it for the last few months it’s now impossible to imagine doing Silverlight development without Rx. As of today the only place you can get it is in the Silverlight Toolkit sources. Take a look. If you are comfortable with Linq programming you’ll find it to be extremely powerful.

Introducing the Rating Control

2009-07-09T22:42:00.001-07:00

Boys and girls, its the most wonderful time of the year: a new version of Silverlight is shipping. Silverlight 3 shipped today along with a refresh of the Silverlight Toolkit. For this release I had the pleasure of writing the Rating control which is available in both the Silverlight 2 and 3 versions of the Toolkit. In this post I'll give you a high level overview of how Rating works and how you can customize it.

Using Rating

The Rating control is located in the System.Windows.Controls namespace in System.Windows.Controls.Input.Toolkit.dll. Once you've added a XAML namespace you can create a Rating like this...

<inputToolkit:Rating ItemCount="5" />

This will create a Rating control with five stars:

Giving Rating a Value

The Rating control has a Value property which is a ratio from 0 to 1. The Value property is a nullable double. In other words the Value property is either between 0% and 100% or it is null.

The Rating control has two selection modes: Continuous and Individual. In Continuous mode (the default) the control behaves the way most star-based Rating controls do: filling the first two stars and half of the middle one.

<inputToolkit:Rating ItemCount="5" Value="0.5" SelectionMode="Continuous" />

However in individual mode, the stars leading up to the middle star are not filled:

<inputToolkit:Rating ItemCount="5" Value="0.5" SelectionMode="Individual" />

Individual mode is useful when you want to offer discrete selection options:

Adding Rating Items

Rating is an ItemsControl with an ItemCount convenience property which adds instances of RatingItem to the Items collection. Therefore this...

<inputToolkit:Rating ItemCount="5" />

...is equivalent to this...

<inputToolkit:Rating>
   <inputToolkit:Rating.Items>
      <inputToolkit:RatingItem />
      <inputToolkit:RatingItem />
      <inputToolkit:RatingItem />
      <inputToolkit:RatingItem />
      <inputToolkit:RatingItem />
   </inputToolkit:Rating.Items>
</inputToolkit:Rating>

...and this:

var rating = new Rating { ItemsSource = new[]{"", "", "", "", ""} };

ItemCount is convenient if you don't need to bind your rating items to an underlying data source or otherwise vary their appearance. However since RatingItems are content controls if you do bind to a data source your data will be displayed below the RatingItem.

var rating = new Rating { SelectionMode = RatingSelectionMode.Individual, ItemsSource = new[]{"Hate", "Bored", "Good", "Great", "Love"} };

The Template

The Rating ItemsControl uses instances of the RatingItem class as its item container. RatingItem inherits from ContentControl and its template contains an instance of the LinearClipper control. The LinearClipper control is used to hide a portion of the star in the RatingItem template.

In addition to the common visual states the RatingItem control has a "Fill States" visual state group which contains the following states: "Empty", "Partial", and "Filled."

The LinearClipper has a property ExpandDirection which can be used to determine whether it expands Up, Down, Left, or Right. By changing this property along with the ItemPanelTemplate property of Rating you can customize Rating to display and reveal stars vertically.

As Rating is an ItemsControl all the tricks you already know to customize an ItemsControl's appearance apply. I won't rehash how to style an ItemsControl here, there's plenty of information on MSDN. For comprehensive examples of re-templated Rating controls you can take a look at the Rating sample page in Silverlight Toolkit samples.

Rate Rating

Rating is being released under the "Preview" quality band. That means we're looking for feedback on ways in which we can improve it. Try it out and let us know what you think on the CodePlex forums.

Better Unit Tests with Test.Assert() for NUnit/VSTT/SUTF

2009-06-02T12:54:00.001-07:00

It’s been over ten years since Kent Beck created SUnit, the first unit testing framework for SmallTalk. Since then, hundreds of unit testing frameworks have been created in its image, one for nearly every platform and programming language. JUnit, the open-source Java unit testing framework, begat NUnit, the popular .NET port, which inspired Visual Studio Team Test, which was ported to the Silverlight Unit Testing Framework, and it was good.

For the most part NUnit’s and VSTT’s API’s are the same as those of JUnit. This is probably a good thing because it makes it much easier for Java developers to adopt .NET. It was also a natural decision given how similar C# and Java were when NUnit was created. However .NET programming languages have evolved rapidly in the last few years. Have you ever stopped to wonder whether the API’s for the .NET unit testing frameworks should still be so similar to those of JUnit?

Nowadays C# and VB.NET are capable of some very powerful code transformations. Despite the fact that .NET developers are conditioned to think of API’s and programming languages as separate the reality is not so simple. The capabilities of programming languages tend to influence the design of API’s. The question is this: Can we use the advanced features of .NET programming languages to create better unit testing API’s?

“What’s wrong with Unit Testing API’s? They’re pretty straightforward.”

There are three things wrong with the assertion API’s used by the major unit testing frameworks:

1. You Can’t Use Expressions

Let’s take a look at a typical Visual Studio Team Test.

[TestMethod]
public void TestStackIsEmptyWhenCreated()
{
    Stack emptyStack = new Stack();
    Assert.AreEqual(emptyStack.Count, 0, "Stack is not empty.");
}

Ask yourself this question: Is the AreEqual method really necessary? Our programming languages already have a rich set of comparison operators. Most of us are accustomed to writing debug assertions this way:

Debug.Assert(emptyStack.Count == 0, "Stack is not empty.");

Operators make common operations more recognizable to the human eye. If comparison operators are easier to read than the Assert methods why do we use the latter in our unit tests?

The reason is that we want descriptive failure messages in the event our test fails. If we fail the test above by adding an item to the stack we get a failure message much like this:

TestStackIsEmptyWhenCreated failed. Values are not equal. Expected 0, got 1. Stack is not empty.

Notice that in addition to including what type of comparison operation that failed the framework also provides the values being tested. If we were to specify an expression (as in the Debug.Assert example above) it would get compiled into executable code and by the time the UT framework got our expression it would be a black box. As a result it would be impossible to determine what kind of comparison we were attempting or the values of the arguments. Therefore Assert methods are necessary, despite the fact that they are ugly.

2. Assert.AreEqual vs. Assert.AreSame

Another problem caused by the inability to use expressions is that we must be explicit about whether we want to use value or reference comparisons. Have you ever used Assert.AreEqual when you should’ve used Assert.AreSame or vice versa? In some circumstances this can lead to false positives or negatives. It is especially annoying for C# and F# developers as we are used to our compilers choosing the appropriate comparison type for us based on context.

3. Redundant Assertion Messages

It is generally considered good practice to add a custom assertion message to provide more context in the event a test fails. This is especially important if a test makes multiple calls to the same Assert method. Let’s say we left the assertion message out of our unit test:

[TestMethod]
public void TestStackIsEmptyWhenCreated()
{
    Stack emptyStack = new Stack();
    Assert.AreEqual(emptyStack.Count, 0);
}

The resulting message would be:

TestStackIsEmptyWhenCreated failed. Values are not equal. Expected 0, got 1.

Of course this is a very simple test so you could probably infer what went wrong. It is a little cryptic though. In a larger test it would be much more difficult to isolate the issue.

So what’s wrong with assertion messages? They’re superfluous. Ask yourself this question: If you didn’t have to specify a message for the Unit Test Framework to display on failure, would you add that message as a comment above the line of code?

// Testing whether stack is empty
Assert.AreEqual(emptyStack.Count, 0);

The answer is usually no. Assuming you’ve properly named your variables it is rarely necessary to comment assertions. In an ideal world our Unit Testing Framework would output the line of code that failed, just as our compilers do when they encounter syntax errors. This would make most assertion messages redundant.

The Root Problem

All of these issues are caused by the same root problem. Conceptually Unit Testing frameworks are an extension of your compiler. Compilers report static errors such as malformed code and type mismatches and unit testing frameworks report run-time errors such as unexpected values. The reason why Unit Testing API’s are so clunky is that our Unit Testing frameworks don’t have access to as much information as our compiler does. Compilers have access to the expression trees generated by our code. They can analyze the code and determine what type of comparison we are attempting, and whether it is a value or reference comparison. If the compiler encounters an error it can print the exact line of code or expression responsible.

What if there was a way to make our Unit Testing Frameworks as smart as our compilers?

Introducing Test.Assert()

Turns out it is possible to express assertions as expressions and get all the feedback provided by the Assert methods when a test fails (and even more).

Assertions as Expressions

Let’s rewrite our unit test using the Test.Assert() method:

using Unfold.Testing.VSTT;

// snip...

[TestMethod]
public void TestStackIsEmptyWhenCreated()
{
    Stack emptyStack = new Stack();
    emptyStack.Push("an item that shouldn't be here.");
    Test.Assert(() => emptyStack.Count == 0);
}

When we run this test and it fails we’ll get a message resembling this:

TestStackIsEmptyWhenCreated failed. Values are not equal. Expected 0, got 1. emptyStack.Count = 0

Notice that we get the same failure message as Assert.AreEqual in addition to the expression responsible for the failure!

Compound Expressions

Now that we can express assertions as expressions you may be wondering whether it is possible to express several assertions in a single compound expression. With Test Extensions it’s as easy as using the “and” operator.

Test.Assert(() => customer.Name != null && customer.Name != “”);

Now our assertions are much easier to read as well as shorter!

“Hold on. Won’t using compound expressions make it harder to figure out which expression failed?”

No. Test.Assert doesn’t display the line of code that fails, it displays the expression that fails. For example if, in the test above, the customer’s name was an empty string we’d get the following failure messages:

TestCustomerDefaultPropertyValues failed. Values are same. Expected not “”, got “”. customer.Name != “”

“Okay, but what if I still want to specify a custom assertion message?”

No problem. Test Assert has an overload for that:

Test.Assert(() => customer.Name != null && customer.Name != “”, "Customer name is null or empty.");

“Is it available for my Unit Testing Framework?”

Yes – assuming you’re using NUnit or VSTT :-). I’m making the source available under MS-PL so you’re free to port it to your unit testing framework of choice. You’ll find the port is trivial if your unit testing framework uses the familiar Assert methods.

“What about the Silverlight Unit Testing Framework?”

Don’t worry, I haven’t forgotten about Silverlight developers :-). In fact Test.Assert() has been integrated into the Silverlight Unit Testing Framework and will ship with the next version.

“How does it work?”

Test.Assert() improves your Unit Testing Framework by giving it access to the same information your compiler has: the expression tree. Test.Assert is similar to Linq to SQL. It converts your assertion expression into data, analyzes it, and then invokes the appropriate Assert methods.

Like Linq to SQL, Test.Assert() only supports a subset of the functionality provided by the underlying API. For certain assertions, particularly those that don’t use operators, you will still need to use the Assert methods.

“Which Assert Methods are supported?”

Here’s a table that shows which expressions map to which Test.Assert methods.

Expression	NUnit	VSTT/Silverlight Unit Testing Framework
value == true	Assert.IsTrue	Assert.IsTrue
value == false	Assert.IsFalse	Assert.IsFalse
value == 2	Assert.AreEqual	Assert.AreEqual
value != 2	Assert.AreNotEqual	Assert.AreNotEqual
value == “Jim”	Assert.AreSame	Assert.AreSame
value != “John”	Assert.AreNotSame	Assert.AreNotSame
“Jim” is string	Assert.IsInstanceOf	Assert.IsInstanceOfType
!(“Jim” is string)	Assert.IsNotInstanceOf	Assert.IsNotInstanceOfType
value < 2	Assert.Less	N/A
value <= 2	Assert.LessOrEqual	N/A
value > 2	Assert.Greater	N/A
value >= 2	Assert.GreaterOrEqual	N/A
double.IsNaN(value)	Assert.IsNaN	N/A
string.IsNullOrEmpty(“Jim”)	Assert.IsNullOrEmpty(“Jim”)	N/A
!string.IsNullOrEmpty(“Jim”)	Assert.IsNotNullOrEmpty(“Jim”)	N/A

If Test.Assert doesn’t recognize any patterns in your expression it will fallback to the Assert.IsTrue method and pass it your entire expression. Often this - in addition including the expression in the failure message - is adequate. If you want to ensure a specific Assert method is used you can always call that method directly as you would have before.

“What about VB.NET support?”

The expression in the failure message is actually language agnostic and is the produced by calling the ToString() method of the System.Linq.Expressions.Expression object. Sometimes it looks like VB.NET, sometimes it looks like C#. There is no reason why you can’t use Test.Assert() in VB.NET.

“What about F# support?”

Although the F# compiler is not capable of converting code into Linq expression trees, F# does have it’s own expression tree format which can be produced using the quotations language syntax.

let expressionTree = <@@ value = “” @@>

You can convert F# expression trees to Linq expression trees using the F# Power Pack available with the latest version of F#. It should be trivial to write a wrapper method which does the conversion and forwards it to Test.Assert().

“Okay, okay. Where can I get it?”

You can download the source project (MS-PL) here. It includes the VSTT and NUnit versions. Test.Assert() will be integrated into the next release of the Silverlight Unit Testing Framework. Enjoy.

Better WPF/Silverlight Development in F#: Attached Dependency Properties

2009-05-24T11:29:00.001-07:00

A very common idiom in WPF/Silverlight is the attached property. Attached properties are properties that only have meaning in certain contexts, usually in relation to another class. Attached properties are everywhere in WPF/Silverlight. Although they are widely useful they are most commonly used with layout panels. By introducing the notion of attached properties the architects of WPF were able to avoid having to add every conceivable property for every conceivable layout panel to each control (Top, Left, Grid Column, Grid Row, Rotation, and so on).

Of course neither the CLR nor C# has any notion of attached properties. Therefore attached properties are typically implemented using a pair of static set and get methods on the Layout class. These static setter/getter methods use a static dictionary to link a control to its attached property value. As an example the Canvas panel lays controls out in a Cartesian coordinate system and has a Left attached property and a Top attached property. Specifying these properties on a control looks something like this in C#:

Canvas.SetLeft(myTextBox, 23.0);
Canvas.SetTop(myTextBox,24.0);
myCanvas.Children.Add(myTextBox);

This works but it isn't ideal. For one thing attached properties are not discoverable because they do not show up in the control’s intellisense list. However the real issue though is that the code is too low-level, exposing the developer to the implementation of attached properties rather than simply letting them express their intent.

F# has the notion of extension properties. Like extension methods in C#, extension properties can be defined on a class outside of the class definition. So with the smallest dab of code...

type UIElement with
   member this.Left
     with get() = Canvas.GetLeft(this)
     and set(value) = Canvas.SetLeft(this, value)
   member this.Top
      with get() = Canvas.GetTop(this)
      and set(value) = Canvas.SetTop(this, value)

…I can do this…

myTextBox.Left <- 23.0
myTextBox.Top <- 24
myCanvas.Children.Add(myTextBox)

Much better. Now the properties belong to the control but like extension methods they only appear when the assembly with Canvas is imported. Unfortunately with the current build of F# you can't use attached properties in object expressions like this...

Image(Uri = Uri(“test.png”), Left = x * 20, Top = x * 40)

...however I've been assured by Don Syme himself that this will be fixed by VS 2010 Beta 2.

So there you have it. An admittedly small, but very nice trick. More to follow.

.NET Language Evolution: Do you care?

2009-05-24T11:03:00.001-07:00

Luca Bolognese recently announced that C# and VB.NET will now be co-evolved. That is to say, no feature will be introduced to one without being added to the other. I can't deny that this makes sense but as a language geek its certainly not very exciting news. More ominously Luca hinted language evolution was going to "slow down." Yikes.

Apparently some of our customers are having difficulty ramping up on language features introduced alongside .NET 2.0. Although I sympathize with these customers Microsoft made the right call when they took an aggressive approach towards language evolution, adding very significant new features inspired by functional languages. Increasingly their customers are having to write scalable, asynchronous code to leverage multi-core processors. These are hard problems and learning to think about them differently is essential to success. There is a parallel here to the introduction of VB.NET and the phasing out of Visual Basic.

The news that C# and VB.NET evolution is going to taper off should not come as a surprise. You can't keep adding features to a programming languages forever and it's especially hard when they have such a long heritage. Under the circumstances Anders has done an admirable job. Unfortunately there are certain functional algorithms that developers cannot, and will likely never be able to, express cleanly in either C# or VB.NET.

Enter F#. Visual Studio 2010 Beta 1 is here and if you take the plunge you'll find that F# has finally been elevated to a first-class .NET language along-side C# and VB.NET. We have every reason to believe F# will continue to evolve. For starters it's just the first version. Don Syme has also expressed interest in adding language features from Haskell as well. The interesting question is: Does Language Evolution Matter?

There is some controversy over the importance of programming languages. Some believe that it's primarily a developers knowledge of the existing class libraries that matters. It's hard to deny this given the massive size of our libraries today. However my personal experience is that in recent years learning the new language features introduced in C# has significantly improved my productivity, as well as the quality of my code. It still fills me with such a sense of wonder that simply thinking about a problem differently can have such a profound effect. It is for this reason that I've already made F# my primary language for play. I hope to get the opportunity to use it at work at some point as well. There are some very compelling reasons to use it to solve certain types of problems we face in WPF/Silverlight development. After all if not at Microsoft, then where? :-)

You can expect more Silverlight/WPF-related F# blog posts from me in the future.

Rx Framework: Asynchronous Programming Made Easy

2009-04-27T17:28:00.001-07:00

A few weeks ago, to little fanfare Erik Meijer gave a presentation on the Rx Framework at the Lang.NET symposium. You probably missed it. Don't worry though. It's no big deal. It's only the culmination of one the most significant discoveries about the fundamental nature of asynchronous programming. Oh yeah, and it's coming soon to the .NET Framework.

The Rx Framework uses Linq to build asynchronous code declaratively. One of the perks of working at Microsoft is that I've been using it for months now. Now that it has finally been talked about publicly I fully intend to start blogging about it but I'm waiting for the folks responsible, notably Wes Dyer, to take the plunge . In the meantime here's a link to the presentation. Watch it here while it's still on-line.

An F# Solution to Eric Lippert's Challenge

2009-04-16T00:06:00.001-07:00

David Anson recently brought Eric Lippert's challenge to my attention. I can't resist an opportunity to showcase F#'s strengths so I thought I'd throw my hat into the ring with a solution.

I'll briefly summarize the problem for those too lazy to follow the link :-):

Given a sequence of strings, concatenate them in a way similar to natural language. For example the sequence "ABC", "DEF", "G", and "H" should be output as:

{ABC, DEF, G and H}

"ABC" and "DEF" should be output as...

{ABC and DEF}

...and finally an empty sequence should yield the following output:

{}

Of course this problem is simple enough to solve. The real challenge is creating a solution which is declarative and efficient. In order to achieve the desired result we must determine if each item is the first, the last, or is in the center without relying on random access. The typical approach in C# or VB.NET would be to get an enumerator from the sequence, step through it, and create a state machine that keeps track of the last two values. Unfortunately this approach wouldn't scale and would be full of corner cases to handle.

Let's see if we can do better with F#.

open System
open System.Text

let concat_string (list: string seq) =
    let tripleWise = 
        Seq.append list [null]
        |> Seq.scan
            (fun (_, previousPrevious, previous) current ->
                (previousPrevious, previous, current)
            )
            (null, null, null)

    let contents = 
        tripleWise
        |> Seq.map 
            (function
            | _, null, _ -> String.Empty
            | null, curr, null -> curr            
            | null, first, _ -> first
            | _, last, null -> sprintf " and %s" last
            | prev, curr, next -> sprintf ", %s" curr)

    let builder = StringBuilder()
    contents |> Seq.iter (fun item -> (builder.Append(item) |> ignore))
    sprintf "{%s}" (builder.ToString())

// prints "{ABC, DEF, G and H}"
printf "%s" (concat_string ["ABC"; "DEF"; "G"; "H"])
// prints "{ABC and DEF}"
printf "%s" (concat_string ["ABC"; "DEF"])
// prints "{ABC}"
printf "%s" (concat_string ["ABC"])
// prints "{}"
printf "%s" (concat_string [])

Let's take a look at the program step by step.

Type Inference, Whitespace Awareness, and Type Aliases

let concat_string (list: string seq) =

The first line of code contains the only type declaration in the entire program. Not too shabby. For those that don't know "string seq" is a type alias for IEnumerable<string>. Having a type alias for sequences is really nice because sequence processing is so common in both C# and F#. Notice that like Python, F# is also whitespace aware. These three features help F# achieve Python-like terseness without sacrificing performance or type safety.

Structural Types

My solution leverages F#'s native support for structural types, that is types that can be used to group arbitrary values together. The following code creates a sequence of triples, which is a group of three values. Notice that pattern matching is used to introduce descriptive identifiers for each element in the triple.

    let tripleWise = 
        Seq.append list [null]
        |> Seq.scan
            (fun (_, previousPrevious, previous) current ->
                (previousPrevious, previous, current)
            )
            (null, null, null)

The "tripleWise" identifier refers to a sequence of triples containing the previous, the current, and the next item. For example if the input list is defined as "ABC" and "DEF" then tripleWise will be:

(null,null,null), (null,null,"ABC"), (null,"ABC","DEF"), ("ABC","DEF",null)

The scan function works in a way very similar to System.Linq.Enumerable.Aggregate. Here's a C# example that uses Aggregate to sum a sequence of numbers.

new[]{2,4,4,2}.Aggregate((accumulatedValue, current) => accumulatedValue + current, 0)

The difference between scan and Aggregate is that scan returns the intermediary accumulated values as a sequence. Given the example above scan would return a sequence of the following values:

0, 2, 6, 10, 12

An empty triple is used as the initial value and scan is passed a function which shifts each item in the sequence through the triple from the right to left. Each time it returns the resulting triple. Now we have a sequence of triples containing the previous, current, and next values. For each triple we can determine if the middle item is the first item or the last item by checking whether the left or right items are null respectively. Note that by appending null to the end of the original sequence in the first line we can be sure that the rightmost item in the last triple will be null.

Parallelizing the Code

We've successfully avoided state and mutation and we now have a sequence of snapshots of each value and its previous and next values. This is very important. Now we can process each triple in the sequence in any order we like: last to first, first to last, or first and last at the same time.

    let contents = 
        tripleWise
        |> Seq.map 
            (function
            | _, null, _ -> String.Empty
            | null, curr, null -> curr            
            | null, first, _ -> first
            | _, last, null -> sprintf " and %s" last
            | prev, curr, next -> sprintf ", %s" curr)

The code above introduces a function that uses pattern matching to declaratively transform each possible triple into a string. It just doesn't get much more readable than this. This function is applied to each element using map (equivalent to System.Linq.Enumerable.Select) which yields a sequence of strings.

Just for fun let's see how much work it would take to parallelize the code above using Matthew Podwasaki's F# parallel extensions library and the latest CTP of the Parallel Extensions.

    let contents = 
        tripleWise.AsParallel()
        |> PSeq.map 
            (function
            | _, null, _ -> String.Empty
            | null, curr, null -> curr            
            | null, first, _ -> first
            | _, last, null -> sprintf " and %s" last
            | prev, curr, next -> sprintf ", %s" curr)

Notice that all I had to do was add 14 characters! Now the code above should increase in speed at a linear rate with the number of cores on the processor. Just try that with a state machine. :-)

In the next five years its very possible we will see processors with over 50 cores on a desktop. This is one of the reasons I get so frustrated when I see developers unnecessarily using state in their computations. State is the new GOTO. It should have to be justified.

State When it Makes Sense

Notice that at the end the strings are concatenated using a StringBuilder.

    let builder = StringBuilder()
    contents |> Seq.iter (fun item -> (builder.Append(item) |> ignore))
    sprintf "{%s}" (builder.ToString())

This operation is decidedly impure. This demonstrates another wonderful F# feature: the ability to perform stateful operations when it makes sense. It's important to understand there's nothing preventing us from writing C#-style imperative code in F#.

An alternate, pure approach to the problem above would've involved using reduce (equivalent to System.Linq.Enumerable.Aggregate) to concatenate all the strings together using the + operator. Although reduce, like map, can be parallelized it is unlikely that this would improve performance because concatenating strings creates so much extra work. Each time two strings are concatenated a new one must be created and the contents of both strings must be copied to a new memory location. Under the circumstances it makes sense to add a dash of state and use a StringBuilder.

Learn F#

The entire program is 25 lines including whitespace and imports and I'm very comfortable with its trade-offs. I look forward to seeing what the other developers come up with but I'm confident that no one will do better in C#. F# really shines when it comes to computation. Learning it is a must if you consider yourself a sharp Elvis or an Einstein and you make your living with .NET.