No Notification for Data Message

[raphaelpreston]

Problem description

When I send a 'data' message, no notification is shown if the app isn't open. I took a look at #9, but I'm fairly certain I'm composing the message correctly.

Expected behavior

The documentation states that a 'data' message is "a notification that also delivers its data to the app", so, I would expect a notification to appear.

Environment

• Tabris.js version: 3.0.0-beta1
• Device: iPhone 7
• OS: iOS 11.1.1

Code snippet

In-app Javascript:

/* check to see if app was launched by notification tap */
setTimeout(() => { // workaround for #41
  console.log('launchData after timeout: ', firebase.Messaging.launchData);
});

/* handle any messages that arrive */
firebase.Messaging.on('message', ({data}) => {
	console.warn('Received message data: ', data)
});

Command Line Notification Composition:

curl -X POST -H "Authorization: key=$key" -H "Content-Type: application/json" -d "{
    \"to\": \"$token\",
    \"data\": {
	  \"title\": \"Title\",
	  \"body\": \"Body\",
      \"payload\": \"custom data\"
    }
  }
" https://fcm.googleapis.com/fcm/send
# Response in terminal: {..."success":1,"failure":0,...}

If the app is open, then the following prints:
Received message data: {payload: 'custom data', title: 'Title', body: 'Body',...}

But if the app is closed, then nothing prints.

[raphaelpreston]

Commenting on my own issue because I found a workaround for sending data from a notification to the app. Please comment on the viability of this workaround as I can only test it for 3.0.0-beta1 on iOS 11.1.1 (iPhone 7).

Workaround

As mentioned in my original post, 'data' messages aren't actually showing any notifications, so we are forced to use a 'notification' message. According to the documentation, tapping on a 'notification' message does not forward the notification data to the app; however, this is not the case.

curl -X POST -H "Authorization: key=$key" -H "Content-Type: application/json" -d "{
    \"to\": \"$token\",
	\"notification\": {
	  \"title\": \"title\",
	  \"data\": {\"key1\":\"val1\",\"key2\":\"val2\"}
	}
  }
" https://fcm.googleapis.com/fcm/send
# Response in terminal: {..."success":1,"failure":0,...}

If the app is open, then the following prints:

> Received message data: { 'gcm.notification.data': '{"key1":"val1","key2":"val2"}', aps: { alert: { title: 'title' } }, ...}`

If the app is closed, then a notification shows up. When it's tapped, the app opens and the following is printed:

> Received message data: { 'gcm.notification.data': '{"key1":"val1","key2":"val2"}', aps: { alert: { title: 'title' } }, ...}
> launchData after timeout: { 'gcm.notification.data': '{"key1":"val1","key2":"val2"}', aps: { alert: { title: 'title' } }, ...}

^{Note: It prints twice because of #60}

So, as you can see, the notification data is indeed passed to the app, and can be accessed by firebase.Messaging.launchData['gcm.notification.data'].

I will leave this issue open, and please comment on the viability of this workaround as the functionality it relies on seems to be contradictory with the documentation.

[karolszafranski]

Thanks, we are aware of the issue, and we will post the update here after solving it.

[patrykmol]

Hello @raphaelpreston. You are right that current behaviour is not as we have described in our documentation. However I believe that our documentation is wrong and needs to be updated. In Send message with notification from server paragraph we link to Firebase documentation and it states no such behaviour as the one described in our documentation. According to Firebase documentation notification-type message can contain data (but it doesn't have to) and will show banner if application is in background. However data-type message will only contain data and will not provide any kind of confirmation that the notification has been received.

I consider current behaviour correct and in line with native iOS behaviour. We will update our documentation. I will leave this issue open until our docs are updated.

[raphaelpreston]

Oh okay, wonderful. Then my 'workaround' is how I should be implementing it in the first place. Thanks!