Faster and Slower

Growing concerns about the direction of Xaml-based applications

Microsoft, what the hell do you think you are doing by diverging WPF, Silverlight and Silverlight for WP7?? None of those 3 destination platforms have any solid foothold as of yet. By making different options of XAML available in different destination platforms, you’re only doing one thing: pissing off developers. Stop doing that, this is really simple:


imagesCA28TSXTWPF should be the mother of all xaml based apps and have every available technology to it – including webcam support as in silverlight, MEF, etc. WPF needs to be that “unlimited” target platform from which both silverlight and WP7 pick their features from.



Why oh why can I not use data triggers in SL? What is the reasoning for it? I know MS has “shifted focus” for Silverlight. This, in my ears, is bull. Silverlight on iOS and Android will give developers reason to use it. WPF alone cannot succeed as the only xaml-based platform, and SL makes sense for servicing the current craze of tablets and smart phones. Very few people will disagree when I say that MS powered devices (tablets and phones) are lagging far, far behind. For SL to be a success, it needs to penetrate iOS and Android. End of story. rest is just bull.

Silverlight for WP7

phone7I accept that SilverLight for windows Phone 7 will offer different capabilities from Silverlight as a xap, but what I don’t get is why this version of Silverlight has to be a framework behind the current release of Silverlight web?? It makes no sense, whatsoever to keep developers in confusion station by not holding back releases until the technology is ready on all platforms!

Converge now!

What Microsoft needs to do, is to hold back releases, so they can do a unified XAML platform upgrade targetting windows, SL and WP7 with the same developer options and syntax. No data trigger support for WP7 means dont release it for Windows or SL either! This is FAR better for developers than the mess you’re giving us now! XAML as a developer platform, needs a unified version number, we dont want to have WPF for .Net 4.0, Silverlight 5.0 for web and SL 3.5 gutted for WP7. 

So, where was I?

You may have notice that digitaldias was down for a week or two.

I’ve been using an SHDSL line (Single-Pair High-speed Digital Subscriber Line) for the last 6 years, giving me a whopping 2Mbit in both directions!

Recently, though, I’ve been on the lookout for higher download speeds, as iPads, laptops, and even the PS3 consume more and more information from the web. When I was offered the option of 20Mbit down, and 1Mbit up for much less moolah, I took it.

My blogs will load at half speed (as if you care!), but then again, I dont connect back to my office over VPN anymore, so I dodn’t have any good excuse to pay that much for a decent speed out anymore.

I still want higher output speed, for using skype in HD, but that’ll have to come when the prices (and availability) fits.


My ISP, Nextgentel delivered fast and reasonably priced this time. For that, they get a nice, well deserved kudos from me Smile

Close( ) – the MVVM chaos

Technorati Tags: ,,

pp_DSC1924 copy

I am an avid adopter of the Model-View-ViewModel pattern for designing applications. It is a sleek, very testable way to write software, but it has one major problem:

Because the ViewModel is unaware of its view, it follows that it is difficult to command a window to close itself.

I googled long and hard for solutions, but what I found was so complex and intricate that it would scare off any developer wanting to do some actual work.

What I give you here, is my own compromise between the want for simple, yet testable software vs the want to have a clean separation between a view and it’s viewmodel.

The BaseViewModel

Because every ViewModel implements INotifyPropertyChanged it is generally a good idea to write a base class that encapsulates this behaviour in most software projects.

In my opinion, every viewModel should also be able to request that a view should disappear for some reason.

Thus, my implementation of a baseclass for ViewModels looks like this:


By providing both an ICommand and a Method that both invoke the RequestCloseEvent, I can choose whether a View should close by binding to a button, or as a consequence of some logic in the viewmodel.

The CloseCommand property simply calls the RequestCloseEvent nothing more.

DataContext Binding

The practical approach to binding a View to its ViewModel should not require more than a one-liner:


The ( Application.Current as App ).ServiceLocator is my IoC Container; it has a public property for every ViewModel that I write. I add the container as a public property in app.xaml.cs. This way, it can be reached from all views.

The line above uses a simple extension method to do two things:

  • Register the ViewModel provided by the ServiceLocator as the DataContext for that view
  • Attach the RequestCloseEvent to the Views Close() method

Here’s the code:


The idea is that the event always closes the dialog.

You can then either bind a close button to the CloseCommand property of the BaseViewModel, or you can have your ViewModel fire the event through calling RequestClose( ) – or both.



Figure: Binding directly to the base class




Figure: Calling Close from a ViewModel method

So…how testable is this?

For all intents and purposes, I now have a loose enough coupling between my ViewModel and View to verify that the ViewModel is requesting a dialog to close:



The method I’ve given you gives a loose enough coupling to be testable, and keeps things simple. There is one single line of code to attach the View to it’s ViewModel, something I find to be an acceptable tradeoff from a pure separation.

The ViewModel also remains 100% compatible with the concept of test driven design, and is simple enough for teams of developers working on large software projects to use

PS: Who else does M.C.Escher inspired photography? :)