Monthly Archives: November 2015

x:Bind and inheritance

(published on 11/30/2015, although WordPress states ’11/15/2015′)


The first time I heard about Compiled Bindings (x:Bind) was at Build 2015. Finally we got compile-time validation on bindings and it promised to be a lot faster as it doesn’t need to do reflection at runtime! After playing around with it for a bit, I introduced it to my development team and we were going to use it wherever possible in our UWP project.

Once we were using it in real-life scenarios we stumbled upon some issues with compiled bindings. Luckily all these issues were apparently due to the fact we were  developing against very early bits of UWP because since the launch of 10.0 Build 10240 these issues were gone… All except for one…

And it’s kind of an annoying one.

The problem

Let me illustrate.
I’ve got two interfaces: IViewModel (exposing a Title property) and IMainPageViewModel which inherits from IViewModel.
I’ve got a Page that has a property ViewModel of type IMainPageViewModel.


On my MainPage, I try to bind the Title property of my IMainViewModel (which is inherited from IViewModel) to a TextBlock.


But, at compile time, Visual Studio throws the following compilation error at me:

Invalid binding path ‘ViewModel.Title’ : Property ‘Title’ can’t be found on type ‘IMainPageViewModel’

It turns out, only properties of the interface you are binding on directly can be found. Properties of an interface that are inherited from an other interface can’t be found.

A solution

We could get this to work by explicitly exposing the Title property on the IMainViewModel.

VS Warning

But, as you can see in the above image, Visual Studio gives us a warning. If we want to do this in a ‘clean’ way, we could use the ‘new’ keyword as Visual Studio suggests.



IMHO, this is dirty… Hiding inherited members can be useful in some situations, but not in this scenario for compiled bindings. The binding engine should in fact recognize the members of all underlying interfaces. Imagine you need to expose a handful of properties from your base IViewModel, the interfaces of our ViewModels won’t look pretty.

Sadly, at this moment, I don’t see any other options. However, despite it being dirty, it does work. For now, we will need to keep ‘hinting’ the binding engine for these properties we inherit from underlying interfaces. Hopefully Microsoft fixes this over time…

Using Rx in a UWP project with MVVM


My team and I are currently working on a UWP project which is a complete rewrite of a WinRT app that we have been building.Recently we started development on the ‘Search’ functionality. It’s that typical search paradigm: only hit the backend when the user has at least typed 3 characters and when he hasn’t typed anything in the searchbox for 500ms. And, ofcourse, cancel an ongoing search operation when the user changes his search query.
It’s the same functionality that we built before in our (almost legacy) WinRT app. Back in days we used CancellationTokens and Task.Delay to do the job. And it worked well! But, I didn’t like the code to be honest, passing that cancellationToken around, cancelling it when needed, checking if it hadn’t been cancelled yet…


Note that this or any code sample in the post, isn’t really our ‘production’ code of our project. I’ve mimicked it so I could easily share it. Also, the code shown here might not be production-ready yet, it might need some additional tweaking before using it in a production environment.

Using Rx

This time around I said to my team to take a look at Reactive Extensions (Rx) in order see if we could implement this search thing in a cleaner way. So we did and the initial result looked somewhat like this (code-behind of the view):

I’ll explain, very high level, what this code does, I’m not going to elaborate too much on Rx itself (see links at the bottom of this post for more information about Rx).
First, we create an IObservable sequence of the TextChanged event of our SearchBox. This means, each time this particular event is triggered, the sequence will push the data of this event. The data that will get pushed to us is of type EventPattern that holds the same information that you would get when handling the event: a sender (object) and eventArgs (TextChangedEventArgs in this case).
Next, as we are only interested in the Text that has been entered in the TextBox and not in the eventArgs or anything else, we cast the sender to a TextBox and select the Text property. The Throttle operator handles our ‘timeout’ of 500ms: this means that the IObservable sequence only pushes an item after 500ms, instead of ‘realtime’.

So what this code does in human language: when the text of the TextBox changes, the IObservable sequence pushes us the entered text after 500ms. If the text changes within these 500ms, only this new value will get pushed (after 500ms), the previous item won’t.
It’s exactly on that moment when we get the entered text from our IObservable sequence, that we want to launch our search request to the server. And that is what we do in the following code:

We also added an additional method to our SearchDataService, one that accepts a query string and returns an IObservable<IEnumerable<Result>>

So when an item is pushed in the throttledTextChangedSequence, we do a call to our SearchDataService and return the result as an IObservable.

Finally, we are going to subscribe to our result sequence so that we can define what code needs to execute whenever a search query is executed. In this scenario, we want to update the Results property of our ViewModel with the result of our search. From each result, we are only interested in the thumb_url.

And that’s it! Bye bye CancellationTokens… But is this code realy more elegant?

Let’s try to make this code more elegant!

Well, while the above code works, and it’s already a bit cleaner than working with CancellationTokens, it is far from being elegant. This block of code in code-behind just feels wrong in an MVVM architecture (although I believe that, in some scenarios you sometimes better ‘break the architectural rules’ rather writing complex workarounds). There has got to be a cleaner way to do this.
So I came up with the following: move this code to the ViewModel and instead of converting the TextChanged event of my TextBox to an IObservable sequence, I’m going to convert the PropertyChanged event of my QueryText property:

This already felt a bit better… Notice though, that I have to do a bit more work here because I have to filter out the event coming from the property we are actually interested in by using an additional Where statement: Where(a => a.EventArgs.PropertyName == nameof(EnteredSearchQuery)).

But, there is still a lot of ceremony right? A lot of which should be repeated if we would like to convert the PropertyChanged event of an other property to an IObservable sequence.

Let’s make this a little bit more generic, by creating an Extension method on the INotifyPropertyChanged interface as almost all of your ViewModels will implement this. This method should accept one parameter, a parameter that reflects the property we are interested in. We can make the type of this parameter an Expression<Func<T>> (the same type of parameter as used in the MVVM Light’s RaisePropertyChanged method). This way we can pass in all the information we need from the property with only one parameter.
In this method, we’ll just create an IObservable from an event, just like we did previously. This time, the target parameter is going to be the class that implements INotifiyPropertyChanged on which we call this method. The event we want to convert to an IObservable is the PropertyChanged event. For this we can use the nameof expression so we avoid typos and don’t need to use ‘magic strings’. We’ll also need to use the Where clause we had before in order to filter out the event coming from the property we are interested in. The name of the property can also be retreived via our parameter. The last thing we want to do is returning the actual value of our property. All put together:




In this blogpost I showed you how you can use Reactive Extensions in a particular scenario. The main purpose was to look if we could get our ‘legacy’ code a bit cleaner without the usage of CancellationTokens. I worked out a way to integrate this nicely in an MVVM architecture, without needing to use an entire 3rd party toolset or framework (other than Rx itself ofcourse).

I can think of at least one scenario in our App where the usage of Rx might result in some cleaner code. One of these days I’m going to work that out, and will probably put the result on my blog.


Example Source Code: GitHub

The Rx Team’s blog:

Beginner’s guide to Rx:

Deferred Loading, mind the Visual State Manager

Deferred Loading is a great way to optimize your XAML views. It allows us to lazy load controls that aren’t visible by default, or that are only visible under certain conditions. It is a great technique to optimize the performance and memory usage of your app!

The last few months, I’ve seen some improper usage of this lazy loading, which causes to totally nullify the purpose of deferred loading.

Recap: Deferred Loading

Deferred Loading is a technique in XAML that you can use to reduce the number of elements in your Visual Tree. Typically you might have some elements on your view that are ‘Collapsed’ by default and that only become ‘Visible’ in a particular case. Note that although an item is ‘Collapsed’, it is still present in the Visual Tree of your view and so it needs some processing time when initializing the page and takes up some memory.

With Deferred Loading, we can prevent UIElements from being created and included in our Visual Tree. Therefore, we can save some precious processing power when our page is being initialized.

Although the control's Visibility is set to Collapsed, the control is being created and is part of the Visual Tree. It is not visible, but it's there!

Although the progressRing’s Visibility is set to Collapsed, it is being created and is part of the Visual Tree. It is not visible, but it’s there!


Because of the DeferLoadStrategy, the control isn't being ceated.

Because of the DeferLoadStrategy, the progressRing isn’t being ceated by default.

There are a few possibilities to initialize and load these UIElements at runtime. For exmple the ‘FindName’ method, which is a method of the FrameworkElement class (I really don’t like the name of that method, tbh, but nothing to do about that). When you call this method, you can pass in the name of the control you want to load.

private void Button_Tapped(object sender, TappedRoutedEventArgs e)


if(progressRing == null)


progressRing.Visibility = Visibility.Visible;


Mind you that I said earlier that with this DeferLoadStrategy, the control isn’t being created by default, it is lazy loaded. In other words, after initialization, the control is null. It will only be created when we want it to. So, when I Tap the button after the page is initialized, my progressRing will be null and we can create it using the FindName method, passing in “progressRing” (or using the fancy nameof operator). This will create the ProgressRing control and add it to the Visual Tree.

An other way to initialize controls at runtime, is by using Storyboards or VisualState Setters. When you access a property of a control in a Storyboard or through Visual State Setters, the control itself will be initialized if it hasn’t been created yet. This technique is used very often in scenarios where you want to show a different set of controls depending on, for example, the screensize of your Universal Windows App. And this is where I’ve seen things go wrong…

 What can possibly go wrong?

Imagine we have a Universal Windows App and we want to have a completely different view on a handheld device than on a tablet or desktop.

This is a typical scenario where Deferred Loading is the way to go! We can build our page in XAML for both form factors. With the help of Deferred Loading, we can perfectly decide which UI Elements should be created when or in what scenario. The other elements won’t be loaded into our Visual Tree, preventing them from filling up memory and using unnecessary processing power.
So, at a high level, we have something like this:

high level small

In the Grid named narrowView, we can build up our UI that we will show on a Phone. The wideView Grid will hold the UIElements that we want to display when the user is using the app on a Tablet or Desktop.

In the VisualStateManager of our page, we can now define two Visual State Triggers (one for each formfactor we want to support). These triggers will, depending on the screen size in this case, set the correct Grid visible and therefore initializing it. Therefore, the following code can be written:

VSM bad

The code above, contains something I’ve seen too often.

Although both grids are defined to load lazy, none of these make truly use of it. When accessing a property of a control in the Visual State Manager, the control will be initialized if it isn’t created yet. In the above code sample, look at the ‘wide’ Visual State and notice that we explicitly set the Visibility of the narrowView to ‘Collapsed’. Because we explicitly set the control’s Visibility property, the control is being initialized. Setting the Visibility property of this control to ‘Collapsed’ in the Visual State Manager, totally invalidates the Defer Load Strategy.
Visual Studio’s ‘Live Visual Tree’ delivers us the evidence: we are actually rendering 13 UI Elements that we don’t see or need. Although, looking quickly at the code, we might think we are preventing this by using deferred loading. In this very simple scenario we are rendering more than 35% of excess controls.


Setting the Visibility of the control explicitly to ‘Collapsed’ can be left out, as it already is defined as ‘Collapsed’ in XAML. Take a look at the updated Visual State Manager and its result:

result good

This is what the result should look like in this scenario: on a wide screen, the controls for a narrow screen shouldn’t be created.


If you have a particular control, that must be loaded lazy, make sure you don’t accidentally set unnecessary properties of that control in your Visual State Manager. In a Storyboard or Visual State Setters, settting the value of a property of a control will automatically cause the control to be created.

It is a good reflex for controls that need to be loaded lazy, to set their Visibility to ‘Collapsed’ by default. This ensures that you wouldn’t need to set its Visibility to ‘Collapsed’ in your Visual State Manager which would consequently create a control that is not visible to the user. For controls that should be lazy loaded, the only Visibility you should set in your Visual State Manager, is ‘Visible’.

Ofcourse, this also applies to other properties, not only Visibility. So, to conclude, in your Visual State Manager try to limit accessing properties of lazy loading controls that you don’t need in that particular Visual State.

Starting a blog since 2011…

Since a couple of years, one of my new years resolutions has been: “Starting a blog”. For some reason or another, for all these years, on the 31 December I needed to conclude that this resolution again didn’t make the cut… And why?
Nothing to blog about? Don’t think so. Stage fright? Maybe a tiny bit. No time? That’s probably it! Time…

Now that 2015 is in its final weeks, I realised that, again (!), I didn’t find the time to start blogging. It then sprung to my mind that this year I already did some stuff I didn’t expect in advance: I went to the Microsoft Build Conference, I proposed to my girlfriend, we bought a building plot, … Things I previously wouldn’t have thought about doing this year. So I said to myself: if 2015 is the year of doing crazy stuff or taking some radical decisions, than “Starting a blog” is peanuts so it should definitely be something for this year! I decided to make some time for creating my blog and so here we are!

And so for the year to come, I don’t need to put “Starting a blog’ on the list again, no I just started it! On the list for 2016: “Maintaining a blog”… With a marriage coming up, the construction of our house, I don’t see any reason why this should be so hard…