There are several ways to send FCM messages and I don't understand which one to use even if I read the documents over and over.
My use case:
I have a user that is logged into the app on her iPhone, iPad and Android tablet. I want to make sure the push notifications are sent to all of her devices.
There are three ways to do this (I'm using the admin to send the push notifications):
Topic messaging (messaging().sendToTopic): My understanding this is for sending the same notification to larger groups. For example a topic could be all users that want weather notifications for New York. Not for my use case.
Send Multicast (messaging().sendMulticast([array of tokens]): My understanding this will send the same message to all device tokens in the array (up to 100). This seems perfect for my use case, right?
Device group messaging (messaging().sendToDeviceGroup): I don't really understand this one. Why use this instead of multicast or topics?
For my use case it seems the best way is to each time a FCM token is updated I add this token to the user in the database. I then send the notification using the admin.messaging().sendMulticast([array of tokens]). Is this what you would recommend? Why or why not?
You probably want to use multicast if you're targeting an individual user's specific devices. You probably don't want to use device groups. I suggest reading the documentation to understand how device groups work:
Device group messaging allows you to add multiple devices to a single group. This is similar to topic messaging, but includes authentication to ensure that group membership is managed only by your servers. For example, if you want to send different messages to different phone models, your servers can add/remove registrations to the appropriate groups and send the appropriate message to each group. Device group messaging differs from topic messaging in that it involves managing device groups from your servers instead of directly within your application.
Device groups are basically just topics whose membership is fully managed by your server code, not by client code.
Related
Seems like majority of solutions here require the developer to manually save each user's push token in addition to Firebase saving these tokens as well, then iterate through these and send out notifications. This is not really desirable since I would be storing push tokens in two separate places and need to make sure their lifecycle management is synchronized, which is error prone 😢Is there a better way?
Some options I considered:
Give each user a person/unique topic, then map out a geolocation per topic; then filter through these locations, aggregate these topics into batches of 500 and send a push. This is probably the best option so far 🤷♂️ but seems like a silly use of topics API.
Bucket users in cities, with each city corresponding to a topic; then find all cities near a location, and send a push to those topics. This is doable, but lots of complex city mapping code without much flexibility (vs. considering a simple radius).
Manually store push token → user → geolocation; filter out the ones you want, then send a push to the token specifically. This is problematic for many reasons (multiple device management, push token lifecycle management, data duplication, etc.)
Ideally, there is a way to send out a push notification to a list of user IDs, without even touching push tokens, is there a way to do this?
The only way to associate a device token to a user ID is to store that mapping yourself. You should also assume that one user could have multiple devices. FCM doesn't have a concept of a "user". It only knows device tokens. Your app has to bring the concept of a user, then map that to tokens in code.
Note that any messaging solution that requires topics is not "secure". Anyone can effectively receive messages from any topic.
I am using FCM console to send push messages to the users. Until now I am targetting using User Segments through which I can filter users based on language. But now I need to allow users to subscribe or unsubscribe to the type of alerts they can receive. So I am exploring the option Topics. But now from firebase console I can either target users based on User Segments or Topics.
I want to be able to use Topics with the options I can get in User Segments(where I can filter based on language). Is there a way to make this possible?
Thanks,
Sindhu
Segments can't be targeted with topics. Segments are populated by data collected by Firebase Analytics, and don't identify individual devices. Topics are just names that you make up, and the names must match between the device and server.
You will need to find a way to match up users in a segment to the topic that you create for that segment. You could try to use Remote Config to give clients the name of a topic that matches their segment, then use FCM to subscribe to that topic.
I am working on an in house project with several sensor devices. I do not want a user to register each and every device individually. In the sense I want to use the same Public/Private Key pair for all devices registering to a registry but be able to pass device information on to pubsub via mqtt/http with unique device information like name or id. Is it possible to achieve that?
I am assuming if i am using the same Keys. I am registering all devices as one but is it possible to send device info as part of the message being published. does doing that inhibit the usage of google's inbuilt functionality in any way like API's.
new to cloud technologies, any thoughts/suggestions would help.
Depends on MQTT-broker configuration.
Normally Certificate based authorization is used only for authorisation on MQTT-Broker side. So you can use Public/Private Key pair to authorize and connect to the broker and use MQTT ClientID to differ between your devices.
MQTT-Broker can be also configured to use Identity from authorization Public/Private Key pair as Username.
use_identity_as_username true
In this case, if MQTT-Broker has also username based ACL configuration for example like that:
#device info sent from device. %u <- username
pattern readwrite %u/devinfo
All your devices will publish messages under same username, you should set different ClientID for each device or use CleanSession Flag in this case.
Here is a good reading to understand how the connection between device and broker works at all: https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment/
Sounds like you really want to be using the new gateway functionality (it's in beta now, but I've run through using it a bunch and it's quite stable).
Check out this tutorial on gateways to get an idea of what we're talking about:
https://cloud.google.com/community/tutorials/cloud-iot-gateways-rpi
TL;DR version is that it allows a single device to manage many smaller devices (which may not be capable of auth on their own) but still have those smaller devices be represented in the Cloud.
So basically, you have a more powerful device (like a Raspberry Pi, or a desktop machine, whatever) registered in IoT Core as a "Gateway". Then when you create the individual devices in the Cloud, you don't specify an SSL key (the Console will warn you about the device not being able to connect) and then you can "associate" the device with the gateway, and it'll handle the auth piece for you. Then the individual devices instead of calling out to the internet, connect and talk to the gateway device locally.
I have a pool of device tokens (iOS and Android) and in the docs, I find only one parameter sound for both platforms and obviously I have 2 different notification sound, one for Android and one for iOS.
Do I have to split device tokens by device type for sending to 2 separate device types? Or did I just miss something ?
Thanks.
Solution 1
You could name the same both audio files, like 'your_app.mp3'.
Same name, but different music file on each app. This not allow the user choose the notification sound, but at least allow each app to have a different sound.
Solution 2
Migrate to the new Firebase HTTP v1 API which allows you to customize notifications across platforms
Personal experience
Solution proposed by #daniel-raouf to send Data Messages is great; but in my experience, some Data Messages could not be delivered to your users when:
An user has a power save mode on his phone (by default on Huawei, Xiaomi, One Plus...)
When iOS users clear your app from recent apps (multitask).
So, in my opinion, Data Messages are not a reliable solution for notifications.
You had missed something,
A- If you want to allow the user to select his preferred notification sound at any device so
don't send notification
send only data to force the received content to pass by the onReceive event
In on receive add the sound the icon and data you want to the notification builder.
B- If you want the app to use the default sound
so in the notification body set sound:'default' and it would work for all types of devices
The Firebase chat application seems to suggest that all clients will receive the messages sent to a given FireBase url.
Now, one way of ensuring that users only receive messages sent to a specific channel is to filter messages at the client, but this would mean that all messages will be propagated to all clients and the client would do the filtering.
Is there any way to establish channels at the Firebase server - or does this mean that one would need to create separate firebases for separate channels, which would mean that if one wanted user-specific push-messages, it might require creating one channel/firebase for each user.
So, what is the suggested solution?
The Firebase Data Structure makes this quite easy, actually! The demo app puts the chat messages in the root of the Firebase (i.e. https://samplechat.firebaseio.com/), but you could just as easily use separate locations within your Firebase for separate chats, e.g. /chat1, /chat2, etc. Or better yet, you could have a /chats/ location with an arbitrary number of chats underneath, each named uniquely (possibly using push()).
Then a user could receive and push messages to a particular chat by referencing it directly (e.g. https://samplechat.firebaseio.com/chats/chat-id/) and then they won't get any data for any other chats.