File names (directories) for the File and Sharing components

This is an issue, not a bug or a problem. (I've solved my personal problem thanks to @Anke.)

My understanding (which may be wrong) is that text files created or read by an app can be saved in three locations:

  1. The app's private directory (APD) from which files can't shared (the clue is the name but it took me some time to work this out).
  2. The app specific directory (ASD) from which files can be shared.
  3. The root directory, which could usefully be called the All Apps Directory (AAD), which Google is making more difficult to use because of privacy concerns.

I eventually discovered that to save a file in the ASD I need to call it
/filename.txt in Android 10
/Android/data/appinventor.ai_mickofemsworth.FE4/files/filename.txt in earlier versions of Android. (The app name is FE4 and my username is mickofemsworth.)

In both cases to share the file I must call it:

My issues are: Why is this so complicated? And why was there nothing about this in the documentation? :confused:

It would be helpful if the Sharing component worked like the File component, and if the distinctions between the storage locations were made clearer in the documentation. :grinning:


thank you @Michael_Wood for bringing this up... I will assign this thread to Evan...

Please, no more abbreviations!
Apparently it wasn't a good idea of mine to introduce the abbreviation ASD for app-specific directory. But I thought this directory would be used so frequently in the future that it makes sense in this case.

But the abbreviation APD (introduced by @ChrisWard as far as I know) has already led to confusion and is unnecessary, since this directory is almost never used. (I think I was the first to mention this in connection with the File component. This is the only component that can use this directory. As far as I know, there is no extension either.)

Abbreviations are only useful and appropriate if they are used frequently.
But the abbreviation AAD could also be confusing, so it is better to leave it:

  • /mnt/sdcard or
  • /storage/emulated/0 or
  • root dir of external storage

And on the question of paths (relative / absolute): Yes, this is not consistent neither with AI2 nor with Kodular, and does not only affect the Sharing component. Some components use relative paths, others use absolute paths. E.g. the SoundRecorder uses the absolute path.

Hi Michael

You are totally on point. What if we had something like this?

Path - Filename - Extension
Path selected from those offered by App Inventor, Filename typed-in by the Developer, File Extension selected from those offered by App Inventor.

The Developer does not have to worry about the Android version or about the syntax of long paths, App Inventor looks after that behind the scenes. The hint/tooltip of the drop-down blocks informs the Developer of the purpose of the path selected, likewise the file extension.

In reply to @ChrisWard I agree that the suggested structure would be very helpful. The second option for the first block would presumably be the root directory. I would prefer to replace the end block by a filename as text - this could end in txt or csv if appropriate. (The app I am working on has list of txt and csv files.) One of the middle block options should be the default if the block is omitted. And all components should use the same structure.

I would agree with @Anke about abbreviations but I think there is a case for making the names more user-friendly. From the beginner's (eg my) perspective "/mnt/sdcard" is horribly confusing because I have an SD card in my phone but this directory is not on it. Root is computer jargon and to make sense of the analogy with plants you need more understanding of directory structures than most beginners are likely to have. A phrase like "many apps directory" sums up the important property of this directory far better.

Although I agree about acronyms, Single App Directory becomes SAD :frowning_face: which is the way I feel about it because restricting apps to this directory hinders the ability of apps to communicate with each other.

I feel Google are following in the footsteps of Microsoft - they have stopped listening to indie developers and later they will pay the price as innovation comes to a grinding halt. Microsoft are now trying to win back the developers they let down, but it's far too late.