I'm trying to make a chat application using GCM, but I'm a little confused about what the best practices are.
The tutorials I've seen recommend using the XMPP-protocol because you can use existing connections and pass bi-directional messages which makes it faster. The problem is that the GCM payload is limited to 4kb. I wonder whether it's safer to use the push notifications to actually deliver the messages or just to notify the clients that there more messages to download using the HTTP-protocol.
There is also the security problem. I use the OAuth resource owner flow to secure many of HTTP-endpoints. It feels bad to also include the client-id, user-id and access-token/refresh-token in my GCM upstream messages since the payload is already limited. Also, it would require me to write a lot of code ensuring that the access-token has not expired and when to retry and include a refresh-token instead and so on.
So I wonder if it's better to just send the upstream messages using the HTTP-protocol and then using GCM to notify the receiver to download the message.
Lastly, I wonder if it's worth using the XMPP-protocol if you are using HTTP for upstream messages anyway. Is the XMPP-protocol still faster, or is it just faster if you are going to use it to send upstream-messages?
Hope I was able to explain my problem well.
Related
I'm new to Android and want some advice please.
I need to build two Android applications.
Android application for train travelers
Purpose: Sending a custom message (for assistence) to the railway guard. The railway guard will be identified on the basis of the wagon number that has been sent.
Android application for train guards.
Guard must be able to login and be able to receive (realtime) messages from travelers.
In short, this should be a one-way messaging system.
I'm used to build RESTful web application with databases. I have no idea which technologies i should use in this situation. As far i know i can't use databases such as MySQL, Oracle on Android. I've read that Firebase is an alternative for this but i'm not sure if it's the ideal solution for this kind of application.
I could build a RESTful server and make calls from the application. I guess if i do so the messages won't be received as realtime push notifications.
Any advice please?
RESTful services are hosted on a server and cater to incoming requests with a response.
Remote notifications are handled by a remote server. Under this
scenario, the client application needs to be registered on the server
with a unique key (e.g., a UUID). The server then fires the message
against the unique key to deliver the message to the client
application via an agreed client/server protocol such as HTTP or XMPP
and the client displays the message received. When the push
notification arrives, it can transmit short notifications and
messages, set badges on application icons or play alert sounds to
attract user's attention.[21] Push notifications are usually used by
applications to bring information to users' attention.
Source of above text
You can understand the basics and implement it into your application.
However, it is too much work and you really won't be gaining much.
It is much better to use Firebase and the documentation is quite good.
You need to pay as you go based on how much you are using Firebase.
A place to start:
https://firebase.google.com/docs/cloud-messaging/
I need to send a large number of web push notifications via FCM, all which are personalized (so I can't use broadcast messages. It's 1 push per token). Let's say the number of subscribers is 500K-2M, so that means 500K-2M API requests I think?
I've read several articles about the topic, such as how discord does it. They use the XMPP API which I would love to use, but currently I'm doing this in ruby and I don't think any of the current libraries support what's discussed in that article (100 requests at a time, connection draining, etc), and I don't want to build something from scratch.
So I think I'm stuck with the HTTP API for now.
The thing I'm having difficulty with is how to actually run the requests asynchronously... I've tried using Typhoeus gem with 2000 connections at once, and many of the connections timed out.
I've tried researching FCM docs for HTTP API rate limits and connection limits but can't find anything...
What is the fastest strategy to send 1M non-broadcast FCM messages using the HTTP API?
Creating an application that needs to be updated when a user registers on a web app. The simplest solution to me seemed to be to integrate a simple client side polling mechanism. But I've read recently about Google Cloud Messaging which would eliminate the need for polling, instead 'pushing' update events to registered devices.
This seems like an unnecessary addition of another layer of complexity, since the GCM server would act as a mediator to the real server.
Can anyone who has used GCM comment? Is it useful in this simple use case where the application is only updated once, or very infrequently?
If I should do something similar, I would integrate the MQTT protocol in my server and in the mobile app. It is explicitly designed for machine to machine. You can find references in the Mosquitto project web page
GCM would work fine for you, instead of polling the server where there may or may not be any new data wasting battery in the process where GCM you would only send a push when there is new data to get so the battery is not wasted on unnecessary calls to the server.
that being said google does not guarantee that any device gets the push so you need to take that into account
I'm starting my way with Android GCM Framework..
It's actually pretty nice and easy to implement but one important question:
The data i'm transferring is not sensitive, but yet i don't want it be available from everyone..
Is this encrypted some how ? or should i encrypt my messages ?
I know that in basic its a notification service - but i'm sending short messages so its important to me to understand how these messages are passing by Google,
Thanks !
Is this encrypted some how ?
Google uses encryption over the air, between your server and theirs (SSL) and between their server and the device. Hence, the only systems that have access to the GCM message data are:
your server
your subscriber's device
Google
should i encrypt my messages ?
That would depend upon whether or not you trust Google, and what the nature of your message payload is. For example, if the message payload cannot be directly used by Google (e.g., it is simply a flag telling your app to sync using your normal Web service protocol), then encryption is perhaps not necessary.
Message payload encryption/decryption is something that you would have to do on your service and client app side. That way anything that passes through GCM is safe, Google won't be able to see what's inside.
However, keep in mind that decryption in client app can be costly process - you would need to wake up the app and decrypt, which will cost you some battery.
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.]