[Enhancement] Replace IsVisible with Visibility (similar to Android)

[GalaxiaGuy]

Summary

Xamarin Forms uses a two state visibility system, something is visible or it is not. Android has a three state visibility system. The third state is not rendered, but is still used for layout. It would mainly be Layouts that care about this third state.

API Changes

public enum Visibility
{
    Visible,
    Invisible,
    Gone    
}

public class VisualElement
{
    public static readonly BindableProperty VisibilityProperty = BindableProperty.Create(
        nameof(Visibility), typeof(Visibility), typeof(VisualElement), Visibility.Visible);

    public Visibility Visibility
    {
        get => (Visibility)GetValue(VisibilityProperty);
        set => SetValue(VisibilityProperty, value);
    }
}

Backwards compatibility

IsVisible would be deprecated.
true would map to Visible and false to Gone. Invisible could go either way., since using both IsVisible and Visibility in the same view hierarchy is likely to be broken (i.e. setting Visibilty and getting IsVisible would not be recommended).

One big caveat is whether this can be reasonably implemented - i.e. can all native renderers be correctly measured while invisible.

Intended Use Case

This can be useful in several situations, for example when something can be toggled visible or invisible, but is also not a predictable size. Using the Invisible state means the surrounding layout can be stable while the visibility is toggled.

[billhenn]

While on the topic, all prior Microsoft UI platforms have used "Visible", "Hidden", and "Collapsed" as the three Visibility options. Would those be better to use since they are known to XAML devs?

[h82258652]

Visibility is an enum that means we can use different names for the same value.
How about this:

public enum Visibility
{
    Visible = 0,
    Hidden = 1,
    Invisible = 1,
    Collapsed = 2,
    Gone = 2
}

[FruitTreeAlchemist]

Visible => Is within the visual tree. Reserve the elements space. Display the element.
Hidden => Is within the visual tree. Reserve the elements space. Don't display the element.
Collapsed => Not within the visual tree. Don't reserve the elements space. Don't display the element.

Invisible ??
Gone ??

[GalaxiaGuy]

The exact name is less important. I think having both would be a mistake though. A new user looking at some XAML that included both Collapsed and Gone would naturally assume they did different things.

[bkaankose]

In WPF, it is Hidden. In UWP XAML, there is no Hidden and only Visible and Collapsed exists. If MAUI must include this support, I suggest Visible, Collapsed and Hidden naming as part of the .NET legacy. There should be no confusion for the new developers by introducing different names for the same functionality.

[billhenn]

Since Maui is a XAML variant and XAML developers are familiar with the Visible/Collapsed naming (and WPF devs with the Hidden value), it seems like using those established standard names is best.

I agree that using different names for the same value, while possible, would be confusing. It would be better to just state in documentation comments that Collapsed is "Gone in Android" etc.

[ChaseFlorell]

I do like this proposal. Currently if I need to reserve the space for something but make it invisible, I have to have IsVisible = true and also Opacity = 0

the OP's idea of continuing with Android's implementation makes the most sense since the intent is clear.

public enum Visibility
{
    Visible,
    Invisible,
    Gone    
}

[vdvman1]

Gone feels less descriptive than Collapsed in my opinion, Gone feels like the component is actually destroyed and no longer exists, whereas Collapsed is more like it is still there but taking no space.

[mattleibow]

Does iOS support this? They just have a Hidden property... We could fake it and just hide it under the hood, but still ask it for sizes.

[vhugogarcia]

If iOS does not support one of the three options. Just implement the ones that are suported for iOS.

What I meant to say is that if iOS does not have a hidden feature and keeping the layout intact, then do not fake it.

Just document it and that is all.

[hartez]

iOS hidden is equivalent to WPF Hidden - the element isn't visible, but it still takes up space. So that one's easy.

We control the layout, so achieving WPF's Collapsed should be possible on iOS, just a bit more difficult. Naively, we could set hidden to true and reduce the frame to 0 width and height. Reality might be a bit more complicated, but it can be done. Forms already does it, since Forms's IsVisible=false is equivalent to Collapsed.

[jonmdev]

I need this function as well. I see in Android, Maui's isVisible = false is setting objects to Android's GONE state, which then triggers a second or more lag for big elements or large groups on making them VISIBLE again. I will need to make them INVISIBLE instead in Android.

Sounds like in iOS, I want hidden (which is the only option). And in Windows Collapsed?

I see in the documentation:

maui/docs/design/layout.md

Line 116 in 87c9aac

In MAUI.Controls, for backward-compatibility, visibility is limited to two values via the `IsVisible` property. `IsVisble == true` maps to `Visibility.Visible`; `IsVisible == false` maps to `Visibility.Collapsed`.

In MAUI.Core, Visibility has 3 possible values:

- Visible: the item is visible
- Hidden: the item occupies space, but cannot be seen
- Collapsed: the item does not occupy space, and cannot be seen

The MAUI.Core built-in layouts understand and honor all three values. 

In MAUI.Controls, for backward-compatibility, visibility is limited to two values via the `IsVisible` property. `IsVisble == true` maps to `Visibility.Visible`; `IsVisible == false` maps to `Visibility.Collapsed`. 

The mapped implementations of visibility for individual controls in MAUI.Core _should_ all handle `Visibility.Hidden` properly. So while MAUI.Controls does not have the concept of `Visibility.Hidden`, other SDKs can use it if they like. And custom handlers/controls in MAUI.Controls can also make use of it if they need to. 

I can see the enum here: Microsoft.Maui.Visibility which has the following options:

namespace Microsoft.Maui {
    public enum Visibility {
        Visible = 0,
        Hidden = 1,
        Collapsed = 2
    }
}

But I suspect what this is saying is if we use any default objects like Border/Layout/Image/Editor they will only have isVisible and nothing else?

We have the IsVisible here:

https://learn.microsoft.com/en-us/dotnet/api/microsoft.maui.controls.visualelement.isvisible?view=net-maui-7.0

Then we have the 3 option Visibility enum here:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.maui.visibility?view=net-maui-7.0

Which we can only get here but not set it seems:

https://learn.microsoft.com/en-us/dotnet/api/microsoft.maui.iview.visibility?view=net-maui-7.0#microsoft-maui-iview-visibility
https://learn.microsoft.com/en-us/dotnet/api/microsoft.maui.controls.visualelement.microsoft-maui-iview-visibility?view=net-maui-7.0#microsoft-maui-controls-visualelement-microsoft-maui-iview-visibility

I also see in Android here is the implementation:

maui/src/Compatibility/Core/src/Android/VisualElementTracker.cs

Line 313 in 87c9aac

void UpdateIsVisible()

		[PortHandler]
		void UpdateIsVisible()
		{
			VisualElement view = _renderer.Element;
			AView aview = _renderer.View;

			if (view.IsVisible && aview.Visibility != ViewStates.Visible)
				aview.Visibility = ViewStates.Visible;
			if (!view.IsVisible && aview.Visibility != ViewStates.Gone)
				aview.Visibility = ViewStates.Gone;

			aview.Invalidate();
			aview.RequestLayout();
		}

		void UpdateNativeView(object sender, EventArgs e)
		{
			Performance.Start(out string reference);

			VisualElement view = _renderer.Element;
			AView aview = _renderer.View;

			if (aview is MauiViewGroup formsViewGroup)
			{
				formsViewGroup.SendBatchUpdate((float)(view.AnchorX * _context.ToPixels(view.Width)),
											   (float)(view.AnchorY * _context.ToPixels(view.Height)),
											   (int)(view.IsVisible ? ViewStates.Visible : ViewStates.Invisible),
											   view.IsEnabled,
											   (float)view.Opacity,
											   (float)view.Rotation,
											   (float)view.RotationX,
											   (float)view.RotationY,
											   (float)view.Scale * (float)view.ScaleX,
											   (float)view.Scale * (float)view.ScaleY,
											   _context.ToPixels(view.TranslationX),
											   _context.ToPixels(view.TranslationY));
			}
			else
			{
				MauiViewGroup.SendViewBatchUpdate(aview,
												   (float)(view.AnchorX * _context.ToPixels(view.Width)),
												   (float)(view.AnchorY * _context.ToPixels(view.Height)),
												   (int)(view.IsVisible ? ViewStates.Visible : ViewStates.Invisible),
												   view.IsEnabled,
												   (float)view.Opacity,
												   (float)view.Rotation,
												   (float)view.RotationX,
												   (float)view.RotationY,
												   (float)view.Scale * (float)view.ScaleX,
												   (float)view.Scale * (float)view.ScaleY,
												   _context.ToPixels(view.TranslationX),
												   _context.ToPixels(view.TranslationY));
			}

			Performance.Stop(reference);
		}

As far as I can tell we are screwed for trying to implement this ourselves as the line (int)(view.IsVisible ? ViewStates.Visible : ViewStates.Invisible), blocks us from setting anything else into this. I am pretty sure even if I manually set the Android view visibility, this is going to override it.

Why on earth would it be set up like this?

The rot goes down to here:

maui/src/Core/AndroidNative/maui/src/main/java/com/microsoft/maui/MauiViewGroup.java

Line 75 in 87c9aac

public void sendBatchUpdate (

    public void sendBatchUpdate (
        float pivotX,
        float pivotY,
        int visibility,
        boolean enabled,
        float opacity,
        float rotation,
        float rotationX,
        float rotationY,
        float scaleX,
        float scaleY,
        float translationX,
        float translationY){
        setPivotX (pivotX);
        setPivotY (pivotY);

        if (getVisibility () != visibility)
            setVisibility (visibility);

        if (isEnabled () != enabled)
            setEnabled (enabled);

        setAlpha (opacity);
        setRotation (rotation);
        setRotationX (rotationX);
        setRotationY (rotationY);
        setScaleX (scaleX);
        setScaleY (scaleY);
        setTranslationX (translationX);
        setTranslationY (translationY);
    }

    public static void sendViewBatchUpdate (
        View view,
        float pivotX,
        float pivotY,
        int visibility,
        boolean enabled,
        float opacity,
        float rotation,
        float rotationX,
        float rotationY,
        float scaleX,
        float scaleY,
        float translationX,
        float translationY){
        view.setPivotX (pivotX);
        view.setPivotY (pivotY);

        if (view.getVisibility () != visibility)
            view.setVisibility (visibility);

        if (view.isEnabled () != enabled)
            view.setEnabled (enabled);

        view.setAlpha (opacity);
        view.setRotation (rotation);
        view.setRotationX (rotationX);
        view.setRotationY (rotationY);
        view.setScaleX (scaleX);
        view.setScaleY (scaleY);
        view.setTranslationX (translationX);
        view.setTranslationY (translationY);
    }

Where again we cannot control our own visibility states it seems as Maui will only lock us to one of two choices every time something is updated. This makes no sense.

Am I correct to think I would then have to replace all these methods myself on runtime with some insane method like this?

https://stackoverflow.com/a/36415711

Why must we then jump through crazy hoops just to use basic essential functions?

Using the Invisible modes are absolutely necessary in Android. How can we design anything without them? Have any Maui project managers ever built a significant Android app before? You will experience continuous 1-2 second lags whenever you hide or show something if you can't use the proper display toggling to optimize.

As for iOS, I see from their literature:

A hidden view disappears from its window and does not receive input events. It remains in its superview’s list of subviews, however, and participates in autoresizing as usual. Hiding a view with subviews has the effect of hiding those subviews and any view descendants they might have. This effect is implicit and does not alter the hidden state of the receiver’s descendants.

https://developer.apple.com/documentation/uikit/uiview/1622585-hidden

I am not clear which of the three states they are then describing. Either way this could then be mapped to whichever of the three behavior states it matches without any hassle.

Why not then give us all three choices?

As far as I can see the above are the only major things to change.

[jonmdev]

Okay, well good news. My first preliminary tests seem to suggest Maui is not overriding the visibility settings as feared. Even when I change an object's height it is not overriding this, so this is great news.

I am not sure what those functions I listed are for but as long as they aren't called, this may be okay

Here's a visibility behavior for iOS/Android/Windows that at least in first testing gives the right visual effect (don't know about how it will react to different click management solutions - I manage my own clicks), but it won't at all do the "hidden but reserved space" style in Windows because Windows only gives us two options now (collapsed or visible):

https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.visibility?view=winrt-22621

    public class VisibilityBehavior : Behavior<VisualElement>{
        public VisualElement ve;
        public Visibility visibility = Visibility.Visible; //SHOULD ONLY GET NOT SET THIS WAY

        //PREVIOUS WINDOWS
        //Visible 0 => Is within the visual tree.Reserve the elements space.Display the element.
        //Hidden 1 => Is within the visual tree.Reserve the elements space. Don't display the element.
        //Collapsed 2 => Not within the visual tree.Don't reserve the elements space. Don't display the element.

        //IN ANDROID
        //Visible = 0,
        //Invisible = 4,
        //Gone = 8

        IViewHandler viewHandler;
#if ANDROID
        Android.Views.View androidView = null;
#endif
#if IOS
        UIKit.UIView iOSView = null;
#endif
#if WINDOWS
        Microsoft.UI.Xaml.UIElement windowsView = null;
#endif

        protected override void OnAttachedTo(VisualElement ve) {
            this.ve = ve;
            base.OnAttachedTo(ve);
            if (ve.Handler !=null) {
                getPlatformView();
                updateVisibility();
            }
            else {
                ve.HandlerChanged += delegate {
                    getPlatformView();
                    updateVisibility();
                };
            }
        }
        private void getPlatformView() {
            viewHandler = ve.Handler;

#if ANDROID
            androidView = viewHandler.PlatformView as Android.Views.View;
#elif IOS
            iOSView = viewHandler.PlatformView as UIKit.UIView;
#elif WINDOWS
            windowsView = viewHandler.PlatformView as Microsoft.UI.Xaml.UIElement;
#else

#endif

        }
        private void updateVisibility() {
#if ANDROID
            if (androidView != null) {
                if (visibility == Visibility.Hidden) {
                    ve.IsVisible = true;
                    androidView.Visibility = Android.Views.ViewStates.Invisible;
                }
                else {
                    ve.IsVisible = visibility == 0; 
                }
            }

#elif IOS
            if (iOSView != null) {
                if (visibility == Visibility.Hidden) {
                    ve.IsVisible = true;
                    iOSView.Hidden = true;
                }
                else {
                    ve.IsVisible = visibility == 0;
                }
            }
#elif WINDOWS
            if (windowsView != null) {
                if (visibility == Visibility.Hidden) {
                    ve.IsVisible = true;
                    windowsView.Visibility = Microsoft.UI.Xaml.Visibility.Collapsed; //ONLY OPTION RIGHT NOW.
                }
                else {
                    ve.IsVisible = visibility == 0; 
                }

            }
#else
            ve.IsVisible = visibility == 0; 
#endif

        }
        protected override void OnDetachingFrom(VisualElement ve) {
            this.ve = null;
            base.OnDetachingFrom(ve);
        }
        public void setVisibility(Visibility visibility) {
            this.visibility = visibility;
            updateVisibility();
        }
    }

From what I am gathering in this thread @mattleibow , Windows used to support the Hidden Visibility status but now this is removed in the current system:

https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.visibility?view=winrt-22621

Given the current Maui system works as shown above for all three of Visible, Hidden, and Collapsed for iOS and Android, is there any reason we can't make it work for Microsoft too?

I mean, Microsoft makes both Maui and Windows. Why should Microsoft be the holdup on it? Can you ask any of your colleagues if they can add the Hidden capacity back for Windows apps?

Then Maui can formally support all three or at least we can make our own custom code to do all three.

[hartez]

Why not then give us all three choices?

Historically, this was because the underlying platforms didn't have 3 choices. Xamarin.Forms was originally written for iOS (which only has "visible" and "hidden") and Android (which has all 3). UWP was added later, which only supported "visible" and "collapsed". (WPF has all 3 options, but Forms/WPF support was sadly only a community.) So Xamarin.Forms, for better or worse, only had 2 visible states and mapped them (unfortunately) to a boolean.

The core layer of MAUI (MAUI.Core) actually does support all 3, as you've found while reading the code. The hope is to eventually deprecate IsVisible and directly support 3-state Visibility; 95% of the work to support that has been done. But for migration/backward compatibility reasons, it was decided that MAUI.Controls (the full UI/MVVM/etc layer) would launch with just IsVisible. Hopefully a full Visibility property will happen at some point, but as I think you've noticed things are a bit in the weeds at the moment.

Until a 3-state property exists, you have some options. Take a look at https://github.com/hartez/RemapVisibility for some alternate ways you can handle visibility in your MAUI.Controls applications.

[Xyncgas]

Maybe we deserve a render stack to put controls inside and it renders, we can say it's on or off or whatever but when we remove it from the stack it's really destoryed

[davepruitt]

Any updates from the MAUI team on implementing this feature?