I’m trying to optimize my Photo Journal app to display photos stored in Cloudinary. The actual urls are retrieved from Firebase and then stored in a local data source because Firebase retrieval was too slow.
The problem I’m running into is that the data only shows up in my DVL (Data Viewer List) some of the time. I can run the same code and 75% of the time, the DVL is blank (it shows each row but there are no images or text). The other 25% of the time, it looks great. And I have no idea why.
The blocks I’m using are below. The idea is to create or update a row by getting the firebase data from an app variable where it’s been stored. I know the data is in the local data source (“Journal”) because I can display it in a label. But it often won’t show up in the DVL. I even tried the “Refresh Data” block – which seems to crash a lot – but it doesn’t appear to help.
I agree. And maybe I’m wrong there but after hours and hours of trying to get cloning and firebase to work together quickly, I gave up. It seems like cloud variable retrieval was the main problem as far as speed is concerned.
But I’ve iterated so many times I’m honestly a little lost. I’m trying to rein in all the variables at this point.
Just to add to the above, I was worried that maybe the DVL wasn’t refreshing the data since I was able to confirm the data exists in the local data source. So I’m trying this now:
But that just crashes the app after about 20 seconds. So I dunno. And then when I try it again, presto! Data appears.
There is a known issue with number of rows block that it retrieves cached data but that was with connected tables (Airtable and Google sheet). @jane is working on a fix and can comment if the situation in your code is affected by it.
Is your firebase top level object actually set? Could you be getting into the loop before it has a value, resulting in setting nulls? That it works /sometimes/ would seem to suggest a race condition of some sort. If you stick a painfully long wait in there before starting the loop, does the behavior go to 100% ok?
Didn’t I see a forum post recently about DVL refresh causing crashes?
Right, that was useful info but this is the 2nd call at the very least. Upon sign-in, I’m retrieving firebase data. This is the third screen so unless that delay gets reset for each screen load, I’ve already connected with the firebase database.
I also added (above) that a 5-second delay didn’t help matters.
In this variation, I first get the number of firebase entries and then wait 5 seconds to start the loop. Each loop iteration has a 1 second delay after creating a row in the local data source.
If you start by setting app variable properties of top level to null or empty and then run function get firebase top level object then check the variable is not null before starting your loop. This should be a better approach.
Again, instead of the wait block inside the creat row block, a better way is to check the green row id is not null. If null then it means the record hasn’t been created but if it has a value (row id) then the record is successfully created.
I’m not convinced that’s possible to check. If I have a create row block inside of a loop, won’t it just bypass the “do” section of the create row block? And if so, how can I check to see if the green “row id” block is null?
I tried this but I’m not sure it’s really doing anything:
Do you want everybody to be able to see the same photos, like social media, or do you want the user only to be able to see his/her photos?
If it’s the latter, then you could use Local DB to save the photos instead of uploading them to firebase and then retrieving them. If it’s the first option, then you could also use Airtable and link it with the data viewer list for immediate results.
Each user needs to be able to store (via camera or album upload) and retrieve their own photos. I hadn’t thought to use the Local DB to save the photos. I like the idea of using Cloudinary (and Firebase) because the photos would be stored in the cloud and the app can transform them as needed to retrieve & display them at small or larger sizes.
But I realized that the Camera component in Thunkable stores the photos on the device whether or not you upload the image to Cloudinary so means my idea to save space doesn’t work.
I suppose I could use Airtable. I’ve found it to be a little clunky but it’s been awhile since I’ve played around with it.
Ah, ok. I find Airtable pretty smooth, and you can directly upload pictures using the green block from the camera component, as long as your column’s type is Attachment.
But how would you structure the data to allow a user to create multiple journal entries? I basically need to store records in Airtable (Airtable calls their rows “records” but that’s not what I mean). I guess I could just have 100 or so empty columns waiting for journal entries but that doesn’t seem like the best idea to me.
My Firebase database allows each user to enter journal entries, as many as they want, and looks like this (for each user):
