Collection Initializers, Events and Variables

Collection initializers are very neat. Great for regular code, but also quite handy for writing minimal demo code... for example, consider this recent winforms example for displaying a button on a form:

   [STAThread]
  static void Main()
  {
      Application.EnableVisualStyles();
      Application.Run(new Form
      {
          Text = "Hello world",
          Controls =
          {
              new Button
                { Text = "Change title" }
          }
      });
  }

What's wrong with that? Events and variables: collection initializer syntax doesn't allow you to subscribe events, and even if it did, we wouldn't have a convenient reference for each of the items (the form, the button, etc) to talk to.

The good news is that there is a simple fix; it isn't especially magic or clever - I'm simply repeating it here becaues I've seen a couple of people surprised by it. Basically, we can get the collection initializer to assign some variables for us - but we need to be a little sneaky because the language specification deliberately disallows assignment expressions from collection initializers (to avoid ambiguity with member assignments in object initializers). So how? Simple: brackets:

   [STAThread]
  static void Main()
  {
      Application.EnableVisualStyles();
      Button button;
      Form form = new Form
      {
          Text = "Hello world",
          Controls =
          {
              (button = new Button
                { Text = "Change title" })
          }
      };
      button.Click += delegate
      {
          form.Text = "New text";
      };
      Application.Run(form);
  }

Points to note:

• We declare variables for the objects of interest
• We assign the variable in the collection initializer, but surround the assignment in brackets (making the result a non-assignment expression)
• We still get definite assignment checking for free
• We can "capture" the variables in anonymous methods / lambdas as normal
• We can assign multiple variables in the same overall statement

Not huge, but one of those small things that might make things easier! The same approach will work with any collection initializer - winforms is just a commonly understood example.

Above The Surface

Or how I got my grubby paws on some very cool kit ;-p

In December 2008, I somehow landed a fantastic opportunity; to spend some time working in the Microsoft Technology Centre (MTC) lab in Reading, UK - on a prototype project for Microsoft's new baby: Surface. This prototype was timed for BETT 2009, the UK's (and quite possibly the world's) largest education exhibition: with ~28,000 visitors last year, this is a high-profile way for RM, Lightbox and Microsoft to communicate with the key educationalists and decision makers.

What was the project?

The aim was to demonstrate how RM could use Microsoft's product to deliver a solution "of defensible pedagogic value" (direct quote), as part of the next generation of collaborative learning systems. Now I should stress that this was a prototype (not a product) - we were mainly trying to get people thinking about such tools in the education context, so we built an education game for spelling, languages and maths.

The concept was quite simple; you get a few students around the Surface, and they have to work as a team to correctly spell the word (from the cue), assemble the phrase, etc - from the available tiles. The tiles are all around the Surface, and the team most co-operate to do well.

 

(caveat: it makes more sense if you can also see the people interacting with the tiles; for BETT, on overhead video was rigged with a big screen to display the users too).

And everything needs a name, we covered a fair amount of wall space with nominations - but please welcome Finguistics (which was my sole offering, in a rare moment of lucidity - I suggested the team's Surface as the naming prize, but they didn't go for it).

The geek stuff

This is a technology blog, after all ;-p

Note that for many reasons, this isn't intended as a "how to" - purely to whet your appetite.

From a development angle, the most important thing is: how do you write code for it? The good news is that you can use standard development tools such as Visual Studio 2008 and C#, with the regular .NET framework (including WPF) - or if you prefer, you can (I believe) use XNA. This means you have full access to the other .NET framework features, so you aren't struggling for building blocks (we used WPF, Entity Framework, LINQ, ADO.NET Data Services, etc).

Don't try this at home

The SDK for Surface includes a simulator to let you develop and debug easily; in particular, for simulating the different types of (concurrent) contact with the device. This works surprisingly well, although for best results you need a few mice (which feels odd at first, but you soon get used to it). Deployment to the real Surface was a breeze too, but this is where you quickly see differences. Not through any fault of the simulator: simply, things look and feel different when they are on a large horizontal screen than they do on a small(er) vertical screen. There were a few minor behavioural differences too (nothing substantial).

So IMO, Microsoft are quite sensible in restricting the SDK to people with a Surface; applications that work well in the simulator may be unusable in the Surface. There is also a strong temptation on a screen to think in terms of "up". There is no "up" on a horizontal screen that you can walk around, and an app that works well on a monitor is not necessarily going to make best use of Surface's unique features.

So even if you do somehow snag the SDK, don't be fooled that you are now the worlds greatest Surface developer: without a physical device to play with, you're fooling yourself.

Surface highlights

• Shiny... a very cool piece of hardware; the youtube (etc) videos fail to do it justice - you have to play with it to get a feel for how it responds.
• Clever detection : of fingers, "blobs", special markers, or even shapes etc (more complex) - very powerful
• Flexible : some of the sample apps simple throw things out on a scatter-panel, but one of the Microsoft team managed to write a replacement layout engine to provide full physics; this made the whole thing feel much more "real"
• Styled : by drawing on the WPF goodness (not to mention Dave "Glossy" Crawford's input, and help from Infusion), it was possible to get a pretty impressive app working (with iterative GUI progression) very quickly
• (more notes on the unique advantages of Surface can be found on the Microsoft site, or RM's version here)

Other learning points

I come away with more than just memories of Surface:

• In the past I've mainly been involved with LINQ-to-SQL (due to timing, complexity, etc). This was my first production use of Entity Framework, and it worked OK. I'm still a little wary of how much might change between now and vNext of EF, but the tool itself worked fine and got the job done, which is what is important to me.
• I've had little production use of WPF, so the whole xaml/designer/developer workflow was new to me; and again, it worked. We had some first-rate designers working in Blend, throwing us xaml for Visual Studio; it all worked very smoothly.
• It was also simply a really enjoyable time working with some Microsoft / external experts - very informative and productive

Anyway - it was a great gig. If you happen to be near BETT over the next few days, check it out (there are 2 devices on-site). A big thanks to everyone involved, especially Microsoft who make great hosts, and my boss (for letting me disappear).