MAUI - A big problem - lack of responsiveness...

[antonycartwright]

Hi everyone,

I've been doing programming for many, many years now, so I have a rough idea about coding and these frameworks.

I had a look at MAUI about a year ago or so when it was released, and honestly, I found it pretty shocking. I thought; "Yes, far from complete, but one to keep an eye on.".

Anyway, I came back to it 3 days ago, and well done, I think it's very good! I feel as though I've got to grips with it in just 3 days! I can see the benefits of MAUI, it's powerful, it's relitively easy, and for by far the most part, it works well. It's great!

However, I have a major concern with MAUI - responsiveness. In 2024, arguably, apps being responsive is more important than them being cross-platform. I've come to learn, to my surprise that MAUI doesn't offer a solution to full responsiveness, and it really, really should.

I can see the layouts, I can see the views concept, but it doesn't work! There's no solution for dealing with a changing orientation! We're writing apps now for phones and tablets, and people do want to change orientation. This is a really basic thing that apps must be able to handle now. Without this, I can't see how MAUI will be successful.

I've looked through the documentation, I've looked through forums here also. There's no reasonable, native solution to be found. There are a few guys who have noticed the problem and sought to get over it, but they're using a hundred lines of code. It shouldn't be like this!

We can make incredibly responsive web apps with the excellent Bootstrap. This is a really important feature. It miust be resolved if people want MAUI to be taken seriously.

[JohnHDev]

Huh? My apps support change of orientation without any extra code.
Can you post your XAML or code? Might be easier to see what you are doing.

[antonycartwright]

Hello, yes ofcourse. I've spent quite a while messing around with it. What I've done now is simplified it and made it for portrait viewing. Landscape, it just doesn't really work properly. There doesn't appear to be a mechanism to tweak the view.

`

<ContentPage.ToolbarItems>
    <ToolbarItem x:Name="btnConnectDisconnect" Text="Connect" Clicked="btnConnectDisconnect_Clicked"/>
    <ToolbarItem x:Name="btnStartStop" Text="Start" Clicked="btnStartStop_Clicked"/>
</ContentPage.ToolbarItems>

<ScrollView>
    <VerticalStackLayout
        Spacing="15"
        Padding="15,8">

        <Grid ColumnDefinitions="*" RowDefinitions="*,*,*,*,*">

            <Label Padding="0"
 Margin="7"
 Grid.Row="0"
 Grid.Column="0"
 Text="Voltage"
 HorizontalOptions="Center"
 TextColor="DarkBlue"
 FontSize="18"
 FontAttributes="Bold"
 VerticalOptions="Center" />

            <BoxView x:Name="boxVoltage" Color="orange" Margin="5" CornerRadius="10" Grid.Row="1" Grid.Column="0"></BoxView>

            <Label Padding="0"
                   Margin="0"
                   Grid.Row="1"
                   Grid.Column="0"
                   Text="-"
                   x:Name="lblVoltage"
                   HorizontalOptions="Center"
                   TextColor="White"
                   FontSize="120"
                   VerticalOptions="Center" />

            <Label Padding="0"
        Margin="7"
        Grid.Row="2"
        Grid.Column="0"
        Text="Temperature"
        HorizontalOptions="Center"
        TextColor="DarkBlue"
        FontSize="18"
        FontAttributes="Bold"
        VerticalOptions="Center" />

            <BoxView x:Name="boxTemp" Color="orange"  Margin="5" CornerRadius="10" Grid.Row="3" Grid.Column="0"></BoxView>

            <Label Padding="0"
                   Margin="0"
                   Grid.Row="3"
                   Grid.Column="0"
                   Text="-"
                   x:Name="lblTemp"
                   HorizontalOptions="Center"
                   TextColor="White"
                   FontSize="120"
                   VerticalOptions="Center" />

            <BoxView Color="LightBlue" Margin="5" CornerRadius="10" Grid.Row="4" Grid.Column="0" HeightRequest="50"></BoxView>

            <Label Padding="0"
                   Margin="0"
                   Grid.Row="4"
                   Grid.Column="0"
                   Text="-"
                   x:Name="lblError"
                   HorizontalOptions="Center"
                   TextColor="DarkBlue"
                   FontSize="12"
                   VerticalOptions="Center" />
        </Grid>

    </VerticalStackLayout>
</ScrollView>

`

[antonycartwright]

[JohnHDev]

For landscape, what changes are you looking to see? Do you have designs for that?

[antonycartwright]

This...

[JohnHDev]

Thanks, so you are looking for 2 different layouts then. The first has a scrollview, the 2nd doesn't.
I normally handle this by binding IsVisible to 2 different layouts and switch which is visible in the VM when the orientation changes.

[antonycartwright]

Yes, 2 layouts. Scrollview correct.

OK, I understand that, and it's a nice solution, but this means I have to draw controls twice. Two set of controls for what is one record.

I effectively have to create a layout for portrait and one for landscape, then make one visible and the other not.

But surely, there should be a more elegant way to do this? They know that reposinsivness is really important now, and it looks like they're forgotten about this problem.

Thanks for your help though, I will do that, but it doesn't feel right does it? :-)

[JohnHDev]

To be fair you aren't drawing controls twice, they are only drawn when visible. When I need to different layouts, 1 portrait 1 landscape, this is what I do. You are defining 2 layouts, that's true. But you would have to do that anyway.

And there are other options, you can bind grid properties and have a bit of code that changes span for example. That to me starts to get quite complex, I prefer small, simple solutions that are easier to support and maintain.

[antonycartwright]

Well, yes, but I have to define the same control twice don't I? One for one layout, one for another. It's cumbersome, especially if the layour has many controls in it. But yes, it's simple, and yes, it will work, but not what I expected from a brand new framework.

We have the likes of Bootstrap for web development which is so powerful. I expected something like that.

Anyway, yes, ok, my suspecion has been confirmed, and I believe your solution is simple and effective.

Thanks,

Antony

[mikkpaasuke]

This is how I've been handling dynamic change of orientation, perhaps not the best way of doing things but it works. I surface a number of ObservableProperties so they can be bound to in XML and, hence, the page layout/sizes/label size can change in real time (via handling the 'OnMainDisplayInfoChanged' event). We have a very specific device target, i.e. a tablet with certain dimensions, hence the hard-coded numbers for label size.

using CommunityToolkit.Mvvm.ComponentModel;
using Microsoft.Extensions.Logging;

namespace App.ViewModel
{
    public partial class BaseViewModel : ObservableObject
    {
        public readonly IAppLocalizationResourceManager resourceManager;
        ILogger<BaseViewModel> _logger;        

        [ObservableProperty]
        [NotifyPropertyChangedFor(nameof(IsNotBusy))]
        bool isBusy;

        [ObservableProperty]
        private AppLocalizedString title;

        [ObservableProperty]
        private string formattedTitle;
        public bool IsNotBusy => !IsBusy;

        [ObservableProperty]
        private double deviceScreenDPI;

        [ObservableProperty]
        private double deviceScreenWidth;

        [ObservableProperty]
        private double deviceScreenHeight;

        [ObservableProperty]
        private DisplayOrientation deviceScreenOrientation;

        [ObservableProperty]
        private double detailViewStandardLabelWidth;        

        [ObservableProperty]
        private string busyStatusDescription;

        public BaseViewModel(IAppLocalizationResourceManager resourceManager)
        {
            this.resourceManager = resourceManager;            
            _logger = AppFieldWorker.Services.ServiceProvider.Current.GetService<ILogger<BaseViewModel>>();
            UpdateStoredDeviceDimensions();
            DeviceDisplay.MainDisplayInfoChanged += OnMainDisplayInfoChanged;
        }

        private void UpdateStoredDeviceDimensions()
        {
            DeviceScreenDPI = DeviceDisplay.MainDisplayInfo.Density;
            DeviceScreenWidth = DeviceDisplay.MainDisplayInfo.Width;
            DeviceScreenHeight = DeviceDisplay.MainDisplayInfo.Height;
            DeviceScreenOrientation = DeviceDisplay.MainDisplayInfo.Orientation;            

            if (DeviceScreenOrientation == DisplayOrientation.Landscape)
                DetailViewStandardLabelWidth = DeviceScreenWidth - 200 - 700;
            else DetailViewStandardLabelWidth = DeviceScreenWidth - 200 - 450;            

            _logger.LogInformation($"UpdateStoredDeviceDimensions: DeviceScreenDensity: {DeviceScreenDPI}, DeviceScreenWidth: {DeviceScreenWidth}, DeviceScreenHeight: {DeviceScreenHeight}, DeviceScreenOrientation: {DeviceScreenOrientation}, DetailViewStandardLabelWidth: {DetailViewStandardLabelWidth}");
        }

        private void OnMainDisplayInfoChanged(object sender, DisplayInfoChangedEventArgs e)
        {
            UpdateStoredDeviceDimensions();
        }
    }
}

[antonycartwright]

This is a very effective way of finding screen dimensions, I agree, but how does it dynamically change properties of a grid, for example "Grid.ColumnSpan='2'"? It seems that Microsoft completely forgotten about this very important problem, which is sad.

[JohnHDev]

You can use a binding for that if you wanted, I prefer to have 2 different grids and bind IsVisible to a landscape/portait property. Its really very simple.

[mikkpaasuke]

It definitely works as John has mentioned, just for our case we have a list of label/data pairs on various views, and for these I use styles in app.xml, and within the style there is a binding to the 'DetailViewStandardLabelWidth' member.

Developer Express created an 'AdaptivePage' to take care of this issue, you can find the code in their freely-available source code for their demo project.

The problem is easily solvable using one or more of the mention solutions here. I don't expect MS to provide every solution to my requirements.

[antonycartwright]

Thanks, I understand. I will use the dupicate controls method with IsVisible because it looks super simple. :-)

It's a shame about Microsoft. This is such a great project, but it's like as if they want to distance themelves from it for some reason.

[acaliaro]

Maybe you can take a look to AdaptiveTrigger

#19197 (comment)

[antonycartwright]

Hello! I'd already discovered this a while ago and gave it a go, but it didn't work for me, and even if it did work, I'd still need to duplicate controls and stuff because it's really complicated to force a grid into that mould, if that makes sense.

Since this is such a basic idea, and super important in 2024, this issue really needs to be properly resolved in my opinion! :-)

[Xyncgas]

1. You can detect change of orientation
2. The definition of pixel is related to actual inches of the device so you don't have to worry

[antonycartwright]

Yes, we can detect orientation, but that's not the issue. The issue is responding effectively!

I don't want to keep refering to older technologies, because we need to look forward and improve this framework rather than look back, however, even since old technologies such as ASP.NET, we were able to use CSS tags and stuff, then came Bootstrap which made everything amazing from a responsive point of view.

I think I have the answer though... in Maui, the way forward is to duplicate controls, have two layouts, show one view when orientation is P, and another when the orientation is L. :-)

It's not elegant, but it's fast, trouble-free, effective and simple.

[Xyncgas]

CSS similar way for adapting to screen is nice, I bet in their code in the browser they eventually have to create a different object with different width height etc for the new element too, we are just doing dirty works right now but in the future maybe we get something like simply say it should adapt to orientation and it would

[Xyncgas]

But why not use MAUI.Blazor, it's a framework for writing UI with or without XMAL, the biggest selling point of MAUI.Blazor is you can run .NET code natively and use web UI for the application

[antonycartwright]

I don't know. It seems that MS is not really interested in MAUI so much.

CSS works by changing the attribues of elements on draw - from what I remeber. It's client-side.

For now, it's ok I guess...

[antonycartwright]

Blazor seems to be a server-side based thing. :-) I'll look at that later in the year I guess. :-)

[antonycartwright]

Hi Everyone.

On second thoughts, this solution is not too good.

I've come too the conclusion that MAUI simply does not fully support responsiveness.

Basically, the accepted solution is either to use triggers, or to use multiple views.

Triggers allow you to change attributes of some object. For example, you could have a button with a trigger. When a trigger is triggered on orientation change, you can change the attribute "width" to 100%, whereas in portrait, it could be 50%. So you ahve one view that can change.

The other option is multiple views. The idea of this is that you have a view for portrait and a completely different view for landscape. Here you ahve two things and just hide one when orientation has changed.

Neither of these fixes are straight forward. The first fix simply doesn't work in practice. You need to be able to change whole parent objects rather than simply change attributes. The second fix isn't simple. you need to double up controls, and not only that, it's not a case of simply making one view invisible and the other visible, because you can onyl have one view in the page! What you have to do is mess about in the code behind.

Neither solutions are sufficiently elegant. In my opinion, this is aserious issue that needs to be addressed. I'm going to start new contracts in a few weeks. I can't offer this sort of thing to my clients! It must look good and work well for users and it must be quick and easy for me to make, otherwise I'm working for cheap!

[mikkpaasuke]

I understand your nervousness regarding being on the hook for implementation choices with clients, that's for sure. If things get complicated and messy, either you need to pass these costs on (which can make you look 'expensive') or otherwise eat the costs yourself (which, yes, mean you are working for too cheap). This has been a bit of an issue for me over the past year working with .NET MAUI, but fortunately for me my client is pretty understanding as I've been working with them for well over a decade now.

DevExpress use triggers, I think, in their sample .NET MAUI application, the source code for which is available for free. I would definitely encourage you to check it out, and you can install the built app from the Google Play store to see how well it works.

In terms of a 'quick and easy' native solution with .NET MAUI or some add-on, I would love it too, but sometimes it's just necessary to go with an inelegant and imperfection solution.

[antonycartwright]

Hi Mike, yes, this is exactly the problem. My clients are also very understanding, but I don't want any unnecessary time-wasting or complication for them. I also want to make money without frustration! :-D

[JohnHDev]

Neither of these fixes are straight forward. The second fix isn't simple. you need to double up controls, and not only that, it's not a case of simply making one view invisible and the other visible, because you can onyl have one view in the page! What you have to do is mess about in the code behind.

If you want to do it the wrong way, feel free to 'mess about' in the code behind. Or use a bindable property on your VM. It really is very simple, I don't know why you are making this more complex than it is.