Shadows in Windows (UWP) XAML Applications – Part 3 – DropShadowPanel

In Part 2 of this series I talked about how to create your own shadow using the DropShadow class. I mentioned that whilst it was easy enough to do, the DropShadow had to be created in code, rather than being applied in XAML. Well the good news is that the team building the Windows Community … Continue reading “Shadows in Windows (UWP) XAML Applications – Part 3 – DropShadowPanel”

In Part 2 of this series I talked about how to create your own shadow using the DropShadow class. I mentioned that whilst it was easy enough to do, the DropShadow had to be created in code, rather than being applied in XAML. Well the good news is that the team building the Windows Community Toolkit say the same issue and have produced the DropShadowPanel which can be used to apply a shadow via XAML.

Let’s again use our two Rectangle series. I’m going to jump straight to the XAML that shows how to use the DropShadowPanel, complete with rounded corners and theme colour support.

<controls:DropShadowPanel BlurRadius="10"
                            ShadowOpacity="1"
                            Color="{ThemeResource ApplicationForegroundThemeColor}"
                            Margin="50"
                            VerticalAlignment="Bottom"
                            HorizontalAlignment="Left"
                            IsMasked="True">
    <Rectangle x:Name="Rectangle2"
                Fill="Turquoise"
                RadiusX="40"
                RadiusY="40"
                Height="200"
                Width="200" />
</controls:DropShadowPanel>

It’s worth noting here that the DropShadowPanel accepts a Color for the shadow, rather than a brush. As such I’ve had to register an additional theme resources.

var foregroundBrush = this.Resources["ApplicationForegroundThemeBrush"] as SolidColorBrush;
Resources["ApplicationForegroundThemeColor"] = foregroundBrush.Color;

And then of course we want to see what this looks like in action.

Note that the DropShadowPanel works in both light (left part of image) and dark (right part of image) themes

One last thing to note before I wrap up this post. You’ll notice in the above XAML that there is an attribute IsMasked that is set to True. This is actually the default value for this property, so could be excluded. However, I wanted to make note of it because it can be toggled to adjust the behaviour of the shadow. For example if I set this attribute to false, we see the following shadow being cast.

Clearly, in this scenario we want to set IsMasked to true so that we get the nice rounded corners in the shadow.

For anyone wanting to quickly apply a shadow in XAML, the DropShadowPanel from the Windows Community Toolkit has you covered.

Shadows in Windows (UWP) XAML Applications – Part 2 – DropShadow

Following Part 1 – ThemeShadow (and Part 1b – Lists) in this post we’re going to look at a very simple example of creating your own shadow. I’m going to reuse my simple example of two overlapping rectangles. The goal is to: Add a shadow around the bottom-left rectangle The shadow should elevate the rectangle … Continue reading “Shadows in Windows (UWP) XAML Applications – Part 2 – DropShadow”

Following Part 1 – ThemeShadow (and Part 1b – Lists) in this post we’re going to look at a very simple example of creating your own shadow. I’m going to reuse my simple example of two overlapping rectangles.

The goal is to:

  • Add a shadow around the bottom-left rectangle
  • The shadow should elevate the rectangle off the background
  • The shadow should elevate the rectangle away from the other rectangle
  • The shadow should handle changing the corner radius to allow for rounded corners
  • The shadow should handle changes to the system theme (i.e. dark mode)

Ok, so let’s see how we can achieve this by creating our own DropShadow. As with the ThemeShadow there are two elements that participate in the creation of the shadow effect. There’s the item casting the shadow (in this case Rectangle2) and then there’s the surface where the shadow needs to be rendered. In this case, since we want the shadow to appear around the edge of Rectangle2, we’re going to create an additional Grid (named Host in the following XAML) that matches the size of Rectangle2:

<Grid Height="400"
        Width="400"
        Loaded="Grid_Loaded"
        HorizontalAlignment="Center"
        VerticalAlignment="Center"
        Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <Rectangle x:Name="Rectangle1"
                Margin="50"
                Height="200"
                Width="200"
                Fill="Turquoise"
                VerticalAlignment="Top"
                HorizontalAlignment="Right" />
    <Grid Margin="50"
            Height="200"
            Width="200"
            VerticalAlignment="Bottom"
            HorizontalAlignment="Left">
        <Grid x:Name="Host" />
        <Rectangle x:Name="Rectangle2"
                    Fill="Turquoise" />
    </Grid>
</Grid>

To create and apply the shadow we’re handling the Loaded event on the parent Grid. The following logic creates the DropShadow, uses Rectangle2 as a mask and then attaches the DropShadow to the SpriteVisual for the Host Grid.

private void Grid_Loaded(object sender, RoutedEventArgs e)
{
    var shadowColor = (Resources["ApplicationForegroundThemeBrush"] as SolidColorBrush).Color;
    var compositor = ElementCompositionPreview.GetElementVisual(Host).Compositor;
            
    // Create the drop shadow
    var dropShadow = compositor.CreateDropShadow();
    dropShadow.Color = shadowColor;
    dropShadow.BlurRadius = 16;
    dropShadow.Opacity = 20.0f;

    // Use the shape of the element (in this case Rectangle2) to 
    // control shape of shadow
    var mask = Rectangle2.GetAlphaMask();
    dropShadow.Mask = mask;
            
    // Set the shadow on the visual
    var spriteVisual = compositor.CreateSpriteVisual();
    spriteVisual.Size = new Vector2((float)Host.ActualWidth, (float)Host.ActualHeight);
    spriteVisual.Shadow = dropShadow;
    ElementCompositionPreview.SetElementChildVisual(Host, spriteVisual);
}

The result of this is shown in the following image

Now let’s try rounding the corners of Rectangle2

<Rectangle x:Name="Rectangle2"
            Fill="Turquoise"
            RadiusX="40"
            RadiusY="40" />

Here’s how it looks

This is looking really nice but what about the dark mode support?

Even in dark mode, we’re still seeing the shadow being cast both against the background but also on Rectangle1. Going back to the XAML and code that creates this effect, it’s important to note that the background is set using the ApplicationPageBackgroundThemeBrush and that the color that’s set for the shadow is based on the ApplicationForegroundThemeBrush. Both these brushes are theme aware, meaning that as the device switches between light and dark mode, the brushes have the appropriate color. This means that there’s little else we need to do in order to support dark mode when creating the shadow.

The upshot of creating a shadow this way is that it’s relatively straight forward but does require custom logic to be written – this is less than ideal if you want to apply shadows easily in xaml for example.

In subsequent posts we’ll look at other options for applying shadows that hopefully will mean less custom code.

Shadows in Windows (UWP) XAML Applications – Part 1b – ThemeShadow in Lists

Originally, I had planned that the next post was going to talk about making use of the Shadow property and creating a custom shadow. However, following part 1 there was a bit of dialog online talking about the use of shadows in lists. I figured that it shouldn’t be too hard to extend my example … Continue reading “Shadows in Windows (UWP) XAML Applications – Part 1b – ThemeShadow in Lists”

Originally, I had planned that the next post was going to talk about making use of the Shadow property and creating a custom shadow. However, following part 1 there was a bit of dialog online talking about the use of shadows in lists. I figured that it shouldn’t be too hard to extend my example to use the ThemeShadow for items in a list.

Let’s start with a simple list of 1000 items which we’ll be displaying using a ListView – I’m sure there’s a better way to generate random list items but I was just hacking around, so didn’t feel like engineering anything more fancy.

public IList<string> StaticItems { get; } = BuildStaticItems();

private static List<string> BuildStaticItems()
{
    var list = new List<string>();
    const int max = 1000;
    for (int i = 0; i < max; i++)
    {
        list.Add($"{max} items - {i}");
    }
    return list;
}

Next up we need the XAML layout for the ListView:

<Grid x:Name="RootGrid">
    <Grid x:Name="ParentBackgroundGrid" />

    <ListView ItemContainerStyle="{StaticResource ThousandItemContainerStyle}"
                ItemsSource="{x:Bind StaticItems}">
        <ListView.ItemTemplate>
            <DataTemplate x:DataType="x:String">
                <TextBlock Text="{x:Bind }"
                            Margin="6" />
            </DataTemplate>
        </ListView.ItemTemplate>
    </ListView>
</Grid>

There are a couple of things to note here:

  • The ItemsSource is bound to the StaticItems property from the previous code block
  • The ItemTemplate is just a simple TextBlock with a Margin set to indent the text from the edge of the item template.
  • There is a ParentBackgroundGrid priors to the ListView which will render beneath the ListView and will be the surface where the shadows are rendered onto.
  • Lastly this snippet defines an ItemContainerStyle called ThousanItemContainerStyle which we’ll go into more detail in a sec.

Note that in this XAML we haven’t defined either an instance of the ThemeShadow and we haven’t set a background on the items in the list. These will both be defined as part of the ItemContainerStyle, so that we can take advantage of the visual states to adjust the elevation (i.e. the Z axis translate), and thus the shadow cast.

Ok, so here’s the ItemContainerStyle.

<Style x:Key="ThousandItemContainerStyle"
        TargetType="ListViewItem">
    <Setter Property="Padding"
            Value="6" />
    <Setter Property="HorizontalContentAlignment"
            Value="Stretch" />
    <Setter Property="VerticalContentAlignment"
            Value="Stretch" />
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="ListViewItem">
                <Grid x:Name="Root">
                    <VisualStateManager.VisualStateGroups>
                        <VisualStateGroup x:Name="CommonStates">
                            <VisualState x:Name="Pressed">
                                <VisualState.Setters>
                                    <Setter Target="ContentBackground.Elevation"
                                            Value="0" />
                                </VisualState.Setters>
                            </VisualState>
                            <VisualState x:Name="PressedSelected">
                                <VisualState.Setters>
                                    <Setter Target="ContentBackground.Elevation"
                                            Value="0" />
                                </VisualState.Setters>
                            </VisualState>
                        </VisualStateGroup>
                    </VisualStateManager.VisualStateGroups>
                    <local:ItemBackground Elevation="32"
                                            x:Name="ContentBackground"
                                            ContentPadding="{TemplateBinding Padding}" />
                    <ContentPresenter Margin="{TemplateBinding Padding}" />
                </Grid>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Things to note:

  • I’ve removed a significant portion of the default ItemsContainerStyle you would normally get when you clone the built-in style. What I’m left with is a basic ContentPresenter element and a new UserControl of type ItemBackground.
  • ItemBackground has an initial Elevation of 32 but this property is adjusted when the user presses the button to control the elevation (see the Pressed and PressedSelected visual states), and thus the amount of shadow.

Of course, now we need to look at the ItemsBackground class so we can understand how it’s generating the shadow for each item. The XAML for the ItemBackground UserControl is similar to what we had in my previous post – a root Grid which defines the ThemeShadow resource and includes a Rectangle which is the background of the item. It’s the Rectangle that has the Shadow property set and will be generating the shadow that is to be cast.

<UserControl
    x:Class="ShadowTest.ItemBackground"
    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">
    <Grid Loaded="RootLoaded">
        <Grid.Resources>
            <ThemeShadow x:Name="SharedShadow" />
        </Grid.Resources>
        <Rectangle x:Name="Rectangle2"
                   Fill="Turquoise"
                   Margin="{x:Bind ContentPadding, Mode=OneWay}"
                   Shadow="{StaticResource SharedShadow}" />
    </Grid>
</UserControl>

We’re intercepting the Loaded event on the Grid in order to connect the ThemeShadow with the corresponding Grid to be the receiver for the shadow (in this case the Grid is the ParentBackgroundGrid defined on the page). Note that this logic could definitely be improved. It steps up the visual tree from the current item (i.e. the Grid in the ItemTemplate) all the way up to the Grid defined on the page called RootGrid.

private void RootLoaded(object sender, RoutedEventArgs e)
{
    var parent = VisualTreeHelper.GetParent(this);
    while (parent != null)
    {
        if(parent is Grid grid)
        {
            if(grid.Name == "RootGrid")
            {
                var bg = grid.Children.FirstOrDefault(x => x is Grid g && g.Name == "ParentBackgroundGrid");
                SharedShadow.Receivers.Add(bg);
                return;
            }
        }
        parent = VisualTreeHelper.GetParent(parent);

    }
}

Again, remembering that we can’t specify a ancestor as a Receiver for the shadow. Instead we’re going to find the first child element with the name ParentBackgroundGrid. This Grid will then be set as a Receiver for the ThemeShadow.

As we want to be able to adjust the Z axis translate when the user presses on the item in the list, we need to expose a mechanism whereby the ItemContainerStyle can simply set a property in the visual state definition. We need to define two dependency properties: ContentPadding, which determines the inset of content, and Elevation, which will determine the z translate value.

public Thickness ContentPadding
{
    get { return (Thickness)GetValue(ContentPaddingProperty); }
    set { SetValue(ContentPaddingProperty, value); }
}

public static readonly DependencyProperty ContentPaddingProperty =
    DependencyProperty.Register("ContentPadding", typeof(Thickness), typeof(ItemBackground), new PropertyMetadata(new Thickness(0)));

public int Elevation
{
    get { return (int)GetValue(ElevationProperty); }
    set { SetValue(ElevationProperty, value); }
}

public static readonly DependencyProperty ElevationProperty =
    DependencyProperty.Register("Elevation", typeof(int), typeof(ItemBackground), new PropertyMetadata(0, ElevationChanged));

private static void ElevationChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
    (d as ItemBackground).ChangeElevation((int)e.NewValue);
}

private void ChangeElevation(int newValue)
{
    Rectangle2.Translation = new Vector3(0, 0, newValue);
}

Let’s give this a run – the following image shows the list of items with the shadow appearing for each item. The only difference between the left and right sides is that in the list on the left side, the item “1000 items – 3” has been pressed.

What’s interesting about applying the shadow to the list of items is that the items almost appear to have rounded corners, in addition to the apparent elevation from the background.

The code in this blog post is very raw and I’ve no doubt there is a way to abstract the various steps to make it easier to define and connect the ThemeShadow with the shadow receiver.

Shadows in Windows (UWP) XAML Applications – Part 1 – ThemeShadow

I’ve been watching James Montemagno bring his AnimalCrossing app to life. The progress continues: #AnimalCrossing Turnip Tracking App powered by #Xamarin and amazing library creators. 99.9% shared code 🙂 pic.twitter.com/7CSlmk6nCJ — James Montemagno – 🔴 Live on Twitch (@JamesMontemagno) April 11, 2020 What’s super impressive is that this doesn’t look anything like a regular out … Continue reading “Shadows in Windows (UWP) XAML Applications – Part 1 – ThemeShadow”

I’ve been watching James Montemagno bring his AnimalCrossing app to life.

What’s super impressive is that this doesn’t look anything like a regular out of the box Xamarin.Forms application. The use of custom fonts, curves, rounded corners and shadows gives this app its own unique look. Unfortunately, it would appear that some of the libraries used aren’t supported on Windows (UWP).

This got me thinking about the use of shadows in UWP, which lead to me sinking time into investigating what is and isn’t support. In this series of posts I’ll walk through some of the options.

Built-in Shadows

Before we get into adding our own shadows to elements in our application, it’s worth noting that UWP already comes with a lot of built-in shadow support. The guidance with regards to using shadows in UWP is that “shadows should be used in a purposeful rather than aesthetic manner”. As such, the built-in shadows appear on elements such as popups and tooltips but don’t appear gratuitously on every list item. For example, the following tooltip has a shadow that makes it appear elevated in relation to the rest of the content.

Dark Mode

I also wanted to see what support there was for dark theme. After switching my Windows theme to dark mode it was evident that there isn’t really any support for shadows. For example, here’s the same tooltip in dark mode.

Whilst there is still some illusion of elevation, this predominately comes from the border that’s been added to the tooltip, rather than an actual shadow. There is definitely no visible shadow around the sides and top of the tooltip, like there is in the light theme.

Now you might be saying “well duh, there is a shadow, you just can’t see it on the black background”. To which, my response is that a shadow, when it comes to applications, is much less about a shadow cast by a light hitting and object, and much more about the illusion of elevation and vertical separation of elements (as described by the Microsoft documentation on Z-depth). As such, even in dark mode you’d expect to see some shadow that illustrates a vertical separation of elements.

WinUI 3

Before we move on, I thought I’d take a quick look at whether there are any difference with regards to shadows in WinUI 3 (grab the WinUI 3 templates to get started). The following image shows the exact same button and tooltip combination, this time using the controls from WinUI 3.

Note that other than a change to the shape and border on the tooltip, there’s really no difference to the shadow cast by the tooltip. The behaviour in dark mode it basically the same too. Although I must admit, do like the new look tooltip with the slightly rounded corners and more gradient border, more than the standard UWP look.

Shadows using ThemeShadow

Whilst support for shadows has been around for quite a while for UWP applications, it was only recent that the ThemeShadow class was added (Windows 10, version 1903 – v10.0.18362.0), making it easier for developers to add shadow support to their applications. To demonstrate this in action, we’ll use a rather contrived example of two overlapping Rectangles, as defined in the following XAML.

<Grid>
    <Rectangle x:Name="Rectangle1"
                Height="200"
                Width="200"
                Fill="Turquoise"
                VerticalAlignment="Top"
                HorizontalAlignment="Right" />
    <Rectangle x:Name="Rectangle2"
                Height="200"
                Width="200"
                Fill="Turquoise"
                VerticalAlignment="Bottom"
                HorizontalAlignment="Left" />
</Grid>

Running this example we can see that both Rectangle shapes appear as one connected shape, flat against the white background. We’ll use a ThemeShadow to elevate the Rectangle2 (bottom left) off the background, and provide some separation from Rectangle1 (top right).

We’ll start by creating a ThemeShadow instance as a Resource with the name SharedShadow. This will be set as the Shadow property on Rectangle2.

<Grid>
    <Grid.Resources>
        <ThemeShadow x:Name="SharedShadow" />
    </Grid.Resources>
    <Grid x:Name="BackgroundGrid" />
    <Rectangle x:Name="Rectangle1"
                Height="200"
                Width="200"
                Fill="Turquoise"
                VerticalAlignment="Top"
                HorizontalAlignment="Right" />
    <Rectangle x:Name="Rectangle2"
                Height="200"
                Width="200"
                Fill="Turquoise"
                VerticalAlignment="Bottom"
                HorizontalAlignment="Left" 
                Shadow="{StaticResource SharedShadow}" />
</Grid>

Note that creating this resource and setting the Shadow property, creates the shadow but it won’t display until you tell the application what elements should show the shadow. This is done by adding elements to the Receivers collection on the ThemeShadow resource.

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);

    SharedShadow.Receivers.Add(BackgroundGrid);
}

It’s important to note here that you can’t add an ancestor of the element casting the shadow to the Receivers collection. This seems rather counter-intuitive since you’d quite often want the shadow to appear on the background behind the element casting the shadow (which would typically be the parent grid or panel). However, it’s also easy to solve – in the above XAML a Grid called BackgroundGrid was added on which the shadow can be cast.

Even after doing all this, if you run this example you still won’t see a shadow. This is because all the elements are all technically at the same elevation (i.e. they have the same Z axis value of 0) so there is no shadow to be cast. To fix this, we simply need to translate Rectangle2 in the Z dimension.

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);

    SharedShadow.Receivers.Add(BackgroundGrid);	
    Rectangle2.Translation += new Vector3(0, 0, 32);
}

Now we’re getting somewhere. The following image shows a shadow around Rectangle2. However, it still shows the two rectangles as being a single shape.

The reason there is no shadow being shown on Rectangle1 is that we haven’t told the application that it should show the shadow there. As before, the fix for this is to add Rectangle1 to the Receivers list of the ThemeShadow resource.

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);

    SharedShadow.Receivers.Add(BackgroundGrid);	
    SharedShadow.Receivers.Add(Rectangle1);
    Rectangle2.Translation += new Vector3(0, 0, 32);
}

And there we have it – a shadow appearing on all sides of Rectangle2.

Of course, we couldn’t just leave it there as I’m sure you’re all wondering what happens in dark mode. Well, there’s good and bad news, as you can see in the following image.

The good news is that the shadow is still being created (see between the rectangles). The bad news is that the shadow hasn’t been inverted with the theme, meaning that you can’t see the shadow against the black background. This is seriously frustrating as it makes the ThemeShadow kind of pointless – it’s main premise was that it was suppose to handle everything for the developer.

Rounded Corners

Updated: I’d forgotten to add this last section on rounded corners in the initial post.

Going back to the designs that James had in the app he’s working on, the items all have rounded corners, giving it a softer, more casual look and feel. To do this in my simple example is relatively easy as I can just set the RadiusX and RadiusY properties.

<Rectangle x:Name="Rectangle2"
            Margin="50"
            Height="200"
            Width="200"
            Fill="Turquoise"
            VerticalAlignment="Bottom"
            HorizontalAlignment="Left"
            RadiusX="40"
            RadiusY="40"
            Shadow="{StaticResource SharedShadow}" />

But what happens to my shadow? Well, the answer is nothing good, as you can see from the following image

In addition to not being able to handle dark mode, it also appears that the ThemeShadow can’t handle non-square corners. According to the documentation, there’s also no support color. Overall the ThemeShadow is severely limited in the scenarios that it would be useful for.

Next up we’ll take a more in depth look at the Shadow property in UWP and how you can implement a shadow yourself.

Dual Screens with Surface Neo (Windows 10X) and Surface Duo (Android)

In October 2019 Microsoft announced a new category of dual screen device with flagship products Surface Neo and Surface Duo. Since then, there has been a massive undertaking by Microsoft to prepare developers of both Windows (UWP and Win32 apps) and Android apps for a new world of dual, or even multiple, screen devices. This … Continue reading “Dual Screens with Surface Neo (Windows 10X) and Surface Duo (Android)”

In October 2019 Microsoft announced a new category of dual screen device with flagship products Surface Neo and Surface Duo. Since then, there has been a massive undertaking by Microsoft to prepare developers of both Windows (UWP and Win32 apps) and Android apps for a new world of dual, or even multiple, screen devices. This included a day focused on building dual screen applications – Microsoft 365 Developer Day: Dual Screens (and here) (this event in itself was weird because it was branded as Microsoft 365 but other than a session on Microsof Graph it had very little to do with Microsoft 365 and everything to do with Windows and Android SDKs for dual screen devices). In this post I wanted to start exploring the dual screen emulators and talk about some points of interest when it comes to interacting with the screens.

Firstly, if you haven’t already, you can grab the emulator images either from the Microsoft Store (for the Windows 10X emulator) or via the Surface Duo SDK. Start at the documentation page for how to Get the Windows 10X development tools and how to Get the Surface Duo SDK.

Now that you’ve got the tools, let’s start to take a look at the emulators. Specifically I want to drill into how the different platforms handle spanning an application across the fold/hinge. The following image shows an image being spanned across the hinge on the Windows 10X emulator.

Notice how there’s a break in the image, making the image feel like it’s broken in two. What’s interesting is that when you take a screenshot using the emulator tools, this break isn’t visible, as shown in the following screenshot.

If we us the Maps application and again span the hinge, there is again a break across the hinge, making the map hard to process visually.

If we switch across to the Android emulator, you can now see that the image spans across the hinge without disturbing the image. The hinge masks or obscures part of the picture, but this is much easier for us to deal with.

And again, using the Android emulator you can see that the map continues beneath the hinge.

Ok, so let’s jump into taking a look at some code. In this case we’re going to look at some UWP code but rather than attempting to treat the two screens as a single page (as shown in soooooo many demos/samples) we’re going to use multiple windows for the application. Into a new UWP application I’ve added a Button and a TextBlock (just to show which window is which). The Button is used to launch new Windows, each showing the MainPage.

private async void Button_Click(object sender, RoutedEventArgs e)
{
    CoreApplicationView newView = CoreApplication.CreateNewView();
    int newViewId = 0;
    await newView.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
    {
        Frame frame = new Frame();
        frame.Navigate(typeof(MainPage), null);
        Window.Current.Content = frame;
        // You have to activate the window in order to show it later.
        Window.Current.Activate();

        newViewId = ApplicationView.GetForCurrentView().Id;
    });
    bool viewShown = await ApplicationViewSwitcher.TryShowAsStandaloneAsync(newViewId);
}

When I first run this, I can see my application taking up a single screen.

Clicking the button the second Window appears on the other screen – this is exactly what you’d hope would happen.

If we now press the button on the second Window, another new Window appears, again on the alternative screen.

Now we can start to arrange the Windows. Here I’ve dragged Window 3 into the lower right corner of the second screen, below Window 2. (ignoring the mouse cursor, which was a result of me attempting to screen capture the drag experience) You can see that there is a visual cue as to what will happen when I release the drag operation.

Window 3 expands to take the lower half of the second screen and prompts me to select what I want to take the top half.

Clicking on Window 2 it expands to fill the top half of the screen.

What’s interesting about this example, which uses Multiple Windows instead of dual panes or a single Window that spans the hinge, is that you get complete control over how the individual windows are positioned. The default behaviour works nicely with Windows appearing in the correct screen, yet you can easily override it by dragging the windows to where you want them.

Along the way (probably because so many apps are modeled on the iOS notion of only doing one thing at a time) we as app developers have forgotten how to take advantage of multiple Windows. Now is the time to think about how best to extend your application to use multiple windows and prepare it for the next wave of multi-screen devices.

Pipeline Templates: Runtime Parameters in Azure DevOps Pipelines

It appears that the Runtime Parameters of Azure DevOps Pipelines has rolled out to most organisations. As such I thought it important that the Pipeline Templates are updated to use strongly typed boolean parameters. For example in the following YAML taken from the Windows Build template has a parameter, build_windows_enabled, which is typed as a … Continue reading “Pipeline Templates: Runtime Parameters in Azure DevOps Pipelines”

It appears that the Runtime Parameters of Azure DevOps Pipelines has rolled out to most organisations. As such I thought it important that the Pipeline Templates are updated to use strongly typed boolean parameters. For example in the following YAML taken from the Windows Build template has a parameter, build_windows_enabled, which is typed as a boolean.

parameters:
# stage_name - (Optional) The name of the stage, so that it can be referenced elsewhere (eg for dependsOn property). 
# Defaults to 'Build_Windows'
- name: stage_name
  type: string
  default: 'Build_Windows'
# build_windows_enabled - (Optional) Whether this stages should be executed. Note that setting this to false won't completely
# cancel the stage, it will merely skip most of the stages. The stage will appear to complete successfully, so
# any stages that depend on this stage will attempt to execute
- name: build_windows_enabled
  type: boolean
  default: true

Previously, the parameters were passed in using variables defined in the main pipeline. The issue with this is that all variables are strings, so there’s no checking that a valid value has been passed in. For example:

Now we have the option of defining runtime parameters. These are parameters that are defined in the main pipeline yml file (ie not in a template). In the following example there are three runtime parameters defined; all boolean; all with a default value of true.

When we manually run this pipeline we’re now presented with a user interface that allows the user to adjust these runtime parameters, before hitting Run.

Another useful feature in the Run dialog is the Resources section

The Resources section lists referenced templates.

Clicking through on a template allows the user to adjust what version of the template to use. This is particularly useful if you are testing a new version of a template because you can Run a build referencing a different version, without making (and committing) a change to the actual pipeline.

Pipeline Templates v0.6.0

Here’s a summary of what’s in release v0.6.0:

Breaking Changes:

  • build-xamarin-[iOS/android/windows].yml and deploy-appcenter.yml – XXX_enabled parameter (eg windows_enabled or deploy_enabled) are now strongly typed as boolean parameters. This means you need to supply either a literal value (eg true or false) or a parameter. Use runtime parameters instead of pipeline variables to ensure values are strongly typed as boolean.

Other Changes:

  • none