๐Ÿ‘ itoo Push Notification Examples for ALL!

Using latest version of both the extensions and connection is pretty good. I m on 5g network,
All changes as indicated, but not getting notification if app is closed for few minutes

Which device and Android version are you using for your tests? You might have to disable battery optimization

Taifun

Vivo T2 Pro, Android - 15, so also users needs to ignore battery optimization to show notification? Thats what most of the users dont like. :slightly_smiling_face:

I do not know
You could test it and let us know, if it works on your device then
Let us know what you find out

Taifun

I just checked.. I opened that app last and showing still active. But when i change the value at firebase (manually) without opening the app the notification is not showing. As soon as i open the app it shows notification.

Show your blocks, and firebase setup (rules, data structure) just in case...

Capture1
Capture

Add debug statements to find out, if the fetchMessage event handler gets triggered...
Probably your if statement does not make sense?
Use the Notifier.LogInfo method for this to log sonething and use logcat to check. .

Also what was the result of this teat?

Taifun

Also personally I would register all events in the main procedure instead of registering the GotText event again and again each time the clock fires

Just keep Web1.Get there

Taifun

Do you mean like so ?

The existing layout is from my example which got the @Kumaraswamy seal of approval when published...

Yes
Sorry , just trying to keep the logic as clean as possible... of course it also would work as you did it...
Taifun

No worries, if it is "better" as you suggest (which it appears to be), I can rework the guide. Is like it is based on earlier examples in the itoo topic.

Can you confirm your firebase project is on a us-central server ?

I have just run a test over the last 4 hours with an app based upon example 2, allowing the app to drift off into the background by itself for the first couple of hours, then manually closing the app for the following two hours. All the while running regular test messages directly from Firebase. All messages were notified to the device within 15 seconds of setting them.

Yes

1 Like

After a 13-hour interval, I manually modified the data, but the notification was not displayed. It also did not appear at the time I initially reported the issue, and I remain unsure why it failed to trigger on both occasions.

I have a doubt regarding two approaches for monitoring data changes in an app:

  • Example 1: Triggers an instant notification when a value changes.
  • Example 2: Checks for data changes every 15 seconds using a timer.

From what I understand, Example 2 might be more reliable in ensuring the app keeps checking for updates even when running in the background.

Is Example 2 a better approach for background operation, especially considering that some platforms may restrict real-time notifications or background services?
Iโ€™d appreciate any insights on the pros and cons of both methods, particularly for apps that need to stay updated with changes consistently.

Where does this "understanding" come from ?

Both methods work, and are equally reliable in my experience.

Iโ€™m using the Firebase Realtime Database on the Spark (free) plan, which allows up to 100 simultaneous connections. In my app, I'm using the FirebaseDB.DataChanged event (in MIT App Inventor) to listen for changes in the database.

My question is:
Does using the DataChanged event keep the app persistently connected to Firebase, even when the app is running in the background or idle?
If so, would each device count toward the 100 concurrent connection limit as long as the event is active?

I'd appreciate any clarification on how these connections are managed under the free plan.

You would need to ask Firebase as to how connections work. From what I remember, several connections are made whenever AI2 makes requests from the Firebase RealtimeDatabase. In this scenario (Example 1 or 2) connections will only be momentary, which should mean that 1000's of devices could be connected without hitting the 100 concurrent limit.