Jonas Follesø's World of Software

Building testable WP7 apps using Microsoft.Practices.Phone.Adapters

2012-04-28T00:00:00Z

I’m a big believer in Test Driven Development as an effective practice that helps me write high quality, maintainable code. TDD is a practice I not only apply on larger enterprise applications, but something I try to do even on smaller mobile apps. In the day of the Apple App Store or Microsoft Marketplace you are relying on Apple or Microsoft to approve your application before it’s made available to your users. The process typically takes around a week – meaning it can potentially take a week before you fix a bug and the update is made available to the users. Introducing a bug in your mobile app can greatly hurt your rating in the Marketplace/App Store. Given the fact that you cannot simply upload a quick fix to the app stores, like you can on a web application, having solid testing for mobile applications is even more important than for other types of applications.

With this in mind I was thrilled to see that Microsoft Pattern & Practices had taken this to hearth in their latest guidance for building Windows Phone 7 applications. The latest guide includes three major topics:

I have previously written several blog posts and given presentations on how the MVVM Pattern can help you separate the state and behavior of a piece of UI from the actual View-code. By moving state and behavior into a View Model-class with no UI dependencies, you can easily unit test the View Model in separation. If you would like to learn more about the MVVM-pattern I would strongly recommend my presentation from NDC 2009, or the MVVM-chapter from the P&P WP7 Guidelines. To ensure that the View Model classes can be tested independently it is important that they do not have any external dependencies that are hard to test. Whenever a View Model depends on some external resource, such as a web service, we introduce an interface for that dependency, and enable some form of Dependency Injection on the View Model so that we can replace the dependency with a stub or a mock during test.

When working against the Windows Phone 7 APIs you will quickly realize that they are not very test-friendly. The API consists of several static or sealed classes that provide access to core phone-functionality such as Location Services, Compass, Camera, Gyroscope or other sensors. Since the classes are sealed, and do not implement an interface, there is no simple way to test code accessing these classes directly. The solution in such cases is typically to define your own interface mimicking the underlying API, and then implement an Adapter class delegating through to the underlying API.

To demonstrate this principle I have created a simple application that displays your current location and compass heading. Such an application would need to use two classes that are hard to test; the GeoCoordinateWatcher-class and the Compass-class. A simple design, using the View Model pattern, would look something like this:

The problem with this design is how the TrackingViewModel-class is using the Compass-class and GeoCoordinateWatcher-class directly. It would be impossible to unit test the View Model, both because the Compass-sensor is not available in the simulator, but also just because of the fact that getting a location/compass reading takes time, and would make the tests slow and unreliable. Instead we are going to modify the design, and use the abstractions introduced by the Patterns & Practices team. We change our TrackingViewModel-class to depend on ICompass and IGeoCoordinateWatcher. At test-time we pass in mock-implementations of these two classes to enable testability, while at run-time we use the adapter classes GeoCordinateWatcherAdapter and CompassAdapter.

With this small change we can now write unit tests for the TrackingViewModel-class. Here is an example of some of the tests I have written for the View Model.

Many people assume that you have to use an IoC-container to use Dependency Injection. That is not the case. My personal preference is to not introduce an IoC-container until it is necessary, and instead use overloaded constructors. The TrackingViewModel-class has two constructors, one that accepts the ICompass and IGeoCoordinateWatcher interfaces as parameters, and one default constructor that calls the parameterized constructor passing in the adapter classes as default. This enables testability, yet at the same time keeps the architecture of the application simple.

In this example I only use two of the wrapped classes provided by the Microsoft.Practices.Phone.Adapters project. In addition the project contains adapters for the following classes in the Windows Phone 7.1 SDK:

Wrapper	Implements	Abstracted Class
AccelerometerAdapter	IAccelerometer	Accelerometer
ApplicationFrameNavigationService	INavigationService	PhoneApplicationFrame
CameraCaptureTaskAdapter	ICameraCaptureTask	CameraCaptureTask
CompassAdapter	ICompass	Compass
GeoCordinateWatcherAdapter	GeoCoordinateWatcher, IGeoCoordinateWatcher	GeoCoordinateWatcher
GyroscopeAdapter	IGyroscope	Gyroscope
IsolatedStorageFacade	IIsolatedStorageFacade	IsolatedStorageFileAdapter, IsolatedStorageFileStreamAdapter
IsolatedStorageFileAdapter	IIsolatedStorageFile	IsolatedStorageFile
IsolatedStorageFileStreamAdapter	IsolatedStorageFileStream, IIsolatedStorageFileStream	IsolatedStorageFileStream
MessageBoxAdapter	IMessageBox	MessageBox
MotionAdapter	IMotion	Motion
AccelerometerSensorReading	ISensorReading	AccelerometerReading
CompassSensorReading	ISensorReading	CompassReading
GyroscopeSensorReading	ISensorReading	GyroscopeReading
MotionSensorReading	ISensorReading	MotionReading
PhotoResultTaskEventArgs	TaskEventArgs	PhotoResult

The Microsoft.Practices.Phone.Adapters project can be added as a NuGet-package. The package adds the interfaces/adapter files to your project, and you can choose to delete the once you don’t need (it is not a pre-compiled package). If you download the example project from the MSDN site you also get a set of pre-written mock-classes you can use in your Unit Test project to mock the different interfaces.

If you want to learn more about making your WP7 applications testable I would strongly encourage you to read the full guide on this on MSDN. As I mentioned in the introduction, testability is just one aspect of the Patterns & Practices Guide for WP7, and I will be covering other areas in a later blog post.

The example application for this blog post is available at https://github.com/follesoe/TestableGeoTrackerDemo.

QR code scanning on Windows Phone 7.5 using ZXlib

2011-07-22T00:00:00Z

One of the big new features of Windows Phone 7.5 (code named Mango) is direct camera access. Having access to the camera stream enables several new scenarios, such as in-app QR and barcode scanning, augmented reality applications or custom looking photo camera UI. There are some good resources on how to use the new APIs to access the camera in Mango, but I haven’t found any complete examples of how to implement a QR code scanner, which is what I am going to do in this blog post.

Mango adds two API to access the camera. You can either use the webcam APIs introduced in Silverlight 4, or you can use the new PhotoCamera class introduced in Mango. I’m not going to cover all the details of the two APIs; instead I will focus on how to solve the scenario of implementing a QR scanner. If you want to learn more about the Silverlight 4 APIs for accessing the camera I would highly recommend Rene Schulte’s detailed blog post. For information on the PhotoCamera API I would recommend this MSDN article showing how to build a camera application for Windows Phone.

When starting on the task of building a QR scanner one of the first things I did was to research different open source libraries to do the image recognition. Thankfully there are multiple libraries available, but the ZXing library from Google seems to be one of the most popular. The ZXing library is ported to multiple programming libraries, and supports a wide variety of 1D/2D codes (QR, Code128, Code39, EAN and many more). There is a C# port of the library, which has later been ported to Silverlight and Windows Phone 7. So the actual task of writing the QR scanner is to integrate the ZXing library with the Mango camera API.

The XAML code for the scanner consists of 4 main components. A Rectangle is used as to display the viewfinder video stream. The way you hook the camera up to the rectangle is through a VideoBrush. A VidoBrush let you paint any XAML element using a video source of some kind. To control orientation (depending on landscape or portrait) a CompositeTransform is added to the VideoBrush. This transform lets us programmatically set the rotation of the video brush to match the rotation of the camera. The final component is a ListBox used to display the text decoded from the QR codes.

In the code behind file we need to add some initialization code. In the constructor we instantiate an ObservableCollection which will be the ItemsSource of the ListBox. Whenever a QR code is successfully scanned the result is added the collection, which in turn will update items in the ListBox. We also create a DispatcherTimer that will execute every 250 millisecond. On each tick we will try to decode the image for any QR codes. In the OnNavgiatedTo method we instantiate the PhotoCamera class and hook the Initialized event for the camera. We also set the source of the VideoBruch created in XAML to the photo camera. This will start drawing whatever the camera sees on the Rectangle. We also hook the ShutterKeyHalfPressed event to focus.

When the photo camera is initialized we run some more setup code. The code needs to access the width and height of the preview resolution, so it cannot run before the camera is initialized. Next we create an instance of PhotoCameraLumianceSource. This is a custom class extending the LumianceSource class from the ZXing library. This class is responsible for extracting luminance data from any image. Since you could have different image formats, ZXing has mad the framework extensible by providing a base class you can extend with the code needed to get luminance data from the specific image format you are working with. Next we create an instance of the QRCodeReader. This is the class responsible for decoding the image to scan for a QR code. The ZXing library comes with multiple readers, so if you want to read Code128 bar codes you simply create a Code128Reader instead. Finally we set the rotation of the preview VideoBrush and start the timer.

Every time the timer ticks the ScanPreviewBuffer is executed. This method is responsible for getting the image data from the photo camera and tries to decode it. The photo camera offers multiple methods to get images. You can either capture a full resolution image, or you can get the preview buffer. Capturing a full resolution image would be too slow for a computer vision application, but thankfully we got methods to access the preview buffer. You can get the preview buffer as either ARGB format or YCbCr format. The camera sensor is internally using YCbCr, so getting it as Argb format would require conversion. If you only care about luminance (the Y in YCbCr) there is a convenient method giving you the Y component of the YCbCr format. This is perfect as this is exactly what we need to pass to the ZXing library. Rene Schutle got a good blog post going into the details of Argb vs YCbCr.

The GetPreviewBufferY method takes a byte array as its parameter and will populate this byte array with the luminance data from the preview buffer. We pass in the PreviewBufferY property from our luminance source class (which will be explained later). Once we have captured the luminance data we create a HybridBinarizer and a BinaryBitmap. They are part of the ZXing library. I haven’t worked enough with ZXing yet to fully understand the architecture, but these classes are steps the luminance data pass through before being passed to the decode method of the QRCodeReader. If the decode is successful the decoded text is added to the ObservableCollection, which in turn will update the ListBox. The QRCodeReader decode method will throw an exception if it is not able to decode the image, so we need to wrap the code in a try-catch block.

The PhotoCameraLumianceSoure implements the LumianceSource base class used by the ZXing library. The class is responsible for exposing the luminance data for the image format you are working with. Conveniently the PhotoCamera class gives us the luminance data directly, so implementing the class does not take much code. There are basically one property and one method you need to implement. The Matrix property simply returns the luminance data for the complete image. The getRow method returns the luminance data for a given row. Both the property and the method simply read the PreviewBufferY byte array which is filled every time the timer calls the GetPreviewBufferY method.

So how does this work in practice? Below is a YouTube video demonstrating the QR scanner. As you can see it’s fairly quick and accurate (well, at least on bright images of my computer screen). I have not yet tested it in the wild, and the ZXing library offers many customizations to fine tune how you want the scanner to behave, but at least this demonstrates how you can combine ZXing and the Mango PhotoCamera API to implement a QR scanner in less than 150 lines of user code!

The complete QR code scanner example code is available on github.

Cross platform .NET mobile apps talk at NDC 2011

2011-07-22T00:00:00Z

Earlier this summer I gave a presentation at NDC 2011 about writing cross platform mobile applications using C# and .NET. At the time of the presentation the future of MonoTouch and Mono for Android was uncertain, but with the recent news of Xamarin gaining ownership of the products, the future of C# on iOS and Android looks brighter than ever.

The presentation covers 8 concrete strategies for designing applications for maximum code re-use across all three platforms, as well as techniques to make development more productive and hassle-free. The strategies/techniques covered in the presentation are:

Portable Class Libraries
Linked Files
The "Project Linker" tool
VSMonoTouch to open MonoTouch projects in Visual Studio
Pre-processor directives
Abstract common functionality
Leverage MVVM on all platforms
Use pre-built abstractions such as MonoMobile.Extensions

All the presentations from NDC 2011 are available in a torrent file, but to make the presentation more discoverable and accessible I have uploaded it to my Vimeo account. The slides are available on SlideShare.

Cross platform .NET mobile apps in practice from Jonas Follesø on Vimeo.

Cross platform mobile apps using .NET

View more presentations from Jonas Follesø.

WP7, iOS & Android: Is .NET the platform to rule them all?

2011-03-20T00:00:00Z

The following blog post is an article originally published in the most current issue of "The Developer", a magazine distributed to Norwegian developers. The article discusses the exciting possibility to use C# and .NET across the three major smart phone platforms WP7, iOS and Android. Since the magazine is only distributed in Norway I decided to post it on my blog as well. You can either read it here, or download a PDF version of the article as presented in the magazine.

If you ask me 2010 was the year of the mobile app. Everyone was talking about them, from consumers around the lunch table, to CEOs in the boardrooms. It was like 1999 all over again; only this time it was not about building websites, but to have some kind of offering in one of the major mobile app stores. According to the analysts at IDG the huge interest in mobile apps is not just a fad. They expect download numbers to grow from 10.9 billion in 2010 to 76.9 billion in 2014. As a result app revenue will surpass $35 billion the same year. In short, mobile is going to play an important role for software developers over the next few years.

As a .NET developer you are faced with some tough decisions. Which platform do you bet on? How do you get your skills up-to-date quickly enough? Do you suck it up and learn CocoaTouch and Objective-C to target the popular Apple iOS devices? Should you learn Java and go for the Android? Or should you skip two of the most popular mobile platforms and stick to C# and develop for the newly released Windows Phone 7?

Businesses face some of the same decisions, as they need to decide where to focus their resources and efforts. Should they target all the major platforms, or focus only on iOS devices? What will be the cost of maintaining these applications over time? A quick search for “DnB NOR” (Norway’s largest financial services group) in the iTunes App Store reveals that they already have five apps available. This is for iOS devices alone. In addition, two of the applications are also available in Android Market. With seven apps published already one can start to imagine what the cost and technical challenges of maintaining them over time will be.

When choosing which technology to use for implementing mobile apps, the popular choices have traditionally been either web-based apps written in HTML, CSS & JavaScript, or alternatively fully native apps tailored to a specific platform. Both alternatives have their pros and cons. Web-based applications might be quicker to build and easier to make cross-platform, but the drawback is that you do not have full access to the phone specific APIs. And it is harder to provide the same high fidelity user experience as a native app offers. With native apps, the challenge might be a steep learning curve and having to re-implement the same app across different platforms.

With the release of MonoTouch at the end of 2009 Novell introduced a new way to build apps for iOS devices. Against all odds the programmers at Novell had found a way to bring Mono, the open source implementation of .NET, to the iPhone without requiring unlocking or jail-breaking the device. The MonoTouch framework enables developers to build native iOS apps using the C# programming language using many of the core .NET libraries. MonoTouch is designed to conform to the strict requirements set by Apple for App Store eligibility. MonoTouch allows .NET developers to take advantage of their existing skills, reuse existing code and libraries, making the transition to the iOS platform easier.

Instead of porting Windows Forms or WPF to the iPhone, MonoTouch provides a thin .NET layer on top of the native CocoaTouch APIs giving your applications a fully native look and feel, making them indistinguishable from the traditional iPhone applications. And where it makes sense, MonoTouch will provide standard .NET APIs instead of the CocoaTouch counterparts. For example, you use standard ADO.NET to talk to SQLite databases on the device, and XML can be processed using the familiar System.Xml.Linq API. MonoTouch apps are developed using the MonoDevelop IDE, an experience very similar to that of Visual Studio.

Managed runtimes like the CLR (Common Language Runtime) and JVM (Java Virtual Machine) typically use just-in-time (JIT) compilation, where byte code is translated to machine code at runtime. Apple forbids the inclusion of mechanisms that enable execution of arbitrary third party code, effectively blocking the use of non-standard runtimes, interpreters and virtual machines. The developers at Novell were able to overcome this obstacle by using an alternative ahead-of-time (AOT) compilation model where .NET Common Intermediate Language (CIL) is compiled directly to native code. AOT compiles the MonoTouch applications to native executables that do not rely on a virtual machine to run.

With the success of MonoTouch, Novell decided to take a similar approach to bring .NET to the Android platform. MonoDroid provides .NET bindings against the Android API, as well as a .NET-to-Java interop mechanism. Android is a more open platform than iOS and allows for JIT compilation of code. The Mono runtime will run side-by-side with the Dalvik runtime, providing direct access to many of the core Linux OS APIs through the standard .NET libraries like System, System.IO and System.Net. Just as with MonoTouch, a MonoDroid app will use the native UI toolkit, giving the user the same great user experience as with any other native app. MonoDroid integrates with Visual Studio making the experience of writing apps for Android even more familiar.

Both MonoTouch and MonoDroid expose the same subset of the .NET core API, which is a subset based on the Silverlight API. This is the same subset Microsoft chose to use for their newly released Windows Phone 7. This means that there now exists a core set of APIs that are the same across the three major smartphone platforms. By carefully crafting an application in such a way as to separate business logic from user interface code, it is possible to reuse code and libraries across all platforms. I expect patterns to emerge over time that describe how to best structure your code for maximum reuse across the different mobile platforms.

For many developers mobile apps have made it fun to program again. Within weeks you can go from an idea to an app that can be downloaded by millions of users through one of these app stores. Who knows, something that starts of as a hobby project might turn out to be the next Angry Birds. No matter if you do app development as a hobby or professionally there is nothing more gratifying as seeing your first app being available in one of the app stores. Happy app-ing everybody!

I’m joining BEKK

2010-08-01T00:00:00Z

Tomorrow will be my first day as a BEKK employee. I will be joining the BEKK Trondheim office as a senior consultant. After three good years in Capgemini I decided it was time for a change. I will continue to work on different projects as a consultant, but my role in BEKK also gives me some dedicated time for other activities like exploring new technologies, preparing presentations, writing articles etc. I will continue to be just as involved in the developer community as I am today, and I already got some cool speaking gigs lined up for the fall. More on that later.

BEKK have some really talented people working for them, and over the years I’ve noticed how they’ve been one of the early adopters of agile processes and techniques (XP, Scrum, Kanban, TDD/BDD etc), as well as new technologies (Ruby on Rails, Cucumber) here in Norway. I hope that by working for BEKK I’ll get a chance to broaden my technical experience, and perhaps do some projects on alternative platforms (I’m sure .NET will continue to be my main platform so don’t worry about me leaving the .NET community).

NDC2010 - Patterns and techniques for building Windows Phone 7 applications

2010-07-07T00:00:00Z

Last month I was lucky enough to both attend and speak at the Norwegian Developer Conference. It was a fantastic conference, and the conversations following the conference are still buzzing on twitter and in the blogosphere. For me NDC must have been one of the best conferences I’ve ever attended, offering a diverse range of topics from some of the best speakers in the industry. I’m humbled to be invited to speak at such a great event.

My session was on building Silverlight applications for the Windows Phone 7 platform. Instead of doing a feature tour of all the new APIs I decided to focus on some of the patterns and principles I find important when doing Silverlight development, and showing how to apply these in a Windows Phone 7 context. Some of the topics I covered in my talk included:

How to do TDD in Silverlight on WP7
The MVVM design pattern and MVVM Light Framework.
How to use dependency injection in a WP7 context and how it can help you inject stub implementations of APIs that isn’t available in the emulator.
Asynchronous web services using Rx (Reactive Extensions).
How to use the location APIs and how to make stub implementations for the emulator.
How to use the push notification API.
Making your views Blend-friendly by supplying design time data.
The Metro design language (look and feel of WP7 applications)

To best illustrate these concepts I’ve built a full Windows Phone 7 application that lets you monitor arrivals and departures from any Norwegian airport. The application consumes a set of REST services exposed by Avinor that lets you look up arrivals and departures for a given airport. I’ve made the entire application available on GitHub as open source, and I do plan to polish it enough to actually publish it on the app marked place as soon as the WP7 is released.

Most sessions from NDC2010 where recorded, and can be downloaded from the Tandberg streaming server or as a complete torrent with all the sessions. I’ve also uploaded my session to Vimeo (for my personal video archive), and to make it easier to embed it on my blog.

Silverlight Applications for Windows Phone 7 from Jonas Follesø on Vimeo.

The slides are available on Slide Share, and the source code is up on GitHub. I do plan to update the code as new versions of the WP7 platform is released, and hope the application can serve as a good example of how to architect a WP7 application.

Get a flying start with Windows Phone 7 – NDC2010

View more presentations from follesoe.

Thanks to everyone who showed up for my session, and for the great feedback on Twitter, in person and through the conference evaluation system. Thanks to everyone I meet during the conference that I got a chance to talk to – it’s amazing how many talented people you meet at a conference like NDC. Also big thanks to the people behind NDC – they did an amazing job and I’m truly looking forward to next year’s conference!

XP2010 and BlackBoxRecorder

2010-06-04T00:00:00Z

This week I have been attending the 11^th international conference on Agile Software Development, XP2010, in Trondheim. It has been an amazing week, filled with learning, excellent food and awesome social events, making new friends and catching up with old. I gave two lightning talks during the conference, one on UI prototyping in agile projects (the same I gave at Smidig 2009), and one on Generating Characterization Tests for Legacy Code. The talk on characterization tests was based on some work I did back in October – December 2009. I was involved in a partial rewrite of some pretty bad legacy code. One of the techniques we discovered was that we could use the slow running integration tests to code generate fast and more targeted characterization tests for the code we were rewriting.

For the last three-four months I’ve been working on an open source testing tool that streamlines the technique of generating characterization tests for your legacy code. The project is called BlackBoxRecorder and is available on Github.

BlackBoxRecorder is a tool that uses AOP-techniques to automatically record and generate characterization tests for legacy .NET code (code without tests). You apply a [Recording]-attribute on the method you want to generate tests for, and a [Dependency]-attribute on any class accessing external resources such as the file system, web services or databases.

Each method invocation of a method marked with the recording-attribute will be stored in an XML file. The XML file contains information about the method, copies of input parameters, output parameters and return values. If the method being recorded invokes any methods on a class marked with the Dependency-attribute, the return values of the dependency will also be recorded in the same XML file. This enables automatic mocking of external dependencies when playing back the characterization test.

For each method recording BlackBoxRecorder will generate a unit test that will play back the recorded XML file against the method. The return values from the method will be compared against the recorded return values using reflection. If any change is detected the test will fail. The test will serve as a change detector (which in essence is what characterization test is), notifying you of any changed behavior in the method being tested. If the change was intentional you can configure the generated test to ignore that property on next run.

The generated tests supports automatic stubbing/mocking of the types marked with the Dependency-attribute. When the test is played back, the dependency will load return values from the XML recording and return these instead of actually calling the external resource. You do not have to change your code for this to work and even static methods are supported.

I got some really good feedback on the session, and it was pretty cool that Michael Feathers attended the session. I referenced his book and quoted him a few times in the presentation, so I was really glad he enjoyed the talk.

I also got questions from several people who where interested in what it would take to port BlackBoxRecorder to Java. So on Thursday evening I organized an open space session where we walked through the code and discussed how to implement a Java version. We continued the talk over lunch Friday, and soon enough Ole Christian Rynning, Johannes Brodwall, Geir Amdal, Marius Kotsbak and myself where hacking away on a spike implementing BalackBox for Java.

We called the implementation JackBox, and the code is up on Github if you want to jump in and contribute.

I will definitely blog more about BlackBoxRecorder as soon as I’m done with my NDC2010 presentations. Thanks to organizers, speakers and attendees for making XP2010 a memorable experience!

Simulating multitouch on the Windows Phone 7 Emulator

2010-03-21T00:00:00Z

Over the weekend I have had tons of fun playing around with the Windows Phone 7 Developers Tools. The platform looks awesome, both from an end user perspective as well as a developer perspective.

One of the scenarios I’ve been exploring involves some simple multitouch pinch and zoom gestures. It’s fairly simple to add custom touch functionality by subscribing to the Manipulation Events hanging off all UIElements. If you got a touch enabled Windows 7 computer you can even test multitouch directly in the emulator. However, I was a little bummed when I read that, unlike the Surface SDK, simulating multitouch input using multiple mice was not supported:

“The Windows Phone Emulator does not support multitouch input through the mouse, so you must test scale transforms on a development computer that supports touch input, or test on an actual device.”

This is not entirely true. When I read this I remembered this cool blog post from Szymon Kobalczyk on emulating a multitouch device in Windows 7. In his post Szymon talks about the MultiTouchVista project. It’s an open source piece of software that lets you install a Windows 7 touch driver. The driver talks to a multitouch service that can read input from multiple sources and turn them into standard Windows 7 multitouch events. Sources for input include things like multiple mice, web cameras and Wii remotes. Since the MultiTouchVista application appears as a standard Windows 7 touch driver it will work in any Windows 7 touch-enabled application, like the Windows Phone 7 emulator.

For detailed installation instructions, check out the projects official CodePlex site. I have recorded a quick demo showing multitouch in Silverlight 3, MS Paint and the Windows Phone 7 emulator using two mice connected to my iMac.

Emulating Multitouch on the Windows Phone 7 Emulator using multiple mice from Jonas Follesø on Vimeo.

MVVM presentation from NDC2009 on Vimeo

2010-03-07T00:00:00Z

Last year I gave a presentation on the MVVM design pattern at the Norwegian Developer Conference. Most of the presentations from NDC2009 was recorded and made available online, including mine. However, the user experience of the video content on the NDC site isn’t the best. Playing a video requires multiple clicks, and the videos are only available in WMV format.

The feedback I’ve gotten on the presentation is so good that I decided to make it a bit more discoverable by uploading it to Vimeo. In addition to the MVVM presentation I have also uploaded my lightning talk from Smidig 2009 (in Norwegian) as well as my Silverlight talk from TechEd New Zealand 2008.

If you want to watch all the content from NDC2009 you can download it nicely packaged as one big torrent file. Oh, and I haven’t made an announcement on the blog yet, but I will be speaking at this year’s NDC.

MVVM Design Pattern NDC2009 from Jonas Follesø on Vimeo.

MVVM Design Pattern NDC2009

View more presentations from follesoe.

Automatic INPC using dynamic proxy and Ninject

2010-01-17T00:00:00Z

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.