SAF: App Inventor implementation of Storage Access Framework

I have a problem with reading external files and an unlikely solution requiring advice.

I’ve tried reading and writing to files using SAF in examples one to three given at the start of the SAF thread and had no problem with examples 2 or 3, which deal with files created by the App. But with example one I can’t get the 'Build Document URI using Tree’ function to work on files created by a text editor as it doesn’t add the file identifier characters. I have demonstrated the problem and one unlikely solution using two versions of example 1 implemented as a series of steps controlled by buttons.

In the first method TSAF1 I list a directory, locate the required file and copy its URI string to label 3 to replace the ‘Build Document URI using Tree’ in the read file function. This works perfectly and could be readily implemented with a search function to find the required file, but is surely not the method intended.

The second method is a copy of example 1, Label 4 is the output of the ‘Build Document URI using Tree’ function. If you compare label 3 with label 4 you will see that the file identifier characters are missing from label 4 and the read operation produces no result.

Can anyone tell me what inputs I need to obtain the complete URI from the ‘Build Document URI using Tree’ block? The URI should be identical with label 3. Alternatively, if reading files created externally is impossible with SAF as appears to be the case from this test, then is it reasonable to use the search directory method in the TSAF1 example?

Version 1 see also AIA below image


TSAF1.aia (31.4 KB)

Version 2 see also AIA below image


TSAF2.aia (31.4 KB)

1 Like

ReadFromFile expects you to provide uri string of file you want to read from, so this works.
image

3 Likes

Agreed Label 3 works eg as in my earlier example, example A below or in your response. But at the moment the only method I know that works is to search the 'Got File List' for the file and copy its URI. Is that the intended approach with this implementation of SAF?

Or are there inputs into the component 'Build document URI using tree' in example B below that can derive the URI from the file path eg from /storage/emulated/0/PushTo/TestB.txt in my earlier example. Or is there any other function in your SAF that can derive the URI from the file path?

Appreciate any advice you can give here as I'd like to use SAF properly to read files rather than putting something together that doesn't take advantage of its capabilities.

1 Like

I copied a text file (hello.txt → "Hello world") from the computer to /Documents and read it after .OpenSingleDocument:

3 Likes

Many thanks, Anke and vKnow360, Anke I've run your method and it worked for me and gave me a better insight into how SAF works.

It seems necessary to run the 'Open Single Document' function each time to read the file, which means a user intervention. which is not too inconvenient for my application. Is this a security requirement for Google?

When I use 'Open Document Tree' and copy the file URI from the 'List Files' component (example A in my first email) it's possible to open any directory and to make multiple reads without having to reopen the document tree each time. Is this likely to be considered a security breach by Google?

1 Like

If your app is only intended *for private use" you can have a look to How to request and grant MANAGE_EXTERNAL_STORAGE permission

1 Like

No, you should try taking persistable uri permission.

For that you must take persistable uri permission.

1 Like

Thank you vKnow360, I will try the persistable permission to see how it works

1 Like

Thank you Patel that looks like a very useful link to study. However, my App is intended for public use and the example I gave looks as if it might breach Google guidelines but it maybe the persistable permission function works by modifying the file being read? I'll keep on testing until I understand the SAF functions better.

1 Like

You can take persistable permission in this way, but i can read file, no write.

Why this block runs well with apk but does not with companion ?

Please upload the aia so that I can take a look.
Though if it works in apk, its functionality in companion shouldn't be a concern.

2 Likes

Find attached aia, I'm using companion 2-62u, error message "media is read only"
Saf_1.aia (60.2 KB)

Works fine with Companion on Android 11 (even with the non-current extension version).

Current version

I am facing some problem with this SAF thing.
My end goal is to read a pdf from Documents folder and upload it to Firebase Storage. The problem I am facing is after picking the file from Documents folder and coverting its URI to path to upload it to Firebase Storage as it accepts File Paths only. I got path as /sdcard/..... which is prompted as No such file or directory while uploading to Firebase Storage.

Sorry actually I am explaining my post but unfortunately ended up posting it. Edited my issue please help me with it if you could.

can you post a link to your companion apk ?

I can see all text files with this block
block1
but I want see only csv