Fixed
Status Update
No update yet.
Comments
sh...@google.com
I believe that this is following on from
In the linked thread it is suggested that withOnItemActivatedListener can be used to correctly handle click events on the view. I've had a look through the sample project
For my use-case I would like a reference to the view in the ViewHolder for shared element transitions - setting on onClickListener in the ViewHolder made this easy. I'll have to work around by finding the view holder with the motion event for now.
I think it should be clearer in the version release notes that this behaviour change is present.
sh...@google.com
Thanks for the report. The behavior relating to onClick handlers should be consistent from 1.0 to 1.1, so, subject to verification, seems like a bug to me that will need to be addressed as part of the 1.1 release.
sh...@google.com
Thanks for verifying the first issue.
But your response sounds like you're focusing on that one and consider the second point a non-issue, just because it was already present in 1.0?
Please note that it does not only affect custom OnClickListeners, but also standard widgets like checkboxes. If you click through items (read: click on the items' checkboxes) slowly after activating selection mode, you will only select/unselect further items. If you click faster, selection will skip some items and instead toggle the checkbox. And as I said, even without interactive items, selection just feels utterly sluggish when it skips user clicks. The whole user experience is far, far away from the "good old" list view.
Offtopic: Those new androidx/jetpack libraries don't feel like they're pretty well geared to each other. Combining RecyclerView and SelectionTracker with ItemTouchHelper opens another issue. When using a drag handle within a selectable list item, clicking the handle and starting to move the item slowly will select the item and start selection mode while drag mode is active. It gives weird user experience and requires lots of workarounds to come to a sane "standard" behaviour.
But your response sounds like you're focusing on that one and consider the second point a non-issue, just because it was already present in 1.0?
Please note that it does not only affect custom OnClickListeners, but also standard widgets like checkboxes. If you click through items (read: click on the items' checkboxes) slowly after activating selection mode, you will only select/unselect further items. If you click faster, selection will skip some items and instead toggle the checkbox. And as I said, even without interactive items, selection just feels utterly sluggish when it skips user clicks. The whole user experience is far, far away from the "good old" list view.
Offtopic: Those new androidx/jetpack libraries don't feel like they're pretty well geared to each other. Combining RecyclerView and SelectionTracker with ItemTouchHelper opens another issue. When using a drag handle within a selectable list item, clicking the handle and starting to move the item slowly will select the item and start selection mode while drag mode is active. It gives weird user experience and requires lots of workarounds to come to a sane "standard" behaviour.
je...@google.com
Thanks again for all the feedback.
The second issue you describe is tracked by 159025478.
The last issue you described is likely related to 139141511.
The second issue you describe is tracked by 159025478.
The last issue you described is likely related to 139141511.
ap...@google.com
None of these are accessible.
sh...@google.com
ch...@gmail.com
I don't honestly know how to control bug visibility, that's someone else's business as they know what's okay to make public and not, I don't.
Just be advised that the issues are being tracked.
...478 > Replace use of GestureDetector with custom event detection
...511 > Handle onRequestDisallowInterceptTouchEvent correctly
Just be advised that the issues are being tracked.
...478 > Replace use of GestureDetector with custom event detection
...511 > Handle onRequestDisallowInterceptTouchEvent correctly
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.