I guess he did not mean to link any resource but just referring the java.io
system.
For Real
That is the Best Extension, Good Job
As @ABG says, this looks important, but I am guessing that most developers (which includes me) are not in the lucky 10,000 on this one, and therefore haven't got a clue as to what this is about our how they might use it in their apps. The example blocks give an inkling, but don't really help. Could a better description be provided, in layman's terms, of What this extension does, Why/When/Where one might use it, and How it works in more detail?
I am certain the work adds value to the AI2 development experience, especially in these times of Google privacy concerns and file location lockdown, but there is little point saying "great extension" in a post, if I have no understanding of what it does.
Yes, SAF is quite complicated to understand because Google had no time to explain why they decided to strict app's access to file system. Most developers felt homely by using legacy "File" approach, but launching of Android 10 started causing troubles for them and SAF is the solution to most of their problems.
Using this, you can-
- access phone storage*
- access SD card*
- read from/write to files created by other apps
- help user in protecting his/her data and restrict Storage consumed by apps
- get access to files and folders which are important to your app.
In this way, you needn't ask for MANAGE_EXTERNAL_STORAGE permission. - work with non-media files too, such as creating a CSV file of user's data or accessing a PDF file
*
: Android/data and Android/obb folders are exception
One major advantage I would like to emphasize is usage of URIs instead of paths.
Example 2
-
Open document picker and create document
(Since you now know how to take persistable permission, so I'll skip that part) -
Read and write to document
-
List files
Developers might also find these links about SAF useful in addition to your nice explanation.
Thanks @vknow360 for your explanations, making more sense now as to what one can do with your extension.
Well I have fallen at the first hurdle....
Following your first image, when I click the button I am taken to the device's default file manager (or what looks like it), I went to the root
folder, the file manager asked me to give permission to this area (to MIT Companion App), then returns me to the project with this error:
I forget to mention that direct child's id should be obtained using GetTreeDocumentId
method.
Sorry, I used the wrong block
OK that all works.
Is there no way then, in order to get started, other than the user going into their file manager and granting a permission, to get the root or other folder (tree)? (Open Document Tree)
Perhaps a uri for the ASD ?
I can see how one can traverse through a file list to find sub (folders) trees, and then list files again and so on. An image component accepts a content uri to display an image. Is this going to be the same for other components needing a file?
No, user must grant access through Documents Picker.
I am not sure about this.
Image component works fine.
Same should be correct for audio and video player.
Understood
SAF
is only needed for → non-media files. Media files (jpg, png, mp3, m4a, mp4,...
) can be accessed from all paths (outside of the ASD or privateDir) with READ
permission.
The question was just about the content uri being read by other components, e.g. it works with the image component:
not had a chance to test some of the others yet.
Could you please provide an example of how one uses the flags in order to set persistent permissions? I presume this saves the user having to visit the document picker again when restarting the app?
With this extension you really have to bite through and some users might lose teeth in the process.
I am prepared to champion
those users, in order to save their teeth ;), and ask Sunny how all the various elements of this extension work.
Sure, here it is:
Also data gets kind of binded to the app and you don't lose access to it even after multiple reboots.