Fixed
Status Update
No update yet.
Comments
sh...@google.com
sh...@google.com
> We accept pull requests! :)
Is there a public repo somewhere? I don't see any obvious repo for it inhttps://android.googlesource.com , and it doesn't seem to be inside https://android.googlesource.com/platform/frameworks/support .
Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.
Is there a public repo somewhere? I don't see any obvious repo for it in
Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.
sh...@google.com
Room supports immutability (it can use arg constructors) but does not directly support AutoValue. It is in the schedule but not high priority :/. Idk much about its internals at this stage so I'm not sure how we would implement it but should be totally doable.
Sorry we don't have the source release yet :/.
Sorry we don't have the source release yet :/.
je...@google.com
"It is in the schedule but not high priority" -- completely understandable.
"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.
Thanks!
"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.
Thanks!
ap...@google.com
Add autovalue support also means you can easily achieve parcelable by https://github.com/rharter/auto-value-parcel . Please consider support this.
sh...@google.com
ch...@gmail.com
AutoValue is really a handy way to ensure data integrity.
Description
When items are same size as the viewport, and RV is currently laid out such that the viewport shows exactly one complete item, and you remove that item from the dataset, it can't find a reference child that is in the viewport. It defaults to using the first child it found in the hierarchy (
getChild(0)for regular LTR RVs) as the reference child. But then it doesn't seem to use that child's old position as the anchor position, but just places that child at the start of the viewport.That is a problem if you are looking at the last item (item N) and have two extra items laid out before the visible one. You'd expect that if you remove item N, you will look at item N-1 after that. But, it will actually go to item N-2.
I didn't check the behavior if you're not looking at the last item, but that might be affected as well.