My Short Opinion About Windows Store Apps

I really like Windows 8. I like the improvements on the desktop side. I like the new start screen better than the old start menu. I like the WinRT technology, design and interactivity of the Windows Store apps. I love the cloud integration of the OS and apps. I believe this is the most user friendly OS for tablets on the WinStore apps side and the most user friendly and powerful OS on the desktop side.

I don’t really use any Windows Store apps though, since I don’t own a Windows 8 tablet and mostly use Windows on a (touch screen) laptop. I think this will be a great platform for games and I believe the AAA titles should and will come out in Windows Store and I will play some of them – perhaps even on my desktop machine since it has better GPU and cooling than my ThinkPad. For the apps on a laptop or desktop machine though – I think the desktop platform is still better. I like my apps in windows, system tray (or as Windows people like to call it – notification area) and I like having all of them on my screen and a consistent taskbar where I see all of them. On the desktop – I like seeing all my 100 open tabs in Chrome, 5 instances of Visual Studio, Outlook, etc. I like that I can play a video in a window and then continue listening to the video (or a webcast) while I move its window behind my Visual Studio window and continue working.

I think things might change – I would love if Microsoft added all the more line of business controls and WPF features to the WinRT platform – such as grid splitters, data grids, tree views etc. I would like to be able to develop windowed applications in WinRT, though I am afraid Microsoft is much more likely to insist on making the full-screen experience more powerful rather than supporting the good old lowercase windows.

I am excited for the future.


Layout and Formatting with Windows 8 XAML Development

When designing a user experience, one of the first things you need to figure out is where to position things on the screen, how they should flow when the content changes, and what shape or color they should be. This article is about the tools you have at your disposal with Windows 8 XAML to control layout and formatting on this exciting new platform.

Read more on Safari Books Online

Tagged , ,

Windows 8 Development with XAML and C# – New and Missing Controls

Although the Windows 8 XAML platform brings back a lot of the controls that exist in WPF and Silverlight, and adds some completely new ones, there are some controls that you might find missing and wonder what to do. In this article we cover a list of some of these controls, along with some suggested ways to cope with their loss.

Read more on Safari Books Online

Tagged , , ,

Windows 8 Development with XAML and C# – Controls

User interfaces are usually composed of reusable controls that encapsulate the logic for rendering the view, taking input and manipulating data. Windows 8 XAML has a wide range of such controls and this is a terse overview of these controls that you can use to check if you know them all.

Read more on Safari Books Online

Tagged , , ,

Windows 8 Development with XAML and C# – Introduction

Why develop for Windows 8?

Windows 8 is a platform with high potential. Based on the trends, Windows 8 is expected to run on half a billion devices within a year or two. Since previous versions of Windows are already running on over a billion machines today, and upgrading from any existing version will cost a mere $15 to $40 – this is just a deal that is hard to miss. Windows 8 is every bit as stable and incrementally improved in its desktop flavor, but it also has a new and exciting part in its touch-centric start screen and app store support.

Read more on Safari Books Online

Tagged , , ,

WPF/Silverlight vs. Jupiter Quirks – Opacity

Have you noticed the difference in how the Opacity property is handled by child elements the Windows 8 XAML vs. Silverlight or WPF?


Windows 8 XAML (Jupiter):

Continue reading

Tagged , , , , ,

Minimalistic MVVM for Windows Runtime XAML Platform Development with C#

I have been using MVVM for a few years now and always felt it needed a summary of the state of things as well as my own opinion about it. This is it today. My approach to MVVM has been changing from the time when I was an eager student, through a devoted disciple, till today when I see it as a small tool in the toolbox of a XAML developer.

The original article has been republished by Safari Books Online.


The Model View View Model (MVVM) pattern is an architectural pattern used for separation of concerns in applications. It is popular in Microsoft’s XAML-based UI frameworks such as WPF, Silverlight or WinRT/XAML.

The MVVM architecture consists of the View layer (the UI design implementation), the View Model layer that provides bindable properties and commands to the view and the Model layer that contains the application’s actual domain model and business logic. The connection between these layers is such that the view model knows nothing about the view (it does not reference it) and the model knows nothing about either of the other two layers.

The qualities of an application architected based on the MVVM pattern are

  • Maintainability – separation of concerns and loose coupling helps modify one layer without affecting the other layers
  • Testability – being able to replace the view as well as view model with a test fixture allows to test the layers separately and avoid having to use unreliable and hard to maintain UI automation for all tests. That also helps overall maintainability of the code, since a change can be made in one part of code while tests reduce the risk of regressions in other areas.
  • Blendability – view models can fairly easily be replaced with design-time data and logic, so designers can create the views using Blend independently of other development work.
  • Ability to split work among multiple developers – not only the views can be implemented by designers or integrators, but also view models can be created separately from the models by mocking the models.
  • Portability – the view models and models can theoretically be reused in versions of the same app for different platforms.

MVVM was made possible in WPF – the original XAML framework thanks to the XAML layer that is the declarative description of the view as well as bindings – that allow to declaratively specify which properties of the view model are displayed or manipulated by the view, and commands that allow to represent actions executed by the view model in form of bindable properties. However, anyone trying MVVM for the first time soon notices problems with MVVM, such as

  • What are commands and why should I use them?
  • What gets created first – the view or the view model and how to connect the two?
  • Animations – how to trigger an animation from the view model or do something when an animation completes?
  • Navigation and dialogs – where to initiate navigation and dialogs – from the views or the view models?
  • State persistence – while saving the state of the application was a nice feature in the past – it is virtually required on modern platforms such as Windows Phone or Windows 8 – how to store and restore the state of the view and the view model though?
  • Non-bindable properties – a lot of the properties in the UI frameworks are not bindable, such as grid column and row definitions, Windows Phone application bar or in many cases – the style setter values.
  • Bindable properties are rather verbose – instead of using auto properties – even for the most basic bindable properties you need to invoke property change notification events.

The languages and the UI frameworks lack built-in solutions to these problems, so the developer community has responded with many frameworks that try to address these issues. Some of the more known libraries maintained by known experts in the XAML community are

  • MVVM Light Toolkit (by Laurent Bugnion) – most popular possibly because it really is pretty lightweight with just the basics of MVVM covered and the source code is easy to understand. For all platforms.
  • Caliburn.Micro (by Rob Eisenberg) – a bit more complicated, but supports convention-based approach where bindings are not explicitly specified and XAML is kept eerily clean. For all platforms.
  • Prism (by Microsoft patterns & practices team) – official guidance from Microsoft for developing composite applications with WPF, Silverlight and Windows Phone.
  • WPF Application Framework (WAF) – a popular, WPF specific library
  • ReactiveUI (by Paul Betts) – based on Reactive Extensions – a bit exotic part of the .NET framework that is well suited for highly asynchronous applications. For all platforms.
  • Cinch (by Sacha Barber) – a “Rich Full Featured WPF/SL MVVM Framework”.
  • nRoute (by Rishi Oberoi) – a big library with a lot of features, available for all XAML platforms.
  • Catel (by Geert van Horrik) – another rich framework with MVVM support with support for all platforms.
  • MVVM Foundation (by Josh Smith) – one of the early MVVM frameworks for WPF by an early MVVM advocate. Worth checking due to its small size and simple project structure.
  • Jounce (by Jeremy Likness) – “Silverlight MVVM + MEF Framework”.
  • Calcium (by Daniel Vaughan) – composite application toolset for WPF/Windows Phone.

Over the years MVVM Light, Caliburn.Micro and Prism have grown to be the three most popular frameworks with the biggest communities around them and are the best choices to start with, though the other libraries have interesting features that are worth checking too.

MVVM for WinRT

What is changing with Windows 8 for MVVM development? Well, Windows Runtime or WinRT is the new default Windows API and the most popular MVVM frameworks are seeing gradual updates to support Jupiter – WinRT’s version of a XAML UI framework. They are however still mostly .NET class libraries – not usable in C++ or Javascript. Right – Windows 8 also enables XAML development with C++ and MVVM is supported there too. Using Javascript with HTML is another option and you can also use MVVM there using the KnockoutJS library. You can then develop WinRT applications in C#, Visual Basic, C++ or Javascript and implement the MVVM pattern in any of these languages. Back to C# and .NET though – if this is the platform you choose – there are some changes coming there that affect how you can implement MVVM like the new CallerMemberAttribute in C# 5.0, but the one I would like to talk about is the BindableBase class that comes standard with multiple Visual Studio project or item templates. Since we now have a base view model class available to people who might not have even heard of MVVM before – this might become a pretty popular class used by C# developers building apps for the Windows Store. You now get a pretty good view model base class out of the box.

Should you use the BindableBase class and is it enough to build MVVM-based applications?

I still do recommend using MVVM Light Toolkit or Caliburn.Micro for larger projects, since they provide features that you will most likely need sooner or later as your application grows and if you want to keep it implemented in clean MVVM fashion, however over the years as these libraries have grown in popularity, they have also grown in features and the built-in cross-platform support, made them more complicated and harder to study. Sure – with NuGet you can now have the latest version of MVVM Light referenced by your project within a few clicks, but then you cannot see the source code and it is harder to figure out how it works or how to use it, especially with the growing number of APIs available.

For smaller projects – the BindableBase from the Visual Studio templates might just be enough. Though a snippet for observable properties as the “pp” snippet in my snippets helps a lot (just install the snippets and type pp[TAB] to insert an observable property in your view model). Commands? Do you really need them to implement the MVVM pattern? A regular public method on the view model works just as well and if you need to disable or enable a button based on whether a method can be executed – a regular observable property like “CanExecuteMyMethod” works just as well as a CanExecute method of a command. By the way – if you really want to – you can still create any MyCommand class that implements an ICommand interface – it is not that much more code than using a DelegateCommand/RelayCommand of Prism/MVVM Light, though admittedly these do make it a lot easier to inline its implementation.

Not using a third party MVVM helper library has many benefits – no need to install anything, no dependencies, no reliance on reflection, no dead code in form of unused framework APIs, no need to justify using open source code at companies that do not generally allow it. It is just what you get with the standard templates.

Of course these existing libraries have custom solutions to some specific problems and provide generic solutions to others, but usually eventually you stumble upon something that the library you chose just does not solve. In such cases I sometimes build my own reusable libraries or controls or just write some one-off piece of code that glues MVVM together. If the problem you need solved involves some custom interaction logic – you are going to be better off implementing a custom control or attached behavior than trying to stuff everything in the view model.


Ultimately using code behind is an easiest choice and does not invalidate MVVM. Experts in the field such as Laurent Bugnion have long been saying that MVVM is just a pattern and you should not be afraid of using code behind in your applications. However religiously it seems to be treated by many developers – if you just start by using view models to drive your views – it is enough to reap most of the benefits of the pattern and will help you create a maintainable application. Unless you are building a big line of business application, planning on unit testing your complicated view model logic or doing a lot of UI development using Blend – you might not need a fully separated view and view model. If you are working on a big project though, or your project just grows big – you might consider one of the popular frameworks or building your own. At some point you will just find that you can’t live without a pub-sub implementation like MVVM Light’s Messenger or Prism’s EventAggregator, you will want to write unit tests and find a need for an IoC container, so you can mock and shuffle your components., you will want to bind everything even if Microsoft’s does not support the binding you want. Until then though – feel free to start small and lean and worry about features rather than patterns. MVVM is just one of the tools to build an app and you might find that learning about custom layout logic, touch interaction, custom controls or behaviors is going to benefit you more than wondering which MVVM framework to use.

Creating a Zoomable ScrollViewer with ZoomSnapPoints in WinRT XAML

The Metro/WinRT XAML ScrollViewer by default allows to zoom in on its contents. That is because its ZoomMode property defaults to “Enabled”. I think in most cases it is actually not the desired behavior and you might want to set ZoomMode to ZoomMode.Disabled. I do understand though that this makes the feature more discoverable and does not hurt much while potentially getting users familiar with the new paradigm of quickly scrolling by zooming that is also displayed in the SemanticZoom control.

For my application I needed to enable users to zoom in on a horizontal StackPanel with a list of buttons so that all the buttons fit on screen. At first I thought I would use the SemanticZoom control, but then I realized I need an actual zoom not a semantic one, so the improved (over WPF/Silverlight) ScrollViewer is an obvious choice.

Continue reading

Tagged , , , ,

In Search of a Better Name Than Windows Runtime “XAML” Framework

XAML is a very non-descriptive name for one of the UI technologies used in Windows 8 Metro style apps. Nothing at the level of WPF/Avalon or Silverlight/WPF/E. “Jupiter” could be its name, but no one at Microsoft ever officially confirmed what “Jupiter” really is or if it really is the father of “Apollo“. I noticed a blog post of a Microsoft Developer Evangelist mentioning XAML being Jupiter, but it might still just be a mistake, since developer evangelists are not usually members of the product engineering teams at Microsoft, so it might still just be based on rumors taken as fact. Looking for any confirmation I found there was not even a Wikipedia article for the latest XAML UI framework so here it is:

Tagged , , , ,

Debug Layer in Direct3D 11.1 Metro Style Applications

DirectX developers might (should) be familiar with the Debug Layer. This is a piece of code that you can inject into Direct3D for debugging instrumentation. When you create a D3D device, by default – Direct3D is a very thin layer that allows you to achieve maximum performance from your API calls through the drivers to the hardware. In fact it is so thin, that when an error occurs – you only get one of few error codes. This might make you wonder why that API call you are making is failing. Did you forget to pad that constant buffer struct to a multiple of 16 bytes size? Or perhaps you passed an invalid combination of flags to that other method. Well, for years now – you could get all that information by enabling the Debug Layer, but how do you do that in the WinRT world?

Continue reading

Tagged , , , , ,