{"id":3728,"date":"2013-03-19T12:00:25","date_gmt":"2013-03-19T10:00:25","guid":{"rendered":"http:\/\/www.centigrade.de\/blog\/en\/?p=3728"},"modified":"2020-01-25T19:42:51","modified_gmt":"2020-01-25T18:42:51","slug":"from-windows-to-tiles-contrasting-winrts-ui-framework-with-wpf-another-case-study","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/en\/blog\/from-windows-to-tiles-contrasting-winrts-ui-framework-with-wpf-another-case-study\/","title":{"rendered":"From windows to tiles: Contrasting WinRT\u00b4s UI framework with WPF \u2013 Another case study"},"content":{"rendered":"

A while back, we have published a small case study<\/a> 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.
\n<\/p>\n

Bindings<\/h3>\n

As already suggested in our previous porting case study<\/a>, the WinRT API\u00b4s 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<\/a> support neither OneWayToSource nor Default. Considering the following XAML snippet, the impact of the absence of the latter one becomes obvious:<\/p>\n

<!-- WPF: implicitely binds TwoWay --><\/span> \r\n<<\/span>TextBox<\/span> Text<\/span>=\"{Binding Source={StaticResource ViewModel}, Path=Value}\"<\/span>\/><\/span>\r\n \r\n<!-- WinRT: implicitely binds OneWay --><\/span>\r\n<<\/span>TextBox<\/span> Text<\/span>=\"{Binding Source={StaticResource ViewModel}, Path=Value}\"<\/span>\/><\/span>\r\n<\/pre>\n
As a TextBox generally represents an interface for user input, its Text property\u00b4s 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\u00b4s Text property would be unidirectional (binding mode OneWay implicitely) thanks to the lacking \u201cDefault\u201d 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.<\/p>\n
Commands<\/h3>\n
Our eventual findings concerning Commands in WinRT may be summed up as below:<\/p>\n
    \n
  1. There are no built-in implementations of the ICommand <\/a>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.<\/li>\n
  2. The ICommandSource <\/a>interface does not exist anymore.<\/li>\n
  3. The only class exposing an ICommand property is ButtonBase<\/a>. Accordingly, the InputBindings<\/a> have neither been adopted in the WinRT Framework.<\/li>\n<\/ol>\n
    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<\/a>.<\/p>\n
    Dependency Properties<\/h3>\n
    Let\u00b4s briefly recap the way WPF calculates a dependency property\u00b4s value<\/a> \u2013 to compute a dependency property\u00b4s actual value, the responsible engine successively runs through the following steps:<\/p>\n
      \n
    1. Determination of a base value based on precedence rules<\/a><\/li>\n
    2. Evaluation (if expression)<\/li>\n
    3. Appliance of animations<\/li>\n
    4. Coercion<\/li>\n
    5. Validation<\/li>\n<\/ol>\n
      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.<\/p>\n
      Recap + Summary<\/h3>\n
      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<\/a>\u00b4s outcomes as well, we may reveal the following provisional results:<\/p>\n
        \n
      1. Different XML namespace declaration<\/li>\n
      2. Missing Expression SDK<\/li>\n
      3. Missing Property-\/Data Triggers<\/li>\n
      4. Reduced BindingMode enum<\/li>\n
      5. Missing MultiBindings<\/li>\n
      6. Missing RoutedCommands<\/li>\n
      7. Missing InputBindings<\/li>\n
      8. DependencyProperty value calculation goes without coercion and validation<\/li>\n<\/ol>\n
        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\u00b4 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.<\/p>\n
        All trademarks or registered trademarks are properties of their respective owners.<\/span><\/p>\n","protected":false},"author":29,"featured_media":0,"template":"","tags":[191,189,208,210,212,214,44,192,40],"class_list":["post-3728","blog","type-blog","status-publish","hentry","tag-migration","tag-windows-8","tag-windows-rt","tag-winrt","tag-winrt-vs-silverlight","tag-winrt-vs-wpf","tag-wpf","tag-wpf-vs-rt","tag-xaml"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/en\/wp-json\/wp\/v2\/blog\/3728","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/en\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/en\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/en\/wp-json\/wp\/v2\/users\/29"}],"version-history":[{"count":0,"href":"https:\/\/www.centigrade.de\/en\/wp-json\/wp\/v2\/blog\/3728\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/en\/wp-json\/wp\/v2\/media?parent=3728"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/en\/wp-json\/wp\/v2\/tags?post=3728"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}