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”

• You could see exactly how the finished product would look WHILE you were designing. True WYSIWYG means efficient designers!
• Blend would provide typesafe data binding (I don’t think I called this out, but bringing up the Binding dialog box shows a chooser for correct property names. Bye bye magic strings!)
• Having sample data in your ItemsPresenters/ListBoxes/TreeViews means that blend will let you edit the template in place, providing for an even more useful WYSIWYG experience.

If you haven’t tried it yet, but you are a XAML developer, I really suggest you try developing a screen in Blend when it’s populated with sample data. It’s just so easy. With unit tests on your viewmodel and sample data in Blend, you can finish a screen without ever having to press F5. Okay, maybe once, but you’ll be super happy because everything will work the way it was intended.

But at what cost?

Here are the problems that I’ve found with this approach in my own projects:

I often had to write alot of code, either dummy services to be passed into the viewmodel, or lots and lots of code to simply add things into the derived viewmodel’s collections. This code (often hacked together) got deployed, bloating my DLL file. This sucks extra for Silverlight where the DLL has to be downloaded every time) and, well, looking messy.

Depending on how your viewmodel is coded, you can’t always provide a simple design-time subclass that will populate everything you want. While Dependency Injection is awesome, we aren’t all the architects on our projects, and you might get handed a viewmodel that relies on hard coded dependencies that will do yucky things like call web services, read files or connect to a database. Other times, the ways in which the services are used are so watertight that it’s impossible (or at least it would take hundreds of lines of well thought out code) to make sure you had the right sample data for your designer.

Whenever the viewmodel or the services evolved, the design-time viewmodel needed to keep up. Often (on my project), the person adding features to the viewmodel wasn’t the person who cared about the design time viewmodel. Sometimes they took the effort to make sure the design-time viewmodel compiled, other times they deleted it. Which is fair enough, they didn’t write the code, they don’t see the point of it, all its doing is helping me design the XAML. So I’d end up restoring the file from source control, adding it back into the project, and maintaining it, which was often a lot of effort!

The solution

In the meantime, I’ve been reading around the blogosphere and found a better way to do design data in blend. It doesn’t rely on Dependency Injection (although DI is lovely), it’s easy to maintain and best of all it has NO effect on your compiled DLL. Stay tuned, having gone over (in tedious detail) the why of this new approach, I’m going write a new post about how.