hi
I have already used the following block
At this time, it is not possible. The last I heard is the team is working on a solution for that but it is not yet ready.
[Edit]
I have to say that this option is still available under the StP UI. You need to use the Firebase DB blocks to make this happen.
You have to first add a listener to any dynamic key you want then use the Data Change block to monitor changes to the database.
hi
thank you for your answer so I should find the time to redo everything using StP
Not necessary.
Are you trying to detect data changes from the same app but with other users or is it from apps you do not have control of?
If the changes are from apps that you can control then there is a workaround which you can do in DnD.
Hi
I’m trying to detect changes with the same app from other users
there is no solid date yet, but we do plan to reintroduce the listeners in DnD. I would imagine if we hear this is causing a lot of disturbance for users it may be prioritized. 
Squeaky wheels do get greased
Thanks for your answer
While waiting for this great announcement I will familiarize myself with StP UI
I haven’t tried it yet, but i wonder how well this may work for people
Essentially you could copy your cloud variables bucket that you want to listen to into a local variable
I have a timer set to fire every 3 seconds. when it fires it checks if my local version matches the cloud version and if not, it updates the local version. This is not the same as what the firebase listener blocks do, but is similar and may function as a workaround until we have a better solution.
I’m so curious if this method is faster or slower than updating individual variables with individual Firebase values, which is what I’m doing for my Next Letter game/chat app. My guess is since Firebase is JSON based, it’s faster to transfer the whole database at one time. It’s also fewer reads from the Firebase database which is important because their limit is not that high.
Firebase doesn’t actually put a read count limit on the dB access. pricing is based on total GB/month stored plus data egress GBs/month
I could be wrong but I’m fairly confident here.
Firestore, on the other hand, does count total reads/writes/deletes per month and charges based on that.
End of day: this is still not ideal and only a workaround for a more solid answer → listeners.
Hmm, I thought I read there was a limit of 1,000 read calls per second. But now that I look at their Realtime Database limits, it’s more like 100,000. I don’t have to worry about those kinds of numbers. I was hesitant to have my “listener” check Firebase more than once per second but maybe I’ll make it more frequent now.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
