Responsive Helpers

[kazo0]

The Problem

There is currently no clean and concise way to handle responsive layouting with XAML. The main way of accomplishing this is through Visual States and AdaptiveTriggers.

For example, changing simple properties on a control based on window width would look something like this:

<Page ...>
    <Grid>
        <VisualStateManager.VisualStateGroups>
            <VisualStateGroup>
                <VisualState>
                    <VisualState.StateTriggers>
                        <!-- VisualState to be triggered when the
                             window width is >=640 effective pixels. -->
                        <AdaptiveTrigger MinWindowWidth="640" />
                    </VisualState.StateTriggers>

                    <VisualState.Setters>
                        <Setter Target="mySplitView.DisplayMode" Value="Inline"/>
                        <Setter Target="mySplitView.IsPaneOpen" Value="True"/>
                    </VisualState.Setters>
                </VisualState>
            </VisualStateGroup>
        </VisualStateManager.VisualStateGroups>

        <SplitView x:Name="mySplitView" 
				   DisplayMode="CompactInline"
			       IsPaneOpen="False" 
				   CompactPaneLength="20">
     
            <!-- SplitView content -->

            <SplitView.Pane>
                <!-- Pane content -->
            </SplitView.Pane>
        </SplitView>
    </Grid>
</Page>

Achieving something more complex like changing the structure of a large part of the UI based on window width would be even more complex and verbose.

Scenarios

There are multiple different scenarios where different responsive design techniques can be used to achieve what we want. We can explore a few and brainstorm on different solutions to make it easy to adapt your XAML to these situations.

Replace/Re-architect

Here we have large pieces of the UI that need to change based on windows size. This technique lets you switch the user interface for a specific breakpoints. In this example, the nav pane and its compact, transient UI works well for a smaller screen, but on a larger screen, tabs might be a better choice.

Currently, this type of scenario would be achieved using multiple named containers defined in the UI driven by Visibility that is set to Visible/Collapsed based on certain Visual States.

Proposed Solution

A reusable component could be created that allows for multiple layouts based on the current display size. For argument sake, let's call it something like ResponsivePresenter.

Properties

Property	Type
DefaultTemplate	DataTemplate
NarrowTemplate	DataTemplate
WideTemplate	DataTemplate

Usage

<Page ...>
	<Grid>
		<utu:ResponsivePresenter>
			<utu:ResponsivePresenter.WideTemplate>
				<DataTemplate>
					<!-- NavView with Top Tabs -->
				</DataTemplate>
			</utu:ResponsivePresenter.WideTemplate>
			<utu:ResponsivePresenter.DefaultTemplate>
				<DataTemplate>
					<!-- NavView in Compact mode -->
				</DataTemplate>
			</utu:ResponsivePresenter.DefaultTemplate>
		</utu:ResponsivePresenter>
	</Grid>
</Page>

We can clean up the XAML even more by extracting the wide layout into a StaticResource and defaulting the content of the ResponsivePresenter to the DefaultTemplate:

<Page ...>
	<Grid>
		<utu:ResponsivePresenter WideTemplate="{StaticResource MyWideTemplate}">
				<DataTemplate>
					<!-- NavView in Compact mode -->
				</DataTemplate>
		</utu:ResponsivePresenter>
	</Grid>
</Page>

Reposition

You can alter the location and position of UI elements to make the most of the window size. In this example, the smaller window stacks elements vertically. When the app translates to a larger window, elements can take advantage of the wider window width.

In case like this, we don't necessarily need a completely new layout or UI structure, this can be done by driving just a few properties of your layout to adapt to the window size.

Using the ResponsivePresenter is an option here but can be a bit overkill, it would be good to have some sort of lightweight way of achieving this.

Proposed Solution

We can dynamically set any property using a custom Markup Extension.

We can have something called ResponsiveValue as a custom markup extension that has the following parameters:

• Default
• Wide
• Narrow

So, we could theoretically do something like:

<Page ...>
	<StackPanel Orientation="{ResponsiveValue Default=Vertical, Wide=Horizontal}">
		<Grid>
			<!-- A -->
		</Grid>
		<Grid>
			<!-- B -->
		</Grid>
	</StackPanel>
</Page>

This is a very simplified version of what can be done, I know that the image above shows the A section as larger than the B section.

Other design techniques

[kazo0]

Need some more input here on customizing the breakpoint values for window size

fyi @francoistanguay / @Xiaoy312 / @agneszitte

[francoistanguay]

Couple of ideas:

First, notsure the value of a "Default" responsibe layout. And maybe we should have at least 3 layouts (Small, Medium, arge) insteadof 2 9Narrow, Wide)

The current layout could be specified by window with a contextual Attached property like Responsive.Layout, It could be read by the markup extension, or the presenter... and it could be set through standard adaptive triggers (or with some helper over adaptive triggers) but in all cases I would try to decouple the setting from the reading....

[kazo0]

Default would be there as basically the fallback value. So if you wanted the Padding to always be "32" except for specifically the "Small" layout, you wouldn't need to specify Medium=32 and Large=32.

Sort of like the MAUI OnPlatformExtension: Color="{OnPlatform Yellow, iOS=Red, Android=Green}" where Yellow is implicitly the Default value for any platform that isn't iOS or Android. It's effectively the same as Color="{OnPlatform Default=Yellow, iOS=Red, Android=Green}"

So we could have something like <StackPanel Padding="{ResponsiveValue 32, Small=12}"> for the example I mentioned above

[Xiaoy312]

im not fond of the multi-DataTemplate approach with ResponsivePresenter, since you'd have to duplicate the xaml (when there are overlaps) so it doesnt work well say for reducing verbosity. it also creates a barrier between stuffs inside and outside of that presenter, eg: you cant access x:name across the border; you cant directly define event handler from the inside without some tricks (the same issue we had to deal with SamplePageLayout, that we solved like this: https://github.com/unoplatform/uno.toolkit.ui/blob/4.0.0/samples/Uno.Toolkit.Samples/Uno.Toolkit.Samples.Shared/Content/Controls/DrawerControlSamplePage.xaml.cs#L49)

however, it is good for when we have two completely different views based on narrow/wide
but then it also begs the question of why we arent just using visibility toggle powered by code behind?

[francoistanguay]

No, not Navigation specific... I dont yet understand the subtlety between a ReponsiveView containing N templates/views for the various breakpoints and how it would be different from something with different Visual States. But happy to see a spec :)

My main point is I think we could come up with a convention for N default theorical breakpoints: XS, S, M, L, XL or Narrowest/Narrow/Normal/Wide/Widest

And then you have a DP somewhere you can set to set the current breakpoint: something like Responsive.Layout

ANd then a few things that can listen to it contextually (per window or wherever the DP is being inherited from) and have a Responsive Binding like {Reponsive Narrow=Red, Normal=Blue}... or a ResponsiveView with diffeent templates...

[Xiaoy312]

in the case of ResponsiveView, we could be using an "arbitrary layer" here, ex:

<ResponsiveView
  <ConditionalView><TextBlock Text=Narrow /></ConditionalView>
  <ConditionalView MinimumWidth=800><TextBlock Text=Wide /></ConditionalView>
  <ConditionalView MinimumWidth=2160><TextBlock Text=ExtraWide /></ConditionalView>

for the default use case, we could have a specially named ones for narrow and wide:

<ResponsiveView
  <NarrowView><TextBlock Text=Narrow /></NarrowView>
  <WideView><TextBlock Text=Wide /></WideView>

the breakpoint can also be defined:

// on the app level:
ResponsiveView.DefaultWideWidth=800; // `static double` property

<!-- and also, overriddable on the ResponsiveView instance -->
<ResponsiveView WideWidth="720">

we could also use an array/collection for the breakpoints if we were to support things like: Narrower,Narrow,Wide,ExtraWide...

ResponsiveView.DefaultBreakpoints = new double[] { 0,300,800,2160 };
---
<ResponsiveView Breakpoints="0,300,800,2160">

[francoistanguay]

You dont want to define breakpoints per ResponsiveView.... They typically are per Window/Page(?) and then you can have multiple views reacting to the same breakpoints I think....

And I wouldnt create special types like NarrowView... it should be DataTemplates withing Responsive View...

ANd I believe that we start by convention with 5 breakpoints.... that it whould be MORE than enough more 99% of scenarios and then we can enable more scenarios later with custom named brekapoints or something...

Named ones are important for the Responsive Markup Extension: Foreground={Responsive Narrow=Blue, Normal=Red}

[Xiaoy312]

ok, probably not as separate child (special types as you called them), but what about as member properties of ResponsiveView?:

<ResponsiveView
  <ResponsiveView.Narrow><TextBlock Text=Narrow/>
  <ResponsiveView.Wide><TextBlock Text=Wide/>
  <ResponsiveView.ExtraWide><TextBlock Text=ExtraWide/>

the breakpoint will be set at an app level:

@ App.ctor
ResponsiveView.DefaultLayout = new ResponsiveLayout(Narrow: 300, Wide: 800, ...);

and, it can be, but not necessarily needed, overridden at control level:

<ResponsiveView
	<ResponsiveView.Layout><ResponsiveLayout Narrow=250 Wide=600 />

[Xiaoy312]

this is also shorter compared to the data-template syntax which will probably looks like:

<ResponsiveView
  <ResponsiveView.Narrow><DataTemplate><TextBlock Text=Narrow/>

adding on extra layer

[kazo0]

So we should have a central spot where a ResponsiveLayout {Narrow = 300, Wide = 800, etc. } object will be defined in the app resources as a StaticResource that both the ResponsiveView and Responsive[Value] will reference using App.Resources and use as the source of truth for the breakpoint values.

On top of that, a performance concern that we should address is subscribing to Window.SizeChanged for each individual binding using the markup extension as that can add a lot of event handlers. So we should come up with some sort of manager that will maintain a list, per window instance, of all instances that need to listen to SizeChanged. And so that manager class will hook to each registered window instance's SizeChanged and then iterate the list of the window instance's registrants and notify them of the new size

[Xiaoy312]

closing this discussion as the discussed features have been implemented:

• https://github.com/unoplatform/uno.toolkit.ui/blob/5.1.0/doc/controls/ResponsiveView.md
• https://github.com/unoplatform/uno.toolkit.ui/blob/5.1.0/doc/helpers/responsive-extension.md