I don't use CloudDB so I was unaware - but then so are the majority of App Inventor Users! The way it actually works though - I think it should be far more simple.
There is this thing called "search", but no-one uses it
The OP did, hence his valiant attempt to use Base 64 encoding.
When you store an image in CloudDB, the CloudDB component takes care of base64 encoding the content of the image and storing it with an internal tag that gives the file's extension. You need to get the StoreValue() call the filename that contains the image. Normally, if you fetch an image from the Camera or the Android image gallery app, Android returns a special filename which you can then hand to CloudDB. You should never need to create AppInventorBinaries.
When you read an image from CloudDB, the component has to put it in a file, so it can give back a reference to it (filename) which can then be used with other components to display or store the content. GetValue() is not handed the filename to use, so it generates a random one and puts the file in AppInventorBinaries.
In general, Android wants you to manipulate images via various content managers. Think of the returned filename from the Camera as an opaque thing, and not attempt to do anything with it other than imagey things.
When you attempt to explicitly use files in Android, things get messy because where files live and what files your app is allowed to touch varies based on the version of Android running on the device and the "targetSdk" of the application. Then there are situations where you have to prompt the user for permission, even after including the permission in the manifest.
App Inventor's handling of files was first written years ago when there were two places you could work with files, an application private directory, or the "sdcard" which was readable/writable to all apps. In the earliest phones, the "sdcard" location only worked if the phone had a physical SDCARD installed. Later phones emulated the SDCARD if the phone didn't physically have one.
Well, you can image that sdcard access was abused, so Google has been changing how these directories are access, what permissions you need, etc. All of this is to prevent apps from messing with each other, i.e., making the App sandbox stronger.
At MIT, we have been attempting to shield the App Inventor developer from a lot of this complexity, with limited success! And each year we have to jump through new hoops. For example, if you package an App on ai2 today, is targetSdk is 30, which corresponds to Android 10 (which was a big change when it comes to file handling vs. 29). Soon we will release a version of App Inventor that targets sdk 31. We have to because Google will not let new apps into the Google Play Store unless they target sdk 31!
When I get some free time, I'm going to see if I can come up with some simple advice which should work with most version. It will likely result in storing files in the App private directory.
Thanks for the explanation!
It is Android 11 (API 30). On Android 10 it works as before, because AI2 decided to declare
requestLegacyExternalStorage=true in the Manifest.
Hi Jeff - off on a tangent there
If you are going to document file handling, Media and Non Media, that would be great. I suggest you read @Anke Guide on the subject and get her permission to publish her chart - a picture paints a thousand words, it makes the subject of Android files much easier to understand.
The CloudDB documentation certainly needs instructions for use with image files. If anyone at MIT has the time, it would be even better if CloudDB could be enhanced with dedicated Blocks for uploading/downloading image files. This would make it easier to understand.
@jis See here from 1 month ago( I did tag you in the topic below):
I say again, you should never need to create AppInventorBinaries. The system (App Inventor) should take care of it for you.
Looks like it doesn't always happen, and that is a bug, which I am now in the process of tracking down.
So the fact that we don't create AppInventorBinaries is in fact a regression. I have submitted a pull request with the fix.
Is there anyone who have aia file(full project) for uploading any image to google drive or any other cloud? help me........
This topic shows how to upload an image to cloudDB
To upload any image to google drive:
Thanks,....I'll try to do it☺
And is there any way to save files in the cloud from the device but first need to capture that picture from the app camera
Yes, use the image block from the camera's picture taken event. You may also want to resize the image before uploading.
@Muhammad_Usama if You want You can try FileStack extension to upload, download, delete, overwrite images or other files.
How to set path and handle them when initializing them??
More explanation here please Muhammad -which solution you are referring to?
Hi @Muhammad_Usama, i think you are speaking about filestack extension. Read the post about the filestack extension, you find how to set the handle, and you can try the sample project to see how i set path and handle.
Thanks everyone to solve my problem
Before you commit to filestack, check out their prices: