0

In a usual Firebase notification scenario, I understand that my apps should subscribe themselves to certain topics that they want to receive notifications for. However, there are cases in which I want to send notifications to specific devices that are not subscribed to a certain topic.

Currently the only way I see of achieving this in Firebase would be to send multiple requests (can easily be a 100+) for each device. Is this the way that this is intended to work or am I missing something?

There is also device groups, but the documentation states that the common use case for this is multiple devices of the same user:

{
   "operation": "create",
   "notification_key_name": "appUser-Chris",
   "registration_ids": ["4", "8", "15", "16", "23", "42"]
}
AL.
  • 36,815
  • 10
  • 142
  • 281
mgrstnr
  • 490
  • 1
  • 5
  • 23

1 Answers1

2

It depends entirely on your use case. If you don't intend to have the registration tokens to have any kind of relationship, the best for you to use is simply the registration_ids parameter where the maximum number of tokens is 1000. Then, as you are currently doing, send batch requests.

For Device Group Messaging, you can create a group, however, if I remember correctly, a notification_id/key has a maximum token of 20.

The least hassle you have is to make use of the Topic Messaging, however, as you already know, you have to subscribe the users first.

AL.
  • 36,815
  • 10
  • 142
  • 281
  • Hey AL. It's me again. Assuming one wants to send a message to, let's say 3000 specific users, that are not subscribed to a topic: Is it reasonable to send 3000 HTTP requests to FCM? Will they be throttled? Doesn't really feel right to just spam the API. – nickdnk Feb 20 '17 at 13:18
  • Hi @nickdnk You're not sending 3000 HTTP requests. You'll only be sending 3 HTTP requests with 1000 registration tokens each. AFAIK, there is no more throttling being applied. There used to be, but (see my [answer here](http://stackoverflow.com/a/39658639/4625829), it was from the old GCM docs, it was removed probably because) it's no longer applied. – AL. Feb 21 '17 at 01:37
  • Okay. That could work. But what if each recipient needs their individual badge icon set? We're back to the "common aps payload" problem again then. Or at least common for 1000 recipients at a time, which is as good as common. I realize this problem also exists for topics, but I'm just wondering! – nickdnk Feb 21 '17 at 01:38
  • If you intend to send something different to each user, unfortunately, you'll have to [send different HTTP requests for each of them](http://stackoverflow.com/a/41756077/4625829). – AL. Feb 21 '17 at 01:44
  • Ah well. Thanks. I really dislike Apple for not providing a "+1" feature for the badge icon. I'll look into splitting the requests and I'll just always send "1" for the badge. – nickdnk Feb 21 '17 at 01:47
  • I'm not too familiar with how APNs works, but maybe you can send in a feature request to them. :) On an idea, why not just have like a boolean value that when `true`, will *+1* the current value shown for your app's badge icon. Of course this'll all be handled on your iOS app side. Good luck! :) – AL. Feb 21 '17 at 01:53
  • 1
    The problem is that the app does not set the badge icon. The APNS payload does. So I cannot send anything custom to modify the badge icon. See http://stackoverflow.com/questions/14256643/update-badge-with-push-notification-while-app-in-background – nickdnk Feb 21 '17 at 01:55
  • I see. So it's just a limitation on the iOS part. – AL. Feb 21 '17 at 01:58
  • 1
    You could argue that, yes. But getting Apple to change their mind... well, you know. I think for FCM to support some kind of array-model with a custom object for each device registration_id is more... realistic. Also this would allow for stuff like %NAME% to replace a user name in a message text. – nickdnk Feb 21 '17 at 02:00
  • If you think it'd be really helpful, I would suggest that you file for a [Feature Request to Firebase](https://firebase.google.com/support/contact/bugs-features/) then. :D – AL. Feb 21 '17 at 02:03
  • I will do so immediately :) – nickdnk Feb 21 '17 at 02:05