[fattire]

Android's Storage Access Framework is really underrated. Just ask the user to choose a document (file or image or whatever) by firing an intent-- then Android's built-in file picker starts up and you don't have to deal with implementing any of that UI experience. After the user picks the file, a content:// URI is returned back.

https://developer.android.com/guide/topics/providers/documen...

Best part-- along with the URI, you get the permission to access the document/file/image/audio/whatever "for free" without ever having to request it! Because you kind of just did-- the act of the user picking the file auto-gives you the read permission, which can be kept ("persisted") across system/app restarts.

This file may not even be on the actual device. It could be on some cloud service or a file server or something else you've never even heard of. Android handles it all for you. An example of this is Google Drive. If they've installed the Google Drive app and it's linked to their account, the Storage Access Framework will let the user pick stuff from there just as easily as their own external storage.

You can also use the picker to create/save a new file or even choose a whole (directory/folder) tree.

Reading from the content:// URI is a little different than from a file:// , and I know there are some situations where this won't cut it. But starting in Q you'll be kind of limited in where those files can be accessed.

But in most situations involving External Storage, the SAF is really what you want to use anyway.

Watch this little-seen video:

https://www.youtube.com/watch?v=C28pvd2plBA

[jbk]

> But in most situations involving External Storage, the SAF is really what you want to use anyway.

Or not. A File Picker does not work for playlists, linked MKV/MOV files, subtitles autodetection (subfolders and such), and so many other multimedia cases.

Also, it is a pain to use from the NDK... And incorrectly documented.

And then, the UI to allow people to give you access to the folders is extremely confusing, hard to explain to users, not customizable, and changes from version of Android to another, so very hard to document.

[iggldiggl]

> Or not. A File Picker does not work for playlists, linked MKV/MOV files, subtitles autodetection (subfolders and such), and so many other multimedia cases.

Exactly. HTML files are another victim of this, as with content://-URIs there's no official way to properly resolve relative URIs for any subresources (images, style sheets, scripts and whatnot) or local links, and even if you could, you wouldn't have the permission to access those files anyway. Even Android's included mini HTML-viewer app (or Chrome for that matter) are broken if you try viewing a HTML file using a content://-URI, e.g. from the file explorer that's built-in since Marshmallow.

I opened https://issuetracker.google.com/issues/77406791 for that, but you can guess at the reply I received so far (none - I guess I should be glad they didn't close it outright...)

And another problem is that even if your app has the appropriate storage permissions itself (whether through READ_EXTERNAL_STORAGE or the new-fangled way, even if that means dealing with the SAF) and could therefore open both that file and its companion resources without relying on the permissions attached to the content://-URI intent, in practice that's rather difficult because even for local files there's no official link between the content://-URI and the file system location. In practice at least some ContentProviders will leak the path through the URI, allowing you to reconstruct the original file path with a little luck, but that's of course not really a reliable method.

[fattire]

Agreed that the UI could be WAY more intuitive. There are issues with it default-opening for saving to an unwritable directory (confusing people), not being clear about why you're there (no way to instruct the user what purpose they're selecting a file for except the "open"/"save" button), the side drawer is not intuitive for new Android users who might not know there are more services beyond the Download folder, etc. There are too-limited sorting options, the MIME filtering could be extended, etc. Older versions of the framework didn't even let you suggest what saved files should be called...

In the case of a sophisticated media player like VLC I totally get your point. The solution before Q was just to ask for the READ/WRITE storage permissions and have full access. I guess they figure that's too broad access for one app to have.

Upsides-- it works great on Chromebooks, integrating with ChromeOS well, and the convenience of seamlessly integrating a single UI with numerous cloud services with no extra SDKs to include or APIs to learn is also a big plus.

[gmueckl]

So how would a file manager work then? I have used several file managers over the years that allowed me to conveniently manage files locally and remotely. E.g. extract the downloaded zip file locally, edit ome of them, copy these 20 selected extracted files via SCP and delete these three folders.

Granted, I only do that on a phome in a pinch but having these features saved me more than once. I dom't want Android to become as restrictive and underpowered as iOS feels to me.

[icebraining]

The Framework lets you ask for access to a whole directory, not just individual files.

[gmueckl]

How is that solving the issue? How can that result in a local and remote file manager with a consistent GUI?

[icebraining]

The file manager would ask you to pick (using the Android UI, via SAF) the directory where you had downloaded the zip, then everything would work the same.

Alternatively, the app can register itself as opener of zip files, then it could extract them freely to its own private directory (without asking for permissions) and let you list and upload them.

[gmueckl]

This is all a load of crappy workarounds leading to a convoluted and cumbersome user experience. From a usability perspective, I would not consider such a behavior a solution.

[UncleMeat]

That's because you like general purpose file managers. But most people would much rather that their calculator app didn't have access to their photos.

[Godel_unicode]

The alternative is malware having free reign over the entire filesystem. This is a real problem which is happening today. With your all-or-nothing solution the user has no ability to limit what files an app can access, which is totally unacceptable.

[yjftsjthsd-h]

I've seen it as "use the file picker to select the parent folder" which works fine

[clumsysmurf]

The SAF APIs are cumbersome garbage up there with Account Manager and ContentProviders. Its missing important providers like DropBox, and even Google Drive doesn't implement it completely.

[Godel_unicode]

If a provider is missing it's because the developer of that app didn't create one.

[fattire]

Exactly. DropBox for example used to support the SAF and then for some reason pulled it, whereas Box.com's app supports it...

[H1Supreme]

> Reading from the content:// URI is a little different than from a file://

I haven't found the reading part to be different, but getting the uri has changed from Uri.fromFile() to their FileProvider package. Which, requires quite a bit of setup in comparison.

To be fair, it's documented well on the Android developer site.

[ge0rg]

But there are some APIs that don't work, e.g. ExifInterface (that you need to properly process image orientation) can only read from InputStream starting with r24, and you need access to the raw File before that [0].

[0] https://developer.android.com/reference/android/media/ExifIn...

[chaisoftware]

> then Android's built-in file picker starts up

This is not a good thing for VR apps. Unless there's a VR system file picker in the works that I'm unaware of..

[Arnt]

I'm curious.

Suppose you're a VR app and you invoke a picker to open a... I don't know... you want to open a sound file. How should the picker's UI be to fit into your general VR interface?

If a sound file is particularly badly suited, then some other kind of file (but in that case I'm interested in why that's easier/better than sound).

[chaisoftware]

Not sure I understand the question exactly. Generally, a file picker UI could look exactly the same in VR as it does out of VR, just projected on a flat surface.

The crucial point is to remain inside the stereoscopic VR view since exiting VR is very disruptive.

[chronogram]

Boxes and drawers. A sound file could be in a collection of records or CDs or tapes. Making it just like real life is like having your users start off with the manual already read.

I’m afraid a general Android VR item picker will be a lot more boring though.

[robin_reala]

And thus was born Microsoft Bob.

[chronogram]

Rather older versions of Macs! With binders where you put files into, and dragging items around, and most of the applications being items on an office desk.

Nowadays I guess the surface studio is a good example. Being laid out like a drawing table and interacting with it like a drawing table.

[joelhaasnoot]

On new devices, this often opens an empty file picker. That's so helpful to a user...