Telerik blogs
This is part two of the RadChart for WinRT blog series. For more information please refer to the other parts of the series:
Part one - A Prelude
Part three - Taking its First Breath

 

Now that we have successfully ported our Windows Phone Chart to WinRT I will share some tips and tricks about the whole process and what is different compared to Silverlight and WPF regarding code behind and XAML compilation.

Code behind namespaces

Both logical and visual tree hierarchies of Dependency Objects now reside in new namespaces and the old ones like System.Windows.Controls do not exist. This automatically breaks any existing C#/VB code.


SL/WPF UI namespaces in WinRT are replaced by new ones

The good news is that this problem may be solved by a simple “Replace in files” command for each conflicting namespace. If the codebase is meant to be common (shareable) among different platforms – as in our case – then we may use conditional compilation symbols.


Using conditional compilation we may reuse one codebase among SL/WPF and WinRT

XAML namespaces 

There are changes in the way namespaces are declared in XAML. The SL/WPF way is:

xmlns:local=”namespace:Telerik.Windows.Controls”
Namespaces within the same assembly where the XAML file resides 

xmlns:telerikChart=”namespace:Telerik.Windows.Controls;assembly=Telerik.Windows.Controls.Chart”
Namespaces coming from other assemblies 

The WinRT model does not include the assembly regardless of where the type is coming from (it will look it up from the known types in the Application Domain):

xmlns:telerikChart=”using:Telerik.Windows.Controls”

Although this model is cleaner IMO, it is a breaking change and the bad news is that there is no conditional compilation in XAML so that we cannot reuse same resources targeting both SL/WPF and WinRT. Still, there are solutions – for example a custom pre-build step (or MSBuild task) that processes all XAML files and updates the namespaces.

Dependency Properties 

The signature of registering dependency properties in WinRT is changed. It accepts String rather than Type parameters. This however is most probably a temporary change and the signature will be the same when the framework hits BETA. Still, if you are experimenting with the platform it is good to know how to translate these:


DependencyProperty.Register signature requires string parameters

You have two options here – either update your code property by property or use a helper method that will perform the actual registration:


A helper class that handles the conditional registration of dependency properties

Now you may simply “Replace in files” all occurrences of DependencyProperty.Register with DPExtensions.Register. You may already wonder – why do we need that “magic” with removing the “System” prefix from primitive types. Well, most probably this is a bug in the early bits of WinRT and this bug will go away once the BETA is out – thanks to Morten Nielsen for figuring it out

The OnApplyTemplate method 

Almost each custom control in SL/WPF will override its OnApplyTemplate method and perform additional logic there. In WinRT this method is no longer overridable (virtual). Luckily there is a virtual OnApplyTemplateCore method that does the same job. So, the solution here will be:

 

TypeConverter missing (Oh, no!) 

To my surprise there is no System.ComponentModel.TypeConverter class or any equivalent:

 

Type converters are fundamental building blocks for implementing great user experience. According to Microsoft there is no new alternative to these but they are looking into it (fingers crossed).

Well, these are most of the compilation problems we were facing during the migration. Although this part was pretty straightforward, there were several pitfalls that we step into once we tried to run the chart for the very first time. But I will tell you about these problems in my next post to come – make sure you do not miss it  :)

If you are curios about our RadChart for Windows Phone, part of RadControls for Windows Phone, do not hesitate to give it a try.


Georgi Atanasov 164x164
About the Author

Georgi Atanasov

Georgi worked at Progress Telerik to build a product that added the Progress value into the augmented and virtual reality development workflow.

 

Comments

Comments are disabled in preview mode.