I'm completely stalled with Event listeners

Hi Thunkers,

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! :frowning:

1 Like

It’s possible that the # and (especially) the / characters in your variable names are causing the issue.

Is this something you can try replicate in a smaller (less important! :joy:) sample app?

1 Like

Thank you for your reply @domhnallohanlon

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.


Hi @domhnallohanlon,

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?



can you try the block?

i see the value of a in the screen1 when click to button.

Hi @eddie.rebehy,

I changed the variabes to [cloud] and your App worked like a charm.


I tested it without initializing the variables but did not work. Once the variables initialize [A] acted as expected.

1 Like

hi @bilastois,

If the listener is working, both labels will increment every second without clicking the button.

1 Like

Hi @eddie.rebehy,
As far as the code goes only [A] should incremented. Nothing is coded for [B] :grin:

1 Like

Yes you are right. I just changed that.

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.

1 Like

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.

Just a suggestion.

1 Like

This is what I started with. It won’t work on multiple acreens for me.

1 Like

@muneer @domhnallohanlon

And just like that…without any communication from the Thunkable beavers… It starts working for all variable types.

Muneer; please confirm that I’m not losing my mind!

Time to test this again in my app.

:crazy_face: :roll_eyes:

edit: you may have to clear your app cache to see this working.

1 Like

Not variable named variables. But you can have multiple paths in one cloud variable!

1 Like

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.

1 Like

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 :face_with_hand_over_mouth:

1 Like

Thanks @muneer

I think I am going crazy. I thought I had three listeners on each screen. :crazy_face: :confounded:

You are 100% correct. I must have been a little trigger happy with my blocks. Back to square one. :frowning:

I have now amended and rechecked the app. My goal is to get the other two screens working on app and stored variable listeners.

I am sorry to have caused you the disappointment. Believe me it wasn’t intended.

:joy: Grateful to have another set of eyes on this.

1 Like


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.

1 Like

Yes, report the bug to GitHub.

A few of tips for Git Hub:

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.

Your pain is real.