PushDelegate.OnReceived not firing despite presence of data payload

[munkii]

• Shiny 2.7.1
• iOS 16.3.1
• Android 13
• Xamarin Forms 5.0.0.2401

I'll start with what I am trying to achieve.

1. Send a visual notification to the user when something happens on the server
2. Include some extra data in that notifcation that tells the app to request and update of a piece of data

I have added some code into the PushDelegate.OnReceived to read the Data portion of the PushNotifcation and from that decide what needs running in the app.

Here's a table of the 6 different scenarios. My primary issue are the scenarios when OnRecieved is not firing.

	Notification displayed	OnReceived Fired	OnEntry Fired (when tapped)
1. Android App foregrounded	Y	Y	Y
2. Android App backgrounded	Y	N	Y
3. Android App closed	Y	N	Y
4. iOS App closed	Y	N	Y
5. iOS App foregrounded	Y	N	Y
6. iOS App backgrounded	Y	N	Y

When the notification appears on the device I see this in the the VS Output window

[FirebaseMessaging] Unable to log event: analytics library is missing
[CompatibilityChangeReporter] Compat change id reported: 160794467; UID 10356; state: ENABLED

I can get OnReceived to fire for silent notifications on both platforms whether in the background or the foreground. However I don't want to use silent notifications as there delivery is less predictable and throttled on iOS. Also when processing the silent notifcations on iOS, with the app in the foreground my attempts to create a local notifcation as the "visual notification" never result in a notification appearing.

I know that OnRecieved does not fire if the Data portion is not populated but in the case of Android I can see from the OnEntry event that the Data object is populated.

In the scenarios where the the app is closed the fact that OnRecieved is not firing is not an issue as the app will update that data on startup anyway

Am I wrong to expect OnReceived to fire for non silent notifications in Android when the app is backgrounded and in either state for iOS?

[aritchie]

For iOS, it is likely you are missing the content-available=1 in your push payload. Also note, that if you send lots of content-available=1, Apple will throttle as well even if you include an alert.

For Android, if you swipe away the app, the service will die. If you stop the debugger, the service will die.

[munkii]

You are right I am not but that is deliberate. I only set tat for "silent" notifcations. The Apple Docs say we should not mix content-available=1 with notifications that could trigger a user interaction i.e. non-silent.

That makes me think that the requirement we have is not really supported by Apple or at least somethig they'd rather us not do. Which seems odd as the requirement is pretty normal sounding to me.

Is there a better way of reliably acheiving what we want apart from explicitly calling the web service everytime the page appears in the app?

With regard to Android, "swipe away" as in close or just backgrounded? I don't care if the OnReceived can't be called when app is closed

EDIT
I can confirm that if i set content-available=1 iOS works exactly how I want except that as i said above this seems to be a mix of options that Apple don't want us to use

[aritchie]

Apple does the throttling for a bunch of good reasons. It prevents you from killing battery, doing things from an app that the user may not care about, etc. There thinking is to just show the user something if it is important. I don't argue the thought process. The user will go into the app if the notification is truly important and you can immediately request data from there. They also offer new extensions like push location instead of tracking the user every footstep.

Is there a better way of reliably acheiving what we want apart from explicitly calling the web service everytime the page appears in the app?

Not really. Data calls usually don't take long so I tend to warn people for thinking the data is that important to be immediately available. If there are offline scenarios, push doesn't solve this issue either. You are better to use jobs with connectivity requirements.

With regard to Android, "swipe away" as in close or just backgrounded? I don't care if the OnReceived can't be called when app is closed

"Swipe away" means destroying actually removing the app from memory. The service will die with it. Also note that if you disconnect the debugger, it is same as closing the app. You need to relaunch your app if you want the events to be picked up.