Issue with preferredWrapContent when content is updated [219091179]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Feb 12, 2022 08:11AM

ConstraintLayout version: 1.O

I'm using a Composable which take a content @Composable in parameter, and it seems that with the final version of ConstraintLayout, there is no update.

Here is the code

@Composable
Example(
modifier : Modifier = Modifier,
content : @Composable () -> Unit
) {
ConstraintLayout(modifier = modifier
.fillMaxSize()
.background(color = Color.Blue)
) {
val (title, someContent) = createRefs()

Text(text = "a text", modifier = Modifier.constrainAs(title) {
top.linkTo(parent.top)
height = Dimension.wrapContent
width = Dimension.wrapContent
})

Box(modifier = Modifier
.constrainAs(someContent) {
width = Dimension.fillToConstraints
linkTo(start = parent.start, end = parent.end)
linkTo(top = parent.top, bottom = parent.bottom, bias = 1.0f)
height = Dimension.preferredWrapContent
}
.background(color = Color.Yellow)) {
content()
}
}
}
The Box height is initialized with the fist element received by the composable and does not change anymore.

For example, I send to this composable a Column with [Button + result of a Webservice]. The button is displayed at startup, and then after some times I received the result of the API, it does not recompose correctly, the size of the Box stays wrapcontent with the button only!
Moreover, it seems that the behaviour in a compose MotionLayout is the same (no update)

Comments

is...@google.com <is...@google.com> Feb 13, 2022 07:18AM

Status: New

[Deleted User] <[Deleted User]> #2Feb 23, 2022 04:56PM

> The Transition Kotlin extensions target the Framework Transition class which is a bit confusing

All extensions in 'core-ktx' target either 'core' or the framework types. This is working as expected. It sounds like this is a feature request for a transition-ktx with equivalent extensions for the androidx.transition types.

> as most framework classes are being deprecated in favor of their AndroidX counterparts, Fragments for example.

"Most"? This *dramatically* overstates what is actually happening. Fragments (and loaders) were added to the framework in a time where the Android team did not have external libraries for shipping features. Transition was added 5 years later.

os...@google.com <os...@google.com> Apr 15, 2022 08:57PM

Assigned to os...@google.com.

ho...@google.com <ho...@google.com> #3Apr 16, 2022 01:24AM

Pardon my misunderstanding, I was under the belief that where possible, new features that could be developed outside the framework, would be under Androidx. Also it's a common refrain to use the Androidx libraries over the framework libraries where possible, as those ship update independently of platform releases. I wasn't attempting to be dramatic.

If the Transition api is unlikely to change, there is no need for a transition-ktx for androidx.transition types. If developers should use Androidx transitions over framework transitions where possible however, then it would be much appreciated.

I am well aware of the limitations that existed when Fragments and Loaders were created, and when the Transition api was introduced.

ti...@gmail.com <ti...@gmail.com> #4Apr 16, 2022 05:33AM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit ae42e311ecfbac18cedc90e489d1fdde956a4557
Author: Jake Wharton <jakew@google.com>
Date: Fri Nov 22 11:13:30 2019

Introduce transition-ktx for standalone transition library

These extensions are the same as androidx.core.transition for the platform types, just adapted to the standalone library.

Bug: 138870873
Test: gw :transition:transition-ktx:build :transition:transition-ktx:connectedCheck
Change-Id: Ie80022cc60ed1f482b7593db5ef1ac1c5ea33d8d

M buildSrc/src/main/kotlin/androidx/build/PublishDocsRules.kt
M jetifier/jetifier/migration.config
M settings.gradle
A transition/transition-ktx/OWNERS
A transition/transition-ktx/api/1.4.0-alpha01.txt
A transition/transition-ktx/api/current.txt
A transition/transition-ktx/api/public_plus_experimental_1.4.0-alpha01.txt
A transition/transition-ktx/api/public_plus_experimental_current.txt
A transition/transition-ktx/api/res-1.4.0-alpha01.txt
A transition/transition-ktx/api/restricted_1.4.0-alpha01.txt
A transition/transition-ktx/api/restricted_current.txt
A transition/transition-ktx/build.gradle
A transition/transition-ktx/src/androidTest/AndroidManifest.xml
A transition/transition-ktx/src/androidTest/java/androidx/transition/TestActivity.kt
A transition/transition-ktx/src/androidTest/java/androidx/transition/TransitionTest.kt
A transition/transition-ktx/src/androidTest/res/layout/test_activity.xml
A transition/transition-ktx/src/main/AndroidManifest.xml
A transition/transition-ktx/src/main/java/androidx/transition/Transition.kt

https://android-review.googlesource.com/1172715

[Deleted User] <[Deleted User]> #5Apr 19, 2022 07:13AM

I need preferredWrapContent for a specific case on an application. I want the content to never be outside my constraints, that's all.

ap...@google.com <ap...@google.com> #6Jan 10, 2023 07:56PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-main

commit 50fdccbb6bd61862f871944da801af71fee9870f
Author: Oscar Adame Vázquez <oscarad@google.com>
Date: Tue Nov 22 12:32:21 2022

Fix not being able to remeasure when the content changes

This makes it so that the MeasurePolicy is at least tied to content
composition. So that ConstraintLayout/MotionLayout are always able to
measure the content with their own logic.

Relnote: N/A

Bug: 243861990
Fixes: 219091179
Test: ConstraintLayoutTest, MultiMeasureCompositionTest
Change-Id: Ibfe8a2aeffba85aa6374d763729887aa1f308b35

M constraintlayout/constraintlayout-compose/api/public_plus_experimental_current.txt
M constraintlayout/constraintlayout-compose/api/restricted_current.txt
M constraintlayout/constraintlayout-compose/integration-tests/constraintlayout-compose-demos/src/main/java/androidx/constraintlayout/compose/demos/CustomKeyAttributesDemo.kt
M constraintlayout/constraintlayout-compose/src/androidAndroidTest/kotlin/androidx/constraintlayout/compose/ConstraintLayoutTest.kt
A constraintlayout/constraintlayout-compose/src/androidAndroidTest/kotlin/androidx/constraintlayout/compose/MultiMeasureCompositionTest.kt
M constraintlayout/constraintlayout-compose/src/androidMain/kotlin/androidx/constraintlayout/compose/ConstraintLayout.kt
M constraintlayout/constraintlayout-compose/src/androidMain/kotlin/androidx/constraintlayout/compose/MotionDragHandler.kt
M constraintlayout/constraintlayout-compose/src/androidMain/kotlin/androidx/constraintlayout/compose/MotionLayout.kt
M constraintlayout/constraintlayout-compose/src/androidMain/kotlin/androidx/constraintlayout/compose/MotionMeasurer.kt
M constraintlayout/constraintlayout-compose/src/androidMain/kotlin/androidx/constraintlayout/compose/MotionRenderDebug.java
M constraintlayout/constraintlayout-compose/src/androidMain/kotlin/androidx/constraintlayout/compose/Transition.kt

https://android-review.googlesource.com/2328906

ri...@ffw.com <ri...@ffw.com> #7Jan 20, 2023 08:14AM

Which version is this fix in?

os...@google.com <os...@google.com> #8Jan 20, 2023 07:35PM

Will be in 1.1.0-alpha06. Which is set to release next week.

pr...@google.com <pr...@google.com> #9Jan 25, 2023 09:35PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.constraintlayout:constraintlayout-compose:1.1.0-alpha06