Fixed
Status Update
Comments
ob...@gmail.com <ob...@gmail.com> #2
I was able to solve it with a custom LinearLayoutManager. It would be nice for the LinearLayoutManager to act this way by default but is not a RecyclerView defect.
to...@gmail.com <to...@gmail.com> #3
Hi obsidianx, what does your workaround look like, just ran into the same issue :(
ob...@gmail.com <ob...@gmail.com> #4
I borrowed the solution from the LeanBack source code in GridLayoutManager.java. Basically in onMeasure of the LayoutManager you check to see if you have any children in your layout yet and if not then have the associated RecyclerView build one for you so you can measure it.
Look at GridLayoutManager.measureScrapChild(...) to see what I'm talking about (<sdk>/extras/android/m2repository/com/android/support/leanback-v17/21.0.0-rc1/leanback-v17-21.0.0-rc1-sources.jar). This particular solution for measurement works best if all of the child views are the same width/height depending on orientation.
Look at GridLayoutManager.measureScrapChild(...) to see what I'm talking about (<sdk>/extras/android/m2repository/com/android/support/leanback-v17/21.0.0-rc1/leanback-v17-21.0.0-rc1-sources.jar). This particular solution for measurement works best if all of the child views are the same width/height depending on orientation.
ja...@gmail.com <ja...@gmail.com> #5
Could you post your code to your custom layout manager?
yb...@google.com <yb...@google.com>
be...@gmail.com <be...@gmail.com> #6
[Comment deleted]
be...@gmail.com <be...@gmail.com> #7
Attached is a custom LayoutManager based on obsidianx's suggestions which worked for me.
pa...@gmail.com <pa...@gmail.com> #8
The solution will work for fixed items provided in adapter. If the items are dynamically added/removed from the adapter then it will not work. For dynamically added items the onMeasure phase fires before any items are added in the view and hence the calculated height is returned as zero.
be...@gmail.com <be...@gmail.com> #9
You're right. I had to initialize the adapter with one dummy item so that the initial measuring could work. Then, later, after re-setting the adapter with the real set of (dynamically obtained) items, the recycler view was (somehow) still properly sized, without me needing to do anything.
ne...@gmail.com <ne...@gmail.com> #10
Check my improved solution: http://stackoverflow.com/a/27616854/1016367
Works good with dynamically changed data in adapter and with zero items adapter too.
Works good with dynamically changed data in adapter and with zero items adapter too.
go...@gmail.com <go...@gmail.com> #11
We really need proper "wrap_content" support in the official layout managers. Can we expect this to come any time soon?
wo...@gmail.com <wo...@gmail.com> #12
Why is this priority-small? Really, this should be a big focus, since RecylclerView is advertised everywhere and seems to be the perfect solution.
This makes layouts really defect, having dialogs strech over the full screen and making the intended use of Dialogs really to nonsense.
Did not find even a workaround yet. With the solution above there are no item decorations and if the list goes beyond the current screen size just all the elements disappear.
This makes layouts really defect, having dialogs strech over the full screen and making the intended use of Dialogs really to nonsense.
Did not find even a workaround yet. With the solution above there are no item decorations and if the list goes beyond the current screen size just all the elements disappear.
pa...@gmail.com <pa...@gmail.com> #14
I also have this problem however when I use the solutions given here and from StackOverflow my onBindViewHolder() gets spammed instead. It seems it's called for every item in the list, every time measureScrapChild() is called (so in my case 11 items -> 88 calls). This is a problem for me since I try to load images async when binding. Anyone have an idea on how to solve this?
se...@gmail.com <se...@gmail.com> #15
Here is my version of LinearLayoutManager which supports WRAP_CONTENT: https://github.com/serso/android-linear-layout-manager/blob/master/lib/src/main/java/org/solovyev/android/views/llm/LinearLayoutManager.java
I tried to fix the problems previously suggested solutions have. Note that the problem still should be solved by SDK itself as there is no way of getting information about dimensions of children when RecyclerView is animating.
Wrapped nicely in the library:https://github.com/serso/android-linear-layout-manager
I tried to fix the problems previously suggested solutions have. Note that the problem still should be solved by SDK itself as there is no way of getting information about dimensions of children when RecyclerView is animating.
Wrapped nicely in the library:
zt...@gmail.com <zt...@gmail.com> #16
This causes all sorts of problems, and should not be considered a "small defect".
al...@gmail.com <al...@gmail.com> #17
Has anyone a fixed GridLayoutManager? I'm an not so skilled android developer, to fix it myself.
co...@gmail.com <co...@gmail.com> #18
It's a shame this has already almost 1 year without a fix...
No wrap_content available for a master piece in the new Material Design pattern, Google do you think this is normal?? no way
No wrap_content available for a master piece in the new Material Design pattern, Google do you think this is normal?? no way
er...@gmail.com <er...@gmail.com> #19
Still not fixed yet :(
ak...@gmail.com <ak...@gmail.com> #20
This is actually really annoying without a fix. Come on Google.
ph...@gmail.com <ph...@gmail.com> #21
Wow. It's been a year but this issue is still not fixed.
fr...@googlemail.com <fr...@googlemail.com> #22
The github code from #15 finally works! Great job - thanks a bunch!
[Deleted User] <[Deleted User]> #23
Just hit this issue too, scratching my head until I saw this ticket
my...@gmail.com <my...@gmail.com> #24
This works for GridLayoutManager
ne...@gmail.com <ne...@gmail.com> #25
So much abandonment. Same quality apps you'll see on the playstore
[Deleted User] <[Deleted User]> #26
[Comment deleted]
rv...@gmail.com <rv...@gmail.com> #27
When is this going to be fixed?
yb...@google.com <yb...@google.com> #28
targeted for early 2016.
ka...@gmail.com <ka...@gmail.com> #29
If I use any custom LinearLayoutManager I am facing issue with scrolling it freezes the app and anr is coming up.
do...@gmail.com <do...@gmail.com> #30
[Comment deleted]
si...@gmail.com <si...@gmail.com> #31
really google? small priority? this messes up the staggeredgridlayoutmanager too.
ev...@gmail.com <ev...@gmail.com> #32
The CustomGridLayoutManager.txt have a bug in calculating the height for the recyclerview when manager.setSpanSizeLookup(new WrappableGridLayoutManager.SpanSizeLookup() {
@Override
public int getSpanSize(int i) {
if(i == 0){
return 2
} else {
return 1
}
}
@Override
public int getSpanSize(int i) {
if(i == 0){
return 2
} else {
return 1
}
}
[Deleted User] <[Deleted User]> #33
I waited till this 2016..but its waste...not solution till...what is this
[Deleted User] <[Deleted User]> #34
I waited till this 2016..but its waste...not solution till...what is this
pa...@gmail.com <pa...@gmail.com> #35
Will the early 2016 solution work also for StaggeredGridLayoutManager?
da...@gmail.com <da...@gmail.com> #36
Hi, I've bumped into this issue this week. First of all, thanks for whoever made that CustomGridLayoutManager available, saved me a lot of time. However, I've noticed a few shortcomings (to me, at least) that were not properly addressed in that class.
The main obstacle I noticed was that the class assumed the dimension of the first item was enough for all subsequent items, which is not the case when [i > 0] items are larger than the [i = 0] item. While it didn't actually crop the RecyclerView contents, it made it appear scrolling even when it should not (i.e., wrap_content with smaller size than the parent).
That said, I made some changes that better suited my case, commenting what I found adequate. It is tested (as far as I can think about use cases) with RecyclerView set to wrap_content and fixed size, which is what I need. I did not tested it (yet?) with max sizings or match_parent.
Link below.
https://gist.github.com/davidcesarino/7e85b5eee82307c06e08
Hope it helps, or at least gives any clue to someone who may be facing a similar challenge. Other than that, if you can help improve it, I'll be glad.
The main obstacle I noticed was that the class assumed the dimension of the first item was enough for all subsequent items, which is not the case when [i > 0] items are larger than the [i = 0] item. While it didn't actually crop the RecyclerView contents, it made it appear scrolling even when it should not (i.e., wrap_content with smaller size than the parent).
That said, I made some changes that better suited my case, commenting what I found adequate. It is tested (as far as I can think about use cases) with RecyclerView set to wrap_content and fixed size, which is what I need. I did not tested it (yet?) with max sizings or match_parent.
Link below.
Hope it helps, or at least gives any clue to someone who may be facing a similar challenge. Other than that, if you can help improve it, I'll be glad.
yb...@google.com <yb...@google.com> #37
#36, you need to disable predictive animations if you do that, otherwise, it may crash in onMeasure when new items are added. (see docs for differences between State#itemCount vs getItemCount).
Meanwhile, we are working on a generic solution where RecyclerView can do most of the work and also support predictive animations.
Meanwhile, we are working on a generic solution where RecyclerView can do most of the work and also support predictive animations.
da...@gmail.com <da...@gmail.com> #38
Thank you very much for your warning, as I'm still learning this.
mc...@gmail.com <mc...@gmail.com> #39
@davidcesarino You have a small bug in your WrappedGridLayoutManager. You're adding rowMeasure on item in the last row column but last row may end before last column. Imagine grid 3x3 with 7 items. I suppose your line 84 should look like this
if (i % getSpanCount() == (getSpanCount() - 1) || i == state.getItemCount() - 1) {
You may want to fix that.
if (i % getSpanCount() == (getSpanCount() - 1) || i == state.getItemCount() - 1) {
You may want to fix that.
lb...@gmail.com <lb...@gmail.com> #40
I don't think setting wrap_content to RecyclerView doesn't make much sense, just as it doesn't for ListView, because it can't know the size of all of the items without going through all of them, yet there can be tons of items (even infinite or close to it in some cases).
The sizes might even change.
Google even talks about this bad practice on its old video "the world of ListView". They said that ListView has a small trick to handle "wrap_content", to check only a few items, and assume all of the others are the same.
However, it could be nice to tell the RecyclerView to assume that all items are the same size (height in case of horizontal, width in case of vertical) and it will set its size automatically.
Maybe it's easy to do it via the onbindviewholder function call.
The sizes might even change.
Google even talks about this bad practice on its old video "the world of ListView". They said that ListView has a small trick to handle "wrap_content", to check only a few items, and assume all of the others are the same.
However, it could be nice to tell the RecyclerView to assume that all items are the same size (height in case of horizontal, width in case of vertical) and it will set its size automatically.
Maybe it's easy to do it via the onbindviewholder function call.
sa...@gmail.com <sa...@gmail.com> #41
Hi , I have attached , Edit #7 betteri...@gmail.com , LayoutManager file (MyLinearLayoutManager.txt) for Horizontal RecyclerView , It's worked fine for me ...
Thanks betteri...@gmail.com .
Thanks betteri...@gmail.com .
yb...@google.com <yb...@google.com> #42
This has been merged into the internal tree, should be available with the next version of support library.
gr...@gmail.com <gr...@gmail.com> #43
How will it be fixed? Will it just automatically work with height=wrap_content? Or will there be a new option on the layout manager? Or.... ?
yb...@google.com <yb...@google.com> #44
We are introducing a new API called auto-measure where RecyclerView measures the Layout by calling LayoutManager#onLayout during an onMeasure call.
By controlling this flow, RecyclerView is able to track animations properly even if onMeasure is called multiple times.
This is an opt-in API and all default layout managers now use it to wrap their contents.
It is very easy for a LayoutManager to support the new API. For instance, for the LinearLayoutManager, it was only 27 lines of code change to support it (mostly calling it to enable and handling infinite layout case).
I'm hoping all external layout managers will move to this API but we are keeping the old API for the backward compatibility. The major benefit of the new API is that it can run predictive animations which was not possible w/ the old API.
By controlling this flow, RecyclerView is able to track animations properly even if onMeasure is called multiple times.
This is an opt-in API and all default layout managers now use it to wrap their contents.
It is very easy for a LayoutManager to support the new API. For instance, for the LinearLayoutManager, it was only 27 lines of code change to support it (mostly calling it to enable and handling infinite layout case).
I'm hoping all external layout managers will move to this API but we are keeping the old API for the backward compatibility. The major benefit of the new API is that it can run predictive animations which was not possible w/ the old API.
gr...@gmail.com <gr...@gmail.com> #45
Sounds great, thanks!
ra...@gmail.com <ra...@gmail.com> #46
Awesome, thanks!
mo...@gmail.com <mo...@gmail.com> #47
When will the change noted in #44 be available?
mr...@gmail.com <mr...@gmail.com> #48
Any ETA on the changes?
aa...@gmail.com <aa...@gmail.com> #49
[Comment deleted]
ju...@gmail.com <ju...@gmail.com> #50
I took the Horizontal RecyclerView CustomLayoutManager from #41 and added the case where there might not be any children so you don't get an IndexOutOfBounds Exception.
Looking forward to the official release; can we get an ETA?
Looking forward to the official release; can we get an ETA?
da...@gmail.com <da...@gmail.com> #51
#39: Sorry I took so long to answer you. As said, I barely tested it at first and didn't account for that scenario (I use multiples of span count). Thank you and gist updated.
ha...@gmail.com <ha...@gmail.com> #52
This issue drove us mad. All the custom LinearLayoutManagers did not work. An ETA on the fix would be really helpful.
yb...@google.com <yb...@google.com> #53
it will be released soon. Sorry i cannot commit to a date but the branch is locked to only bugfixes.
md...@gmail.com <md...@gmail.com> #54
Will this work for GridLayoutManagers as well? I have a solution for the LinearLayoutManager in place but the GridLayoutManager still produces problems.
yb...@google.com <yb...@google.com> #55
yes. all built in layout managers will have this support.
pn...@gmail.com <pn...@gmail.com> #56
Would this solve the issue for Wrap_Content in A StaggeredGridLayout Manager?
am...@gmail.com <am...@gmail.com> #57
When will be solution in support library will be available for this major issue.
am...@gmail.com <am...@gmail.com> #58
I want to achieve something like attached in screen shot. I am using nested RecyclerView this but wrap_content on child is not working since there is issue as mentioned can anyone tell me how to achieve this
yb...@google.com <yb...@google.com> #59
Released with 23.2. If you have issues with 23.2, please create separate tickets with sample apps to reproduce the issue.
gr...@gmail.com <gr...@gmail.com> #61
Worked for me! Thanks!
bu...@gmail.com <bu...@gmail.com> #62
Finally, it fixed!
ev...@gmail.com <ev...@gmail.com> #63
We love you Yigit 👏😍
an...@gmail.com <an...@gmail.com> #65
The issue is fixed now, but there is another issue:
In a framelayout a have the recyclerview as child of a cardview, the cardview has some margin, on portrait it works fine, but in landscape the bottom the card is not fully visible, its like 8dp of the bottom is cut off
In a framelayout a have the recyclerview as child of a cardview, the cardview has some margin, on portrait it works fine, but in landscape the bottom the card is not fully visible, its like 8dp of the bottom is cut off
an...@gmail.com <an...@gmail.com> #66
UPDATE to my recyclerview landscape issue, if I touch the tab bar and scroll app, then I see the space like in portrait, but on portrait its fine
yb...@google.com <yb...@google.com> #67
#65 thats not related to the RecyclerView. Your cardview (which contains the RV) does not fit the screen.
To fix that. you should make your card view match_parent.
To fix that. you should make your card view match_parent.
yb...@google.com <yb...@google.com> #68
#64 please create another issue with steps to reproduce your problem.
an...@gmail.com <an...@gmail.com> #69
#67 why it wouldn't fit its WRAP_CONTENT
yb...@google.com <yb...@google.com> #70
because its children require more space then you have available.
an...@gmail.com <an...@gmail.com> #71
#70 it didn't fix it by setting match_parent, also the issue is only on landscape not portrait, plz have a look:
https://code.google.com/p/android/issues/detail?id=201856
fr...@gmail.com <fr...@gmail.com> #72
WRAP_CONTENT still doesn't work when the RecyclerView has no children...
yb...@google.com <yb...@google.com> #73
#72, thanks, i can reproduce it and i've created an internal bug.
yb...@google.com <yb...@google.com> #74
#72 will be fixed in the next release.
fr...@gmail.com <fr...@gmail.com> #75
When removing a child and using animations for it, the wrap_content size is decreased before the animation finishes.
ml...@gmail.com <ml...@gmail.com> #76
yb...@google.com <yb...@google.com> #77
#75 it is supposed to do that. RV's animation is controlled by its parent (as RV controls its children). See the release notes:
http://android-developers.blogspot.com/2016/02/android-support-library-232.html
"Note that although RecyclerView animates its children, it does not animate its own bounds changes. If you would like to animate the RecyclerView bounds as they change, you can use the Transition APIs."
"Note that although RecyclerView animates its children, it does not animate its own bounds changes. If you would like to animate the RecyclerView bounds as they change, you can use the Transition APIs."
zt...@gmail.com <zt...@gmail.com> #78
"Note that although RecyclerView animates its children, it does not animate its own bounds changes. If you would like to animate the RecyclerView bounds as they change, you can use the Transition APIs."
Would love to see an example of this. Because RecyclerView changes its bounds on its own, I'm not sure how to utilize the transitions API to animate the change (while keeping recyclerview abstracted from the Transitions API)
Would love to see an example of this. Because RecyclerView changes its bounds on its own, I'm not sure how to utilize the transitions API to animate the change (while keeping recyclerview abstracted from the Transitions API)
yb...@google.com <yb...@google.com> #79
sorry didn't have time to create a sample app but we'll do that.
TransitionAPI does not resize views. It always lets views decide their before and after sizes and animate between them. This is actually what RV does to its children except its logic is a bit different because RV is a collection.
We had a talk about this if interested:
https://www.youtube.com/watch?v=imsr8NrIAMs
TransitionAPI does not resize views. It always lets views decide their before and after sizes and animate between them. This is actually what RV does to its children except its logic is a bit different because RV is a collection.
We had a talk about this if interested:
yb...@google.com <yb...@google.com> #80
one more thing, if you play with it, make sure you exclude RV's children from transition's targets.
http://developer.android.com/reference/android/transition/Transition.html
see addTarget, removeTarget methods.
see addTarget, removeTarget methods.
lo...@gmail.com <lo...@gmail.com> #81
I'm wanting to add a RecyclerView into a ScrollView so I can easily add a header to the RecyclerView.
I've called setAutoMeasureEnabled(true) to the LayoutManager but the result is no recycling of child views.
If there are 10,000 items in my adapter, 10,000 views are created...
Is this expected behaviour?
I've called setAutoMeasureEnabled(true) to the LayoutManager but the result is no recycling of child views.
If there are 10,000 items in my adapter, 10,000 views are created...
Is this expected behaviour?
yb...@google.com <yb...@google.com> #82
you should not put a RV inside a ScrollView because scrollview gives its children infinite space.
Unfortunately, you plan to use ScrollView and RV to implement headers cannot work. Instead, use a wrapper adapter.
Unfortunately, you plan to use ScrollView and RV to implement headers cannot work. Instead, use a wrapper adapter.
lo...@gmail.com <lo...@gmail.com> #83
That's a shame. Would of made adding a header much simpler!
Thanks for the clarification.
Thanks for the clarification.
yb...@google.com <yb...@google.com> #85
that is WAI. Animating a child's bounds is the parent's responsibility.
gr...@innodroid.com <gr...@innodroid.com> #86
I do not think this is working as intended. I do think this is a very difficult problem that nobody wants to deal with.
[Deleted User] <[Deleted User]> #87
I have tried setting rv.setHasFixedSize(false); and now RecyclerView is getting adjusted based on its items.
[Deleted User] <[Deleted User]> #88
email rmattison1@gmail.com I'll fix Google's implementation for you for $.
kh...@gmail.com <kh...@gmail.com> #89
Up to now, the problem #1 isn't able to be fixed ? Horizontal RV does not "wrap_content" with height of item view base on its data.
ch...@gmail.com <ch...@gmail.com> #90
wu...@gmail.com <wu...@gmail.com> #91
Same issue, seems not fix by google using recyclerview1.2.1
Description
Example:
Horizontally scrolling RecyclerView with width=match_parent and height=wrap_contents and properly measured child views does not display on screen and the final measured height of the RecyclerView is 0.
Problem:
Looking at the RecyclerView source code it falls back on ViewCompat.getMinimumHeight() if it has not been explicitly sized. The minimum height is not set based on the size of the child views and is always zero unless explicitly set.
Expected outcome:
RecyclerView sizes itself based on its child views if wrap_content and no explicit minimum height has been set.