Embedded ScrollView size constraints - Findings about how external constraints ultimately allow ScrollView to do its job !

[bebenlebricolo]

[TL;DR]

The "auto" size in Grids in .Net MAUI does not constraint children's size, but only wraps it tightly and grows with it - it's an InfiniteSize sizing mode.
When using ScrollView as part of a tab's content, it needs to know its external boundaries in order to trigger scrolling events whenever its content grows past the defined boundaries.

Findings

Well, I suspect I should have written this probably somewhere else, but as I discovered this while trying out the Sharpnado.Tabs, I thought it would be a good fit to add an example somewhere about ScrollViews and CollectionViews within a tab.

Hi folks,

I'm still pretty new to .net Maui and experiencing my load of daily roadblocks with this framework, and while trying out the Sharpnado.Tabs I managed to pull out something useful (at least for me).
So it might have some use to share with you, albeit I think most of you already know that stuff, but at least it'll leave a trace somewhere so that other folks like me will hopefully find it someday.

For the context, I was having troubles to get a ScrollView wrapping a CollectionView to scroll as expected while being set as a Sharnado.Tabs content view. The issue was lying in the way .net Maui computes layout sizes, and this caused the ScrollView to never expand past its parents layout constrained boundaries (there was none); despite it being well out of the viewport.
In my opinion, this should be a bug of some sort because this is really not straight forward to figure out...
Unless maybe you have some sort of experience with this, but at the very least it's not a nice developer-experience...

The solution I found to this issue (...)

When using tabs in a ContentPage like so :

<ContentPage.Content>
      <Grid Margin="0" Padding="0"
            RowDefinitions="auto,auto,*">
            <!--                      ^  
                                      This "star" sizer is REALLY important here
            -->
            <!-- Some widgets/controls  ... -->
            <tabs:TabHostView x:Name="TabHost"
                                          Grid.Row="1"
                                          Margin="0,0"
                                          BackgroundColor="#272727"
                                          HeightRequest="50"
                                          SelectedIndex="{Binding Source={x:Reference Switcher}, Path=SelectedIndex, Mode=TwoWay}">
            </tabs:TabHostView>
            
            <!-- Some Tabs description ... -->

            <tabs:ViewSwitcher x:Name="Switcher"
                                          Grid.Row="2"
                                          x:DataType="viewmodel:ReferencesPageViewModel"
                                          Margin="0"
                                          SelectedIndex="0"> <!-- Trying to force the startup index here -->
                        <tabs:LazyView x:TypeArguments="views:MyCustomView"
                                       AccentColor="{StaticResource Primary}"
                                       UseActivityIndicator="True">
                        </tabs:LazyView>
                        <!-- Other tabs ... -->
            </tabs:ViewSwitcher>
      </Grid>
</ContentPage.Content>

and having MyCustomView looking like this :

<ContentView xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">

      <Grid RowDefinitions="auto,*">
            <!-- First row occupied by some content -->
            <ScrollView Grid.Row="1">
                  <CollectionView >
                        <!-- Templated data assets, filling up the whole screen and more -->
                  </CollectionView >
            </ScrollView>
      </Grid>
</ContentView>

I discovered that having the "auto" size constraint on the top Grid's RowDefinition is essentially an "Infinite Size" trigger for the Grid, which only wraps the child object as tightly as it can and grows with it, without ever constraining the content.
This has some consequences, as a ScrollView container will only trigger its Scrolling behaviors if its Children size exceeds the limits the ScrollView parent imposes.
In other terms, when ScrollView's belly inflates so much that the box in which it's suppose to fit becomes to small, then and only then it'll trigger the scrolling events !

When the ScrollView is the child of another ContentView, it's up to the parent ContentView to constrain the Child area, and so on and so forth.
But at some point, we need those constraints to be automatically calculated based on the physical device's screen size.
And this can be achieved at the top level, that's the only place (to my knowledge) where this data is automatically handled by the framework itself, thus the need to propagate the "*" scaling up to the top of the page.

Note that I originally tried with the StackLayout, using the VerticalOptions="Fill", but this does not work...
So better use a Grid for finer control...

Note : As tabs:ViewSwitcher inherits from a Grid, it borrows most (if not all) utilities for Children placement of a regular Grid object.
As such, the way the ViewSwitcher resizes itself and propagates the boundaries constraints is preserved along the way.