Is there a particular component of interest that you think should be writing to the private data dir but isn't?
Sorry, now I got it.
A note about iOS vs Android:
I'm not a huge fan of Apple & iOS (only a gut feeling), but most of it is just better and more sophisticated. I've only had a problem with Apple (my iOS apps) once in all these years and that affected iOS 13. This was really a fiasco. At one day none of my apps worked without me changing anything. There was an update every 17 days for iOS 13 on average and always with new bugs. There have been 17 updates to iOS 13. 
However, I only have to make adjustments to my iOS apps once or twice a year (if at all).
With Android I have to be careful at all times that I have to adjust something ...
And the iOS file system seems to be more transparent than that of Android.
1 Like
I think regarding the file system it is more the fact that iOS has always had the more restrictive view of files compared to Android. Now, Google is trying to limit the originally permissive file model and it's causing a lot of pain.
1 Like
Exactly, and the users express their anger very clearly.
Here are my tests copying images to the private data dir (→ internal storage), tested on:
- Android 11, APK,
targetSdkVersion=29 - Android 11, APK,
targetSdkVersion=30
I first downloaded 7 images from my webspace in the ASD and copied them from there to the privateDir without permissions. I also copied one image from the assets to the privateDir:
This one:
The other (downloaded) images are pics of a car.
(total size of images = 4MB, but 30MB works too)
Of course, I could not use the Image component without READ permission. So I used an extension for this. But I'm pretty sure that the permission request will be removed when AI2 targets Android 11, Aug. 2021).
I added "GetPrivateDir" in my GetASD extension:
Blocks
I think this is a milestone (at least for me):
I am very happy that this is (now) possible, because I could bypass the problems that will arise when Google only allows AABs (and no longer allows APKs, Aug. 2021 for new apps). Because I have to pack all my media files and other sensitive data in the internal storage to avoid that users (without root access) can access them. (And decompiling in order to build a big app does not seem to be possible with AABs.)
The maximum AIA sizes of 30 MB or 50 MB (http://code.appinventor.mit.edu/) are not enough for my apps. So I have to download the files on the first run, download them to the ASD, copy them to the privateDir and then remove them from the ASD.
And I know from many posts in the AI2 and Kodular forums that many others feel the same way.
Note:
If the File component could save / delete all file types in the
ASDandprivateDir
no File extension would be required and this might also be possible with iOS.
2 Likes
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
