OpenDocuments ActivityResultContract with one selected file [152941153]

Fixed

Bug

Status Update

No update yet.

Description

ih...@gmail.com

created issue #1

Apr 1, 2020 06:28PM

Component used: Activity
Version used: 1.2.0-alpha03
Devices/Android versions reproduced on: All

I used the OpenDocuments contract in my project, everything works fine if more than one file is selected in the called explorer.
But if you select only one (which the system does not prohibit) - the contract returns null in response.
I create my own, it seems to me a logical workaround for this situation, but I would like to see this solution out of the box:

https://gist.github.com/SteinerOk/1d992ac1ecf5c74810d5b0a05d76138b

Comments

il...@google.com <il...@google.com> Apr 1, 2020 06:36PM

Assigned to jb...@google.com.

ap...@google.com <ap...@google.com> #2Apr 3, 2020 07:51PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 05741ce5020c2cf3ab0fb2cfc9665a0046922e08
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Apr 03 11:03:04 2020

Ensure getContents and OpenDocuments return single elements

When using the getContents and OpenDocuments contracts if you selected
multiple items it worked corrected, but selecting only one item returned
null. This is because the intent stores multiple items as `clipData`, but
a single item as `data`.

This change ensures that we handle the `data` so selecting single items
now works.

Test: added verification to integration app
Bug: 152941153
RelNote: "When using the getContents and OpenDocuments
ActivityResultContracts and selecting a single item, it is now correctly
returned to your callback."

Change-Id: I92b445feaf7fc651cdf9e7787a84e839d723da00

M activity/activity/src/main/java/androidx/activity/result/contract/ActivityResultContracts.java
M activity/integration-tests/testapp/src/main/java/androidx/activity/integration/testapp/MainActivity.kt

https://android-review.googlesource.com/1278011

jb...@google.com <jb...@google.com> #3Apr 3, 2020 07:57PM

Marked as fixed.

This has been fixed internally and will be available in the Activity 1.2.0-alpha04 release.

ma...@gmail.com <ma...@gmail.com> #4Apr 4, 2020 09:51AM

I have two comments:

Is the order of the ClipData relevant, i.e. does it reflect the order in which the user selected the content? In that case it might make sense to use a LinkedHashSet instead of a HashSet.
Why not return a Set instead of a List? That would get rid of some copying and carry the semantic that content can't be selected twice (which seems like a safe assumption to me).

ap...@google.com <ap...@google.com> #5May 11, 2020 04:48PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 13352b5a3b2aca96bba64662027347d66d39c6b5
Author: Ian Lake <ilake@google.com>
Date: Fri May 08 16:10:17 2020

Keep the ordering of ClipData in the resulting list

When combining the Intent's data field and the
Uris in the ClipData, we should attempt to maintain
any ordering present in the ClipData's items.

Test: existing tests pass
BUG: 152941153
Change-Id: I26ee368605054a3e8c090d384ac0843674ee378f

M activity/activity/src/main/java/androidx/activity/result/contract/ActivityResultContracts.java

https://android-review.googlesource.com/1306485

il...@google.com <il...@google.com> #6May 14, 2020 10:43PM

Re #4 - As part of Activity 1.2.0-alpha05, we keep the ordering of the ClipData in the final result. There's no guarantee that the ordering there has any relation to the other the user has picked items (or even if it is in first->last or last->first order) since that ordering is completely under the control of the other activity, but it at least serves as a consistent starting point.

We're staying with List for the API side of things; the use of a Set internally is just that - an internal implementation detail.

ih...@gmail.com <ih...@gmail.com> #7May 15, 2020 06:27AM

When do you plan to release 1.2.0-alpha05?