Introduction
Already introduced in the context of Windows Phone, Microsoft's "Modern UI" paradigm dictating flat, content-oriented designs experienced a renaissance in the course of the launch of the Windows RT and Windows 8 operating systems. It
would not be accurate to say that the "Modern UI" design language had been temporarily dead - but it is thoroughly legit to tell that it experienced a considerable increase in awareness due to the new operating systems’ release. The application of related concepts on well-known websites such as YouTube or MySpace underpins the emerging impact of the "Modern UI" language remarkably.
Facing the undeniable significance of WinRT (respectively, the technology behind Windows Store Apps) in terms of establishing "Modern UI" as a recognized design language, the WinRT's UI API comes into focus: How does it feel to implement a Windows Store App GUI? Can we apply the same functions and concepts as we used to in the WPF? And how is the WinRT's UI API related to the Silverlight API? In this article we are going to successively examine differences between the WPF, Silverlight as well as the WinRT's UI framework in order to eventually get a feel for this new technology. Please note that we are going to consider API-relevant aspects only. Speaking of API-relevant aspects: We are talking about the Windows RT API here. But what does this mean with regard to this article's target audience? Well, this simply means that we may utilize the discussed functionality from within C#, VB, C++ (in combination with XAML) as well as from within JavaScript (together with HTML and CSS). In a nutshell, regardless of being a web developer or being a Desktop application programmer: the WinRT API applies to all of us!
The Windows RT UI framework from a WPF developer's point of view
Changes to the XAML syntax itself: XML namespace definitions
Being maybe one of the most prominent aspects that distinguish WinRT XAML from WPF or Silverlight XAML, the significantly differing XML namespace definition syntax is one of the first peculiarities to come across when developing a Windows Store App. Therefore, let's firstly consider how we may define an XMLNS using WPF, Silverlight or Windows Phone:
xmlns:mns="clr-namespace:MyNamespace;assembly=MyAssembly"
Before Windows RT this would have been correct: defining an XMLNS by specifying both a CLR namespace and, where required, an assembly. In Windows Store Apps, however, we don't build our applications upon the CLR – wherefore it makes sense, that such a syntax is now invalid. Instead, we can now use the prefix "using" to introduce our runtime namespace. Apart from that, we don't require to define any assembly name as the containing assembly will be determined automatically (as illustrated
here). From now on, a valid namespace declaration would look like this:
xmlns:mns="using:MyNamespace"
This obvious change in XML namespace resolution implies that the mapping of identical namespace names from different assemblies within the same XAML scope is no more possible in Windows Store Apps.
SDK support: The Expression SDK
Generally, functionality provided by the Expression SDK contributes to a stricter separation of responsibilities between UI and application logic. It's a Designer's task to design and implement impressive "Look & Feels": On the one hand, he/she may utilize Control Templates and Styles in Expression Blend (or the new Blend for Visual Studio 2012) to define the right "Look". On the other hand, we may consider more complex requirements with regard to the "Feel" that require real coding. As Triggers and Behaviors (parts of the Expression SDK) facilitate the implementation of such "Feels" in the backend and their subsequent utilization on design-side, we argue that these concepts are of utmost importance when designing systems following designer-developer-collaboration-friendly patterns like MVVM. Above all, because of these concepts, Expression Blend and the Expression SDK are great tools for designers to create hi-fidelity prototypes that can be partially migrated to
the real product.
Being a mighty tool for scenarios as illustrated above, we were slightly disappointed not to find a WinRT compatible version of the Expression SDK.
Happily, we found two projects on CodePlex that are worth having a closer look at:
- WinRtBehaviors provides a custom Behavior implementation
- WinRtTriggers provides an
EventTrigger
similar to the one contained in the Expression SDK as well as a GoToStateAction, an
InvokeCommandAction, a ControlStoryboardAction plus the required super types to derive from (i.e. when implementing one's own Trigger or Trigger Action) and other related classes.
For the sake of completeness, please note that there is also another Interactivity implementation for Windows RT available on github.
Remarkably, at the time of writing, WinRT is the only platform within the current eco system of UI frameworks from the house of Microsoft (WPF, Silverlight, Windows Phone) that does not support the Expression SDK.
Triggers
Similar to Silverlight, Microsoft did not adopt the concepts of Property and Data Triggers in the WinRT API. Please note, that this gap may be bridged by utilizing the custom trigger implementation as already mentioned in section "SDK Support: The Expression SDK" as well.
Data Bindings
The WinRT API ships with a noticeably diminished binding mode enumeration: Windows Store apps support neither OneWayToSource nor Default. Considering the following XAML snippet, the impact of the absence ofthe latter one becomes obvious:
<TextBlock Text={Binding Source={StaticResource ViewModel), Path=Value}/>
<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
TextBlock as defined above will update its Text property each time the corresponding
TextBox's
Text property changes (since they are both bound to the same variable).
In contrast, in a Windows Store app such a binding declaration on a
TextBox's Text property would be unidirectional (binding mode OneWay
implicitly) 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.
In addition to that, both Multi and Priority Bindings are not supported by the WinRT API as well.
Please note, that the binding mode enumeration as well as the lacking support of Multi/Priority Bindings in the RT API is similar to the Silverlight/ Windows Phone APIs.
Commands
Our eventual findings concerning Commands in WinRT may be summed up as below:
- 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. Consequently, the WPF's 161 built-in static RoutedCommand properties (introduced in version 4.0) are not included as well.
- The ICommandSource interface does not exist any more.
- 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 capabilities.
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:
- Determination of a base value based on precedence rules
- Evaluation (if expression)
- Appliance of animations
- Coercion
- 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.
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 our findings we may reveal the following provisional results:
- Different XML namespace declaration in XAML code
- Missing Expression SDK
- Missing Property-/DataTriggers
- Reduced
BindingMode enum
- Missing Multi/Priority Binding
- Missing RoutedCommands
- Missing InputBindings
- 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.
Apart from that, we should become aware of the fact that Microsoft did not just customize an existing framework – instead, they found an entirely novel platform exposing pretty the same functionality as Silverlight to a whole bunch of popular programming languages. Particularly by including an interface to JavaScript/HTML, Microsoft explicitly addresses a different type of potential app developers that have not necessarily been concerned with the Microsoft ecosystem before.
Further reading
