Using FCM notifications with data payloads leads to potentially confusing results

[READ] Step 1: Are you in the right place?

Yes, your people might consider it is a feature request but to me this is clearly a bug due a bad architecture.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: any
• Firebase Component: FCM
• Component version: any

[REQUIRED] Step 3: Describe the problem

Steps to reproduce:

When using FCM to push notifications to android devices, developpers need to deal with a 6 posible scenarios described in this table https://firebase.google.com/docs/cloud-messaging/android/receive#handling_messages

the simple fact of having a 6 scenario table for something simple like “push notification” should alread trig an ‘alert’ in any architect mind, but the thing gets worse when we think about the messages with data. they might be delivered to onMessageReceived and might be to the launcher intent.

so it automatically creates a scenario where the code will be duplicated, two classes will need to deal with same business logic. but this is not the end

follow my logic: 1- app is in background 2- fcm pushes a data+notification message 3- user sees the notification in system tray… and simple ignores it, or even has that kind of notification set to NEVER SHOW on android settings

following this scenario the app WILL NEVER RECEIVE THE DATA FROM THAT NOTIFICATION. since the launcher intent from the notification tray will never be clicked

i dont know what kind of android restrictions lead the engineers decide for this such frankstein behavior but at first glance it could be easily fix

if the android-fcm SDK is able to send the data messages to onMessageReceived even during background time… why the mixed data+notification could not send the data part also to onMessageReceived?

imho everything could be sent to that method and this class could implement a very simple method allowing any developper to foward the notifications to system tray from the onMessageReceived method

this would avoid so much code replication and create a less franksteins behavior

[samtstern]

@bolds07 as I mentioned in https://github.com/firebase/firebase-android-sdk/issues/1818 it’s not acceptable to abuse anyone in the Firebase community (Googlers or other developers like @carlonzo) on GitHub. We’re all here to make Firebase better but that has to start from a place of respect.

[carlonzo]

Hi, I would like to add a few points to your post:

• reading a post with the title “TERRIBLE ARCHITECTURE” is totally starting in the wrong way, accusing the engineers who are supposed to come here and help you to have taken terrible architecture decisions.
• if I was one of them I would have stop reading at the title and close the issue. but I was in the mood of reading something to make a good laugh, so I kept going.
• you start the post saying there is a “bug” due to bad architecture. sadly there is no bug described.
• you complain that there are 6 (6!!) differen scenarios to handle, referring to a table where it shows you 2 scenarios (background and foreground) describing what happens when a notification message is received.
• FYI https://firebase.google.com/docs/cloud-messaging/concept-options#notifications_and_data_messages notification messages are “display messages” carrying an in intent to open the application. bringing the data (if present) within the intent makes perfect sense to me instead.
• if you want to only receive data from the push, dont opt for a display message, but for a data message. if you read the docs they can explain to you what they are, and that they are all being handle by a single place.
• be nice with people, please.