Update the logic to decide if it's an alert/background notification

[sirghi]

We have a use case when we send a category in a silent push:

"aps" : {
  "category": "myCategory",
  "content-available" : 1
}

It may seem it doesn't make sense, but our logic uses this category to schedule a local notification later on. But the app sends an alert notification instead of a background one with the above payload. Will you update the logic to send a background notification in the above case?

[Ariandr]

Hi @sirghi Fair enough. It's a good case we didn't consider. I will update the logic and let you know when it's released.

[Ariandr]

@sirghi I created a new release with the update. Please, check it out: https://github.com/onmyway133/PushNotifications/releases/tag/1.7.2

[sirghi]

Hi @Ariandr, that's a quick turnaround to this, I really appreciate it! Thanks

[sirghi]

I was thinking if it is a valid scenario to have alerts with title/subtitle etc. and still have a content-available key in general? i.e. Will both the notification be showed and application(_ application: UIApplication, didReceiveRemoteNotification userInfo:..) of the App Delegate be called with the following payload?:

{
  "aps" : {
    "alert" : {
      "body" : "Going somewhere?",
      "title" : "Hey you"
    },
    "category" : "myCategory",
    "sound" : "default",
    "content-available": 1
  }
}

I didn't have a chance to experiment with this and don't know how iOS (especially 13) handles it. But if it is the case, maybe it's worth removing the additional fields check altogether?

[Ariandr]

@sirghi When you include "alert", "badge" or "sound" into "aps", iOS just ignores "content-available" flag, so, your iOS app will receive notifications as usual.

Moreover, for iOS 13 we explicitly set pushType header to alert, unless "aps" contains only "content-available" and "category" keys.

[sirghi]

Cool. I checked 1.7.2 and works ok. Thanks again.

[Ariandr]

@sirghi No problem, I'm glad to help 🙂