Fix measurement of Row and Column on iOS inside of UIStackView #2426
Conversation
There was a problem hiding this comment.
More ComposeUI layouts that are broken. This is a problem, but it’s not new and it’s not urgent.
| this.alignment = UIStackViewAlignmentLeading | ||
| this.distribution = UIStackViewDistributionFill | ||
| this.alignment = UIStackViewAlignmentFill | ||
| this.distribution = UIStackViewDistributionEqualSpacing |
There was a problem hiding this comment.
I had better luck with these ones
| @@ -144,8 +144,8 @@ class UIViewScrollWrapper : ScrollWrapper<UIView> { | |||
| scrollView.addSubview(value) | |||
| value.translatesAutoresizingMaskIntoConstraints = false | |||
| value.leadingAnchor.constraintEqualToAnchor(scrollView.leadingAnchor).active = true | |||
| value.widthAnchor.constraintEqualToAnchor(scrollView.widthAnchor).active = true | |||
There was a problem hiding this comment.
It’s way too cute, but UIScrollView scrolls horizontally if you bind leading and trailing, but doesn’t scroll horizontally if you bind leading and width.
| override fun invalidateIntrinsicContentSize() { | ||
| super.invalidateIntrinsicContentSize() | ||
| this.widthForIntrinsicSize = UIViewNoIntrinsicMetric | ||
| this.heightForIntrinsicSize = UIViewNoIntrinsicMetric |
There was a problem hiding this comment.
I don’t have a test case to prove that this override is necessary. I might try to make one? That might be tricky
redwood-layout-uiview/src/commonMain/kotlin/app/cash/redwood/layout/uiview/YogaUIView.kt
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Without the fix, this thing’s intrinsicContentSize is is 10,000 pixels wide and 20 pixels tall
There was a problem hiding this comment.
Similarly, without the fix each subview is super wide and not very tall
swankjesse
force-pushed
the
jwilson.1104.intrinsicSize
branch
from
a77d94a to
c3828da
Compare
swankjesse
force-pushed
the
jwilson.1031.test_redwood_view_measurement
branch
from
d861e69 to
483577f
Compare
swankjesse
force-pushed
the
jwilson.1104.intrinsicSize
branch
from
c3828da to
0aa3561
Compare
| * We work around this by: | ||
| * | ||
| * 1. Making [intrinsicContentSize] depend on the mostly-recently applied bounds | ||
| * 2. Invalidating it each time the bounds change |
There was a problem hiding this comment.
This work around sounds good to me, though @edahle do you know how a UITextView and other views that depend on knowing the width to compute the height provide a reasonable intrinsicContentSize? Maybe private APIs of some kind?
There was a problem hiding this comment.
UILabel has a feature called preferredMaxLayoutWidth that you can use for this.
UIStackView uses UIView.intrinsicContentSize on its subviews, but our Row and Column implementations don't have a natural implementation of this API. In particular, if any subview wraps its contents (so its height depends on its available width), there's no single intrinsicContentSize(). We work around this by following some online advice: invalidate the intrinsic size when the bounds change, and then use those bounds when computing the new intrinsic size. This is more fragile and stateful than I'd like, but it seems like a common practice for working around UIStackView's API.
swankjesse
force-pushed
the
jwilson.1104.intrinsicSize
branch
from
0aa3561 to
581c732
Compare
UIStackView uses UIView.intrinsicContentSize on its subviews, but our Row and Column implementations don't have a natural implementation of this API. In particular, if any subview wraps its contents (so its height depends on its available width), there's no single intrinsicContentSize().
We work around this by following some online advice: invalidate the intrinsic size when the bounds change, and then use those bounds when computing the new intrinsic size.
This is more fragile and stateful than I'd like, but it seems like a common practice for working around UIStackView's API.
CHANGELOG.md's "Unreleased" section has been updated, if applicable.