Blog

From windows to tiles: Contrasting WinRT´s UI framework with WPF – Another case study

A while back, we have published a small case study illustrating our experiences gained in the course of porting an existing WP7-based application to WinRT. As we are continuously growing our competencies regarding WinRT development, we were able to identify a bunch of further differences between WinRT XAML and WPF XAML (as well as Silverlight or Windows Phone 7.X). In this blog post, we want to introduce you to some further prominent differences as well as important characteristics of the WinRT UI Framework that differentiate this API from WPF. Specifically, we will have a look at Bindings, Commands and DependencyProperties.

Bindings

As already suggested in our previous porting case study, the WinRT API´s Binding class ships with rather reduced functionality compared to the implementation as supported by WPF. One characteristic of this limitation is the diminished binding mode enumeration: Windows Store apps support neither OneWayToSource nor Default. Considering the following XAML snippet, the impact of the absence of the latter one becomes obvious:

<!-- WPF: implicitely binds TwoWay --> 
<TextBox Text="{Binding Source={StaticResource ViewModel}, Path=Value}"/>
 
<!-- WinRT: implicitely binds OneWay -->
<TextBox Text="{Binding Source={StaticResource ViewModel}, Path=Value}"/>

As a TextBox generally represents an interface for user input, its Text property´s binding mode is set to TwoWay by default in WPF. As a consequence, a TextBox as defined above will update its underlying view model variable each time its Text property changes. In contrast, in a Windows Store app such a binding declaration on a TextBox´s Text property would be unidirectional (binding mode OneWay implicitely) thanks to the lacking “Default” binding mode and thus does not trigger updates of the bound view model variable. Particularly when porting a WPF-based application to WinRT this characteristic is quite error-prone as we perceive a different behavior by writing the same code. Accordingly, we urge everybody planning to port a WPF app to WinRT to verify if explicit binding mode declarations are defined. Please note, that the binding mode enumeration in the Silverlight/ Windows Phone 7.X API is similar to the WinRT version.

Commands

Our eventual findings concerning Commands in WinRT may be summed up as below:

  1. There are no built-in implementations of the ICommand interface. Being an implementation of this very interface in WPF, the concept of routed commands has not been adopted in the WinRT XAML Framework. Moreover, the WPF counts 161 built-in static RoutedCommand properties (measured in version 4.0) which are not included either.
  2. The ICommandSource interface does not exist anymore.
  3. The only class exposing an ICommand property is ButtonBase. Accordingly, the InputBindings have neither been adopted in the WinRT Framework.

As a consequence, Commands in Windows Store apps feel more similar to Silverlight/ Windows Phone 7.X than they do to WPF. Please note that the statements made above are based on examinations leveraging the respective reflection APIs.

Dependency Properties

Let´s briefly recap the way WPF calculates a dependency property´s value – to compute a dependency property´s actual value, the responsible engine successively runs through the following steps:

  1. Determination of a base value based on precedence rules
  2. Evaluation (if expression)
  3. Appliance of animations
  4. Coercion
  5. Validation

As opposed to this, the WinRT Framework lacks steps (4) and (5) and hence behaves more like Silverlight as well as Windows Phone 7.X in this regard.

Recap + Summary

At the bottom line, we already managed to identify a set of characteristics that distinguish the Windows Presentation Foundation (WPF) from the Windows RT Framework. Recapping and including our previous case study´s outcomes as well, we may reveal the following provisional results:

  1. Different XML namespace declaration
  2. Missing Expression SDK
  3. Missing Property-/Data Triggers
  4. Reduced BindingMode enum
  5. Missing MultiBindings
  6. Missing RoutedCommands
  7. Missing InputBindings
  8. DependencyProperty value calculation goes without coercion and validation

In light of these findings, we may ascertain that the WinRT UI framework is rather guided by Silverlight than by WPF. Recalling the respective frameworks´ target platforms, this correlation appears to be pretty reasonable: both WinRT and Silverlight applications target sandboxed environments providing only a limited set of resources whereas the WPF goes without these boundaries and is consequently capable of implementing a surplus of functionalities.

All trademarks or registered trademarks are properties of their respective owners.

Want to know more about our services, products or our UX process?
We are looking forward to hearing from you.

Corporate Experience Manager
+49 681 959 3110

Before sending your request, please confirm that we may contact you by clicking in the checkbox above.