Retain user selection order in RecyclerView Selection [128455535]

Fixed

Feature Request

Status Update

No update yet.

Description

zh...@google.com

created issue #1

Mar 12, 2019 11:08PM

The Android file management app (DocumentsUI) uses androidx.recyclerview:recyclerview-selection for picking multiple files. And in cases when an app requests user to pick several files, it would be nice if we can (mostly) preserve users' selection order, an improvement over the current random order.

For example, an app that can concatenate images may allow user to pick multiple image files at a time (e.g. a web app

https://join-screenshots.zhanghai.me/ opened in chrome), and since the images are sequentially concatenated, the user will probably want some kind of order (instead of random order) in such a scenario.

Currently the androidx.recyclerview.selection.Selection class keeps track of user selection with two HashSets, so changing them to use LinkedHashSet (and modifying setProvisionalSelection() a bit) should be doable to keep user selection order in most cases.

Comments

sm...@google.com <sm...@google.com> #2Mar 13, 2019 06:58PM

This isn't fixed in alpha 6 :(. It's easily reproducible by starting a drag with one finger and then tapping somewhere else (think back button) which calls clearSelection().

zh...@google.com <zh...@google.com> #3Mar 13, 2019 08:02PM

Comment from

https://b.corp.google.com/issues/128054552#comment9

ap...@google.com <ap...@google.com> #4Apr 13, 2019 03:15PM

Fix is in the works. Until then, a workaround is to avoid calling SelectionTracker#clearSelection while a gesture or mouse-band selection operation is in progress. Such a condition is likely not reflective of user intent (given the ongoing stream of selection operation), but reflective of a stray tap.

State can be monitored using OperationMonitor:

https://developer.android.com/reference/androidx/recyclerview/selection/OperationMonitor.OnChangeListener.html

sm...@google.com <sm...@google.com> #5Apr 15, 2019 03:03PM

BTW, working on a fix for this (general improvement to state management). My unassigning this issue from me should not be construed as lack of attention to the matter. I just manage issues by hotlist (rather than ownership).

sm...@google.com <sm...@google.com> #6Apr 15, 2019 03:04PM

Rolling all state-related crash reports up into a single tracking bug.

zh...@google.com <zh...@google.com> #7Apr 16, 2019 10:30AM

Marked as fixed.

Fixed in upcoming beta01 release.

zh...@google.com <zh...@google.com> #8Apr 16, 2019 10:33AM

Received email and the reported buganizer bug about this bug is at

b/130621113

sm...@google.com <sm...@google.com> #9Apr 16, 2019 03:28PM

Yup. Fixed. Thanks.