Status Update
Comments
vi...@google.com <vi...@google.com>
vi...@google.com <vi...@google.com> #2
Please provide sample project or apk to reproduce the issue.
Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Expected output
What is the expected output?
Current output
What is the current output?
logcat output
See
si...@gmail.com <si...@gmail.com> #3
vi...@google.com <vi...@google.com> #4
Please confirm if this is the issue. If not please provide the right sample code to reproduce the issue accordingly to what you experience.
si...@gmail.com <si...@gmail.com> #5
The repo also contains a layout file with an item view that does not produce the problem (working_item_view.xml), and if you inflate that one instead in the adapter you will see that the background color that is shown as red in your screenshots will be blue. Blue is the background color of the root view (ConstraintLayout) which is full size in the activity and should thus be visible between the green view at the bottom and the RecyclerView.
vi...@google.com <vi...@google.com> #6
si...@gmail.com <si...@gmail.com> #7
si...@gmail.com <si...@gmail.com> #8
se...@springworks.in <se...@springworks.in> #9
sh...@google.com <sh...@google.com> #10
Can you determine how old of a regression this is? Is this reproducible with support library ConstraintLayout 27.0 and/or RecyclerView 27.0?
That will help determine prioritization on my end.
Thanks,
-Shep
vi...@google.com <vi...@google.com> #11
We have narrowed down the support libraries of constraintLayout , recyclerview and appcompat and found out that:
-> The issue seems to be with the constraintLayout:1.1.0-beta2 where constrainedheight is added as per the release notes
used appcompat-v7:28.0.0 and recyclerview-v7:28.0.0.
Attached apk, bug-report, screen-shot and sample code are available here:
->The app works fine with constraintLayout:1.1.0-beta1 as we can not use the attribute constrainedheight in this library.
used appcompat-v7:28.0.0 and recyclerview-v7:28.0.0.
Attached apk, bug-report, screen-shot and sample code are available in
-> Libraries above constraintLayout:1.1.0-beta2 (1.1.0, 1.1.0 beta-3 to beta 6, 1.1.1, and so on) has the issue.
sh...@google.com <sh...@google.com> #12
The issue may actually be with RecyclerView and not with ConstraintLayout. Can you please keep ConstraintLayout at the AndroidX version 1.1.3 and see at which version of RV the bug is no longer reproducible. I'd like you to try going back all the way to the RecyclerView support library version 25, but if that isn't feasible, just go back as far as you can until the issue no longer reproduces.
That would be very helpful!
Thanks!
vi...@google.com <vi...@google.com> #13
As per the request in
Issue is observed in almost all of the versions of RV till 21.0.0.
Below 21.0.0 we couldn't get the library versions hence we couldn't check in them.
Attached screen-shots for reference.
sh...@google.com <sh...@google.com> #14
I appreciate the effort!
sh...@google.com <sh...@google.com> #15
I took your sample and took the RecyclerView out of the equation, and the odd measuring behavior persisted. A colleague then took a look and realized that if layout_constrainedHeight was taken out, then everything worked correctly. Double checked the same behavioral change by putting RV back into the equation and removing layout_constrainedHeight also seemed to fix the issue.
I'm forwarding this on to the primary owner of ConstraintLayout for further analysis.
sh...@google.com <sh...@google.com> #16
If you take the same app from
<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout
xmlns:android="
xmlns:app="
xmlns:tools="
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#0000FF">
<androidx.constraintlayout.widget.ConstraintLayout
android:id="@+id/recyclerView"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:background="#FF0000"
app:layout_constrainedHeight="true"
app:layout_constraintBottom_toTopOf="@id/bottomGreenView"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintHeight_max="0dp"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
app:layout_constraintVertical_bias="0">
<TextView
android:id="@+id/itemViewTextView"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_margin="15dp"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
tools:text="List item 0" />
</androidx.constraintlayout.widget.ConstraintLayout>
<View
android:id="@+id/bottomGreenView"
android:layout_width="0dp"
android:layout_height="100dp"
android:background="#00FF00"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent" />
</androidx.constraintlayout.widget.ConstraintLayout>
Can you quickly explain what app:layout_constrainedHeight is supposed to do here and why adding it results in the strange layout behavior that it does? Is this a bug?
ma...@gmail.com <ma...@gmail.com> #17
<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_margin="16dp"
android:text=" Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam pellentesque velit vel facilisis maximus. Proin eu ornare ante. Cras posuere elit nunc, in maximus mi varius sed. Donec fringilla facilisis metus, non sagittis nulla ullamcorper nec. Vivamus risus augue, auctor nec nisi vitae, vulputate posuere eros. Integer volutpat venenatis metus, sit amet tristique augue maximus nec. Ut vulputate placerat eros. Duis porta feugiat lectus."
app:layout_constrainedHeight="true"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />
</androidx.constraintlayout.widget.ConstraintLayout>
If you notice (don't need to run it, just paste it in Android Studio and observe the Preview), the text view is clipping the last line.
Now you can do a few things, but in short:
1. If you remove the Margin, the problem goes away.
2. If you remove the constrainedHeight (or set it to false), the problem goes away.
3. If you remove both... well, if a tree falls and nobody hears it... did it really fall?
There's clearly a calculation made by CL that is not right when there's a margin or the height has to be constrained.
ni...@google.com <ni...@google.com> #18
ni...@google.com <ni...@google.com>
ma...@gmail.com <ma...@gmail.com> #19
I just tested the above layout (the textView I posted) with 2.0.0-beta7
and it appears to be working fine.
Nick, can you explain what constrainedHeight(and width) exactly do to the algorithm?
What does it mean to have it, and what side-effects does it have; it's very mysterious and I don't know any developer who doesn't "try it" to "see if it does anything" (it mostly never does, I've only found real valid differences in rare instances, and it was mostly due to the "non constrainedXXX" version doing something that seemed incorrect at the time). But then again, I usually have a hard time explaining it to peers.
I mostly describe these two properties as something along the lines of (and I paraphrase me):
"If you set this to true, you're telling CL that it's O.K. to 'break' some constrains to accommodate for what you're asking, e.g.: a TextView with WRAP content, may need to 'violate' a constrain to be able to wrap a dimension which would have otherwise been made 0dp/match_constraint"
I use different words, different times, am I misunderstanding this?
ni...@google.com <ni...@google.com> #20
- if it's a fixed dimension, CL will just use that dimension
- if it's match_parent, CL will use the exact dimension of parent
- if it's wrap_content, CL will ask the widget for its size, but then use it as a fixed dimension
- if it's 0dp, CL will apply constraints to the dimension
0dp has notably spread and wrap behavior (also percent). the wrap behavior starts with the dimension of the widget's wrap_content, but constraints /can/ impact it.
Now why do we need constrainedWidth/Height? well... it's because some widgets (looking at you, TextView) takes some shortcuts and if they see 0dp they sometimes will not update correctly (note that this use of 0dp is what LinearLayout did for weights, not like CL did something new).
So with this context -- what does constrainedWidth/Height do? if the widget's dimension is set to wrap_content, it's just another way to say 0dp+wrap behavior. But this way TextView will correctly remeasure itself.
Typically this problem happens when trying to reuse TextView, e.g. in a Recyclerview item.
ni...@google.com <ni...@google.com> #21
ma...@gmail.com <ma...@gmail.com> #22
Thank you very much for the detailed info. Relying to everyone on my team :)
Description
- androidx.appcompat:appcompat:1.0.2
- androidx.constraintlayout:constraintlayout:1.1.3
Version used: Android Q beta 1, but also on P, likely also lower
Theme used: AppCompat.Light
Devices/Android versions reproduced on:
- Pixel 3, Android Q beta
- Also in the layout designer
Note that I've also asked this as a question on StackOverflow:
Code to reproduce:
<!-- container.xml -->
<androidx.constraintlayout.widget.ConstraintLayout
xmlns:android="
xmlns:app="
xmlns:tools="
android:layout_width="match_parent"
android:layout_height="600dp"
android:background="#0000FF">
<View
android:id="@+id/bottomGreenView"
android:layout_width="0dp"
android:layout_height="100dp"
android:background="#00FF00"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent" />
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/recyclerView"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:background="#FF0000"
app:layout_constrainedHeight="true"
app:layout_constraintHeight_max="0dp"
app:layout_constraintVertical_bias="0"
app:layout_constraintBottom_toTopOf="@id/bottomGreenView"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
tools:itemCount="1"
tools:listitem="@layout/test_list_item" />
</androidx.constraintlayout.widget.ConstraintLayout>
<!-- test_list_item.xml -->
<androidx.constraintlayout.widget.ConstraintLayout
xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="#FFFFFF">
<TextView
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_margin="15dp"
android:text="List item here"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />
</androidx.constraintlayout.widget.ConstraintLayout>
See issue.png for what the end-result looks like with the code above running on a Pixel 3 with Android Q beta 1. See expected.png for what I would expect the UI to look like.
I did manage to get this to work by changing the TextView's (in the list item) width to wrap_content instead of 0dp (MATCH_CONSTRAINT). However, that is not a viable option in many scenarios where there are elements on the right that should not overlap the text on the left. (The issue is also present if one constrain the TextView to another view on the right side.)
Interestingly, this does actually work as expected if I have the TextView's width `wrap_content` and remove its end-to-end constraint (the latter only so that it's not being centered horizontally). However, in my actual app I need these constraints as I also have content on the right side that I don't want to potentially overlap with long texts.