Is there a default exit from the SAF OpenSingleFile method if a file you want to read is not in the file picker directories. Is the only alternative to check the file existence before reading?
if not.isEmpty_get.uriString then SAF.ReadFromFile uriString_uriString else Notifier.ShowAlert notice_No files in dir
2 Likes
it would be better to understand if you provided an image of blocks instead 
Hi Anke and Ay Productions,
Thank you for the code and comment. When using SAF it's necessary to read a file to return from the directory. If the file is missing then reading a file that isn't the one required may corrupt the workflow. Here are the blocks I used. They check if the file path is in the directory before manually locating and reading the file, however you need to know the file path in advance. A solution that doesn't require knowing the file path is to include an innocuous dummy file in the directory that can be read in order to leave the program. Alternatively is there an Android equivalent to a Windows computer Esc key or Ctrl Alt Del keys?
TestDirExit.aia (30.3 KB)
1 Like
Connect to Companion, click on this block, "Do it" and post the result.
If the non-media file whose existence is queried was not created by the app itself, false is returned.
Hi Anke,
Here is the result when I connect to Companion and click the Do It request on the Call File 1 Exists block. It returns False and the file has not been created by this app, however, it is just a section of an app that can create files so I will repeat the test with the original app that can create files.
I should add that I'm using Android 11 and the Screen File Scope is set to Legacy with the File Scope set to Shared.
I tested the full app "PushTo42" using an additional screen called 'calibration', with the main screen storage scope set to Legacy and the calibration screen storage scope set to Shared. This allowed the app to open the Internal storage directory using any file path on most, perhaps all, internal storage folders with the "Do it" showing true. The directory doesn't open if the file path doesn't exist and then the "Do it" shows false. Once open it's possible to navigate the internal storage directory and the external drive to read text files in any of the folders. None of the files were created by the app. Should this be possible?
I don't yet understand why the same thing doesn't happen with the test block that I used for my enquiry. Significant differences are that in PushTo42 i) I'm not using the main screen, ii) I'm not using a text box to enter the path and iii) I have to press the read button to read the file I can't read it using Companion "ReadFromFile Do it". See image attached.
1 Like
First of all, we should clarify what you mean by "internal storage". Read my guide "Some basics on Android storage". According to this understanding (according to Google) the "internal storage"
- /data/data/<packageName>/ (assets)
- /data/user/0/<packageName>/files/ (Private directory)
is accessible on all Android versions without READ permissions. However, the assets are read-only, while the PrivateDir is also writable (without WRITE permissions). Neither the assets nor the PrivateDir are accessible via the device unless it is rooted.
Secondly: On Android 11+, non-media files (only in one of the Shared folders) are not readable / writable if they were NOT created by the app itself. This means that a specific app can create a file with Companion (e.g. myTextFile.txt), but then it can't be overwritten with that app's APK. It MUST be deleted beforehand with the app (via Companion) or it MUST have another file name (with the APK).
Once these things are understood, we can then turn to SAF ...
1 Like
Hi Anke,
Re your first point.
My apologies I slipped into using the term Internal storage for Scope type shared storage because Google uses the terminology "Internal storage" for the shared files displayed in their file manager. So is it ok if I use the terminology 'scope type Shared' or just 'Shared' to refer to the files I am discussing in this topic?
Re your second point I agree and have not observed anything to the contrary.
The restrictions in your point 2 were the reason I used the SAF blocks as you recommended in a separate thread. They work well except for the minor inconvenience of requiring a default file to be selected in order to return from the directory if the required file is not available.
I was also surprised that SAF OpenSingleDocument allowed me to navigate the shared directory and read and write from any of the shared files or Google Drive. I had thought it would only allow access to the Documents or Download directories.
The anomaly between the Test blocks and the PushTo42 blocks is in the FileExists function. The TestBlock doesn't allow Shared files to be read if they have not been written by the same App. Whereas the PushTo42 app will report all the directory file paths as True, if they exist, whether they are created by the same app or not. The OpenSingleDocument function operates identically on both the Test and the PushTo42 apps.
Thanks, Peter
I'm starting to get confused. I'm not sure anymore if I still understand correctly where exactly the problem is. So post the respective (relevant) blocks of the two apps (tests) separately. And please explain once again precisely what exactly is to be achieved.
(And / or post the AIAs).
Yes, you can navigate and select files from any visible folder in the external storage. But the ASD (which is in the external storage) can not be accessed on Android 11+, because it is no longer visible on Android 11+.
But you cannot write (save a text file) in
/storage/emulated/0(the root dir of the external storage) and in the folder/Download(absolute path:/storage/emulated/0/Download)
using SAF.
1 Like
Hi Anke,
The original issue was how best to manage an exit from SAF OpenSingleDocument if the desired text file wasn't present in the directory that SAF opened.
SAFOpenSingleDocumenExit.aia (30.3 KB)
Your description of the OpenSingleDocument capability answered my question, showing that SAF allows a greater range of files to be navigated than I had realised. The Files Exist method would limit this range. I think the SAFList files will help I'll try that out.
When trying your test file suggestions I noticed that my main program PushTo42 responded differently than my test program to the Files Exist function. This anomaly may be a bug in my PushTo42 app or in the Files function. The anomaly is interesting but not relevant to the main question especially as you pointed out the potential use of SAF List Files. To avoid confusion I'll investigate the anomaly separately from this thread.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.