In a , I outlined the three main jobs of the in order to run a UWP app on iOS, Android, and in the browser: previous article Uno Platform Parse XAML files; Implement data-binding; Implement the suite of views in the for each platform. UWP framework In this article I want to focus on that last point. How does Uno implement UWP’s views? As a case study I’m going to use that humbly ubiquitous UI control, the button. The number goes up I present the simplest interactive application imaginable, one step above ‘Hello World’: XAML: <Page x:Class="UnoExtTestbed.MainPage"xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"xmlns:d="http://schemas.microsoft.com/expression/blend/2008"xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"mc:Ignorable="d"> <StackPanel>   
    <TextBlock x:Name="ClickTextBlock"   
               Text="Button wasn't clicked yet" />   
    <Button Content="Click me"   
            Click="Button\_Click" />   
</StackPanel> </Page> code-behind: using System;using Windows.UI.Xaml;using Windows.UI.Xaml.Controls; namespace UnoExtTestbed{public sealed partial class MainPage : Page{public MainPage(){this.InitializeComponent();} private int \_clickCount = 0;   
    private void Button\_Click(object sender, RoutedEventArgs e)   
    {   
        \_clickCount++;   
        ClickTextBlock.Text = $"Button was clicked {\_clickCount} times.";   
    }   
} } I made a blank app using the and put this code on the main page. Whenever the is clicked, the number goes up. Add a bit more chrome and we could have a . Uno Solution template Button viral hit Note that the XAML is useful here but not obligatory, either on UWP or Uno. We could have defined and created all our views in C#, had we really wanted to. That flexibility is handy to have. Exhibit A — the visual tree Visual tree information for UWP Visual tree information for Android Visual tree information for iOS Visual tree information for WASM So what does that get us? You can see the resulting visual trees on each target platform. They’re all substantially similar. The top-level wrapping varies a little, but inside we can see the , , and we defined in XAML. (The is created in the stock code that comes with the project template.) MainPage StackPanel TextBlock Button Frame App.xaml.cs You might notice there are a couple of extra views inside the that weren't explicitly defined in the XAML. These are part of Button's . If you're not familiar with UWP/WPF/Silverlight/etc's concept of control templating, there's a lot to say about , but the gist of it is that any view which inherits from is a tabula rasa, an empty vessel which will be filled with inner views as defined in its template. (Some of these child views might be templated controls themselves.) It's a powerful means to customise the look of a reusable control. Button default template the subject Control How do we go from a logical tree defined in XAML to a native visual tree? Let’s keep the visual aids rolling. We’ll create an empty class inheriting from , and take a look at its inheritance hierarchy. Button Inheritance chains for the Button class on UWP, Android, iOS, and WASM Like the visual tree, the platform-specific inheritance chains are pretty similar (identical in fact) at the ‘leafward’ end, and diverge a bit at the root. Let’s focus on where they diverge: after the UIElement class, the in UWP. base view type On UWP, inherits from , the base class for types which support data-binding using values. UIElement DependencyObject DependencyProperty In Uno.Android and Uno.iOS, any is an instance of the native base view type ( and respectively, mapped to managed types via the magic of ). So views defined in XAML are also native views. This means, for example, that it's possible to incorporate native views that know nothing about Uno directly into your app's XAML. The following works on iOS: UIElement Android.Views.View UIKit.UIView Xamarin <Page x:Class="UnoExtTestbed.MainPage"...xmlns:uikit="using:UIKit">...<StackPanel><uikit:UILabel Text="Native label"/></StackPanel></Page> This is uniquely easy to do in Uno. We talk about ‘leaving an escape hatch’: the goal is 100% code reuse, but if you positively have to use a platform-specific feature or view library, the flexibility is there. But wait, what about ? DependencyObject Since it’s an important part of the UWP contract, we didn’t want to leave out of the picture, but we also have to be able to support that aren't views at all. ( and , to name just a few.) In Uno therefore is defined as an . It's a 'special' interface however: Uno's code generation automatically adds the backing methods when it finds a class like , allowing code written for UWP to mostly 'just work.' I'll talk more about it in a future article on code generation in Uno. DependencyObject DependencyObjects Brushes Transforms DependencyObject interface MyDependencyObject : DependencyObject In WebAssembly, for now the inheritance hierarchy is a bit simpler and is at the root of the type tree. As you can see in the screenshot, Uno.WASM is generating elements for each view in the visual tree. UIElement <div> Style points The code above nets us a very plain, workaday button, but we could easily spice it up. We set the property to a text string, but can be anything, even another view. Our button could be an , a , or a complex visual hierarchy. It could even have another button inside of it. Content Content image shape What if we want to go in the opposite direction? What if we want to abdicate control over our button’s appearance entirely? A number of controls implemented by Uno, included, support the concept of a 'native' style. Instead of a button that's consistent across all versions of your app, you get a button that looks the way a user of the target platform would expect it to look. Button It’s supported by setting a pre-defined that puts an instance of the native control inside the XAML control. In our code above, we could have written: Style <Button Content="Click me"Click="Button_Click"Style="{StaticResource NativeDefaultButton}" /> Since Android’s default button looks rather similar to UWP’s, I’m going with a more visually obvious illustration using a different control, . I’ll use the from the app. ToggleSwitch sample Uno Gallery Uno’s ToggleSwitch control on Android and iOS, using default and native styles. The with the default style looks the same on all platforms, both statically and in motion. On Android and iOS, however, the with the style replicates the native toggle control of each platform. Of course you can still bind to its properties in XAML as you normally would. This is another powerful option to have: for some apps it makes sense to look as 'native' as possible, for others its desirable to have a rich, customised UI. You may even want to mix and match different approaches for different screens in your app. With Uno it's straightforward. ToggleSwitch ToggleSwitch NativeDefaultToggleSwitch What if I don’t like buttons? In fact implements primitive interaction events like , , etc, so all views in Uno can handle touches/clicks, not just . (The big advantage of using , apart from the MVVM-friendly property, is that it implements to animate your button with.) UIElement PointerPressed PointerReleased Button Button Command visual states There’s plenty more to talk about, like the way that UWP’s API is hooked into each platform’s native input detection, or the way that layouting is done, but that’s all for now. Uno, and if you have any questions. Try out hit us up

Apple

Microsoft

Pushing the right buttons : How Uno implements views — Under the hood

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Introducing Uno WebAssembly Projects and Debugging

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

Introducing Uno WebAssembly Projects and Debugging

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps