There has been lots of talk in the Silverlight community about what is the best way to implement the INotifyPropertyChanged interface. During Christmas I blogged about how you can use dynamic proxies to get INPC implemented automatically. Since then both Einar Ingebrigtsen and Justin Angel have blogged about an interesting approach to INPC using MSIL weaving. I really recommend checking out Justin’s post, as he covers some of the pros and cons of different INPC implementations, as well as purposing an elegant solution using post-build MSIL weaving.

One of the things Justin mentions as a drawback of the dynamic proxy approach is that you cannot simply new up your ViewModel directly and get change notification automatically. You have to explicitly create the ViewModel instance through a proxy creator. Einar also mentioned that he had a hard time finding a way to integrate the proxy creator with an IoC container.

When I write code I’m always careful about where I instantiate my objects, and lately all projects I’ve worked on have used some sort of IoC container. Having an IoC container gives you a single place in your code base to create- and register objects. If the dynamic proxy implementation of automatic INPC is going to be useful it has to be as simple requesting a ViewModel instance from the IoC container. In this blog post I’m going to show how you can combine automatic INPC using dynamic proxy with the Ninject IoC container.

If you have read my blog you may have noticed I got a soft spot for Ninject. I mean, who cannot love a framework whose name, graphic profile and code examples are all about Ninjas? When I first set out to integrate my automatic INPC interceptor with Ninject I wasn’t quite sure where to start. Ninject 1.0 had AOP concepts built in, but in 2.0 (which are under development) this has been moved out of the core and into a separate interception extension module. This is part of the new modular design of Ninject 2.0. Features you may not need all the time are moved out to separate extensions, leaving the core really small and simple (~90kb).

My first plan was to use the Ninject interception extension. The extension uses the LinFu framework for dynamic proxies, and I wasn’t sure how to get my Castle Dynamic Proxy based implementation to work directly. I later got contacted by Ian Davis, the owner of the interception-extension project. He asked if I needed some help getting automatic INPC working with Ninject. After some back-and-forth on Twitter Ian had an implementation of automatic INPC added to the Ninject.Extension.Interception project. The code is commited to the trunk, and is available on github if you want to check it out. Ian’s implementation is probably worth a blog post on its own.

A comment from Miguel Madero pointed me in the right direction to get my interceptor working with Ninject. Miguel had integrated it himself by implementing the interceptor as a Ninject Provider. Ninject lets you register types against providers which let you write code that creates the instance when the type is requested from the container. The interface is really simple, having one Create-method. In this method you have to create the instance being requested.

The implementation for the automatic INPC provider is fairly simply. It finds the largest constructor of the ViewModel being requested, creates instances of all constructor parameters, before calling the dynamic proxy creator I implemented in my previous two blog posts.

In Ninject all configuration is done through code using an internal DSL. You configure the container by creating module classes specifying the bindings of the different types you want to be able to create. In this example I have a simple logging service (to demonstrate constructor injection combined with automatic INPC) as well as a simple ViewModel. The ViewModel is bound to the provider, which will call the proxy creator when the ViewModel is requested.

This unit tests shows how to request an instance of the ViewModel from the container. When the Name-property is set the ViewModel will log the action to the fake logger which was injected into the ViewModel constructor.

Having to register every single ViewModel against the provider is tedious and repetitive. Miguel Madero also suggested that you can override the GetBinding method of the Ninject StandardKernel and use convention over configuration. By overriding the GetBinding method we can check if the type being requested is a ViewModel, and if it is we can create a binding on the fly tying the ViewModel type against the automatic INPC provider.

The implementation of the AutoNotifyKernel is really simple. It checks if the name of the type being requested contains “ViewModel” and implements the IAutoNotifyPropertyChanged interface. If it does we create a binding for the type.

Having a convention based approach in place we do not have to manually register every single ViewModel.

Some of this code might seem complicated, but I really wanted to cover the details of how to integrate it with Ninject, as similar approaches probably work for other containers. Once you got a framework for automatic INPC in place the usage becomes really simple. In the example application for automatic INPC the code needed to implement the ViewModel, configure the container and tie the ViewModel to the View looks something like this:

It’s funny how such a simple interface can trigger so many different implementations. I hope you found my blog post on combining a dynamic proxy approach with an IoC container useful. It will be interesting to see which approach emerges as the most used, and which frameworks that will provide implementations of the different techniques.

Yesterday I published a post showing how we can use AOP and Castle Dynamic Proxy to get automatic change notification for ViewModels by intercepting property setters. One of the comments I got was from Krzysztof Koźmic who suggested that I should use ProxyGenerationHook to narrow down the scope of the proxy.

By implementing the IProxyGenerationHook we get to choose which methods to intercept. In my original implementation this logic was handled by the interceptor itself. The interceptor would check that the method being intercepted was indeed a property setter, that it was not of type ICommand, and that it was not marked for exclusion. By implementing a ProxyGenerationHook I could move all this code into a separate class, making my interceptor much cleaner. The ShouldInterceptMethod implementation of the ProxyGenerationHook now looks like this:

I also got a good question from Anders Knutsen asking how to handle change notification for properties depending on another property. A typical scenario for a ViewModel might be to have a ZipCode-property with both setter and getter, and City and State properties with only getters. When you set the ZipCode you raise change notification for ZipCode, City and State. In the City- and State-getter you look up the values based on the ZipCode. This means that you must be able to raise multiple change notifications in a single setter.

I solved this by adding a new NotifyChangesFor-attribute that you can decorate properties with to trigger change notification for additional dependent properties.

I have also updated the tests to document this behavior.

The sample code has been updated with the new ProxyGenerationHook and the new NotifyChangesFor-attribute.

As a WPF or Silverlight developer chances are you have implemented the INotifyPropertyChanged-interface more than once. The interface is simple enough, consisting of a single PropertyChanged-event. The data binding infrastructure in WPF and Silverlight will look for this interface and subscribe to the PropertyChanged-event. As a developer you have to write code in your property setters to raise the event whenever some property is changed. This is boring and repetitive code to write, that often contains magic strings (property names) and can really clutter your ViewModels. Finding an elegant implementation of the INotifyPropertyChanged-interface has become one of the holy-grails of WPF and Silverlight developers.

An idea I had some time back where to use AOP-techniques and dynamic proxies to get INotifyPropertyChanged implemented automatically. With the recent beta release of Castle Dynamic Proxy 2.2 with official support for Silverlight, combined with Christmas holiday, I figured this would be a good time to take a stab at this problem.

After doing some research I found a couple implementations of INPC using AOP. In August 2008 Gian Mari Ricci published two blog posts about automatic implementation of INPC. The first one he used Reflection.Emit and dynamic code generation, the second was a much simpler implementation using Castle Dynamic Proxy.

In June Ray Houston published an interesting post on how they had implemented auto wiring of INPC as part of the Fluent Silverlight framework. Fluent Silverlight is an open source framework by Ray Houston and Gabriel Schenker that provides a fluent interface for configuring data binding in a strongly typed manner using C#. Their implementation of automatic wiring of INPC is based on Castle Dynamic Proxy, and is really simple and elegant. Instead of trying to reinvent the wheel I decided to re-implement the automatic INPC parts from Fluent Silverlight, and walk you through the code in this blog post. I do not want to take credit for Ray and Gabriel’s work, and must emphasize that this should be considered a walkthrough of their implementation.

The first part of the implementation is a new IAutoNotifyPropertyChanged interface that extends the INotifyPropertyChanged interface with one new method. This interface will be implemented for any ViewModel where we want automatic change notification. The interface serves as both a marker interface for the interceptor, as well as providing a method that the interceptor can call to raise the PropertyChanged-event.

To create a new ViewModel we simply implement the interface, and make any property we want change notification for as virtual. The properties need to be virtual so that the generated proxy class can override the property setter method and call the interceptor. The implementation of the interface can off course be moved down to a base class, but I have included it in this sample to make it clear what is required by the ViewModel for automatic change notification.

With a ViewModel implementing the IAutoNotifyPropertyChanged-interface in place we can now write an interceptor that will add change notification for the properties on the ViewModel. Interceptors are a concept from AOP that enables us to intercept method calls and add new behavior dynamically. This is helpful as we can move cross-cutting concerns out of the business logic. Typical use cases for AOP often include authentication, logging, exception handling and other technical concerns. By having these concerns implemented outside our class we can keep our business logic nice and clean. In our case we are going to apply some of these techniques to keep the ViewModel free from change notification code cluttering the class.

The interceptor is defined as a generic class that intercepts classes implementing the IAutoNotifyPropertyChanged-interface. The interceptor implements IInterceptor-interface which defines a method that will be called for every method invocation, providing us a hook to add addition behavior to the method call. Our interceptor will start by letting the original method call (the property setter) run before checking if we should raise change notification. If the property being set isn’t marked for exclusion we call the OnPropertyChanged method on the IAutoNotifyPropertyChanged-interface, passing in the property name as the parameter.

The code to determine if we should raise change notification starts by checking if the method being invoked is in fact a property setter. This is done by checking the IsSpecialName-property on the MethodInfo object, as well as checking that the name of the method starts with “set_“. The second step is to check if the property is marked with a DoNotNotifyChanges-attribute. This is a marker attribute that can be applied on properties to prevent automatic change notification. The third step is to check if the property being set is of type ICommand. A common pattern when creating ViewModels is to expose operations as Commands hanging of the ViewModel as properties. You do not need change notification for commands, so they are ignored by the interceptor.

Now that we have our change notification interceptor the only thing missing is a way to create the proxy object. To do this we create a new proxy creator. The proxy creator has a generic method that creates proxied instances of any class implementing the IAutoNotifyPropertyChanged-interface.

This diagram illustrates how the View calls the property setter on the proxied ViewModel. The property setter gets intercepted, and the interceptor lets the original setter execute before raising the PropertyChanged-event.

Now that we got the proxy creator it is really straight forward to create an instance of our ViewModel that will have automatic change-notification. I have included the tests documenting the behavior of the automatic change notification interceptor. The tests documents change notification for simple properties, as well as exclusion of commands and properties marked with the DoNotNotifyChanges-attribute.

Summary

Using dynamic proxies for automatic change notification is a good way to keep your ViewModels nice and tidy as well as not having to hand-write tedious, repetitive change notification code. In my next blog post I will explore how we can integrate the change-notification interceptor with the Ninject IoC-container. By integrating the interceptor with an IoC-container we can have any ViewModel retrieved from the container support automatic change notification.

For more information about Castle Dynamic Proxy I would recommend Krzysztof Koźmic excellent 15-part tutorial.

The example code for this blog post requires Silverlight 3, and includes the latest beta of Castle Dynamic Proxy 2.2. The code is experimental, and not intended for production use.

This blog post is not about software development. Or maybe it is. I will leave that up for you to decide.

On the flight home from Frankfurt last night I was reading D2, a magazine that comes out every Friday as part of the Norwegian newspaper Dagens Næringsliv. I haven’t read D2 before, but I was surprised by the quality of design and print as well as the great feature stories. Some of the quotes in the stories caught my attention and I want to share them with you.

The first feature story was about the perfume industry, and the increasing popularity of smaller, more exclusive and personalized niche perfumes. I’m not at all interested in perfume and cosmetics, but it was still fascinating to read about the movers and shakers of that industry. I want to share a quote from Francis Kurkdjian, one of the most famous perfumers in the world:

The problem with this industry is that there are too many people involved in the process. There are too much thinking and rationalizing, and too little passion.

- Francis Kurkdjian, famous perfumers.

The next quote is by Sissel Tolaas, taken from the same story:

Excellent perfumers have been forced to make a commercial soup. It came a point where they said; “this is boring, we can do better”.

- Sissel Tolaas, artist and perfumer

The next story was about Mario Batali; perhaps USA’s most famous chef. Mario owns 15 restaurants, and is in charge of 1800 employees. He has also written several books and appeared on multiple TV shows. Mario is a fascinating guy, with a great passion for his craft. The following quote is taken from his answer about whether his colleague education and specialization in Spanish classical theater is of any relevance to his profession:

All knowledge about the world around you makes you better suited to complete the task at hand. I could teach a fucking chimpanzee the manual work involved. But I cannot teach him to love it, day after day, thousand days in a row.

- Mario Baltali, most famous chef in the USA

The third story was about the Norwegian architects Geir Brendeland and Olav Kristoffersen, who became famous for creating the tallest building in Norway built using solid wood. They now run their own architecture office where wood as a building material is one of their specializations.

We are extremely interested in the field of architecture. Our goal was not to build up a large office; the goal was to learn the craft and create projects. To build.

- Geir Brendeland, architect

The distance between architects and craftsmen has gotten way too big.

- Olav Kristoffersen, architect

Last month I was lucky enough to attend and speak at the Smidig2009 (Agile 2009) conference in Oslo. This was my first time attending the conference, and I’m really impressed with the content, speakers, organizers and attendees. The format of the conference was four lightning talks per hour in three simultaneous tracks before lunch, and open spaces after lunch. The formatted worked out really well – and I got to see several inspiring and educational talks, as well as taking part in some interesting discussions in open spaces.

My talk was about UX prototyping as a natural part of an agile software project. This is something I have written about both on this blog, as well as the Capgemini technology blog. The talk covered UX prototyping as a technique and the benefits it gives you in an agile project, as well as showing two short demos of mockups in Balsamiq, and interactive prototypes in SketchFlow.

Thanks to Tandberg video recordings of the entire conference was made available almost instantly. The image blow takes you directly to my presentation. I have also uploaded the slide deck to Slide Share and embedded it into this post.

On Wednesday 21 October I will be visiting the Kristiansand chapter of NNUG to give two Silverlight presentations. The first will be about the MVVM design pattern, and the second on building business focused applications using .NET RIA Services. After the NNUG meeting there will be a geekbeer get-together at Patrick’s. Details and registration for the meeting is up on the NNUG site.

On Thursday and Friday (22-23 October) I will be attending the Smidig 2009 (Agile 2009) conference in Oslo. This will be my first time attending the Smidig conference, and I’m really looking forward to it. The format of the conference is 4 lightning talks pr hour before lunch, and open spaces after lunch. Judging by the number of submitted talks I think it is going to be a really interesting conference, and I hope to learn allot about how to run successful agile software projects. I’m also a big fan of open spaces and the interaction between conference attendees it enables.

Since I was planning to attend the conference I made a last minute decision to submit a talk on UX prototyping in agile projects using Balsamiq and SketchFlow. The talk got accepted, which means I will not only be attending – I will also be speaking at the conference!

I’m looking forward to doing some presentations again, and I hope to see you in Kristiansand or Oslo next week!

(Time-lapse video taken by @petesamuel from a presentation I gave earlier this year) 

For me agile software projects is all about maximizing the customers’ value of the software being built by encouraging and incorporating feedback, new features and change requests as quickly and cheaply as possible. To achieve agility we adopt agile project process like Scrum, which helps us manage and prioritize the features of the software we are building into short iterations. To build a flexible code base that enables us to quickly add, remove or change features throughout the project we adopt agile development practices like Test Driven Development. We try to follow good design principles like SOLID, and we build and integrate our code frequently using Continuous Integration. But what can we do to become more agile in the way we build the User Experience (screen layout, navigation structure, colors and graphic design, imagery, error messages, texts and labels) of our application?

On most of the software projects I have worked on the User Experience have been left up to the developers to decide. Towards the end of the iteration we bring in the customer for a demonstration of what we have built, implemented as running HTML, Windows Forms or perhaps XAML code. In many cases the customer immediately starts focuses on the tiny (perhaps unimportant) details of the UX. Like, “the title should be bigger and bluer”, or “the save button should be 4 pixels to the left”. One of the reasons for this reaction might be that by demonstrating a complete implementation of the UX straight away the application looks too complete, and the customer might feel that it is too late in the project to make substantial changes to the UX of the software. However, if this does not happen and we do get good feedback, suggesting that we need to rethink the UX of the application, the reaction from the development team might be hesitation. If you have put lots of effort into building the UX of the application you don’t want to throw it away. And in contrast the business logic of the application we do not have the same refactoring and testing support for the UX of our application as we do for the other parts of the system, making it harder to make big changes with little effort.

One way to work efficiently with UX in an agile software team is to create low-fidelity prototypes. These prototypes can be created using pen and paper, or tools like Visio, PowerPoint, Balsamiq or SketchFlow. Low-fidelity prototypes feel less finished, but are at the same time concrete enough for the customer to really “get” the concepts being prototyped. Using low-fidelity prototypes the customer is more likely to give constructive feedback about the important aspects of the UX, like how the screen layout and navigation should work, which fields are needed, or how we are going to display error messages, than if they were presented with a high-fidelity prototype or near complete version of the software.

The developers are going to be less attached to a low-fidelity prototype, as the amount of effort put into it is far less compared to a real implementation done in code. Using prototyping the development team and the customer can do multiple iterations trying out different ideas and concepts for the UX, hopefully coming up with a great solution in the end. After all, good design is all about exploring multiple ideas, before narrowing it down to the right design for the problem. Good design is not about picking the first solution that pops into a developers mind.

I think UX prototyping fits perfectly with agile software development, and should be a natural tool for any agile team building software that interacts directly with end-users. My next blog post is going to be more concrete, giving an introduction to two great prototyping tools: Balsamiq and Microsoft SketchFlow.

The videos from NDC2009 are now published on the conference agenda site. The site isn’t the easiest to navigate, so Mark Nijhof went through the effort of creating a simple list of all the videos grouped by speaker. There is tons of great content available and the videos should be a great way to do some (relaxed) learning in the summer heat.

There is a problem with some of the links, and the link to the video of my second talk on .NET RIA Services is broken. I’ll make a new post when that video becomes available.

Click to view my Model-View-ViewModel presentation from NDC2009.