Fixed
Status Update
No update yet.
Comments
em...@google.com
ry...@google.com
sm...@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.
na...@gmail.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.
sm...@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.
ap...@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.
sm...@google.com
None of these are accessible.
ap...@google.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
ap...@google.com
I haven't been able to reproduce issue #1 described in the initial report (onClick fired after long press). For issue #2 it appears that GestureDetector is firing onDoubleTap in cases where there is a sequence of taps in rapid succession inside the "slop square". I'm investigating a fix.
Separately I landed a fix to comply with onRequestDisallowInterceptTouchEvent requests. This will appear in 1.1.0-rc02. Fancy demo app was updated with "swipe away" supporting using ItemTouchHelper to demonstrate compliance.
Separately I landed a fix to comply with onRequestDisallowInterceptTouchEvent requests. This will appear in 1.1.0-rc02. Fancy demo app was updated with "swipe away" supporting using ItemTouchHelper to demonstrate compliance.
sm...@google.com
I have a fix out for review that address the issue where selection lib isn't handling the second tap of of two that fall into the double-tappy category as GestureDetector would have it. This addresses the issue where the second of two rapid taps in close proximity is not handled correctly.
That said, there are still cases where OnClickListeners added to child views are being called (at least using the Fancy demo activity).
1) Long press on an existing selected item.
2) When making many multi-taps (whacking the screen repeatedly with multiple fingers).
In both of those cases I haven't been able to track down a cause, but have verified that *when* TouchInputHandler receives events, it handles them correctly. It doesn't rule out issues elsewhere in the library, but I don't see any obvious paths of investigation. <Steve glares directly at GestureDetector once again>.
That said, there are still cases where OnClickListeners added to child views are being called (at least using the Fancy demo activity).
1) Long press on an existing selected item.
2) When making many multi-taps (whacking the screen repeatedly with multiple fingers).
In both of those cases I haven't been able to track down a cause, but have verified that *when* TouchInputHandler receives events, it handles them correctly. It doesn't rule out issues elsewhere in the library, but I don't see any obvious paths of investigation. <Steve glares directly at GestureDetector once again>.
cr...@gmail.com
danielstone411@gmail.com, I'm curious where I might be able to add a note about use of View#OnClickListener vs OnItemActivatedListener. Where would you first look for your docs? Javadoc? If so, which class?
I'd like to update the docs to provide some guidance, but am not sure where would be most effective.
I'd like to update the docs to provide some guidance, but am not sure where would be most effective.
Description
- I have a RecyclerView using Selection with SelectionPredicates.createSelectSingleAnything() and StableIdKeyProvider.
- A selected item will be colored RED, unselected item will be colored GREEN.
- I select item whose adapterPosition is 0.
- I scroll the list so the item whose adapterPosition is 1 will be on top.
--> What I actually want is the item at '0' will be offscreen and will be detached, but not enough for recycle.
- I select item of adapterPosition '1'.
--> Because it is single selection list, I expect that the item of position '0' will *appear to be unselected*.
- I scroll to top and see if item of position '0' appears to be unselected or not.
Expect: item of position 0 will be colored GREEN (it should appear to be unselected), item of position 1 will be colored RED (it should appear to be selected).
Actual: item of position 0 is colored RED (it appears to be selected), item of position 1 is colored RED (it appears to be selected). (See attachment: recyclerview_selection_issue.mp4).
Note that, the item is correctly unselected, but the change is never delivered to the Adapter due to the behavior of StableIdKeyProvider (I have post about this here:
Source code:
Version used (can be found in the repo): RecyclerView 1.1.0, Selection 1.1.0-beta01.
Thanks in advance.