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.
Related
I am trying to develop the Messenger App like Whatsapp using Firebase.
I'm already done the code for device to device notifications and now I am trying to send the notifications to specified group.
Please provide the example code for the Group Notifications.
There are a few ways to send messages to groups of users:
Send the message to a topic that all users subscribe to. This is the simplest scenario, since you don't need to keep a list of tokens. But you have less control over the actual people that receive the message, as anyone who knows a topic can subscribe to it.
Keep a list of device tokens for each group in your app server, and then send to each individual device in the group.
You can also use the previous version of the API to send to batches of up to 500 tokens at a time. This sort of multicast delivery is not yet possible in the new API.
For an example of this, see the documentation of Cloud Functions and the sample repo.
Send to a device group with the legacy API. I'd only recommend this approach if the devices are actually owned by one user, which is the case that device groups are meant for.
Try this link
Don't forget this line Authentication:
key=<Your_API_Key>
The word (key) is important
I am working on an app, which requires Android push notifications to be implemented.
I have decided to use Firebase Cloud Messaging directly; without using any other abstraction such as AWS SNS or Pusher.
I would like to avoid storing and managing device tokens in the backend, by using the following approach.
In the android app.
When the user logs into the android application, obtain device token but not send it to the server.
Subscribe to a topic that is based on a agreed convention, such that the topic is unique to that user.
On logout unsubscribe from the topic.
In the Server.
Whenever a situation arises to send a notification to particular user, send push notification to the topic, that is based on the convention.
I would like to know if this is a viable strategy to avoid managing device tokens ?
Case against using topics.
From the official docs.
Based on the publish/subscribe model, FCM topic messaging allows you to send a message to multiple devices that have opted in to a particular topic. You compose topic messages as needed, and FCM handles routing and delivering the message reliably to the right devices.
For example, users of a local weather forecasting app could opt in to a "severe weather alerts" topic and receive notifications of storms threatening specified areas. Users of a sports app could subscribe to automatic updates in live game scores for their favorite teams.
I see that topics are recommended, when multiple devices are to be notified. But I have decided to create a topic per user, this would mean most topics would end up getting subscribed by only one device; Is this approach ok ?
I see that topics are recommended, when multiple devices are to be notified
Yes, multiple devices that have something common to listen to, which is the topic. Topics are used for messages that could be received by the general clients since it is public -- i.e. anyone could subscribe and receive messages sent to it.
What is advised to use for multiple devices, but for the same user is to use Device Groups (see my answer here for tips on Managing Device Groups). However, if you don't mind the "topics being public" part, then your approach should be fine.
Yes, Here required device tokens if we want to send push notification whoever installed your app.
My research we can save device tokens in back end at first time installation of your app that is better according to my understanding so that we can easy to send push notification across all devices.
We have a design approach which is creating a topic for each registered user.
Creating a new user
Save it to our database with a generated token
Subscribe to /topics/{user-token} when user login on android or
ios device.
So if user have more than one device and if we want to send a user specific notification, we just send it to /topics/{user-token} so it received by all devices.
We've not encountered any problem with a few users yet, but is that ok for Firebase limitations and is it a good approach?
(I am moving my comments into an answer)
Most of the times creating an FCM TOPIC per user is NOT a good idea.
Messages sent to an FCM TOPICS are public. Any user (even from a
different app) can subscribe to /topics/{user-name} and receive those
messages.
Example:
Another developer can copy the google-services.json file from your apk.
Then he can subscribe to any topic.
To intercept your user messages the attacker still need to guess the {user-name} or any other identifier you are using. But if you assume this can happen then the issue is big because you would never know if someone is receiving a copy of your messages, and you usually never change {user-name}.
This is not a security issue of FCM. This is part of the topic API design.
If you need secure messages you can send them directly to the device token.
If you still want to do one topic per user, please pay attention to not send sensitive data, or data that should not be intercepted by third parties.
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.
I'm making an application for Android that allows me to send a set of geolocation points from one user to a group of users playing a game together, but I don't really know where to start on sending the messages.
I had one idea that involved sending the message from the one user to a server, and then having the server push the message to the other users, but I don't know how to let the server know which users to send the message to.
Am I on the right track? Are there services already set up that deal with this kind of problem? Do you have any other suggestions? Your comments are appreciated.
You simply need to create a shared context e.g. topic on the server for each group of users. Sender publishes to the topic. Listeners are subscribed to the topic. It is a simple matter of the server receiving a message; mapping to the topic; and sending the message to the subscribers of that topic.
Main design issue is to determine if you need static or dynamic topics. In other words, in static topics, the server is given a (static) list of topics (via say a config file). In dynamic variant, you would need to provide the mechanism for dynamic group formation.
Second issue is topic durability. Can users of the group drop out (of net) and then re-establish connection and get messages that they missed when disconnected? etc.
p.s. there are a variety of messaging frameworks, from JMS to AMPQ to PubSubHub for Java so you can probably highly leverage existing code. But it really can be something as simple as pushing messages to server via REST calls. Receivers would need to either poll the server (via an analog REST call) or maintain a connection for the server to push to them. (The latter is probably not a very good idea if you expect a lot of users.)
[final edit: If you are going to roll your own, I strongly suggest you take a look at Redis. It should be easy for you to quickly prototype something that way.]