Take a look at this design document, which is still draft status, to see if you think it would meet your needs:
You should have the ability to comment on the document.
7 Likes
I don't see any discussion of file access differences between Companion (development) and Built apps.
I see code in many apps making file path adjustments for that.
1 Like
Sorry, but I don't see the connection to my question / topic.
Maybe I haven't read it carefully enough, but what is the lesson from it?
What's the problem with answering my question clearly?
I'd need to see what they're doing, but in most cases it's probably because there is a misunderstanding about how something works. For example, I've seen people construct paths to read assets for their projects from the companion's directory, which of course breaks as soon as you put the compiled app on another device that doesn't have that path. In the proposal, the app specific directory would be the default space in which to read/write all files, and this is necessary on Android 11 and higher because of the constraints put in place by Android. I can't fix people accessing arbitrary paths--that's a human problem not a technical one--and so they will get smacked by the changes when they upgrade their OS.
The other main thing I've seen people adapting paths for is the WebViewer. In the last components release we included the ability to prefix http://localhost/ to all assets with the intent that it will work the same in both the companion and compiled apps across both platforms. This means there should no longer need to be companion-specific checks related to this component.
1 Like
To answer the only question you've actually posed in this thread:
Because 12 years of design decisions have simply made it that way. Remember that App Inventor first and foremost is an educational tool, and so it made sense to put files in a place where they can be seen as a means of students to validate that things are working correctly. The vast majority of people do not have rooted phones, so can't see the private app directories, which would make it much harder to confirm that the contents are there and as expected. Some of our tutorials rely on this as a form of checkpoint. If every component did this by default it would lower the pedagogical value of the tool.
The proposal includes the addition of a DefaultScope property on Screen1 that will default to the ASD, but can be switched to Private if you would prefer your app mainly write files to the private app directory. All components except for the file component would use this for determining where to write files by default. A future proposal could make it so that every component can control this independently (at the cost of increasing the complexity of the blocks language, which is its own problem on which I get push-back).
1 Like
For me (and apparently some others, who are aware of the problem) it is not about the question that every component that can save something has the option of doing this in the privateDir, but only about the File component. Because this would also allow any file that was created with another component to be subsequently copied / moved to the privateDir.
Apart from that, even the ASD is no longer visible from Android 11 onwards without using external file managers (such as Total Cammander). So with Companion files could be saved in the ASD for test purposes (instead of in the privateDir).
The move/copy blocks I propose in the document seem like they would fit the bill then.
Yes, we have no intention of moving the companion files from the ASD. My previous comment in response to ABG was more to do with people assuming that this is a valid way to load assets in their project when it's mainly provided as a debugging technique, and that it will break in compiled apps, and now even more so with apps not being able to read each other's storage.
2 Likes
thank you very much for coming up with a design document... this is greatly appreciated...
and as I can see, we will be able to read and write also from/to the shared directories in future... 
- Shared - Reads and writes files to shared directories, such as Documents, Music, etc. The paths are rewritten to use the MediaManager API.
you mentioned in that document
The File component is the component most affected by Google's technical changes in Android and policy changes in Google Play.
what about the other components? Example: Let's assume, I like to take a picture and store that picture in the shared directories, so it will be available also for the Gallery app.
Will the new Scope functionality also be implemented in other components like the media components, especially Camera, Camcorder, ImagePicker, Player, Sound, SoundRecorder, VideoPlayer?
Taifun
3 Likes
At the moment the plan is to implement a property on the Form to control the default for all of the other components. A future release may bring the scope property to the other components if needed. The File component also adds a MakeFullPath method that given a scope and a path will return a fully qualified path that can be used with the other components if needed.
6 Likes
Good job for me. I think that this functionality is enough for now. If something is missing, it will definitely come out in the wash ...
I would like to test the new File component.
Is there an (approximate) date from when and where (on which test server) it can be tested?
I encountered some issues during testing that I'm working to fix. Hopefully it shouldn't be too much longer.
2 Likes
@Anke Here's a link to a test server. I'm still doing some bug fixes but it should give you an idea of how the updated component works. Please let me know of any issues you encounter.
5 Likes
I did a few tests on the test server with the File component, which don't seem to make much sense (or are not very helpful). Unfortunately I was only able to test with Companion (Android 11) because the build server does not work.
4 Likes
I've had a look at the design document for File API Changes which looks very useful indeed. One thing that bugs me is the fact that the Sharing component uses different file/path naming conventions from the File component (saving and reading). Will this be fixed in the update?
(I use the sharing component to share txt and csv files produced by apps with google drive and so my computer where I have a lot more flexibility.)
I'll have the build server set up today. I was trying to get this up before my vacation but didn't have enough time to finish the build functionality since there's some additional complexity there.
1 Like
same issue here 
The build server is available now. Note that "I'll" expands to "I will" not "I have". 
3 Likes