In my app, I had set up a listener on my loading page which referred to any changes in the Firebase RTDB Users root node.
I then added The data change block to each screen where I needed the Event Listener.
This was working at one stage but I haven’t visited it in a while. Today, I am in the process of tidying up my app and I hit a brick wall. The listener no longer works between screens. If you navigate away and then back again the listener stops triggering and only continues to work on one screen.
I have tried to including a change Variable in just one listener block to one screen and add listeners to that variable on the other screens instead of the RTDB listener but that too does not work between screens.
Does anyone have any ideas? I am completely stalled!
You suggestion regarding Variable names is noted with thanks.
Here is a much simpler example that doesn’t involve Firebase:
Screen two is a simple one second counter which works happily in the background.
Screen one does not trigger the event listener for Variable ‘A’ that is changing every second in screen two. By pressing the button on screen one we can see that Variable “A” is indeed incrementing however Variable “B” is not being changed as the Listener is not being triggered. If I can solve this simple problem, I can fix everything in my more complex scenario in my other app.
Should I expect any support with this? Any work around I come up with is extremely inefficient and messy. Listener Callbacks are essential to my application. Am I doing something silly or is this a bug?
Thanks for making me aware that the listener works for initialised cloud variables.
Unfortunately this won’t work in my case because the variable names are unknown. They are created when the user is created. Thunkable doesn’t have a block to allow initialization of a variable named variable.
let me ponder on your discovery and see if I can find a way to make it work.
Firebase is designed to work with thousands of listeners in one function. Unfortunatly Thunkable isn’t.
Have you tried the [Data Changed] event of Firebase.
It returns the [key] name and the [value] of this key. Using successive if statements you can determine which [key] was changed and what action you want to take.
I tried that this morning Jared by initializing cloud: users/ … then setting listeners to the users path. It still only worked on a single screen. There are definitely some inconsistencies occurring.
Hi @eddie.rebehy,
Your App works as expected. You used the screen [start] event to start a [forever] loop to increment all three variables and in the other two screens you are tracking changes using the [cloud] variable which we found that it works therefore they will all seem to be working.
However, if you changed the tracked variable in the other two screens to [app] or [stored] variable the changes will not reflect in those two screens and will only reflect in the first screen.
I don’t know if you can understand what I’m trying to explain
While I am still unable to get App and Stored Variable listeners to work across screens, I am able to get the RTDB listeners to work on all screens even without initializing a cloud variable, however only when I remove any type of Navigator and create my own ‘button’ screen navigation.
The anomaly of this listener only occurs inside the navigator containers. If a Navigator is used then the listener appears to be restricted to one screen only.
And still no input from Thunkable staff. Should I be using Github or some other medium to report these bugs? I am not too familiar with that.
Simply stating the problem within a complex app will not get you very far. As the software development saying goes, “it works on my computer”. You will need to create a clear demostration app. If you can provide both a link to the app as well as a GIF of the app behavior (I love AZ recorder on Android). It also helps to engage the Thunkable staff via DM, discuss the problem, then show them the issue. That can often get you request prioritized. I’ve found simply logging the GitHub issue will result in it being ignored. To be frank, there are a significant number of GitHub tickets that are programmer errors vs. errors in Thunkable. You can help the staff prioritize your issue by making someone on the staff aware of the issue and tagging them on your GitHub Submission.
) sample app?
Grateful to have another set of eyes on this.