we've been trying to develop an android application which uses the c2dm service of Google.
When we start the application after clearing all data, the application receives the c2dm messages just fine, but after some time (maybe 2 minutes) the messages refuse to arrive.
We also checked the code we received after pushing the c2dm messages from the server, and the code was successful (code number 200 without error).
After searching relevant posts on Stack Overflow, we came across this post:
Why do Android C2DM push messages not always arrive?
but we verified that we don't register to the c2dm service each time the application starts.
What seems to be the problem in our case?
We use android 2.2 API 8 version .
Thanks in advance,
Mark.
You should always have in mind that Google's C2DM allows a certain limit of messages/day. I'm thinking that sending a large number of messages in 2-3 minutes (a client-chat, or something like that) could be the source of your problem.
And also, have in mind that there is no guarantee whatsoever that messages will arrive. Per Google's C2DM Introduction: C2DM makes no guarantees about delivery or the order of messages. But you probably already know this.
I am thinking that if your 2-3 minute average is a rule, then probably the limitation of the messages could be the cause. Try sending fewer messages and see if the interval doesn't get larger.
"maybe 2 minutes" - you should confirm that first of all. You must clarify:
Is this issue related to this one device?
Does it happen consistently? If not, what triggers it?
Has it happened once, or does it happen every time?
Do bear in mind that C2DM messages are not guaranteed. Some will not arrive.
Also be aware that sometimes Android devices "fall off" c2dm and don't receive messages for a period of time. You will see similar effects on some networks (e.g. in my experience some C2DM messages are not delivered over wifi networks, so try 3G too).
Related
I am relatively new to Android programming and invested a lot of time in reading and testing all about Services and Push-Notifications. I have the requirement for my App to deliver reliable (in terms of delivery time under one minute) Notifications for Users. For this I have some Questions, which I still haven't found an answer for:
Is FirebaseCloudMessaging (FCM) still "unreliable". In reference to this statement from 2014, the Connection refresh rate by Google is with wifi every 15 Minutes and with mobile-connection every 28 Minutes https://productforums.google.com/forum/#!msg/nexus/fslYqYrULto/lU2D3Qe1mugJ. Is this still the case? Has Firebase a more reliable connection-management than GCM? I am aware that this doesn't mean, that Notifications are pushed only after this time, but when a warning or error message has to be pushed to the user, the possibility that die connection has failed and is re-established only after 15 Minutes is not acceptable for my use-case.
What is the best way to create a Service for Android, which holds an connection to a Server and listens for Messages. My problem is, that (especially with API-Level 23 /Android 6.0 and its radical Power Management) every Service is paused or stopped nearly immediately. Even a Wake-Lock is not reliable that is is somehow released after one hour. Yes, i could try to merge all ways to reactivate the Phone or the App (Timer, Alarm, Delayed Handler, Wake-Locks, ...) to Hold a connection, but it is still possible that all these fail and my warning is not delivered. Am i missing something here?
Is is possible to create a deamon for non-rooted devices which is not likely to be killed by the System? Is is possible to create someting like a watchdog, to observe a Service and its state, and restart it, if necessary?
How is this implemented by big Apps like Facebook or Whatsapp? Is Facebook still using MQTT?
Are there any OpenSource Projects which implement such a service?
1) Notifications sent via GCM / FCM are still quite unreliable and unsuitable for real-time, mission-critical delivery. The heartbeat intervals have slightly decreased since 2014, but popular apps like WhatsApp and Facebook still make use of their own push notification solutions, implemented using the XMPP and MQTT protocols. This must mean that FCM is not reliable enough yet for mission-critical delivery.
2) Dealing with the recent power-saving optimizations in recent Android versions becomes more and more difficult in regards to maintaining a background connection for push notifications. Doze mode will kill your service's network connectivity and Background Execution Limits will terminate your service when your app goes to background.
3) A foreground service comes to mind, but this will require your app to display a non-cancelable notification while the service is running. The system will not terminate your foreground service as long as it is running, but the obvious drawback is that your app must display this notification which the user will probably find annoying. Otherwise, try using the JobScheduler APIs to adapt your service to the new battery optimization features.
4) As mentioned, WhatsApp still uses XMPP and Facebook Messenger still uses MQTT.
5) You may be able to find and piece together several open source projects to achieve this, such as the paho.mqtt.android client library and Mosquitto broker.
Alternatively, consider a paid product, Pushy (https://pushy.me/) which provides reliable push notifications via a fine-tuned MQTT socket. The SDK includes support for recent Android OS battery optimizations.
Full disclosure - I founded Pushy.
You may need to use Oksocket on your client and maybe solve the problem.
Your problem is very common in China, as FCM/GCM is prohibited in this country. Apps developed in China use OkSocket communication library, and implement Notification, Alert, or RPC based on TCP/IP transmission protocol provided by OkSocket.
https://github.com/xuuhaoo/OkSocket this is the library in Github.
I develop the Android watch/phone application pair, where watch and phone communicate using Data API.
I need to pass the messages immediately, or with few minutes delay at most (not 30 minutes). To achieve so, I call setUrgent() on my PutDataRequest.
For the reasons I do not understand, the message still takes very long time to deliver.
The message is delivered immediately if I try to play with the stock Android Wear app changing the watch face. Also, after the first message is delivered, others seem passing immediately. However, after some longer time of inactivity (few hours) the slow delivery problem resumes.
I have updated Google Play Services to 10.2.1, I tried to use GoogleApiClient.reconnect() on every action, I have removed all threading from the connectivity listeners - no help. Even rebooting both watch and phone does not pull out the pair of the stalled communication state.
From watching the logs, seems that one side sends the message, other just does not receive it. The sending side receives own data message instead.
As the communication is bidirectional, and messages may come at any time, I need to keep the connection permanent. The sender tries to connect before sending the message, and the onConnected listener is called, yet the message is not delivered immediately.
Is anything is required to deliver messages immediately, in addition to calling of the setUrgent method? Which kind of magic the Android Wear app does that not only it has no problems of communicating, and even pushes my "forgotten" messages through?
If you needs some additional information for diagnostics, please tell me how to debug.
My android system needs to send frequent updates to an app for tablet (a kiosk always connected to wifi and power plug).
GCM-HTTP (//developer.android.com/google/gcm/http.html) works fine but in some cases it can happen that a single device receives many notifications triggering the well- known throttling issue described here (//developer.android.com/google/gcm/adv.html#throttling). This is a problem since the payload in the notification is of great importance for the system.
What is the best solution to prevent this?
implement in the server a service that groups notifications to the same device and shoot them with a limited frequency.
use a XMPP service. I would like to use GCM-XMPP (//developer.android.com/google/gcm/ccs.html) but you need to be signed in a whitelist so I don't think everyone can already use it. As alternatives should I use aSmack or Quickblox as advised here (Android and XMPP: Currently available solutions) and here (Better Way to implement the chat application using XMPP on Android?) respectively?
implement a basic socket connection as described in (//thinkandroid.wordpress.com/2010/03/27/incorporating-socket-programming-into-your-applications/)? In this case I have to take into consideration the possibility of the connection getting momentarily lost?
SOLUTION:
I found the solution to my question, that is XMPP protocol. At the beginning I implemented aSmack in the tablet application and configured an eJabberd server running locally. The implementation has been pretty easy.
After a couple of weeks I received a mail from Google for the GCM-XMPP, that is even quicker to embed in the app and works super fine!
Maybe setting time_to_live to 0.
From http://developer.android.com/google/gcm/adv.html:
"Another advantage of specifying the expiration date for a message is that GCM will never throttle messages with a time_to_live value of 0 seconds. In other words, GCM will guarantee best effort for messages that must be delivered "now or never." Keep in mind that a time_to_live value of 0 means messages that can't be delivered immediately will be discarded. However, because such messages are never stored, this provides the best latency for sending notifications."
Everybody tells me that polling server for new data is stupid if the server is yours and you should implement push with GCM instead. Well, I agree and have done so but, I was wondering, how often can or should you perform push?
I have a simple app where people post stuff to the server and have a feed of everyone else's posts. The method on the server that does the saving to the database also triggers the GCM Push at the end, so Google sends out the push notifications to everybody and everybody then requeries the server for new posts, containing the post weve just made.
But, what if I have, lets say milion users and a new post is created lets say every minute. This will mean that app will connect to server every minutes and will kill the battery. So my question is, how often you perform Push? Wouldnt in this case polling every 10 minutes be actually better for battery, right?
I know this example is kind of crazy, having milion people in your feed, but its just to make a point, because I cant imagine how this would scale. I figure Google will handle sending million gcm messages at once no problem.
So the question is, is there a limit after which Push is contraproductive? I guess its kind of a first world problem :D but cant imagine Facebook handles stuff like this.
Thanks!
Push notifications are welcome when the server has important new data to show to the user (and by important I mean important to the user).
I believe that if any app sent me a notification every minute I would either disable notifications from that app or uninstall that app. You should be very carefull when deciding what updates to send to your users as push notifications, in order not to antagonize them. If your server can send push notifications very often to the same device, you must have settings options in your app that can reduce the frequency of those notifications.
Push notifications are usually relevant when the app is not running (or is running in the background). When it is running in the foreground, polling the server is probably a better solution (given the disclaimer that you can't rely on the push notifications being delivered every time).
In your example, I'm not sure I'd want to be notified automatically about each new post in the DB. Even while I'm using the app (i.e. it's in the foreground) I wouldn't want it to update with new posts automatically. Even facebook don't update the view automatically (they show you on top of the screen that you have new posts, and you have to pull the list view down in order to load them. And when the app is not running, I'd want to be alerted only about important posts (for example, posts from specific users). When an app sends me too many push notifications, I go to its settings to reduce them.
I can't give you a numeric figure of a reasonable frequency of push notifications, but I hope my answer helps. In short, you don't have to worry about GCM's technical limits. You should worry about the user experience.
I have a working C2DM project, atm. I have me and my colleagues phones registered and it has worked very well so far.
Though today we were both doing testing with it, which resulted in us having to wait a really long time for these messages to appear on our phone, and even some that were never delivered.
We are talking a bout ~100 messages to 2 devices in an ½-1 hour...
Anyone have any clue if this could be Google issues or?
This is well within reason. C2DM is not a guaranteed message delivery service. It is certainly not designed for "~100 messages to 2 devices in an ½-1 hour". That sort of message rate calls for something like XMPP, where you are maintaining a persistent socket connection.
How big are your messages? My understanding is the payload for C2DM is 1kb or less.