Xamarin.forms: [iOS] ListView Group Header size incorrect on iOS

Created on 12 Sep 2018  路  28Comments  路  Source: xamarin/Xamarin.Forms

Description

When using a grouped ListView with a custom header template, Android and UWP expand the header size.

iOS has a set height to the cell, and then overflows to write over the children cells

Steps to Reproduce

Run the supplied project on iOS. See it look like trash.

Expected Behavior

Headers resize

Actual Behavior

They do not.

Basic Information

Ran on iOS simulator and a real device on iOS 11.3 and 11.4.

  • Version with issue: Forms 3.2.0
    Never seen it work, been around since 1.3

Screenshots

iOS:
2018-09-12_10-24-33-am

UWP:

image

Reproduction Link

ListViewHeaderRpo.zip

layout listview 4 high impact iOS 馃崕 bug

Most helpful comment

Would like to know what will be the version with this fix

All 28 comments

what happend to this issue?

This is surely a priority 1 issue?

For anyone who cares, this issue still happens as of Forms 3.6 latest at this time.

I just updated this morning to check.

There are historical threads on the old Xamarin Forums dating back to 2014 discussing this issue. It's also on the Bugzilla in various issues. We are now in 2019 and still XF on iOS cannot properly adjust for height of a ListView Header. Let that sink in for a minute... ;-)

I've looked at the relevant bits of source code in XF and it actually looks quite trivial to fix. Basically, it isn't using the AutomaticDimension that iOS has supported for a while now. Which is odd because XF did implement support for this on regular rows... go figure.

In the next day or two I am going to have a go at making a custom renderer to fix it.

    internal class HeaderWrapperView : UIView
    {
        public Cell Cell { get; set; }
        public override void LayoutSubviews()
        {
            base.LayoutSubviews();
            foreach (var item in Subviews)
                item.Frame = Bounds;
        }
    }

https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Platform.iOS/Renderers/ListViewRenderer.cs#L1431

This wrapper view that wraps all section headers is the root cause of the problem. The way it is laying out the subviews like that is quite bizarre and will certainly be screwing up iOS' AutoLayout mechanism which is needed to support AutomaticDimension.

I've got a fix, both in the form of a Renderer hackfix but also as a proposed patch to XamForms.

The proposed patch is:

Change the HeaderWrapperView class as follows:

            internal class HeaderWrapperView : UIView {
                public Cell Cell { get; private set; }
                public UIView Subview { get; private set; }

                public HeaderWrapperView(Cell cell, UIView subview) {
                    Cell = cell;
                    Subview = subview;
                    AddSubview(subview);
                }

                public override CGSize SizeThatFits(CGSize size) {
                    return Subview.SizeThatFits(size);
                }

                public override CGSize IntrinsicContentSize => Subview.IntrinsicContentSize;

                public override void LayoutSubviews() {
                    base.LayoutSubviews();
                    Subview.Frame = Bounds;
                }
            }

Change the GetViewForHeader method as follows:

// remove the following 2 lines:
-    view = new HeaderWrapperView { Cell = cell };
-    view.AddSubview(renderer.GetCell(cell, null, tableView));

// replace with this line:
+    view = new HeaderWrapperView(cell, renderer.GetCell(cell, null, tableView));

And here is my renderer hackfix for those that need an immediate solution to use whilst they wait for the above patch to be incorporated in a new release of XF: https://gist.github.com/nbevans/a713dc9c77a8f530b6f4f3cd4fad83c2

@samhouts @PureWeen Can we reprioritise this issue now and try to get it fixed in the vNext and all the service releases as well?

@samhouts ? That new inactive tag really seems effective! ;-)

Will my fix ever get merged in?

Im waiting for this fix to be merged, @samhouts when can we expect this fix to be merged? thanks and keep up the good work both of you :)

@nbevans Would you care to submit a pull request? Thanks!

Has this been fixed in Xamarin Forms? If so, which version?

@nbevans I鈥檝e incorporated your fix here: https://github.com/xamarin/Xamarin.Forms/blob/fix-3769/Xamarin.Forms.Platform.iOS/Renderers/ListViewRenderer.cs

The only thing I鈥檓 worried about is the backwards compatibility. Before this, the header would have a certain height. People might depend on that now. With this fix the height, when not setting the height explicitly, will suddenly be determined automatically.

Would like to know what will be the version with this fix

@nbevans I鈥檝e incorporated your fix here: https://github.com/xamarin/Xamarin.Forms/blob/fix-3769/Xamarin.Forms.Platform.iOS/Renderers/ListViewRenderer.cs

The only thing I鈥檓 worried about is the backwards compatibility. Before this, the header would have a certain height. People might depend on that now. With this fix the height, when not setting the height explicitly, will suddenly be determined automatically.

That's great. As far as the backcompat is concerned we could introduce a property to enable/disable the automatic height mode (and default it to disabled to maintain compat)

When can this be merged into the mainline @samhouts ?

Yes this is quite a pain, hoping soon!!

Do we know in which Xamarin.Forms version this bug will be fixed? It's quite painful.

I just upgraded to XF ver. 4.7 but this issue is still there.
Also, renderer given by @nbevans was working absolutely fine with XF 4.5 but after upgrading to XF 4.7 it is throwing an exception - "Objective-C exception thrown. Name: NSInternalInconsistencyException Reason: UITableViewHeaderFooterView's contentView must remain a direct subview of it. Unexpected superview of the contentView"

Anyone else facing a similar issue? and Do we know in which Xamarin. Forms version this bug will be fixed?

@samhouts @jamesmontemagno Pretty please can this fix be sorted out?

I just upgraded to XF ver. 4.7 but this issue is still there.
Also, renderer given by @nbevans was working absolutely fine with XF 4.5 but after upgrading to XF 4.7 it is throwing an exception - "Objective-C exception thrown. Name: NSInternalInconsistencyException Reason: UITableViewHeaderFooterView's contentView must remain a direct subview of it. Unexpected superview of the contentView"

Anyone else facing a similar issue? and Do we know in which Xamarin. Forms version this bug will be fixed?

I am now seeing this exception when I upgraded to Xamarin.Forms 4.8 the other day. Does anyone have a workaround to the renderer given by @nbevans to solve this new issue?

I think my fix was broken when they made this commit: https://github.com/xamarin/Xamarin.Forms/commit/ff74a81a03dfe51cabde71a20f15158b5e5b4911#diff-198607f4ce97efcc515a271473524b08

My fix needs some tweaks to make it work with this change.

I think my fix was broken when they made this commit: ff74a81#diff-198607f4ce97efcc515a271473524b08

My fix needs some tweaks to make it work with this change.

Thanks @nbevans So I replaced the following 2 lines in your renderer hackfix

var newWrapper = new HeaderWrapperView(cell, cellView);
return newWrapper;

with

var renderer = (CellRenderer)Xamarin.Forms.Internals.Registrar.Registered.GetHandlerForObject<IRegisterable>(cell);
var view = new HeaderWrapperView(cell, renderer.GetCell(cell, null, tableView));

And now it seems to work okay without the crash.

That looks like a good stop-gap fix. It would really ideal if Xamarin Forms team just included my fix in the core codebase.

It looks like they're now eyeing v5.0 to include this fix but that is a shame since my understanding is that v5.0 is the MAUI release - so does that mean Xamarin Forms will never actually get this fix before it enters the 2 year maintenance-only period?

Important fix for me too

For all guys out there who want to make the groupheader invisible, you have to set the ViewCell Height on iOS to 0.0001 or something like that but not zero

@samhouts not anymore?

a definitive fix is really needed!

Was this page helpful?
0 / 5 - 0 ratings