Skip to content

Parse Server 3.9 Silent Push Notification on iOS 13 Not Working #6106

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
AliZahr opened this issue Oct 3, 2019 · 18 comments
Closed

Parse Server 3.9 Silent Push Notification on iOS 13 Not Working #6106

AliZahr opened this issue Oct 3, 2019 · 18 comments
Labels
type:question Support or code-level question

Comments

@AliZahr
Copy link

AliZahr commented Oct 3, 2019

Was anyone able to send silent push notifications? I am unable to receive the push although it says SENT, in the dashboard.

Can anyone send a sample code of the payload if you were able to successfully send one?

@davimacedo
Copy link
Member

Can you share your current code so we can take a look and try to help you to figure it out? Anyway, I can take a look in this thread as it looks to be a good approach.

@davimacedo davimacedo added the type:question Support or code-level question label Oct 4, 2019
@AliZahr
Copy link
Author

AliZahr commented Oct 4, 2019

I am sending this push notification from the dashboard with this JSON:
{
"push_type" : "background",
"content-available" : 1,
"priority" : 5,
"videoCallRelated": true,
"videoCallSessionId": "blabla",
"callRejected": true
}
But I am not receiving the silent push notification

@drdaz
Copy link
Member

drdaz commented Oct 17, 2019

I'm experiencing a similar issue. And I can see on my device logs that the notification is being delivered with a priority of 10, despite my having set priority to 5 in the data object. This is known to fail in iOS 13.

This same setup (without push-type / pushType and priority) worked fine against iOS 12.

@drdaz
Copy link
Member

drdaz commented Oct 17, 2019

Yeah something seems wrong here. Here's a snippet from an afterSave method I've got:

    const data = {

        where: installationQuery,
        
        data: {
            'content-available': 1,
            'category': 'MessageCategoryId',
            'messageId': objectId,
            'apns-priority': 5,
            'pushType': 'background'
        }
    }

    Parse.Push.send(data, { useMasterKey: true }).then(function() {
        // Successful Push
        console.log("Push success!")
    }, function(error) {
        // Failed Push
        console.log("Push failed :(")
    })

When one of these notifications is received on the iOS device, this is logged in the console:

default	22:44:09.091864 +0200	SpringBoard	Received incoming message on topic org.example.myApp at priority 10

default	22:44:09.095459 +0200	SpringBoard	[org.example.myApp] Received remote notification request F694-86D3 [ hasAlertContent: 0, hasSound: 0 hasBadge: 0 hasContentAvailable: 1 hasMutableContent: 0 pushType: Alert]

So both the priority and the push type are wrong. Any ideas what I'm doing wrong here?

EDIT: I was trying previously with the documented 'priority' rather than 'apns-priority'. Same result.

@drdaz
Copy link
Member

drdaz commented Oct 18, 2019

I've spent most of the day trying to figure out how to debug installed modules in node; I'm an iOS guy usually.

Now that I've got there, the implementation of the new iOS flags seems off.

In node_apn/lib/notification/index.js in the exported headersmethod, where we check for, for example, this.pushType before setting the value on the notification. But the pushType value we set in 'data' is in this.payload.pushType at this point.

It's the same mistake for all the others it seems.

The tests in node-apn seem to test the default values given to the notification at init (like priority===10 and pushType===alert). That's why they pass. EDIT: Just double-checked, this isn't correct. I have no idea why the tests pass.

My notifications have started working again locally by adding .payload in all the appropriate places in that headers method.

I'll create a PR; this seems broken.

@drdaz
Copy link
Member

drdaz commented Oct 18, 2019

@davimacedo Can you comment? I see you've been active on that repo.

@dplewis
Copy link
Member

dplewis commented Oct 19, 2019

@drdaz Please check the Push Notification Guide

data: {
            'content-available': 1,
            'category': 'MessageCategoryId',
            'messageId': objectId,
            'apns-priority': 5, // should be priority
            'pushType': 'background' // should be push_type
}

@drdaz
Copy link
Member

drdaz commented Oct 19, 2019

@dplewis I'm aware what the documentation says. What I posted here was a snippet where I was experimenting.

The documentation is wrong about pushType, and the headers aren't being sent.

@dplewis
Copy link
Member

dplewis commented Oct 19, 2019

@drdaz @acinader @davimacedo

Edited

Looking at the JS Docs headers like push_time and priority should be in the data field. There are other headers like expiration_time aren't in the data field.

The push adapter doesn't check the data field for headers.

Parse.Push.send({
  channels: [ "Mets" ],
  expiration_time: oneWeekAway, // Header
  push_type: ... // push adapter is expecting this.
  data: {
    alert: "The Mets scored! The game is now tied 1-1.",
    badge: "Increment",
    sound: "cheering.caf",
    title: "Mets Score!",
    push_type: ... // not supported by push adapter, is in documentation
  }
})

Can you try if this works for you?

@dplewis
Copy link
Member

dplewis commented Oct 20, 2019

I updated my comment. I wrote a failing test here

@drdaz
Copy link
Member

drdaz commented Oct 20, 2019

I tried this adding push_type: 'background' and priority: 5 in the root of the object like you describe here, and that does seem to work. Although the console output on the device is a little odd; the initial message suggests that the notification is sent at priority 1, but delivered to the app with priority 5:

default	10:56:55.382793 +0200	SpringBoard	Received incoming message on topic org.example.myApp at priority 1
default	10:56:55.386442 +0200	SpringBoard	[org.example.myApp] Received remote notification request CAC9-8138 [ hasAlertContent: 0, hasSound: 0 hasBadge: 0 hasContentAvailable: 1 hasMutableContent: 0 pushType: Background]
default	10:56:55.386517 +0200	SpringBoard	[org.example.myApp] Deliver push notification CAC9-8138
default	10:56:55.386594 +0200	SpringBoard	[org.example.myApp] Request DUET delivers content-available push notification to application
default	10:56:55.387768 +0200	dasd	Submitted Activity: com.apple.pushLaunch.org.example.myApp:B5AA90 at priority 5 <private>

I don't think that was happening with the mods I made in the other PR.

Just tested it. With the format you describe here, setting priority to a value other than 5 doesn't work. The incoming priority value on the device is always 1, and the notification is always delivered to the app with priority 5 as shown in that log snippet.

Oddly enough, the push_type value seems to get sent just fine.

@drdaz
Copy link
Member

drdaz commented Oct 21, 2019

@dplewis I've been poking at this, and I think I was mistaken. It's certainly hard to see why the code wouldn't behave as you describe, and even harder to see why it would ignore priority but not push_type.

It looks like the priority the message is delivered to the app with, doesn't necessarily correspond with the arguments we assign. Apple's documentation only mentions priorities 5 and 10. And after some hours experimenting with this, I only see messages being delivered with priorities of 1, 5 and 10.

Certainly my claim that the priority value being set here doesn't make a difference was wrong. Sending a background push with a priority of less than 5 doesn't get delivered to the device at all.

@drdaz
Copy link
Member

drdaz commented Oct 21, 2019

TL;DR Yeah, that works. Thx. 🙏🏼

@MohammadAdib
Copy link

MohammadAdib commented Nov 8, 2019

Are any of you guys able to send background notifications? I only receive them in-app on iOS...

Here is the payload I am using

var data = {
    'aps': {
      'content-available': 1,
      'apns-priority': 5,
      'push_type': 'background',
      'notificationId': id,
      'sound': ''
    },
    'content-available': 1,
    'notificationId': id,
    'push_type': 'background'
  };

And I'm sending it using this code:

await Parse.Push.send({
        channels: [channel],
        push_type: 'background',
        priority: 5,
        data: data
      }, { useMasterKey: true });

@dplewis
Copy link
Member

dplewis commented Nov 8, 2019

Read my #6106 (comment)

This will be fixed in the next release. You don’t add push_type in the data field.

Edit: sorry just read it, if you are able to receive it in your app is there an issue?

@MohammadAdib
Copy link

MohammadAdib commented Nov 8, 2019

Read my #6106 (comment)

This will be fixed in the next release. You don’t add push_type in the data field.

Edit: sorry just read it, if you are able to receive it in your app is there an issue?

I am trying to receive the notification in the background even if the app is in the background. So if the app is not in foreground, I still want to receive a silent push. Is this possible on iOS 13? It has been working for a long time. This is for the app CarMeets. www.carmeets.app

Edit: Is my only option to send a non-background notification with alert? Currently the reason I send it in the background because it takes the notificationId in the payload and generates a client-side notification with the proper title/desc based on the 'Notification' object from Parse (queried by notificationId in push payload)

@dplewis
Copy link
Member

dplewis commented Nov 8, 2019

If I remember correctly, Background apps have a 30 second max before they sleep.

https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app

From what I read here, a background app will wake up for 30 seconds from a silent push.

I may have misread it but feel free to open an issue one on the node-apn repo

@dplewis
Copy link
Member

dplewis commented Jan 9, 2020

Closing via 3.10.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:question Support or code-level question
Projects
None yet
Development

No branches or pull requests

5 participants