Centigrade GmbH
Thinking Out of the Box

Philip Schäfer

From windows to tiles: Porting a Windows Phone 7 app to Windows Runtime – A small case study

October 30th, 2012 by Philip Schäfer

I. Setting

To begin with, the application we intended to port as a first get-in-touch with Windows RT (also referred to as Windows Runtime, WinRT) is a small, Windows Phone 7 based soccer game leveraging the mightiness of Silverlight as a subset of the Windows Presentation Foundation (WPF). Therefore, the game´s entire frontend had been designed exclusively using Silverlight XAML and related concepts. Furthermore, the applied architecture strongly follows MVVM (Model-View-ViewModel) principles targeting a strict separation of user interface and application logic. The reason for this is, that the game itself has not been created with the intention of selling it but with the intention of evaluating MVVM in the context of rich graphics and highly dynamic UI states.

Typically, computer games tend to contain various animations ranging from trivial styling of UI elements to complex transitions. Therefore, it would make sense to thoroughly stick to the MVVM pattern to enable designers to do their creative stuff without having to care about any C# code . Usually, the design guys don´t even need to launch a Visual Studio instance, they exclusively need the more design-oriented tool Expression Blend where they can exploit the code provided by their coding colleagues without having to care about the respective implementation details at all (and vice versa).
To carry this clear separation and smooth collaboration to extremes, we intensely utilized Triggers, Actions (of all kinds) and Behaviors.

Being guided by the General Porting Process as specified by Microsoft, we started creating a new, so-called “Windows Store” Project and copied our folders containing code and assets. Please note, that the aforementioned project type specifies a Windows RT (or Modern UI style) application.
Apart from that, please take into account that this article takes the (Developer) Preview as a basis and might apply only partially in future versions of the Windows RT API.

II. Model and View Model Code

After replacing many namespaces, our Model and View Model related C# sources mainly appeared to be fine again. While those namespace issues may be tackled exclusively by backtracking error messages in Visual Studio, Microsoft also provides an interesting overview concerning this matter on MSDN . Except these modified namespace notations we were pleased to observe that data structures as well as established concepts like the PropertyChanged mechanism did not need any alignment at all. Although we ran into some smaller issues i.e. regarding communication with device resources such as sensors, amplifying these topics would be both beyond the scope of this blog post and not that relevant.
In this context we also want to emphasize that our entire code located in the Model and View Model layers could be ported without any considerable effort: an observation that underpins the MVVM pattern´s distinctive advantages. This applies for custom value converters, which may be considered being a part of the glue between View and View Model layer, as well. Amazing, huh?

III. XML Namespaces

Still having some smaller issues in our code we subsequently started to port our XAML. As our View required knowledge about the correlating View Model, we first needed to establish a connection to our C# code by defining an appropriate XML namespace. Therefore, we added an XML namespace GameViewModel:

xmlns:GameViewModel="clr-namespace:SoccerPunch.GameViewModel;assembly=SoccerPunch"

Before Windows RT this would have been correct: defining an XMLNS by specifying both a CLR namespace and, where required, an assembly. Being maybe one of the most conspicuous changes regarding XAML, such a definition is now invalid. Instead, we only need to define the respective namespace – as illustrated on MSDN , the application model and our app package composition will handle both assembly qualification and inclusion. From now on, a valid namespace declaration would look like this:

xmlns:GameViewModel="using:SoccerPunch.GameViewModel"

IV. Bindings

Firstly, the Binding class ships with immensely reduced functionality. Still, the binding implementation as supported by Windows Store apps rather feels like its counterpart in the Windows Phone API than the WPF version. Comparing the WPF´s binding class as supported in version 3.0-4.5 to the WinRT edition, the overall limitation´s extent becomes obvious.

V. Multi Bindings

As already reported in several forums, multi bindings (as provided by WPF) are currently not supported in Windows RT. Admittedly, this feature is neither supported by Windows Phone; sadly, we could not re-use our custom implementation that we used to utilize in WP7. To work around this issue in the context of our migration project, we are currently applying less generalized behavior-based workarounds but do still hope for Microsoft to re-add this important feature in a future version.

VI. Interactivity, Behaviors & Triggers

Generally, Triggers and Behaviors contribute 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 to set 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 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 patterns like MVVM.
Being a mighty tool for scenarios as illustrated above, we were slightly disappointed not to be able to reuse our Behaviors since the “Behavior” concept appears not to be supported natively by Windows RT. Moreover, the System.Windows.Interactivity assembly, which formerly contained Behaviors (amongst others), is missing on Windows RT.
Happily, we found a project on Codeplex bridging this gap by providing a custom Behavior implementation. For the sake of completeness we want to concisely mention the two major issues we came across while applying this project (version 1.0.2):

  1. Since the Behavior super class manually sets its Data Context, we needed to redefine our respective Data Context within Behavior definitions when trying to bind to properties specified therein.
    <Grid DataContext={StaticResource ViewModel} />
     <TextBox>
      <bhv:Interaction.Behaviors>
       <local:MyCustomBehavior Value={Binding Source={StaticResource ViewModel}, 
        Path=Something}/>
      </bhv:Interaction.Behaviors>
     </TextBox>
    </Grid>
  2. Because Behaviors are indeed being attached to but not registered as a child of a Framework Element, they are not part of the Visual Tree and thus can only contain Data Bindings (to CLR objects) but no Element Bindings (specifying an ElementName and a Path).

As already stated in the introductory part, the project we wanted to port also contained a number of Triggers of all kinds – Property Triggers, Data Triggers as well as Event Triggers (particularly, those provided by the Interactivity assembly). Accordingly, we have not been satisfied to observe that Windows RT provides neither Data/ Property Triggers nor the Event Triggers that ship with the Expression Blend SDK. Even though Windows.UI.Xaml provides an Event Trigger, the contained Actions-Property expects BeginStoryboard objects only and therewith behaves like the WPF System.Windows.EventTrigger, disregarding the more powerful EventTrigger implementation as provided by the System.Windows.Interactivity assembly formerly. Due to this restriction, the utilization of customized Triggers and Trigger Actions on the design side becomes impossible. That being said, we deem the available Event Trigger as being rather inflexible.
To our great joy, we were not the first guys to come across this issue and managed to find another Codeplex project providing an EventTrigger similar to the one contained in the former Interactivity assembly 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. As this project appeared to contain much of the commonly needed functionality, we decided to use and extend it.
To facilitate porting and to decrease overhead if Microsoft decides to re-add custom Triggers later-on, we eventually added those Triggers ourselves exploiting the functionality already provided by the WinRT.Triggers.EventTrigger.
As a result, we are now – again – able to use all kinds of custom Triggers when developing Windows Runtime applications.

For the sake of completeness, please note that there is also another Interactivity implementation for Windows RT available on github.

VII. Summary: Key Findings

Neglecting changed namespaces and differences when utilizing sensors, our findings concerning differences between Windows Phone 7 and Windows RT may be summed up as below:

  1. Different declaration of XML namespaces
  2. Missing System.Windows.Interactivity assembly
  3. Missing Property- and Data Triggers
  4. Reduced Binding class (especially compared to WPF)
  5. Missing MultiBindings and MultiValueConverters (compared to WPF only)

One the one hand, there are workarounds available to facilitate the further utilization of functionality as formerly provided by the Interactivity library (i.e. custom Triggers, Trigger Actions, Behaviors etc.). Moreover, we were able to work around the missing multi binding functionality by making use of Behaviors. Thus, porting our Windows Phone 7 app to Windows Runtime so far required only a feasible effort.
On the flipside, we should consider the impact of the absence of concepts like exemplified above, especially regarding an application´s architecture. The concerned functionality is not only beneficial when applying the MVVM pattern but also facilitates a strict separation of responsibilities between UI design and backend development in general. This being the case, we argue that the abovementioned concepts and features strongly contributed to the development of desperately flexible software architectures wherefore their absence is a considerable disadvantage.

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