I am having an issue where the datachanged block is firing unexpectedly. There have been similar posts to this but I am not even comparing strings to numbers or anything. I am questioning why this block is firing at all.
My Firebase “848JobID” value has remained at 328 for the past week so there are no changes to it. I have a listener set up for this key like this.
When I run the app in test the datachanged block is triggered even though I am sitting looking at the Firebase data and can see the value is not updated at all.
The datachanged block is here.
I have an alert set up to view datachanged block and it is showing as follows
The Alert title is the name of the key in question and the key=value is the green value tag from the change block.
My expectation here is any code in the DataChanged block is not run unless the key 848JobID changes. It doesnt change but the code here is still firing. Is my expectation wrong here?
I would welcome some help with this. Is my understanding of the datachanged block wrong or is there an issue with the IF statement. Or is my programming logic wrong. I’ve been staring at this for 3 days now and made no progress. Any advice people?
Hi Muneer, I wasnt aware of the child note thing. However there are no child nodes under the 848JobID key. Other data does change when I am testing but the 848JobID does not. The structure is like this.
Also I would have thought my check on the key changed would have prevented code firing. Am I wrong on this one?
Do you have any thoughts on how I can get what I am trying to do. Currently the listener thing seems pretty useless in anything other than the simplest of applications.
There is one more listener, listening to Jobs/YearMonthDay/JobXXX/Status. But this is not changing either. The only thing that actually changes when a driver logs on is the LoggedInDriver value which increases by 1. I still don’t understand why my check for the key ( If Key =848JobID do some stuff) doesn’t prevent the code from firing unexpectedly.
Can you move the blocks from the screen.starts event to a button.click.
Just add a button in the screen and place the code in the button instead of the screen.
In certain cases, the code in the screen gets executed every time the screen is active even though it is in the starts event not the open event. To eliminate this condition, put the code in a button and click that button to activate the listener and then work with your app as you would do and see if the Data Changed event is being triggered unnecessarily.
I can do that but it’s not ideal. Thank you for your input which is as valued and appreciated as ever. I am going to raise this with Thunkable staff as this looks like an issue with the if block to me.
@Thunkable_Staff can you review this please. Is there a problem with the IF block? In my code the Firebase data “848JobID” does not change but the IF block inside the data_changed block is still firing. You can see from the above screenshots there is no data below the 848JobID node so this block, in my mind, should not be triggered.
Wait… but the listener isn’t added until a later screen. This is the order my project runs:
Sign-in screen (firebase data changed)
Main menu (no data changed)
Input screen (no data changed)
Screen #3 has the listener added when the screen opens. And it triggers the listener immediately… I can tell because I have a vibrate block inside the listener.
I have noticed that the listener is triggered (in some situations) while the app only made an inquiry and there was no change of data in the database but could not figure out why.
I also noticed that only cloud variable listeners are triggered if you use navigators, other variables (app and stored) works in standard screens but does not work when screens are part of a navigator.
[Edit]
I found that Thunkable acts differently between variables created by initialize block and variables created by indirect assignment (the blocks at the bottom of the variable drawer. The latter cannot be used for listeners which means you cannot create listeners with dynamic names.
That was few months ago and because Thunkable staff continue changing and enhancing I need to revisit the projects again and test them.
