I'm new to push notifications and here's what I understood so far -
Client app will need to register with Google Cloud Connection Server (GCCS).
GCCS will return a registration ID back to the client.
Client will send the device id and registration ID to the app server.
App server will store device & registration in its database. This database could get huge depending on the number users.
The app server in my case comprises of a single HTML page, and a node.js script. Admin will get to the page, types in a message and hits Send.
The app server will make a POST call to GCCS with the Sender ID, API Token, array of registration ID's etc.
Message is received by the devices.
There is also this thing called as Topics that the client apps can subscribe to. Using Topics, you do not have to send registration ID's of all devices. All devices "subscribed" to this Topic will get the message. This is very useful if you have millions of users (depending on the popularity of the app) and you don't have to split the registration ID's into chunks of 1000s to send the message.
My questions are -
If we're using Topics, do we need to persist the Registration ID, Device ID to a database on the App server? It seems redundant.
Are there any ready-to-use/commercial GCM servers that can send Topic messages?
Is it easy enough to build on your own (since its a simple POST call)? If I'm going to use JavaScript, wouldn't I run into CORS issue?
Thanks for the help!
If we're using Topics, do we need to persist the Registration ID, Device ID to a database on the App server? It seems redundant.
Are you referring to C2DM implementations? Those are deprecated as shown on the GCM documentation. In relation to topics, they may not be necessary but are necessary to other message calls.
Based on the documentation, to needs to be set as topic/[yourTopic] with the necessary payload
https://gcm-http.googleapis.com/gcm/send
Content-Type:application/json
Authorization:key=AIzaSyZ-1u...0GBYzPu7Udno5aA
{
"to": "/topics/foo-bar",
"data": {
"message": "This is a GCM Topic Message!",
}
}
Are there any ready-to-use/commercial GCM servers that can send Topic messages?
I can't find any sources about this, so I'm guessing we're left to implement it on our own application server. Google provided us with a sandbox project for us to play with.
Is it easy enough to build on your own (since its a simple POST call)? If I'm going to use JavaScript, wouldn't I run into CORS issue?
If you're talking about setting up the Client App (specifically Android), there's a setup guide on the documentation. But if its more on the application server, I can't comment on it really. XMPP libraries can be used to handle XMPP Connection Servers
Related
I have an Android app, and I want it be able to receive push notifications from two different Firebase projects.
I read the blog "Working with multiple Firebase projects in an Android app" https://firebase.googleblog.com/2016/12/working-with-multiple-firebase-projects-in-an-android-app.html which talks about "Accessing the Databases from two different Firebase projects".
However, there is no info about receiving notifications from multiple Firebase projects.
So, how to integrate my app with multiple Firebase projects and receive push notifications from them?
There is actually a part in the documentation about this topic:
Receiving messages from multiple senders
FCM allows multiple parties to send messages to the same client app. For example, suppose the client app is an article aggregator with multiple contributors, and each of them should be able to send a message when they publish a new article. This message might contain a URL so that the client app can download the article. Instead of having to centralize all sending activity in one location, FCM gives you the ability to let each of these contributors send its own messages.
To make this possible, make sure each sender generates its own sender ID. See the client documentation for your platform for information on on how to obtain the FCM sender ID. When requesting registration, the client app fetches the token multiple times, each time with a different sender ID in audience field.
Finally, share the registration token with the corresponding app servers (to complete the FCM registration client/server handshake), and they'll be able to send messages to the client app using their own authentication keys.
Note that there is limit of 100 multiple senders.
I think the confusing but important part here is:
When requesting registration, the client app fetches the token multiple times, each time with a different sender ID in audience field.
In other terms, you'll have to call getToken() passing the Sender ID and simply "FCM" (e.g. getToken("2xxxxx3344", "FCM")) as the parameters. You'll have to make sure that you call this for each sender (project) that you need.
Also, note from the getToken() docs:
This is a blocking function so do not call it on the main thread.
Some additional good-to-knows:
It does not auto retry if it fails like the default one.
It returns an IOException when it fails.
I had some issues when implementing the accepted answer and hence went ahead and tried to do it on my own when I came to find a robust solution. I have shared in detail there solution here.
I've been doing so much research, but it seems like all the articles out there are either sending notifications from the console or sending a push notification to a single device.
All I want is to send a push notification using Firebase ON my client and not on the Console to everyone. Do I need a server? If so, what information do I need to retrieve from it?
If you simply want to send a downstream message, you don't really need a server. You can simply use Postman or cURL. Just specify the registration token(s)/topic you want to send your message payload to.
If you are aiming to send the downstream message from the client (Android app) itself, I would strongly advise not to. Quoting a portion of #FrankvanPuffelen's answer here:
Sending a message to devices (so-called downstream messages) requires a HTTP call that specifies the server key. As its name implies, this key should only be used in environments you can trust.
It is to avoid exposing the key to unauthorized users, preventing exploitation.
I am having trouble understanding the specific meaning of "app server implemented in my own environment" as used in this documentation on how to send upstream messages to the "Cloud" using Firebase Cloud Messaging.
Context
The documentation is saying that for me to send upstream messages, I need my own app server that implements one of two connection server protocols in HTTP or XMPP.
The Reason why I am confused
My expectation is that if I use Firebase, I don't need to create my own server. All of the backend stuff is handled by them. So to me, when they say I need to create my own app server in my own environment, it is contrary to my expectation and understanding and thus makes me second guess the meaning.
What it is I am specifically confused and asking about
What exactly do they mean by app server?
What exactly do they mean by "in my own environment"?
Another way my two questions could be asked is:
Is an app server in this context meaning just a typical app server that I write on my own using something like Node.JS/Express.JS and host on something like Digital Ocean? and/or
Is it something I need to do with other Firebase/Google Cloud products (eg Hosting or App Engine)?
Or could my implementation of the RealTime Database feature on my app be considered an "App Server" as it serves my app with data.
What I have done so far
Reading through every single documentation on Firebase relating to Cloud Messaging and browsing around Google.
I have had a solid read of what questions to ask and what to avoid. I am mindful that this question could be something with lots of varying and all correct answers so apologies if that offends one of the rules. But I have come across this question on Meta which suggests that asking for clarification on documentation is OK for SO.
Is an app server in this context meaning just a typical app server that I write on my own using something like Node.JS/Express.JS and host on something like Digital Ocean?
Exactly.
Is it something I need to do with other Firebase/Google Cloud products (eg Hosting or App Engine)?
Depends on your use-case. But for Firebase Cloud Messaging, when all you need is to send Downstream Messages, you don't need an App Server. You can just make use of the Firebase Console. If you need to send Upstream Messages, then you have to implement your own App Server.
Or could my implementation of the RealTime Database feature on my app be considered an "App Server" as it serves my app with data?
Not exactly. The Firebase Realtime Database stores the data you need, but the App Server needed for FCM is something that can process requests (Send (Downstream and Receive (Upstream)).
App notifications are sent by Firebase Cloud Messaging server. To send these notifications you will have to tell to which device notifications have to be sent.
So you will have to send the FCM Client ID from your backend server (Node.js, PHP server). You will get the FCM client ID when you integrate Firebase into your app. You will have to store the FCM client ID in your backend server like during registration of a user.
To send a notification to a device retrieve the FCM Client id from your backend server and send it to the Firebase cloud messaging server and it will check if the client id is valid and trigger a notification.
I'm totally new to hybrid world so I have to ask first.
Can I send notifications through GCM without a server?
I mean, I'm building a SPA with AngularJS and Firebase, but my customer asked me to make a dashboard for Android, so every time an user makes an order, they (both dashboard administrators) receive a PUSH notification on their phone: "A new order has been created", and when they "tap", the application opens.
I've been reading something about /topic/ endpoint to notify both of them, but I think I still need a server to do it. Do I?
It would be great if I simply post a http query using something like AngularJS' $http service to tell GCM to send a notification for that topic/usergroup.
Is that possible? If so, any idea about how?
Thank you very much in advance!
Sending a downstream GCM message can be done "without a server". One option is to send an HTTP request to GCM containing the required fields. Topic Messaging is available with GCM which does make it easier to send downstream messages without a server. Your client apps can subscribe for messages from /topic/usergroup and then you can send an HTTP request with /topic/usergroup as your "to" value, and subscribed clients will get it.
Note that you will need to set up a Google Developer Console project to get the required API key.
Check here for more information on the structure of GCM HTTP downstream messages.
Is it possible to register many diferent servers to notify users with c2dm?
The ting is, my users will host the serverside on there own, meaning one user will always get the messages from the same server but almost all users will have there own server.
Do anyone know if this is possible, or should i start searching for a diferent solution?
This is possible, but I'm not sure you want to do it.
C2DM push uses a Google Account to send messages, so the messages can originate from any server. Your app will receive a registration id and will need to send it to the server that will send it messages. The server will need this id, as well as the Google account information to send a C2DM message to the device.
I'm guessing you probably don't want to do this, so might I recommend a couple of other options:
Have the user's server send the message to your server, which forwards it to the C2DM service and ultimately the device. Your app will send your registration ID to your server.
-or-
Have the server software on your user's server request a Google ClientLogin Token from your server. Your app will have to send the registration ID to your users server. //I don't know if this will actually work, I think it will in theory, but if Google checks IPs or something with the token it might not.