BT

Introducing Common XAML UI

by Jonathan Allen on Apr 02, 2014 |

A constant complaint amongst .NET developers is the myriad of different XAML-based UIs. The problems started with Silverlight, which had a similar but different set of controls than WPF. Silverlight for Windows Phone added a third set, and XAML for WinRT a fourth.

In today’s Build Keynote we heard that Microsoft is finally starting the reconciliation process with the introduction of Common XAML UI. Based on XAML for WinRT, this UI framework will allow the same UI code to be shared on phones, tablets, desktop computers, and eventually Xbox One.

A cornerstone of the Common UI is a new project type called “shared projects”. This is a new concept for Visual Studio and works very differently than portable class libraries. A shared project cannot be independently compiled into a DLL or EXE. Instead it is merged at build time into one or more traditional project types. The traditional projects are informally referred to as “project heads”.

Core primitives such as panels, buttons, and text boxes/buttons will have the same behavior on Windows and Windows phone. Higher level primitives such as Hub, AppBar/CommandBar, date/time pickers, ListView, flyouts, and media will have the same API on both platforms but will behave differently. The Ads SDK will also have a common API signature between the platforms, but again the behaviors will differ.

It should be noted that some features will silently fail. For example, if you have too many buttons in the CommandBar then Windows Phone will only render the first few.

While many of the controls are scalable to different screen sizes, there will be times when you need to tailor the behavior for some devices. One way to accomplish this is through the use of platform specific custom controls. Shared controls can reference these platform specific custom controls so long as a control with the correct name exists in each project head.

Another option for improving code reuse is the use of conditional compilation and #if def in the code-behind. In this sense it is like the classic approach of sharing source code files between projects using soft links.

Resource files, the same that are used for localization, offer a third way to tailor the user experience. The cited example is how command bar buttons are expected to be in lower case on phones and title cased on the desktop.

While most of the APIs are now shared, there are some UI aspects that are not available on all platforms. The most significant ones are:

Windows Only APIs

  • SearchBox
  • Settings Flyout

Windows Phone Only APIs

  • Pivot
  • AutoSuggestBox
  • ContentDialog
  • Maps
  • System Chrome
  • Progress area, in-call UI

The Windows and Windows Phone back button do behave differently, so some custom work around them may be needed. Platform specific code will also be necessary for file pickers, share, and settings.

Common XAML and Universal Apps are available in all versions Visual Studio 2013 Update 2.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Forgot one by Jonathan Allen

There is also Silverlight for Windows Embedded, which is similar to Silverlight 3 but is meant for C++ developers.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT