I want to avoid the complexities of managing Device Tokens at the application level
One user using multiple devices on iOS and Android
Multiple users subscribed to an application group
Treating #1 and #2 as topics on GCM is obviously an easy solution.
So that I only have to deal with my Application UserIds and GroupIds while sending notifications.
1) When device is registering (iOS/Android), I just subscribe the device to topics ["USER_A", "GROUP_A", "GROUP_B"]
2) When sending a notification, just send to a topic.
However, that means, number of topics = users + groups.
1 million users + 500K groups = 1.5 million topics on GCM
My question is..
Is there any limit to the number of topics on GCM?
Is there a better approach to avoid managing device subscriptions without having to deal with its complexities when delivering messages.
For #1:
Nope. As per their blog last December 2015:
We’re now happy to announce that we’re allowing unlimited free topics for your app. This means app developers can place an unlimited number of devices within each topic and create an unlimited number of topics.
As far as I know, there still hasn't been any changes with regards to the number of topics.
For #2:
I think it pretty much depends on your preference. For your use case in #1, I think that Device Group Messaging is the one to use. But since you're aiming to avoid too much complication, I think what you did using Topic Messaging is pretty much it. I actually found this post that kinda discusses what to use between the two, the comments are very enlightening, if you will. :D
Cheers! :)
GCM has removed the limitations on Topics as well as subscriptions
FCM also supports the same
Check This: https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
Related
Let's say I have an Android app with 100 users that I don't know personally. Is it right to make each one of them subscribe to topics like FirebaseMessaging.getInstance().subscribeToTopic("<company_id>_<user_id>"); so I can address them and send notifications for one or two specifically or there is a better way to do that?
If you intend to send a message to specific users only, you could simply go ahead and use to or registration_ids when targeting the specific users. registration_ids has a limit of 1000 tokens per request.
As per the topics, it was designed to easily send messages to its subscribers. Depending on your use-case, it could be fine to subscribe them. However, you should still keep the registration tokens for each user in case you need to send specific messages.
It all depends on your goal.
Anyone can subscribe to a topic, so you should only use those for sending messages targeted-but-public messages. While you can counter this a bit by making the topic names hard to guess, the inherent behavior of topics is that you lose control over precisely what devices are targeted in return for having to write less code.
If you send to a token in your own code, you determine precisely who receives the message. But you will have to run the code that maps the message to the tokens yourself.
I think the answers are pretty clear, I would only like to add that, this method of subscription it can be easily combined with the Firebase web console. If you want to quickly send a message to any topic, the topic is created on registration, so you only have to know the topic name.
In the Firebase Web Console, you can find the target, an application, a token for a device or a topic. If you choose a topic, just write the topic name. There is an error which always says there is no topic, disregard it, and click send, the push will be sent and the subscribers will get their notifications.
I am creating a solution that permit other app editor to sent notifications to their app through Firebase Cloud Messaging, and I want to develop the possibility to do A/B Testing.
I came across the groups syteme of FCM and, if that works, it would be a good way to separate audiences in two or three groups, as it is possible to register several devices at the same time in a group. However it seems to be designed to represent the devices of a single user, which means a small number of devices.
So my question is, can we still use FCM grouping with a large number of devices (in the tens of thousands) ? Or can they not be used this way?
No. Device Groups have a limit of 20 tokens per group:
The maximum number of members allowed for a notification key is 20.
High volume tokens in a group could be handled by Topics better.
I realize you asked this question six month ago, but for anybody who is looking to A/B test their notifications using Firebase Cloud Messaging, this functionality is now directly built into the Firebase Notifications panel. I'd recommend checking out the documentation, and heading right into the Notifications panel of the Firebase Console to start building your A/B test.
Is there any constraints about number of different topics for Firebase Cloud Messaging in one app?
Nope. Seeing that FCM has GCM as its core, there is no limit in the number of Topics for any app. There used to be a 1 million limit, but it was removed. You can refer to this Google Developers Blog for that.
Also, when creating a Topic in FCM, it could take up to 24 hours for it to be show up in the Firebase Console, as per this post. Cheers! :D
No I don't think so!
Based on the publish/subscribe model, topic messaging supports unlimited subscriptions for each app. You compose topic messages as needed, and Firebase handles message routing and delivering the message reliably to the right devices. link
Seems like you can create topics when you need them!
Just been doing a bit of research on the different ways to send/receive remote notifications and many answers suggested GCM (now FCM). From what I can understand, this seems feasible for a small scale app that can support 100 online users (free) or 10k users (paid). But I fail to see how it is feasible for a background type notification system which, to be frank, are expected of most apps these days.
Hypothetically, if an app has 1mil users, then there will need to be 1mil simultaneous connections sitting in the background for the notification to reach its user in a timely fashion.
Or am I misinterpreting the "simultaneous" part? When does it apply?
Their FAQ doesn't go into too much details here.
The limit on "simultaneous database connection" refers the usage of the database API.
To receive notifications (whether the app is in background, open, or closed doesn't matter) through FCM (or GCM is the same) your app doesn't need to keep any connection open.
The firebase SDK together with the each platform operative system will take care of that.
Probably a GCM newbie question...
I more or less understand how to subscribe to topics and how to send messages to topics. But I was wondering : how does a topic gets created ?
From the docs I read, I guess a topic exists when at least one app subscribes to it, correct ? (As far as I could see there's no specific api to 'create' a topic).
I also noticed that it should be possible to register apps to a topic not from the app itself, but from an app server (by sending a HTTP POST message to a specific URL). Does this work the same way ?
E.g. if the topic doesn't exist when subscribing, it will be 'created'?
As far as I can tell, yes, whatever topic name a client app uses when subscribing, will get created. Even if it is "sdfgklfhjashfgkjas" and purely accidental.
I have seen no mention of deleting topics. I guess unused topics don't really cause Google any problems; they don't take up much space.
On the server side, you can force an app instance to subscribe to a topic by passing the token in a http POST as mentioned in the GCM documentation. Ditto for unsubscribing from a topic.
Bear in mind there are limits on topics which could cause problems for popular apps.
How does a topic gets created?
There is no detailed explanation in the documentation on how topics are created but according to the documentation.
An app can subscribe to different topics defined by the developer. The app server can then send messages to the subscribed devices without having to maintain topic-subscribers mapping. Topics do not need to be explicitly created before subscribing or publishing—they are automatically created when publishing or subscribing.
From the docs I read, I guess a topic exists when at least one app subscribes to it, correct ?
I think this is the case because in order to create a topic you will have an app subscribe to it.
I also noticed that it should be possible to register apps to a topic not from the app itself, but from an app server (by sending a HTTP POST message to a specific URL). Does this work the same way?
Yes your app can subscribe to other topics not necessarily related to your app as long as you pass the GCM registration token and topic name. See Subscribe to a topic.