Status Update
Comments
an...@google.com <an...@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
mi...@google.com <mi...@google.com> #3
mi...@google.com <mi...@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.
an...@google.com <an...@google.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.
[Deleted User] <[Deleted User]> #6
ad...@lawmaster.com.au <ad...@lawmaster.com.au> #7
pe...@gmail.com <pe...@gmail.com> #8
it...@entitysolutions.com.au <it...@entitysolutions.com.au> #9
or...@gmail.com <or...@gmail.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
cu...@gmail.com <cu...@gmail.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.
st...@mandrill.emotedigital.com.au <st...@mandrill.emotedigital.com.au> #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!
[Deleted User] <[Deleted User]> #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.
ju...@bubsngrubs.com.au <ju...@bubsngrubs.com.au> #14
I appreciate the effort!
cy...@gmail.com <cy...@gmail.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...@gmail.com <sh...@gmail.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?
ro...@captovate.com.au <ro...@captovate.com.au> #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.
sh...@gmail.com <sh...@gmail.com> #18
co...@googlemail.com <co...@googlemail.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?
si...@gmail.com <si...@gmail.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.
am...@gmail.com <am...@gmail.com> #21
[Deleted User] <[Deleted User]> #22
Thank you very much for the detailed info. Relying to everyone on my team :)
mo...@gmail.com <mo...@gmail.com> #23
ez...@gmail.com <ez...@gmail.com> #24
ti...@digistorm.com <ti...@digistorm.com> #25
pr...@gmail.com <pr...@gmail.com> #26
ro...@gobigriver.com <ro...@gobigriver.com> #27
ch...@gmail.com <ch...@gmail.com> #28
li...@gmail.com <li...@gmail.com> #29
ry...@gmail.com <ry...@gmail.com> #30
da...@gmail.com <da...@gmail.com> #31
mi...@gmail.com <mi...@gmail.com> #32
This way you will vote for the issue and get notified for its status... And not spam everyone else.
ik...@gmail.com <ik...@gmail.com> #33
af...@gmail.com <af...@gmail.com> #34
mj...@gmail.com <mj...@gmail.com> #35
[Deleted User] <[Deleted User]> #36
jo...@jch254.com <jo...@jch254.com> #37
mb...@gmail.com <mb...@gmail.com> #38
[Deleted User] <[Deleted User]> #39
st...@gmail.com <st...@gmail.com> #40
[Deleted User] <[Deleted User]> #41
With the absence of this feature, we will have to build our own Autocomplete API that uses the Google Places Autocomplete and is backed by the Geocode API. Of course our API will not be as good as Google APIs.
mi...@google.com <mi...@google.com>
mi...@google.com <mi...@google.com> #42
Since July 28th, Place Autocomplete supports subpremise predictions in 3 countries:
Australia, New Zealand and Canada.
We acknowledge support for US address is on demand and will look into this.
Unfortunately there is a new issue where a few subpremise predictions return a Place ID that cannot be retrieved from Place Details:
We are actively working on a fix for this.
There is no ETA we can provide at this time for any of the above. We will keep you posted.
bs...@gmail.com <bs...@gmail.com> #43
[Deleted User] <[Deleted User]> #44
ac...@salesforce.com <ac...@salesforce.com> #45
Based on the behavior in the following API demo:
1) When subpremise is included in the search, it can be recognized and predictions returned contain addresses which match the subpremise
2) However, when the prediction is selected, the subpremise part is taken as street number, and the street number gets eliminated from the auto-populated address field.
Appreciate your clarification on this behavior.
Thank you
mi...@google.com <mi...@google.com> #46
Yes, that is the case.
Place Autocomplete preserves user input as closely as possible. In the case of subpremise tokens, these will typically be returned in the prediction from Place Autocomplete (1) even if there is no guarantee that Place Details will return the same (2). This Feature Request is directed at returning these subpremise tokens also in the Place Details response. This is currently available only in Australia, New Zealand and Canada. We are working on expanding this to other countries, including US.
ac...@salesforce.com <ac...@salesforce.com> #47
Hello there,
Thank you for the quick response!
Regarding the statement "This is currently available only in Australia, New Zealand and Canada", are you refer to the support for subpremise in the Place Automcomplete(1) only, or that it is currently supported (guaranteed to be returned) in the Place Details response for these 3 countries too?
Thanks again for your clarification! :)
mi...@google.com <mi...@google.com> #48
In these 3 countries, for the specific subpremise formats that are supported, Place Autocomplete returns a different Place ID that guarantees Place Details will return the subpremise token.
For instance, the Place ID for the address in
mi...@google.com <mi...@google.com> #49
We greatly appreciate your patience and have good news: subpremise predictions are now returned in all countries.
When Place Autocomplete recognizes the input as representing a subpremise location (e.g. apartment, suite, etc.) one or more predictions are returned with types: ["subpremise","geocode"]
and a Place ID that will enable Place Details to do the same.
Example address: tome cano 9 piso 11 puerta 13
description: "Calle Tome Cano, 9, piso 11 puerta 13, Santa Cruz de Tenerife, Spain",
place_id: "EkRDYWxsZSBUb21lIENhbm8sIDksIHBpc28gMTEgcHVlcnRhIDEzLCBTYW50YSBDcnV6IGRlIFRlbmVyaWZlLCBTcGFpbiItGisKFgoUChIJDzhGUJrMQQwRK8l9IT0vJVwSEXBpc28gMTEgcHVlcnRhIDEz",
types: ["subpremise","geocode"]
formatted_address: "C. Tome Cano, 9, piso 11 puerta 13, 38005 Santa Cruz de Tenerife, Spain",
name: "C. Tome Cano, 9, piso 11 puerta 13",
types: ["subpremise"],
Additional example addresses, as previously reported here:
9500 Bryn Mawr Avenue #650
description: "9500 West Bryn Mawr Avenue #650, Rosemont, IL, USA",
place_id: "EjI5NTAwIFdlc3QgQnJ5biBNYXdyIEF2ZW51ZSAjNjUwLCBSb3NlbW9udCwgSUwsIFVTQSIfGh0KFgoUChIJE0vqdAi2D4gR9ySp6a8lEmkSAzY1MA",
types: ["subpremise","geocode"]
formatted_address: "9500 W Bryn Mawr Ave #650, Rosemont, IL 60018, USA",
name: "9500 W Bryn Mawr Ave #650",
types: ["subpremise"],
130 Bowdoin st., apt. 1010
description: "130 Bowdoin St apt 1010, Dorchester, MA, USA",
place_id: "EiwxMzAgQm93ZG9pbiBTdCBhcHQgMTAxMCwgRG9yY2hlc3RlciwgTUEsIFVTQSIkGiIKFgoUChIJ-wFl5bh744kR-oIrrKrdqwcSCGFwdCAxMDEw",
types: ["subpremise","geocode"]
formatted_address: "130 Bowdoin St apt 1010, Dorchester, MA 02122, USA",
name: "130 Bowdoin St apt 1010",
types: ["subpremise"],
gaston geenslaan 11/b4
description: "Gaston Geenslaan 11/b4, Leuven, Belgium",
place_id: "EidHYXN0b24gR2VlbnNsYWFuIDExL2I0LCBMZXV2ZW4sIEJlbGdpdW0iHhocChYKFAoSCUcVDMwIYcFHEfSCQ0O8JMyFEgJiNA",
types: ["subpremise","geocode"]
formatted_address: "Gaston Geenslaan 11/b4, 3001 Leuven, Belgium",
name: "Gaston Geenslaan 11/b4",
types: ["subpremise"],
515 W 42nd St #10, New York, NY 10036, USA
description: "515 W 42nd St #10, New York, NY 10036, USA",
place_id: "Eio1MTUgVyA0Mm5kIFN0ICMxMCwgTmV3IFlvcmssIE5ZIDEwMDM2LCBVU0EiHhocChYKFAoSCUWVl5ZNWMKJEbXGp_jlkxplEgIxMA",
types: ["subpremise","geocode"]
formatted_address: "515 W 42nd St #10, New York, NY 10036, USA",
name: "515 W 42nd St #10",
types: ["subpremise"],
We believe this issue is now fixed, hence marking it as such.
Thanks for working with us!
ma...@gmail.com <ma...@gmail.com> #50
ra...@remato.com <ra...@remato.com> #51
For example:
"Pikk 74, Tartu, Eesti" returns type "premise" prediction with placeId "ChIJv5XKc9s260YRdo9JMHN3oE8"
But input with apartment number "Pikk 74-3, Tartu, Eesti" returns only type "street_address" with inaccurate placeId "EhdQaWtrIDc0LTMsIFRhcnR1LCBFZXN0aSIwEi4KFAoSCcNrdp7bNutGEYzpBfD8K5N7EEoqFAoSCY9eIILcNutGEeF6uOx2JXki"
mi...@google.com <mi...@google.com> #52
Please
Description
* 9500 Bryn Mawr Avenue #650:
* 1403/648 Bourke Street:
"130 Bowdoin st., apt. 1010" also gives 0 results, looks like suite/apartment isn't recognized at all.
Related issue: