.NET, Featured, General, Silverlight, Headline »

[16 Sep 2011 | 5 Comments]

Windows 8 is here!


Well, it's been announced :-)  The last few days, a lot of new information has been released about Windows 8, specifically aimed at the new Metro-style apps.  Windows 8 will essentially feature 2 modes: the regular desktop, and the touch-optimized Metro style.  I'm not going to go into much detail about this: I'm guessing people who end up reading this post already know a thing or two about Windows 8.  But: I've been getting a lot of questions on this topic, so I decided to try and answer a few, and share my 2 cents.




Some things we've been hearing: Windows 8 changes everything.  HTML5 + javascript is the way to go.  XAML is a first class citizen.   OH MY GOD IE10 Metro doesn't support plug-ins: Silverlight is dead.  Silverlight is alive and well.  Et cetera, you know the drill.


Time to take a step back.  Does this really change everything?  Is the change that big?  Well: I don't think so. 


What is Metro?  What about the regular desktop?

If you look at Windows 8, it actually falls apart in 2 vastly different experiences.  We've got the regular desktop, which is much like Windows 7.  Everything we know about Windows 7 still applies to Windows 8: all the applications we've built, including WPF, Silverlight, in-browser apps built with ASP .NET MVC, ... Winforms, even, still run on Windows 8. Aka: the .NET we know and love.  This is the way applications will be built for a long, long time: just as we do it now.


And then there's the big new thing: Metro-style apps.  This is what all the fuzz is about.


One way to look at this, and this is the way I like to look at it, is: in fact, Metro style Windows = iOS or Android, the Microsoft way.  It's made for tablets/slates, it's made to be touch-optimized.  It's aimed, mainly, at consumers, or at apps that don't require a lot of input.  And every app you build for it will be built using the new development paradigm: WinRT, in combination with HTML/js or XAML/C# (I know, VB .NET etc is also possible - but let's just assume the majority uses C#), and they will be distributed through the Windows App store. 




WinRT (regardless of how you talk to it - through JavaScript or C#) allows us to talk to device-specific functionality through C# or js (although it does still run in its own sandbox).  That's "The Cool Thing".  But in essence, writing Metro-style apps is a lot like writing apps for Android or iOS: you've got the power to use most of the capabilities of the device, the distribution mechanism is more or less the same, and the apps are OS-specific. 


But at the same time: Metro style apps do not run on anything but Windows 8 - Metro style (nope, not even the regular desktop).  Metro apps do not run in a browser, do not run on other devices, do not run ...  well, you catch my drift.  Even though you code these apps using syntax that is much like the XAML/JavaScript you're used to, they are not redistributable through other channels.


So what have we got here?  A new type of apps, with lots of capabilities, built in a new way that's a lot like what we're used to, but not quite the same.


What about IE10?

A nice example of this is IE10: there will be 2 versions of this: a regular IE10 for the desktop, and a Metro Style IE10.  This is actually just a Metro Style app: that version will not run on anything else but the Metro Style desktop.  By the way, this also means that other browsers like Chrome, Firefox, ... do not run in Metro Style mode - unless Google & Mozilla create Metro-versions of their browsers, and Microsoft allows it.  Just like none of your existing apps run in Metro Style mode (you might start to see why I like to think of this as "MS's iOS" :-)).


Now, of course: web applications do work, as you're just browsing to them using IE10, Metro Style.  But don't be mistaken: these are the web apps we're used to, and they are confined to the browser sandbox, just as we're used to.  They do not have access to any of the WinRT-stuff.  It's, well, just a browser.

And what's more: it's a browser that does not support plugins.  None.


Well, that sucks.  Shouldn't these plugins be supported?

No plugins.  That means: no Flash.  No Silverlight.  But also: no Adobe Reader, and none of the other plugins a lot of LOB applications rely on. 


There's been a lot of concern about this: does this mean Silverlight is dead?  Or Flash?  Isn't this a very bad decision? 


No: it's a good decision.


It's like wanting to have support for Flash or Silverlight, in-browser, on your smarthphone or iPad.  It can be done, technically (there's a Flash for Android), but it will offer sub-par user experience, almost by definition.  Steve Jobs was right on this one: if you create a Flash app (or Silverlight app for that matter) that runs in the browser, it's supposed to be manipulated with keyboard & mouse.  Using an app designed for those input types on a touch-based device is not - and I mean: never - a good user experience.  Let alone the different amount of screen estate, orientation, ...  any designer will tell you a specific form factor with a specific input type requires an application design catered to those specifics. 


From an end-user POV, not supporting plugins in Metro is a good thing.  And for those who are concerned about Flash or Silverlight: this is, and stays, fully supported in regular Windows 8.  Remember: Metro apps are touch-centric apps, for slates and tablets.


Touch centric?  Metro?  Isn't this supposed to work with mouse & keyboard as well?

Yes, it works.  But this is one of the things where I'm quite opposed to what Microsoft is trying to sell us with its Metro paradigm: the idea that Metro works just as good with mouse & keyboard. 


With Metro, we're looking at a UI and UX tailored to touch devices.  As any - and I mean any - UX specialist will tell you (and as I've stated above): a different input methodology requires a different UI approach to ensure good UX.  Even Microsoft themselves tell us that: just read their Metro design guidelines for WP7: it's based upon the notion that a touch-centric UI is vastly different from one in which you manipulate your apps with mouse and keyboard.  So, Metro with mouse and keyboard?  It's not because it can be done that it should be done.


My gut feeling?  The typical LOB/Enterprise applications that require mouse/keyboard input will not be Metro applications - they will look, feel, and be developed just as we do today, web-based or desktop-based, and will be run through the regular desktop in Windows 8.



With Windows 8, we get a new type of application: the Metro style app: touch-centric, Win 8 only apps, using a new WinRT stack, which can be developed using XAML/C# or HTML/JavaScript (keeping in mind that those apps will not just run in a browser, or in Silverlight).  This Metro style version of Windows is, in my opinion, quite similar to what we've got with iOS/Android-based devices.  The thing Windows 8 has going for it is the ability to switch between Metro & regular mode, but we've got to keep in mind that these are 2 very, very different environments, from a user POV AND from a development POV.

But for the most part, and for the majority of applications that are built today by companies as the one I work for, there's not that much that changes: we typically buildLOB / Enterprise apps, not very suited for the touch-based, small application, consumer-like approach Metro is tailored to.


The best advice I can give anyone who’s building applications today: build a decent, standards-based service layer, and tailor the frontend to the devices it has to run on, be it a regular web app, a Silverlight OOB app, an iPad or iPhone app, or a new WinRT Metro Style app.  The “build once, run everywhere”-dream should be put to rest.  The best user experience is, and stays, a native experience.

.NET, Silverlight, WCF RIA Services, WCF, RIA »

[14 Jul 2011 | 0 Comments]

Just a quick heads-up: in case you haven’t noticed, Silverlight Show started publishing e-books a few weeks ago.  These provide a convenient way to read up on some of their most popular article series, including source code, while you’re offline.


I’m glad to announce that two of my article series are now available as e-books:



Happy coding! :-)

Featured, General, Headline »

[23 Jun 2011 | 2 Comments]

Quick post: the slides and demo-code from my Silverlight, MMVM & RIA Services – an Architectural Story are available for download from my SkyDrive.


Thanks for joining the session, the nice comments and interesting questions afterwards :-) I enjoyed delivering it, hope you enjoyed listening to me, and if you’ve got any questions, drop me a line.

.NET, MVVM, RIA, Silverlight, WCF RIA Services »

[9 Jun 2011 | 0 Comments]

I’ve just finished my session on Silverlight, MVVM and RIA Services – an architectural story at NDC2011.  Almost a full room, thanks for such a great turnout!




As promised, the slides + democode are available for download.  Any questions on the session or the principles discussed therein?  Drop me a line or contact me on Twitter.


Cya around! :-)

.NET, Featured, RIA, Silverlight, Headline, WCF RIA Services »

[10 May 2011 | 0 Comments]

With the release of SP1 for WCF RIA Services, a bunch of new and/or enhanced collection types became available to developers: the EntitySet, EntityList, ICollectionView & DomainCollectionView. 


I wrote a round-up of these collection types for SilverlightShow, explaining how they can be used and for what scenarios they are best used.  The first part of this series has been published today, and the second part will follow shortly.


If you’re working with WCF RIA Services, knowledge of these new types is essential, as they offer a lot of productivity value for your applications.  Have a look at the series, and feel free to let me know how you feel about them!  Source code is, as usual, included.


Happy coding! :-)

.NET, Silverlight »

[26 Apr 2011 | 0 Comments]


clip_image001Those of you who read my Twitter messages might have picked up a few hints about this already: a few months ago, we started working on an official application for Techdays 2011, which would allow attendees to have a look at the agenda, compile a list of favourite sessions, and give both general as well as session-specific feedback.


This app is now available in the marketplace.  It’s part of a larger “group of apps”, which started as a way to, essentially, test how we could bring together all the cool new techs we’ve heard about the last few years: we’ve got a Silverlight backend app, a WP7 app, an MVC frontend (both full & jQuery-mobile based), and all this is backed by WCF RIA Services and fully hosted in the Azure cloud.


If you want to find out more about how we did this, make sure to come to the session Maarten Balliauw & yours truly will be giving at Techdays, right after the keynote.



Cya there?  For now, feel free to check out the app! :-)

RIA, Silverlight, .NET »

[14 Apr 2011 | 0 Comments]

At MIX11 today, Silverlight 5 beta was released.  It includes a whole load of new features (most of which were already known by people who watched the Firestarter event last December), you can find the full list at Tim Heuers’ blog.


One of the small, yet pretty interesting additions in my opinion are Markup Extensions.  Tim quickly mentions it, but there’s no example to be found on Silverlight.NET, so I figured: why not try it out myself? :-)


With custom markup extensions, you can in essence execute your own code instead of the default Binding markup extension, which will provide the correct desired value for the property you’re using the markup exension for.  One of the typical uses for this could be for multi-language apps: getting the correct text in the correct language from your resource dictionaries. 


Up until now, I had to provide quite a bit of code to enable my app to handle multiple languages: I would typically create some kind of resource wrapper, make that available through App.XAML or a resource dictionary, reference the resource on all my Views and bind to the resource wrapper + resourceKey property of that wrapper.


With markup extensions, this becomes a lot easier.  Start out by creating a new SL project, and add 2 resx-files: one default, one with the .nl extension for Dutch translations.  Then, add a new  class to your project, and make it implement the IMarkupExtension<T> interface, where T is the type of object you want to get back from the code.  In that class, you can add a bunch of properties, methods, … to your liking.  In this case, all I need is a string property, ResourceKey.  The ProvideValue method is what gets executed to get the desired value, which, in this case, comes down to getting the translation with key ResourceKey from the resx file.  That’s no more than a few lines of code:


public class TranslationExtension : IMarkupExtension<string>
    public string ResourceKey { get; set; }

    public string ProvideValue(IServiceProvider serviceProvider)
        // get the ResourceKey value from translations
        return SL5MarkupExtensions.TranslationResources


Next, we need to use this in XAML.  Import the correct namespace, and call the Markup Extension from XAML, passing in the ResourceKey parameter:


<TextBlock Text="{me:TranslationExtension ResourceKey=DemoResourceKey}"/>


And… that’s it.  Really.  Instead of having to create all I described in the beginning, all I need are these few lines of code.  To check if it still works when changing the language, I added a button which will set the culture to “nl”, and navigate to another View, containing a TextBlock using the markup extension with the same ResourceKey.


This is one really short example to show you how easy it is to use markup extensions, but I ‘m pretty sure you can already see how it can prove useful.  For example, you might use it to get the correct ViewModel for your View, if you’re using MVVM.


By the way, in case you’re wondering why I’m navigating to another View: I want to make sure the markup extension code gets executed again.  If you want true on-the-fly language changing in your app, you’ll have to provide a way to notify your app it should re-execute the extension.  This goes beyond the point of this blog post, but there already are quite a few implementations for this available for WPF, like this one, which should be easy to port if you really need it.


That’s it!  You can download the source code here.  Happy coding! :-)