September 27, 2016 at 13:27UWP beginner: Responsive Design (VB.NET + C #)
- Tutorial
We continue the story of developing for the universal platform of Windows (UWP). The topic of this article was born due to the large number of questions on it to the author from independent developers of UWP applications. For some, it may seem quite obvious, but we hope that you find in this article a useful life hack on responsive design in UWP.
This article was prepared jointly with an active participant in the Microsoft Developer community , Alexei Plotnikov , and Stas Pavlov , manager of technical audiences .
The first truth that any UWP application developer should remember is “thoughts as a user”. The second truth is “without an adaptive design, the application is doomed to a slow and painful death”, since the number of devices and screen extensions is simply huge. The first and most frequent decision to create an adaptive design that immediately comes to mind is AdaptiveTrigger.
Of course, you should not write another article about them, but to understand further considerations, a little help will not hurt. Take the most common use of adaptive triggers:
Run the project and see how the color changes when changing the width of the window: from green to red and vice versa.
If you do not understand what is happening here, then first you need to get acquainted with the concept of adaptive triggers. A good course on responsive design and responsive triggers is available at Microsoft Virtual Academy. By the way, it will not be superfluous to go through it all - this will significantly expand your knowledge in the development of UWP applications.
A nice feature of adaptive triggers is that we do not need to perform any actions in the code and this simplifies the division of labor between the designer and the developer, and in addition makes the project independent of the programming language used (C # or VB.Net).
At first glance, everything may seem extremely simple and obvious, but starting to apply the knowledge obtained above, you will encounter a number of issues and difficulties that arise. The first thing that comes to mind is “What window width should I choose to see a suitable layout on the phone screen?” This question may seem silly, and the answer is quite simple - we will choose the largest value from the minimum. For example, in the code above, the width is set to 600 px, and in other examples and similar articles 720 px is often found. Let's set 720 px, and then all devices whose screen width will be either less than or equal to 720 px will have the representation we need. And you will be right exactly until the moment you turn your device into a horizontal position (remember the first truth?). For someone, perhaps this will be a revelation, but there are devices in which the screen height is less than 720 px. By turning the device in a horizontal position, the height will turn into a width, the trigger will give us an idea for a narrow window, which will completely break our layout.
To fully understand the picture, consider the example above with the following modification:
Run the project on the very first emulator from the debug list Mobile Emulator 10.xxx. WVGA 4 inch 512MB ”and put it in horizontal mode. As you can see, the StackPanel remained in a vertical orientation, although it would be more logical to see a horizontal one. The trigger did not work, because both the width and the height of the device in our case are less than 720 px.
Ok, then let's choose a lower value for the trigger, for example, 500. But here we get the same problem, but on modern devices where the screen width in vertical orientation is more than 500. In fact, we don’t even need to reproduce the problem low resolution device emulator. It is enough to run the application on a PC and make the window size minimum in height, and then reduce the width until the value from the trigger is reached. StackPanel again does not look like we would like. By the way, if this problem does not seem significant to you, then remember that in Windows 10 on the PC we got the opportunity to fix four windows on the screen at once, which gives them just such proportions.
Let's move on to the solution. The StackPanel example shown above is not just an example for the sake of the example, but the main part of the working draft, in which the indicated problem was the cornerstone. To understand what is at stake, consider the “Ruble Life” application from a co-author of an article that displays real-time exchange rates.
The application shows the position of the ruble in three main indicators - the exchange rate against the dollar, the exchange rate against the euro and the price of oil. It is logical to assume that for these purposes a StackPanel is used, the orientation of which is adjusted to the orientation of the device or the aspect ratio of the window. More precisely, it is precisely to the aspect ratio. The advantage of the approach is that no matter what device we use or in what position it is, the StackPanel has a suitable orientation and it is convenient for the user to receive data.
How is such a trip implemented in practice? Pretty simple. All that is needed is to respond to the resize event in the head Grid and save the change to a variable / property, which we will then use to build the layout.
Vb.net
C #
In this example, the corresponding value is assigned to a property of its own class. Further, all that is needed is to bind the Orientation property of the StackPanel to the corresponding property in our class. You can also save the benefits of setting values in XAML and, instead of setting class properties, make the transition to the desired visual state with
It is worth noting one more trick that turns this solution into an ideal one for such projects. In order not to guess with the font sizes for different devices and screen resolutions, just wrap the StackPanel in the Viewbox and then on any device from the smallest phones to large TVs, you will see a nice-looking picture.
By the way, when studying the Ruble Life application, you can also notice that when the aspect ratio changes, other changes in the interface occur. For example, if you run the application on a PC and deploy to full screen, then the application buttons will be located above and below, occupying free space, and if you squeeze the window, the buttons will hide and the CommandBar will be displayed with a set of the same actions. On the contrary, if you run the application on the phone, we will first see the view with the CommandBar, and turning the phone, the view with the buttons. This approach is truly universal and allows the user to get the preferred version of the interface by simply resizing the window or rotating the device.
What really works with StackPanel, you say, but what about more complex interfaces? You will be surprised, but this approach can be applied on more complex interfaces by combining reactions to changing aspect ratios and using adaptive triggers. For example, you have a group of objects that forms a height of 600 px. No matter how you react to changes in the aspect ratio, this will not help you make this group of objects convenient for perception if the height of the window or the height of the phone screen in the horizontal position is less than 600 px. It is precisely for such situations that adaptive triggers are needed. You can rebuild the group so that objects become smaller, or hide / move less significant objects.
In conclusion, it is worth adding that the main idea of building an interface in response to a change in the aspect ratio is based on the fact that we do not always need to radically change the interface for different types of devices and sometimes it’s enough to create two presentation options for situations that we called “horizontal” and “ vertical ”arrangement of a window / device. For example, the standard application for Windows 10 “Mail” has different XAML files for the version for PC and phones, while the concept described above would also look quite logical. In particular, in the version for phones, turning the device to a horizontal position, the interface will not change, while there is enough space to display both the list of letters and the contents of the letter by version type for PC. In future articles, we will constantly resort to examples of using such a strategy,
The first article in the UWP beginner series: Window title in applications .
This article was prepared jointly with an active participant in the Microsoft Developer community , Alexei Plotnikov , and Stas Pavlov , manager of technical audiences .
The first truth that any UWP application developer should remember is “thoughts as a user”. The second truth is “without an adaptive design, the application is doomed to a slow and painful death”, since the number of devices and screen extensions is simply huge. The first and most frequent decision to create an adaptive design that immediately comes to mind is AdaptiveTrigger.
Of course, you should not write another article about them, but to understand further considerations, a little help will not hurt. Take the most common use of adaptive triggers:
Run the project and see how the color changes when changing the width of the window: from green to red and vice versa.
If you do not understand what is happening here, then first you need to get acquainted with the concept of adaptive triggers. A good course on responsive design and responsive triggers is available at Microsoft Virtual Academy. By the way, it will not be superfluous to go through it all - this will significantly expand your knowledge in the development of UWP applications.
A nice feature of adaptive triggers is that we do not need to perform any actions in the code and this simplifies the division of labor between the designer and the developer, and in addition makes the project independent of the programming language used (C # or VB.Net).
At first glance, everything may seem extremely simple and obvious, but starting to apply the knowledge obtained above, you will encounter a number of issues and difficulties that arise. The first thing that comes to mind is “What window width should I choose to see a suitable layout on the phone screen?” This question may seem silly, and the answer is quite simple - we will choose the largest value from the minimum. For example, in the code above, the width is set to 600 px, and in other examples and similar articles 720 px is often found. Let's set 720 px, and then all devices whose screen width will be either less than or equal to 720 px will have the representation we need. And you will be right exactly until the moment you turn your device into a horizontal position (remember the first truth?). For someone, perhaps this will be a revelation, but there are devices in which the screen height is less than 720 px. By turning the device in a horizontal position, the height will turn into a width, the trigger will give us an idea for a narrow window, which will completely break our layout.
To fully understand the picture, consider the example above with the following modification:
Run the project on the very first emulator from the debug list Mobile Emulator 10.xxx. WVGA 4 inch 512MB ”and put it in horizontal mode. As you can see, the StackPanel remained in a vertical orientation, although it would be more logical to see a horizontal one. The trigger did not work, because both the width and the height of the device in our case are less than 720 px.
Ok, then let's choose a lower value for the trigger, for example, 500. But here we get the same problem, but on modern devices where the screen width in vertical orientation is more than 500. In fact, we don’t even need to reproduce the problem low resolution device emulator. It is enough to run the application on a PC and make the window size minimum in height, and then reduce the width until the value from the trigger is reached. StackPanel again does not look like we would like. By the way, if this problem does not seem significant to you, then remember that in Windows 10 on the PC we got the opportunity to fix four windows on the screen at once, which gives them just such proportions.
Let's move on to the solution. The StackPanel example shown above is not just an example for the sake of the example, but the main part of the working draft, in which the indicated problem was the cornerstone. To understand what is at stake, consider the “Ruble Life” application from a co-author of an article that displays real-time exchange rates.
The application shows the position of the ruble in three main indicators - the exchange rate against the dollar, the exchange rate against the euro and the price of oil. It is logical to assume that for these purposes a StackPanel is used, the orientation of which is adjusted to the orientation of the device or the aspect ratio of the window. More precisely, it is precisely to the aspect ratio. The advantage of the approach is that no matter what device we use or in what position it is, the StackPanel has a suitable orientation and it is convenient for the user to receive data.
How is such a trip implemented in practice? Pretty simple. All that is needed is to respond to the resize event in the head Grid and save the change to a variable / property, which we will then use to build the layout.
Vb.net
Private Sub GlobalGrid_SizeChanged(sender As Object, e As SizeChangedEventArgs)
If e.NewSize.Height > e.NewSize.Width Then
MyApplicationData.Orientation = Vertical
Else
MyApplicationData.Orientation = Horizontal
End If
End Sub
C #
private void GlobalGrid_SizeChanged(object sender, SizeChangedEventArgs e)
{
if (e.NewSize.Height > e.NewSize.Width)
MyApplicationData.Orientation = Orientation.Vertical;
else
MyApplicationData.Orientation = Orientation.Horizontal;
}
In this example, the corresponding value is assigned to a property of its own class. Further, all that is needed is to bind the Orientation property of the StackPanel to the corresponding property in our class. You can also save the benefits of setting values in XAML and, instead of setting class properties, make the transition to the desired visual state with
VisualStateManager.GoToState(). It is worth noting one more trick that turns this solution into an ideal one for such projects. In order not to guess with the font sizes for different devices and screen resolutions, just wrap the StackPanel in the Viewbox and then on any device from the smallest phones to large TVs, you will see a nice-looking picture.
By the way, when studying the Ruble Life application, you can also notice that when the aspect ratio changes, other changes in the interface occur. For example, if you run the application on a PC and deploy to full screen, then the application buttons will be located above and below, occupying free space, and if you squeeze the window, the buttons will hide and the CommandBar will be displayed with a set of the same actions. On the contrary, if you run the application on the phone, we will first see the view with the CommandBar, and turning the phone, the view with the buttons. This approach is truly universal and allows the user to get the preferred version of the interface by simply resizing the window or rotating the device.
What really works with StackPanel, you say, but what about more complex interfaces? You will be surprised, but this approach can be applied on more complex interfaces by combining reactions to changing aspect ratios and using adaptive triggers. For example, you have a group of objects that forms a height of 600 px. No matter how you react to changes in the aspect ratio, this will not help you make this group of objects convenient for perception if the height of the window or the height of the phone screen in the horizontal position is less than 600 px. It is precisely for such situations that adaptive triggers are needed. You can rebuild the group so that objects become smaller, or hide / move less significant objects.
In conclusion, it is worth adding that the main idea of building an interface in response to a change in the aspect ratio is based on the fact that we do not always need to radically change the interface for different types of devices and sometimes it’s enough to create two presentation options for situations that we called “horizontal” and “ vertical ”arrangement of a window / device. For example, the standard application for Windows 10 “Mail” has different XAML files for the version for PC and phones, while the concept described above would also look quite logical. In particular, in the version for phones, turning the device to a horizontal position, the interface will not change, while there is enough space to display both the list of letters and the contents of the letter by version type for PC. In future articles, we will constantly resort to examples of using such a strategy,
The first article in the UWP beginner series: Window title in applications .