The RelativePanel is a new control introduced for your UWP tool box. It allows us to define relationships between different visual elements - a convenient and simple approach to arranging UI features based on an app's screen width. Let's begin by priming our understanding of the RelativePanel with a simple example.

This XAML renders the following layout:

Figure 1: Simple RelativePanel Layout

Man on Windows Computer

This simple example displays a title and applies a left margin value specified inside SubHeaderTextStyle to the SubheaderText TextBlock element. The layout for the line below the sub-header is set by the containing RelativePanel positioning properties, RelativePanel.Below and RelativePanel.AlignLeftWith. By setting these properties inside the actual element, we are establishing the default position of the line. It's a good practice to define element positioning at the default level, but be reminded that we must support positioning for more than one screen size.

The first post in this series introduced the AdaptiveTrigger control. Using the AdaptiveTrigger and RelativePanel together offers flexibility to implement adaptable screens. Our next example will illustrate how we can use the RelativePanel with AdaptiveTrigger, but first, let's understand when RelativePanels are helpful and when they are not.

When and When Not to Use

As seen above, implementing a RelativePanel is quite straight-forward, as it requires minimal effort to position elements relative to each other. It may even be tempting to use this control in many different scenarios. Think of a case where we want to present a registration form, for example, that has many different elements - textboxes, combo boxes, and maybe some elements with conditional visibility. Applying an adaptive layout in this scenario using only the RelativePanel might add unnecessary complexity while making the XAML markup hard on the eyes. Additionally, we'd end up creating a hierarchy of element relationships that would be difficult to maintain. Imagine the number relationships and positioning dependencies that would have to be established on a screen with, say, 50 different UI elements. Let's examine a situation that demonstrates a practical use of the RelativePanel.

These two screens show the same form, but for two different screen sizes, narrow and wide.

Figure 2: Feedback Form - Narrow and Wide Views

Most of the elements on this screen maintain the same positioning regardless of screen size, except for the two category ComboBox items. In the narrow view, they are aligned vertically, and in the wide view, they are aligned horizontally. Since only one element on this form uses relative positioning, using the RelativePanel positioning properties on the second category ComboBox is a quick and easy way to apply adaptability in this scenario.

Here's the XAML that's represented in Figure 2 (only relevant code is shown):

VisualStateManager

Form Content


… 
	
… 

Combined with the AdaptiveTrigger, we establish control over element layout at the default and variable screen size thresholds. Only one element on this form requires re-positioning, so using the RelativePanel here is perfectly fine. If all the elements on this form required re-positioning, then a better approach might be to group some of these elements together in a Grid or StackPanel, and then set RelativePanel positioning properties on the Grid or StackPanel over each element. Let's reinforce this point with a conceptual scenario…

Think about a music player that has a control panel with 'Back', 'Play', and 'Forward' buttons under another element that displays some type of visualization when a song is playing. Rather than thinking about positioning for each button on the control panel, consider putting these buttons inside a horizontally-oriented StackPanel. Now we only have to position the control panel element in relation to the visualization panel. Easily done, as seen in the code for Figure 2.

Closing

The RelativePanel is a nice addition to our UWP toolbox. Creating positional relationships between elements allows us to effectively organize screens with predictable and simple adaptability. The final post in this series will showcase several more features involving listing repeatable elements, as seen in ListView and GridView controls, in different form factors and screen sizes.

About the Author

Jeremy McBrideJeremy is a software development consultant in the Washington, DC Metro office with expertise in the Microsoft technology stack. He has experience architecting and implementing enterprise applications facilitating ASP.NET, WebAPI, and Windows Mobile. His most recent projects include leading a Windows 10 UWP development team and providing Android development support.