Currently I am working on an alert app, which receives push notifications from a server. Reading a lot about that topic on the internet lead me to firebase which can be used to achieve that.
Now I was wondering: Are Whatsapp, Signal and other messengers using firebase or do they have any other solution to receive messages from servers even if the app is not active opened?
They use push messaging. It might be firebase, it might be another provider. MQTT is popular. All any of those things do is open up a persistent socket connection to a server and listen for messages. The trick is that whatever process is doing that needs to be whitelisted from power management restrictions, because you don't want to delay your message notifications for 15 minutes.
Now if you're writing something that's supposed to be robust queueing on the server side and deduping on the client side would be a good idea. But the basics is open socket connection and block on it on a thread.
Related
I'm working on app the share tasks between users. By Google Cloud Messaging, I can notify the user target that he has a new task shared. The problem is : GCM does not offer a delivery guarantee. Would someone use an app like WhatsApp if he took minutes to deliver a message or not come to hand? That's my problem with GCM.
So I've got a solution : Use Socket!!!
Using Socket.oi and Node.js, my dream came become really works like magic !!!
But as nothing is free, keep a socket connection has a very high cost for the battery. Some people argue that the use of Sockets when there is no communication, nothing in or out, no cycles, so there is no consumption.
My friends, I've read a lot of text and do not know what approach should I follow. I ask your help. Soket.oi? WebSocket ???
How to maintain a connection to my server permante preserving the most of the battery?
I appreciate everyone's help!
You need to use mix of a socket connection and GCM. Both connection types do no guarantee delivery so you need to implement mechanism which checks consistency of messages history.
Simplified scenario could look like this:
a user launches your client
the client app registers at GCM and sends google id to your server.
the client app establishes socket connection
your server sends messages to a client through GCM and socket connection (if it is establish with particular connection)
each message has unique id, therefore the client could just ignore second identical message from Google of a socket connection
About not delivered messages:
When client connects to the server through socket connection it should receive response where history of messages should be put. It shouldn't be full history, it could be just last message (in case you develop chat app). Then a client just checks if he has notified user about last message or not. If not then your client makes request(http or through socket) to your server and receives undelivered messages.
Battery consumption:
Do not acquire wake lock to maintain socket connection! A device must go sleep. GCM will wake up handset.
Socket.io is good, and certainly useful in many real-time applications, but what happens when the app is terminated by the user? Or if the user restarts their phone? How would you receive notifications then?
For all purposes, GCM is good enough.
I have an android app that uses GCM for push notifications. Lets say I need this for ambulance drivers when new calls are received. Right now there is a delay between when the server sends out the push notification and when the android device receives it, sometimes more than a minute. I've read on Stack Overflow about sending the heartbeat out, set delay_while_idle to true/false( yes I've seen both) etc...
What I need to know is if this is just how it is with GCM or if there is a way to make push notification times much more reliable. I've had suggestions of sockets, test messages etc... Because this is potentially for medical services I can't afford to have delays longer than what is absolutely necessary.
I've read that GCM notification delivery isn't guaranteed so is there a direction someone can point me to maybe do this on my own so that I can make something is guaranteed???
GCM push notifications are not reliable.
Have a look at "Pushy": https://pushy.me/
They state the following on their website:
The most reliable push notification gateway, perfect for real-time
applications.
Google Cloud Messaging simply doesn't cut it for time-sensitive,
real-time apps, due to its instability and push notification
throttling.
Pushy works by maintaining a dedicated background socket connection
using the MQTT protocol, an extremely light-weight pub/sub protocol
that consumes very little network bandwidth and battery, which makes
it perfect for mobile.
You can use it for free with up to 100 devices, so you could just give it a try to see, if it fits your needs. I didn't try it.
I am an android user and of course I use whatsapp, twitter for android, facebook and many other apps that notify me of events.
As a proogramer whats keeps me wondering is how fast notifications or whatsapp messages arrive.
My intuition tells me that is not possible for the whatsapp or twitter server to open a TCP connection with my cellphone by a given port to deliver a new message. If i am in wifi mode the router would block that connection.
And if my whatsapp client is pooling the server every second.... Poor server if it has 1000 clients making request every second.
What is the approach to face this issue?.
Is there some other protocol involved?.
Those apps use services that utilize "long polling" - primarily based on XMPP or some variation of XMPP (like jabber - http://www.jabber.org/). The client does not poll often. A quote for the Wiki page:
The original and "native" transport protocol for XMPP is Transmission
Control Protocol (TCP), using open-ended XML streams over long-lived
TCP connections.
It sends a message to the server that basically is a mechanism for the server to send a message back at any time (as long as the client is available). It's like sending a request to an HTTP server and the server "time-out" does not occur for a very long time (hours), so the client just waits. If the server receives a message destined for the client, it sends a "response" to that request. After the time out does occur, the client sends another request and waits.
GCM does the same thing - but does not require you to setup servers for all portions of the connection. It's easy to search for GCM, AWS, etc. to see examples.
Typically GCM should be used if you dont want to guarantee immediate delivery and it is okay for your app to miss out on certain messages.
This is because GCM tries to optimize by bundling several messages (even from other apps) into a single package. And it has a limited buffer to maintain the messages per device (in case the device is not reachable).
Here is just one way to do the job.
I have a server with sql database.
Also have about 100k users on android application.
What I need now is to send immediately notifications from the server to all devices.
Im researching the GCM system but as I see there`s a huge delay on the receiving side.
What I need is when I click the send button on my server,everyone device to receive it in a few seconds.
Is the delay only happening when using the HTTP connection?
Is it going to be different with the XMPP connection ?
You are trying to broadcast a message to nearly 100k users and currently xmpp downstream messaging does not support broadcasting. Use http server to send message to 1000 devices at a time. This can be improved by using multi curl. see this https://github.com/mseshachalam/GCMMessage-MultiCURL
In general the GCM is the right choice for massive broadcasting.
On the other hand the messages are not guaranteed to be delivered immediately, the delay might be up to 25(!) minutes given, that all devices have your app up and running.
See Google Cloud Messaging - messages either received instantly or with long delay for explanations why
This is not a question for a ready-to-use solution including sources but for getting ideas/hints/tips for a solution.
Assumed I have a messenger. User A types some text that has to be sent to user B. This text is sent to a central server first where it is stored when user B is not online or where it has to be transmitted to user B immediately when he is available.
For second case, what mechanism should be used here on a mobile device?
1.) Let the messenger of user B open a client connection to the server and to permanently receive data from there does not sound good to me. When the connection is interrupted it has to be re-established - possible until next interruption. So establishing of such a connection may cause traffic and consume power without transporting any payload in between.
2.) Let the messenger use a ServerSocket and let the central "server" connect to the device has the same problems: the connection may be interrupted.
So my question: is there a mechanism available for mobile devices that transmits such messages only in case they are available and establishes a connection only when it is needed? Some kind of automated push-notification without permanent connection between client and server?
It is recomended to use GCM for Android. Here You have nice tutorial. You could also use frameworks like Parse.
Either
1. Have a persistent connection between client and the server. Client can poll at a predifined interval to check incoming payload. You may have to optimize the 'poll' logic to avoid frequent 'poll' payload
Or
Server side may push a WAP push to the client when messages are available, then the client wakes up and retreive the payload.
don't use Polling. Use Google Cloud Messaging. suseba answer references to gcm deprecated in the "Here" link.
Use GoogleCloudMessaging. comes with GooglePlayServices Library
Documentation : http://developer.android.com/google/gcm/client.html
and the source is: https://code.google.com/p/gcm/source/browse/#git%2Fgcm-client
you just need to import libraries