I’m finding that my Photo Journal app is getting huge. The data use on my iPhone is currently at 350 MB even though I’m storing everything in Cloudinary.
Which leads me to believe that when a photo is taken with the camera and then uploaded to Cloudinary to produce a mediaURL, the photo remains stored in the app.
Is it possible to then remove that photo? It’s problematic that although I’m uploading photos to Cloudinary to save space on the device, the photos get stored on the device anyway and take up the space that would be saved by hosting them in the cloud. So what’s the point of using Cloudinary at all?
I hope I’m missing something but if not… I’ll add a feature request to have a camera component property/switch that deletes the original photo after it’s uploaded to Cloudinary.
In fact, delete photos (and now videos) from the local cache is very important to keep the internal device space under control, in two cases: (1) after Cloudinary upload or (2) when you are storing data 100% locally and want to delete it!
And if I understood correctly in this post, another issue in PhotoLibrary block is that after you update the app on iOS you loose all local photos.
@jared, how about to set this post in the feature request, and the other I mention as ISSUE/BUG ?
My guess is that the main purpose of Cloudinary is not to save your space, but to easily provide a way to share your pictures to others As I didn’t used it yet, it’s just a guess
I believe in that Cloudinary is more than “a backup & share” approach for store images (and now videos).
Is a solution for who wants to keep images safe on cloud. So, when using cloudinary don’t make any sense to keep images using local space (that became a problem depending on the volume of images you manipulate).
In my case, for example, I’m working in a social network project. Can you imagine the problem I’ll have after the users posts 10, 100, 500 pictures/videos and Thunkable keeps the files locally? For me is a NO-GO situation to use Thunkable in this project if they don’t fix this.
In other hand, for the projects that will not use Cloudinary, and you need to keep the images locally, you must have a way to delete the file when you want, to also save space.
So, both blocks must to be improved:
Media DB to delete pictures locally after upload.
Photo Library AND/OR File Picker must to provide a way to delete saved files locally.
Again, to not depend of upgrades in Tkunkable, since we are waiting for bugs fixings, someone knows any workaround (yes, another one) to delete local files?
The fact is that we can see the full path of local file in the PhotoLibrary block (photo / video output property), so it’s possible to delete it.
I agree that deleting files manually is extremely dangerous as it can break the application.
But…as today Thunkable doesn’t provide support to perform a garbage collection of unnecessary or obsolete images/videos, the only solution is to find a way to delete it manually.
Anyway, keeping the files locally will also break the app due to space exhaustion that will happen one day which will force the user to remove the app to clear this “cache”.
And the worst: if the idea is to keep the files local, you can’t delete the obsolete images to save space, which would allow the user to manage their space without having to make a backup, remove and reinstall the application, and finally restore a backup.
Fortunately in this case we have the exact location and file name to delete the file safely. It’s just a matter to store this filename with the full path to delete the media when necessary.
That’s why I asked for some delete file workaround…
Yes, I suppose that’s the way… But I have no idea how to implement it, as I don’t know node js, nor how to integrate it with Thunkable.
The challenges I’ve encountered with Thunkable today, is that I’ve been bumping into product limits, bugs and workarounds constantly, that can only be solved in two ways:
Product improvements (to maintain the “no code” premise), that unfortunately we don’t have enough information when will be available (a clear product development roadmap)
Learn to program in node js to do all the necessary workarounds. And this gets even more difficult when there are no tutorials or examples available to learn it. Anyway, at the end of the day, this totally breaks the idea of using a “no code” tool, besides the fact we still have to pay monthly to have to do things “on the outside” that Thunkable doesn’t do natively.
Unfortunately, this is something that is becoming more and more evident as I advance with my projects.
