January 18, 2018

Build 2015 Session Summary: Building UWP Experiences with XAML (Important)



This is another in the series of Build 2015 Summary. The video below is titled: “From the Small Screen to the Big Screen: Building Universal Windows App Experiences with XAML”, posted on Channel 9. Without exaggerating, this is one single most important session of the entire Build 2015 beside the first day keynote. Reason I am saying that is that this video touched and explained the essence of UWP: the adaptive programming (these are my own words). The adaptive concept is, my opinion, sitting at the bottom of Windows 10 experience.

For developers, there are two things: One, runtime Feature Detection, two, Adaptive UI.

Imagine this, you write code, compile it, one binary is put into the Windows Store, you never know what kind of device it is going to be running on. It can be a PC, a phone, a HoloLens, an IoT.  As a developer, you need to keep that in mind. What to do? Answer is feature detection at runtime. I am not sure if there are tools to assist this, but it’s just limited set of things you need to worry about. This video doesn’t go in details on this one, but a lot about adaptive UI.

Adaptive UI is about changing UI elements layout, surface or hide information according to windows size. That’s what the title means from small screen to big screen. How to achieve that? Simply put: SplitView, and RelativePanel. These are two newly added controls in XAML. If you master these two, that’s pretty much all for programming UWP! I am overly simplifying it a little, but it is not far off.

SplitView is so-called hamburger button. Most people hate it, including myself, you can check my writings here. My major complain is it removes the metro elements that everyone loves. Including swipe, automatic animation and fluidity. Rant aside, we live in a world others created for us. Does SplitView work? Yes. That’s good news. SplitView looks like a control, it expends, shrinks as needed. It also acts as a menu. The menu adapts to screen size, or window size to be precise.

RelativePanel is a layout control. It controls how controls inside it flows as windows size changes. What a developer needs to do is to define the positional relationship between the controls inside a RelativePanel, so that when the entire panel change size, some controls move/hide/show but the relationship is maintained. This sounds complicated, but if you follow the general patterns, those patterns can be copied with little change. I think with RelativePanel, they have really figured out how to write one code, run on all screens. It’s not hard to use.

At the bottom of the video, there is a strip showing sections in the video. You can see first big block is the demo of RelativePanel and SplitView. The second big block is a demo of extending VisualState Trigger. This is another way of developing adaptive UI.

I recommend watch this video at least two times if you would. It’s by Tim Heuer, who is a familiar name since Silverlight days, and another speaker, both are good speakers.

By the way, pay attention: Pivot Control is ported from Windows Phone to UWP. The result is good.

>> What you get for free (done automatically)

>Flyout Menu (context menu)

>Pivot Control: pivot control was only available in Windows Phone, now added to Windows 10. Watch how it works at 06:00.

>Scaling happens automatically

>> Easier Responsive UI
>Respond to windows size change using markup
>demo SplitView at 10:30
>and RelativePanel