Textures can make your application beautiful. Here’s an example from http://subtlepatterns.com, which is full of classy textures:

A nice tile texture

These textures can make great backgrounds, but because the texture is usually smaller than your application (especially tiny textures like  ), you need to repeat (tile) the image vertically and horizontally. Images that “match up” on opposite sides are ideal. All the images on  http://subtlepatterns.com, http://bgrepeat.com and http://www.repeatxy.com are tileable.

So how do you program your application to repeat this image across a surface? In HTML, you can use the css style “background-repeat: repeat” to tile an image across your webpage. In WPF, you can set up the TileBrush properties on an ImageBrush to tile an image across your application. But in Silverlight, Silverlight for Windows Phone, or Metro style XAML applications, you’re out of luck.

Fake it

The easiest solution is to use Photoshop (or cheaper equivalent) to create a huge image that you can set as a background. Just use the pattern tool to tile your texture onto an image that’s bigger than your application’s surface will ever be. The question is: can you guarantee a maximum size? With Metro style XAML applications,  there is no maximum resolution. The other problem is that these massive image files tend to use up a LOT of memory. In my case, it was so much memory that I was likely to fail Microsoft’s Win8 certification.

Make it

There was no way I was going to convert my application into a JavaScript & HTML app, so I set out to create a control that would look just like a WPF tiled brush. The easiest way to do this is to manually arrange a set of images in a control. I’m very familiar with WPF, and I just knew there’d be some weird inconsistencies in the new WinRT APIs that made this harder than it should be, so I decided to spike this in WPF first. I inherited from Canvas, gave it an ImageSource property, and slapped my code into the OnRenderSizeChanged method. It worked perfectly, here’s the code:

    public class TileCanvas : Canvas
    {
        public static readonly DependencyProperty ImageSourceProperty = DependencyProperty.Register("ImageSource", typeof(ImageSource), typeof(TileCanvas), new UIPropertyMetadata(null, OnImageSourceChanged));

        private static void OnImageSourceChanged(DependencyObject o, DependencyPropertyChangedEventArgs args)
        {
            ((TileCanvas)o).Rebuild();
        }

        public ImageSource ImageSource
        {
            get { return (ImageSource)GetValue(ImageSourceProperty); }
            set { SetValue(ImageSourceProperty, value); }
        }

        protected override void OnRenderSizeChanged(SizeChangedInfo sizeInfo)
        {
            base.OnRenderSizeChanged(sizeInfo);
            Rebuild();
        }

        private void Rebuild()
        {
            if(ImageSource == null)
            {
                return;
            }

            var size = RenderSize;
            Children.Clear();
            var width = (int)ImageSource.Width;
            var height = (int)ImageSource.Height;
            for (int x = 0; x < size.Width; x += width)
            {
                for (int y = 0; y < size.Height; y += height)
                {
                    var image = new Image { Source = ImageSource };
                    Canvas.SetLeft(image, x);
                    Canvas.SetTop(image, y);
                    Children.Add(image);
                }
            }
            Clip = new RectangleGeometry(new Rect(size));
        }
    }

I broke a convention

If I was a WPF Purist I would have never extended a Panel class in order to provide a visual control. I’d have built a templated control (Inheriting from Control), and declared the canvas as a template part, and provided a default template that just contained that canvas in my Generic.xaml file. But my whole aim was to keep memory usage low, and in WPF every visual costs you memory, so I decided to pre-optimise. It’s also simpler this was as I only have to show you one file .

Optimising Memory

A tilebrush in WPF on a 1000×800 surface will happily repeat a 4 pixel image for you, thousands of times (200,000 to be exact), without breaking a sweat. However, with my TileCanvas, we’re creating an Image visual every time we want to repeat the tile, so you don’t want an ImageSource that’s too small. You have to find a happy balance between a huge image (which uses up a lot of memory by itself) and a lot of small images (where you don’t keep paying for the image data, but you do pay for the visual tree explosion). I have found that by repeating your pattern, Photoshop style, onto an image that’s a sized with a nice round number like 128×128 pixels is a good compromise. This applies to the WPF spike as well as the following Metro solution.

Make it – Metro Style

If you want to build a Metro Style application, you need to program against the WinRT API. This provides .NET developers with new challenges. Microsoft say that WinRT allows .NET developers to use their existing skills, which is fair. What they don’t mention is that you’re going to need a lot of new knowedge. WinRT is like a parallel universe – a lot of the things you expect to find are there, but they are a bit different, or they’re in a different place. A lot of operations are now done asyncronously, which should be make apps snappier. Truly a “parallel” universe (sorry).

When I tried to port my WPF TileCanvas over to use the WinRT version of XAML controls, I ran into two differences that changed the way I had to do things:

• There’s no longer a RenderSizeChanged method – after a bit of experimenting, I decided on the LayoutUpdated event (although adding images causes this event to be raised, so I had to track the old size in order to avoid stack overflow)
• ImageSources now start with a width and height of 0. It’s not until the ImageOpened event is raised that you can find out the width and height of an image. And you don’t get an ImageOpened event until your image is loaded into the Visual Tree. To get around this chicken-and-egg situation, I add a single image to the canvas, and then once it’s opened and I have the width & height I do a proper layout of the whole screen. I also attach to the ImageFailed event to help you debug, and clean up my event subscriptions once they’ve fired.

Here is my working Metro-style TileCanvas:

    public class TileCanvas : Canvas
    {
        public static readonly DependencyProperty ImageSourceProperty = DependencyProperty.Register("ImageSource", typeof(ImageSource), typeof(TileCanvas), new PropertyMetadata(null, ImageSourceChanged));

        private Size lastActualSize;

        public TileCanvas()
        {
            LayoutUpdated += OnLayoutUpdated;
        }

        public ImageSource ImageSource
        {
            get { return (ImageSource)GetValue(ImageSourceProperty); }
            set { SetValue(ImageSourceProperty, value); }
        }

        private void OnLayoutUpdated(object sender, object o)
        {
            var newSize = new Size(ActualWidth, ActualHeight);
            if (lastActualSize != newSize)
            {
                lastActualSize = newSize;
                Rebuild();
            }
        }

        private static void ImageSourceChanged(DependencyObject o, DependencyPropertyChangedEventArgs args)
        {
            TileCanvas self = (TileCanvas)o;
            var src = self.ImageSource;
            if (src != null)
            {
                var image = new Image { Source = src };
                image.ImageOpened += self.ImageOnImageOpened;
                image.ImageFailed += self.ImageOnImageFailed;

                //add it to the visual tree to kick off ImageOpened
                self.Children.Add(image);
            }
        }

        private void ImageOnImageFailed(object sender, ExceptionRoutedEventArgs exceptionRoutedEventArgs)
        {
            var image = (Image)sender;
            image.ImageOpened -= ImageOnImageOpened;
            image.ImageFailed -= ImageOnImageFailed;
            Children.Add(new TextBlock { Text = exceptionRoutedEventArgs.ErrorMessage, Foreground = new SolidColorBrush(Colors.Red) });
        }

        private void ImageOnImageOpened(object sender, RoutedEventArgs routedEventArgs)
        {
            var image = (Image) sender;
            image.ImageOpened -= ImageOnImageOpened;
            image.ImageFailed -= ImageOnImageFailed;
            Rebuild();
        }

        private void Rebuild()
        {
            var bmp = ImageSource as BitmapSource;
            if (bmp == null)
            {
                return;
            }

            var width = bmp.PixelWidth;
            var height = bmp.PixelHeight;

            if(width == 0 || height == 0)
            {
                return;
            }

            Children.Clear();
            for (int x = 0; x < ActualWidth; x += width)
            {
                for (int y = 0; y < ActualHeight; y += height)
                {
                    var image = new Image { Source = ImageSource };
                    Canvas.SetLeft(image, x);
                    Canvas.SetTop(image, y);
                    Children.Add(image);
                }
            }
            Clip = new RectangleGeometry { Rect = new Rect(0, 0, ActualWidth, ActualHeight) };
        }
    }

Almost perfect?

One thing that I would add in future would be to not throw away the entire canvas of images every time it was built. It would be better to determine just how many images need to be added and removed. At the moment, this isn’t a big issue because metro apps are always fullscreen so they don’t change size unless you snap/rotate them.

Shameless plug

I needed this class because I wanted a background texture in my new Windows 8 game, Chromazone. It’s just been accepted my Microsoft to the store, check it out: http://apps.microsoft.com/webpdp/en-US/app/chromazone/fe3aea27-d44f-43e0-8662-1c45178e4dec

When you create a new ShellTile, you get to specify one or two image URIs (for the front and back). If you use a relative URI, then the shell will look for the image inside your XAP – just like any other image URI in your app. But that means you only get to use images that you ship with your app – how does the music & video app render the album art for each tile? What if you want to take a screenshot of the current game and use that?

One answer is to use or generate images on the internet and use an http-schemed URI, but that approach can cause the tile to unpin when you turn off your phone (I don’t know if that’s a bug or a feature), and you’ll also be relying on an internet connection.

The best option is to save the image to your application’s isolated storage, because you are free to save whatever file you like there (with full control of the content and format), and the image will always be available (so your tile won’t unpin). If you’ve already sourced your image from the internet, then you can just save it to iso storage, but what if you want to generate an image on the fly? Have a look at the mail app, and how it tells you how many emails you’ve got in big letters. If you’ve got no unread email, it adjusts the position of the email icon too. This image is probably built on the fly by a background process.

But what’s a good way of rendering text and images to an image file?

In my opinion, the best way to render custom, dynamic content in a Silverlight app is to leverage the platform: just render some XAML. If you create a 173 by 173 control, you’ve got full control of how those pixels will look. You can even use databinding. You can use the WriteableBitmap. It’s got a constructor that takes in a UIElement (which will immediately render that element into the bitmap) and a SaveJpeg extension method that will write the bitmap to a file.

In my Bus Alert London WP7 app, I used this technique to render custom tile icons with maps in the background:

Bus Alert Tiles

In the process, I discovered a few very important gotchas:

• The UIElement that you render has to be in the application’s visual tree when you call the WriteableBitmap constructor. Otherwise, it may not render at all, may lay out incorrectly, may not have access to the correct StaticResources, or databinding may not occur. You can put it in the visual tree, render it and immediately hide it so that the user never sees it if you like. Unfortunately, this rules out the use of XAML to produce live tiles from background agents.
• The image must be stored under the special directory \Shared\ShellContent in your isolated storage folder or it will not be accessible by the operating system.
• If you don’t close the image’s filestream before creating the live tile you will see a weird bug where the live tile’s image is only visible when you are moving it around the start screen
• If you want transparency, you’ll need to save a PNG. For this you will need to use the .NET image tools library as documented on stackoverflow.

I’ve also put together a sample project that builds a custom live tile out of XAML and avoids all of these gotchas. It’s available on the MSDN code gallery at http://code.msdn.microsoft.com/Building-Dynamic-Live-52bdc195

Some other links that are useful for people who are getting started with WP7 development are:

• Microsoft’s AppHub portal (download the SDK, sign up for the developer program, upload an app)
• 31 days of mango (A set of recipies for the new features in wp7.5 – mango)
• A really great book on windows phone, written by some very handsome authors

I’d always been hoping that C# would introduce something similar to the “typeof” operator that would help you get the name of the current property (or method) without having to use any slow reflection. Before the “//BUILD/” conference, I had given up on C# 5 bringing in anything useful here.

But then I was reading Colin Jack’s summary of the //BUILD/ talk on Future directions for C# and Visual Basic, and was particularly interested by the new Caller Info Attributes feature of C# 5. This feature is not in the CTP of VS11 yet, so I can’t test it, but I expect you’ll be able to write the following RaisePropertyChanged method:

protected void RaisePropertyChanged([CallerMemberName] string member = "")
{
    var copy = PropertyChanged;
    if(copy != null)
    {
        copy(new PropertyChangedEventArgs(this, member));
    }
}

and now when you call this method from a property setter, leaving out the optional parameter:

public string UserName
{
    get
    {
        return _userName;
    }
    set
    {
        _userName=value;
        RaisePropertyChanged();
    }
}

the compiler will fill out the parameter for you, passing “UserName” to the RaisePropertyChanged method.

What I like about this is that the compiler is creating the magic string for you on every compile – so when you rename your property, the string is automatically kept in sync. This is the best of both worlds, we get the performance benefits of a hardcoded string literal, while keeping everything DRY (and therefore hard to inadvertently break).

A quick search will tell you that with Silverlight Local Messaging each message has to be under forty thousand characters, but I haven’t found anything on the internet yet that tells you that you can have a maximum of 255 channels open at a time. So I’m taking responsibility and putting it out there.

Going over the limit will give you a cryptic COM exception, and channels can be “leaked” if one browser process crashes while another is open (for example iexplore.exe and chrome.exe, or just two instances of chrome.exe). Often closing all browsers will clean up the phantom channels, but not always.

Remember that other Silverlight applications might be using some of these channels too, so you should always design your application such that it uses a minimum number of channels.

Power Assert .NET is a .NET port of Groovy’s PowerAssert, which replaces your normal unit test assertions.

Unlike the standard assertions built into nunit, MSTest, and xunit etc; Power Assert gives you a breakdown of all the values within your assertion expression, making it quicker for you to hunt down the cause of the test failure:

System.Exception : IsTrue failed, expression was:
x + 5 == d.Month * y
| | | | | | |
| | | | | | 6
| | | | | 18
| | | | 3
| | | 01/03/2010 00:00:00
| | False
| 16
11


It’s quite a simple little thing, but it’s already saved me lots of debugging time. Give it a go

INotifyPropertyChanged

INotifyPropertyChanged is an interface that most viewmodels need to implement. It’s used implicitly by the Silverlight and WPF data binding system to register a databinding’s interest in the fact that a property has changed, thus keeping all bindings to the same property up to date. When you implement it, you’re responsible for firing a PropertyChangedEvent event every time a property changes, with the name of the property as a parameter to the event.

Sometimes, you might want to programatically watch changes to a property too. Imagine a screen where users can add rows of data that represent orders. If there needs to be a “grand total” on the screen, then one viewmodel (possibly the root VM for the whole screen) will want to subscribe to the PropertyChanged event of each of the order’s Viewmodels. However, there’s a nicer programming model for listening to updates (events etc) than the INotifyPropertyChanged event…

IObservable

IObservable is the core of all RX programming (like IEnumerable is to LINQ). If you want to expose a source of data, you need to expose an IObservable. There’s already a utility method to turn an event into an IObservable. But this Observable will publish IEvents, which isn’t quite what I was after. What I wanted was to create an IObservable of the new values of the viewmodel’s property. Just like LINQ, we can use the “Select” method to acheive this.

Funcy Expressions

An Expression is a C#3 construct that allows you to pass expression trees around. This is a very popular way for you to strongly type property names, because you can reflect over an Expression> to get the name of the Property. You can also Compile() the expression to be able to execute it. My method uses both of these: It needs to know which PropertyChangedEvents it should react to (the Where() clause), and it needs to read the new value out (the Select() clause).

The tests

Here are the unit tests for this extension method. I had to create a dummy view model class to test, named “PropertyChanger”. Note how you can supply “true” to the startWithCurrent parameter to make sure your subscription will instantly start with the current value of the property, as well as receiving new values whenever a PropertyChangedEvent is fired.

Enjoy!

I was recently interviewed for a podcast about my Behaviour Driven Development framework, StoryQ. David Starr from Pluralsight did a great job with the interview – check it out at www.pluralsight-training.net/community/blogs/pluralcast/archive/2010/06/21/pluralcast-18-bdd-in-net-with-storyq.aspx.

David also gave a great presentation on BDD at the 2010 tech ed in New Orleans, and I highly recommend it for anyone wondering how to get started, or even whether they should get started, with BDD: http://www.msteched.com/2010/NorthAmerica/DPR302

Improvements

I think this is a good opportunity to talk about some of the new features in StoryQ. My first post on StoryQ came when we’d just committed it to codeplex, and a lot has changed since then:

• We’ve moved to Mercurial, which means our users can create public forks
• No more ()=> operator. Thanks to FLIT, our fluent interface has evolved to accept plain old delegates, instead of Expression<Action>s.
• Tagging. Any Step can be “tagged”, which makes it easy to find in the output report
• By default, the HTML report generated by StoryQ is JQuery-enriched, which makes it easy to narrow down stories by class hierarchy or tag. I’m particularly proud of this report – it’s a great way to share test results with everybody, especially when published from a continuous integration server.
• A rewritten converter gui, which lets you convert plain text stories into StoryQ code. The new version lets you choose what level of code generation you want (from Story initialisation statement to entire test class), and offers a basic form of intellisense.

Roadmap

• The new fluent interface architecture allows us to support multiple (human) languages, and I’m looking forward to creating fluent interfaces for non-english speakers.
• I think we’ll be able to create a new way of doing BDD in .NET that takes advantage of C# 4.0′s dynamic features
• We still haven’t added xUnit support! Which is lame, because it’s probably going to be really easy…

Please check StoryQ out and let us know if you’ve got any bright ideas for it! And if you’ve never tried BDD, you should definitely look into it. It’s even more fun than TDD!!!

• Blend will render your control as though it’s running with real data, as you design.
• You won’t have to look up and type magic strings when you’re creating your bindings in Blend, Blend will be able to list the possible properties for you. Intellisensational!
• Once compiled, your output dll will have NO baggage associated with your designery frivolities.
• You don’t have to write lots of dummy / mock / stub code
• You don’t even have to finish writing your viewmodel: however you DO have to write all your properties. This is a Good Thing, because it means your bindings will have the right magic strings in them.

How does it work?

First, you need a xaml file that builds up a sample instance of your viewmodel. Then all you have to do is set your Blend-specific DataContext to read from that file.

How do I tell Blend where to get this design data?

I’ve already blogged about the d:DataContext attribute, letting you set up a DataContext but only inside Blend. Another secret of the “d” xml namespace* is the {d:DesignData Source=someDesignDataFile.xaml} markup extension. So all you need in your UserControl or Window’s xaml is (usually on the first element):

d:DataContext=”{d:DesignData Source=someDesignDataFile.xaml}”

Karl’s blog post explains this in a little more depth.

What should be in this design data xaml file?

Just like you usually declare and populate a Window or UserControl, you can actually declare and populate your own view-models as the root element of a xaml file.

I got myself quite confused when I started working with this, because i didn’t realise that the root element of the xaml file should be a declaration of your viewmodel (I was actually placing my viewmodel within a ResourceDictionary >< ):

Here you can see I’ve defined a new ScrumBoardDesignDataDemo.ViewModel.Board, and started assigning some StageNames to it. I’ve used the clr namespace of my viewmodel classes (“ScrumBoardDesignDataDemo.ViewModel”) as the default xml namespace, instead of using what xaml files usually give you: the WPF control namespace. This just cuts down on the amount of typing required.

Normally, if you’re trying to instantiate a class without a public, parameterless constructor in xaml, you’ll get a compiler error. You also won’t be able to set properties that don’t have public setters. This technique allows Blend to do a bit of magic (reflectively creating a doppelganger of your class) that means you can bend the rules a little. More on that in my next post. Let’s just concentrate on getting some sample data into Blend.

By now, if you go into Blend and you try to set up a binding through the binding dialog (you get this by clicking on the peg next to a property, say ItemsSource, and choosing Binding), you’ll get  this helpful dialog:

See how the “Fields” tree is populated? That’s Blend’s version of intellisense, which means you no longer have to rely on knowing what the right property name is and hand-typing it.

Don’t go away! We are only half finished. Blend might be helping you choose property names, but we’re left with two more problems:

• Blend isn’t displaying the sample data on screen.
• This xaml file full of things that were only useful during development is being shipped to our customers inside our DLL.

We can fix this with a simple, but quirky little feature. By setting our design data file’s build action to “DesignData” we will have both of our problems fixed. Blend will realise that it’s ok to try and instantiate the object in the xaml file, and MSBuild will leave that xaml file out of our dll.

Setting DesignData build action for the first time

Normally, if you have a look at the properties of a xaml file in visual studio you’ll see that the Build Action is set to “Page”, or in the case of App.xaml it’s “ApplicationDefinition”. You’d think that it’s just a simple matter of typing the word “DesignData” into that combobox, but if you try this, you’ll get an exception message. Karl’s blog post is about a template he wrote that gets over this problem (by creating the file with all the right properties for you), but I had to figure out how the magic worked. It turns out that it’s relatively easy to work around this, you just have to edit the csproj file manually. I’ll walk you through doing this with visual studio – although you could just as easily use notepad.

Save all your files, right click your WPF project and choose “Unload”. This puts your project into a disabled state where you can’t do anything but hand edit the xml – which is exactly what we want to do.

1. Right click the (now greyed out) project file and choose “Edit”.
2. Locate the design data xaml file:
3. Edit the element to be a “DesignData” element with no children:
4. Save your csproj file, right click it and choose “Reload”

Now if you compile your project, you’ll find that all traces of this design data have been erased. Even better, if you go back to blend, you’ll see that your sample data is now present (you may have to rebuild or even reload the project):

So hopefully you’ve got another tool in your toolbox to help you (or your graphic designer) be effective in Blend. This is my favourite method so far, however there’s a couple of situations where it might be unsuitable. My next post will be all about why, but just so you know, this doesn’t work well when:

• You want custom logic to occur in your viewmodel at design time (ie a Color property on your viewmodel changes whenever another integer property goes below zero)
• You are using DataTemplates with no Key, just a DataType, and are relying on WPF to find the Template by your ViewModel class. (I understand that Silverlight doesn’t support this anyway, so no problem there!)

As always, I’m keen to know if I got anything wrong. There isn’t much information about the whole “d:” namespace on the internet! Also, my third and final post in this series (about the magic that makes this work and how said magic causes the above problems) will come with a demo project.

* This namespace is actually http://schemas.microsoft.com/expression/blend/2008, but Blend always imports this as “d”