Onesignal-android-sdk: Is os_notification_received fired every time a push notification is added to the tray?

[epetre]

Description:
Does os_notification_received reliably fire regardless of the app and phone state?
https://documentation.onesignal.com/docs/google-analytics-for-firebase.
The integration seems to work well and we do get events such as
os_notification_received in the Firebase DebugView after following your integration steps.

However, I still have a few questions about the event os_notification_received since the debug view doesn't seem to be able to test those or they are not fired in those situations:

1. Do we get this event when the app is closed.
2. When the app is put to sleep.
3. When the phone was off, but then brought back on.
4. When we are on airplane mode and we come back off airplane mode.

According to this comment there, it would seem that it's tracked in all those cases, but doesn't work in the dedug view (which is fine, but could be added to the doc).
https://github.com/OneSignal/OneSignal-Android-SDK/blob/cd82dbb14fcdd3064990a0a04f79dd23e4961ac8/OneSignalSDK/onesignal/src/main/java/com/onesignal/OneSignal.java#L2061

Basically, do we get this event event every time the push is added to the tray or is there a limitation in those cases.
This event is going to be crucial for our analytics, so we just want to make sure that we can rely on it.

Environment

1. Ionic4
2. Android cordova 8.1.0
3. Android SDK 26

Steps to Reproduce Issue:

1. https://documentation.onesignal.com/docs/google-analytics-for-firebase

Anything else:
This is not really an issue, but more of a question on the code as I didn't find precisions on it or the README or previous issues on that matter.

[epetre]

Any news on this one? Even if it's to post it somewhere else :D

Thx!!

[rgomezp]

Hello,

Do we get this event when the app is closed.

Android Native SDK calls this method when the app receives a notification while app is in focus or in the background.

When the app is put to sleep.

A normal close such as swiping your app away is a normal close and won't be an issue on most devices. However, force-closing it through the app settings, task killer, or through Android Studio would result in most Intents (including pushes) preventing services from starting.

When the phone was off, but then brought back on.

You will want to use the Service Extension which handles restored notifications. Notifications are restored after an app update, device reboot, and app opened after being force killed. If you have customized any alerting / priority settings check the restoring flag before applying them. You may want to omit displaying if your notification is no longer relevant to the user.

Use the NotificationExtenderService for Android and implement the NotificationProcessingHandler

When we are on airplane mode and we come back off airplane mode.

See previous response

[epetre]

Android Native SDK calls this method when the app receives a notification while app is in focus or in the background.

Sorry, but this sounds odd. As the comment in the code that I linked and Jon from your support team seems to say that this method is called when you the Push notification is displayed.

The Code
https://github.com/OneSignal/OneSignal-Android-SDK/blob/cd82dbb14fcdd3064990a0a04f79dd23e4961ac8/OneSignalSDK/onesignal/src/main/java/com/onesignal/OneSignal.java#L2061
// Called when receiving GCM/ADM message after it has been displayed.

From Jon:

If the notification shows up on the device, then you should get this event.

Also, in the code when a method is called when the app is in focus or in background, it seems to be stated as a comment:
https://github.com/OneSignal/OneSignal-Android-SDK/blob/cd82dbb14fcdd3064990a0a04f79dd23e4961ac8/OneSignalSDK/onesignal/src/main/java/com/onesignal/OneSignal.java#L283

So I am a bit confused as to when that method is actually called.
I want to make sur that this method is supposed to be called regardless of the app state basically and it would fit with the event name os_notification_...

[rgomezp]

Like stated in the comment, it will only be fired if app is in focus or background, meaning your app is running. For this reason, you should only use it in logic that involves the app actually running. If it isn't running, consider adding your handling to the "opened" event instead. This event fires when a notification is clicked/tapped.

[epetre]

@rgomezp

Do we get this event when the app is closed.

Android Native SDK calls this method when the app receives a notification while app is in focus or in the background.

I was asking about the event os_notification_received that specific method is just a guess as to where that event might be fired. My question is about when that event is supposed to fire and if it's supposed to fire even if the app is closed in normal circumstances (no carrier blocking or anything).

You guys have confirmed deliveries and the way you documented this, they fire an API call even when the app is closed. That API call is sent out to confirm the delivery of a push. If you are able to do that API call to confirm the push delivery, why would the event os_notification_received not fire in the same way?

[epetre]

@rgomezp Should I open a different issue for this or contact someone else?

[rgomezp]

Howdy @epetre ,
EDIT: Confirmed deliveries are already implemented and is handled for you automatically. You can modify your own extender service to manage incoming notifications if you would like.

For the normal "on received" event + callback, see my above response. Perhaps if you give me some context as to what you're trying to do I will have a better understanding of what you're trying to figure out.

[epetre]

@rgomezp yes I can provide some more clarifications with pleasure.

We are Interested in tracking how many of our pushes make it from the OneSignal Server to the user's device. We are having a hard time getting accurate data on this.

We spoke with someone from your support team that lead us to believe that there were 2 comparable solutions for this. 1. Firebase events integration and 2. Confirmed deliveries.
We followed those steps for the Android integration and we started collecting data about the os_notification_received, os_notification_opened and os_notification_influence_open.
https://documentation.onesignal.com/docs/google-analytics-for-firebase
Now we are discovering that those events are tracked only if the app is in focus or in background.

I was led to believe that those events were fired using the notification extender service in the same way as a Confirmed deliveries, except instead of making a call to the OneSignal API to confirm the delivery, it would just fire a Firebase Event. And this would make the firebase events os_notification_* work in most situations even when the app is closed.

2 points are very confusing to us at the moment.

1. From what I understood, you are saying that for Confirmed Deliveries requires an additional notification extender service to add that would then track this information and deliver it back to OneSignal. If this is done automatically, it means that your implementation of the notification extender is part of this plugin?
2. Why doesn't this implementation of the notification extender fire the Firebase events in the same way? It's confusing to have an event named os_notification_received when it only fires when the app is in focus or in background and maybe it's just me but I didn't get that from the documentation.
   If it was named notification_received and wasn't presented to us as a solution to track deliverability, it would have been less confusing.

We are using Ionic and if we wanted to implement our own NotificationExtenderService, we'd have to fork this project and maintain it or create a plugin for Cordova with our extender. It looks a little bit easier to change in iOS, but still not trivial in our setup.

[rgomezp]

@epetre ,
Sorry for the miscommunication. Just to clarify, the notification extender service is NOT required for Confirmed Deliveries to work. All I meant to say was that Confirmed Deliveries work automatically without further configuration.

I'll let @jkasten2 address your concerns regarding the firebase events

[jkasten2]

We spoke with someone from your support team that lead us to believe that there were 2 comparable solutions for this. 1. Firebase events integration and 2. Confirmed deliveries.
We followed those steps for the Android integration and we started collecting data about the os_notification_received, os_notification_opened and os_notification_influence_open.
https://documentation.onesignal.com/docs/google-analytics-for-firebase
Now we are discovering that those events are tracked only if the app is in focus or in background.

@epetre The Firebase Analytics os_notification_received event and the Confirmed Deliveries built into OneSignal should both fire in the same cases. That is when a notification received and displayed. This applies to all states the app can be in, foreground, background, or closed. The only exception is if the app is in a Force Stopped, in that case the app will never receive the push payload at all. Swiping away the app is a normal close, not a Force Stop but you can find more details on the our app state documentation below.
https://documentation.onesignal.com/docs/notifications-show-successful-but-are-not-being-shown#section-the-app-is-force-stopped

Now we are discovering that those events are tracked only if the app is in focus or in background.

The only way I can see this happening is if the Firebase library can't be initialized in time or if the Firebase library does not send events if the app process was started but no Activities have been shown yet. We have a catch for any errors that Firebase may throw but we do print them to the logcat so please check to see if you are getting anything. Listing the OneSignal source here for reference.
https://github.com/OneSignal/OneSignal-Android-SDK/blob/c33b7a943fb8e08e174ecae8d0a63c67c0a5140c/OneSignalSDK/onesignal/src/main/java/com/onesignal/TrackFirebaseAnalytics.java#L160-L173

From what I understood, you are saying that for Confirmed Deliveries requires an additional notification extender service to add that would then track this information and deliver it back to OneSignal. If this is done automatically, it means that your implementation of the notification extender is part of this plugin?

Sorry for the initial mistake on this, it isn't required for either Firebase or Confirmed Deliveries.

Let me know if I missed something in this thread that I overlooked or if you have any additional follow up questions. Thanks.

[epetre]

Thank you for the clarifications, it makes sense!!

1. If confirmed deliveries fire the same way, it's weird that a decent number of the clicked notifications didn't give us the firebase events, but they show up as confirmed if we check their status on the OneSignal dashboard. I have collected 4 of those just as an example if you want their IDs.

2. For confirmed deliveries, their promise is:

   provide accurate click-through rates as well as confirmation that notifications are successfully being delivered to your users.
   But the problem is that they accomplish that on a per-notification basis. It's really hard to get a higher level view about deliverability right now.
   [[source](https://documentation.onesignal.com/docs/confirmed-deliveries)]

3. The export functionality doesn't include the status of the notification.
4. The confirmed state is only visible when looking at individual notifications, so we'd have to visit each notification individually to gather that info.
   Do you think that it would be possible to add the status of each notification to the export to spreadsheet?

Thank you for all your help guys and if you prefer continuing this by email or some other tool just let me know. I realize that this is starting to go outside the scope of this SDK.

[jkasten2]

1. The Firebase click event os_notification_opened count is most likely due to the reason of why os_notification_received isn't always working. The Firebase library may not have initialized in time so the Firebase library drops the event. It might be possible to fix this issue in the OneSignal SDK if the Firebase library has a way to know it is ready. So the next steps here would be search this in Firebase's docs if there is a way to know it is ready.

2. The received field is available on the REST APIs view and list for notifications https://documentation.onesignal.com/v6.0/reference#view-notification and the dashboard only today, as you have noted. It will be available in the export in the future.