I want to push notifications to around 50,000 users at a time and about 50 notifications per day, is it a good choice to use GCM in this case?
If not can i know which other push services can i use , i dont mind even if its a paid service..
Thanks in advance
One notification can send only to 1000 devices (GCM limit).So you must split your array of devices.
50.000 users its ok for GCM.
Our application serve 100.000 users.
As case you can use airpush notification service:
http://www.airpush.com/
I think that GCM is a good choice to use. It's reliable and using it helps to conserve battery and data usage since it piggybacks other Google services. All you need is Android 2.2 or later with the Google services installed, which means no Kindle Fire.
I do not think that GCM would have any problems handling the number of messages or devices that you gave.
If you use it you will still have to write your own server component to handle registrations and message sending. I wrote a blog post that describes how this works.
Some commercial services that handle the server component for you (as well as other things) are AirBop, UrbanAirship, and ClixAp. Parse is a commercial solution that (I believe) does not use GCM. As I noted in the comment above I helped create AirBop
Like others we struggle with GCM as well for some time. However we believe we have finally figured out the factors which affect the performance of GCM the most:
For fastest delivery of Notifications with least amount of jitter:
1. delay_while_idle - set to false
2. time_to_live - set to zero (but we have set to 30 for just in case)
3. Canonical IDs - Make sure Canonical IDs returned by GCM replace the old PushID in database
4. collapse_key - The most important factor - set it to random or TOD to avoid Google to throttle notifications
With these, our GCM is working satisfactorily. Good wishes, post if you still have issues.
Related
Our app with more than a million subscribers is facing huge delivery issues with FCM. It has become worse lately and the service is hardly working anymore. We are receiving errors like:
{ code: 'messaging/message-rate-exceeded',
message: 'Topic quota exceeded.' },
codePrefix: 'messaging' }
We get this error a lot. And it seems to be worse during EU / US evenings. In some cases over 90% of the notifications are failing.
We are in contact with the firebase support team, but so far there seems to be no solution. The gave us lots of information with some useful facts though:
resources are shared between developers. So the max message rate can be different because of other developers taking up resources.
OR queries should be converted to multiple AND queries because OR queries actually generate messages to all of user base, and then the filtering condition is applied
240 messages/minute and 5,000 messages/hour to a single device.
limit upstream messages at 15,000/minute per project (we don't understand this one)
limit upstream messages per device at 1,000/minute
They also updated their docs at https://firebase.google.com/docs/cloud-messaging/concept-options#topics_throttling
So we are aware of message rate limits and fanouts mechanism. In our case we have an approximate of 6000 different topic send requests per hour and on average 10k subscribers per topic.
A single user will never get more than 50-100 notifications per hour.
We believe we are not hitting the limits set by FCM.
Back in the GCM time everything worked fine. So we are quite unhappy about the current situation. The core functionality of the app is really bad right now. And a solution seems to be not there.
We are considering switching to a SSE solution.
There is a story about someone who succesfully moved away from FCM
https://f-droid.org/en/2018/09/03/replacing-gcm-in-tutanota.html
But since Google has made it very difficult lately to have background processes running, I wonder what other people with similar experience did.
Or can we still fix this situation?
One such alternative is Cloud Alert - it can replace FCM, provides high throughput and unlimited messages. It uses a background job and maintains its own connection to its dedicated servers. While a free plan is present, your 1 million connection requirement would put you into the paid bracket.
Disclosure: I work for Cloud Alert.
It's simpl question. I don't need code examples or somethings.
Can I send a data message from my backend every 5 minutes? Is there a Google rules forbidding it?
Are there any limits for sending notifications?
I searched on the firebase site, but I could not find anything about the restrictions.
Well there is no rule which restricts you to send the FCM push so frequently. What would impact is the ability of receiving push by your app.
With introduction of doze mode, Google has placed several restrictions on how freely you can perform background processing. Although high priority FCM messages are delivered even during doze mode, but if they don't end up in user interaction they will be deferred.
Based on documentation:
High priority messages generally should result in user interaction
with your app. If FCM detects a pattern in which they don't, your
messages may be de-prioritized.
Android P comes up with priority buckets. If your app falls in Rare bucket, then high priority notifications drops to a limit of 5 a day.
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."
I just inherited an Android app project as a (technical) product manager that uses a 5 second timer to poll a remote URL to see if some work initiated by the app has finished. My initial reaction of course was to suggest to replace this with a push/notifications mechanism, preferably Android's built in GCM, so the work is removed from the app on the phone and put on the server side.
Surprisingly I met resistance from the development team. A former product manager (my predecessor) seems to have explicitly requested the implementation to work this way. Unfortunately, he wasn't big on documenting his decisions, so I now have to try to retrace which reasons could have led to this decision to justify a change in the implementation. I came up with the following pro and contra list:
Contra Push / Pro Poll
-
-
Server side work needed to implement push notifications
-
No direct way to know if push notification was successfully delivered
Scaling push notification delivery can be a pain
Pro Push / Contra Poll
Work is removed from device
Lower bandwith usage
Lower battery usage
More responsive application and device
Server load is lowered as devices don't poll every x seconds even if nothing changed (DDOS)
-
Push is faster (more responsive) than 5 seconds (current timer)
Delivery proof of push notification is trivial to implement with a poll of a remote URL (here it makes sense)
Scaling push notification delivery is a solved problem with lots of open source projects and trivial implementation with a message-queue
Are there any other reasons to avoid Push Notifications and use Polling for this usecase?
Are there any other reasons to avoid Polling and use Push Notifications for this usecase?
Any other important things I forgot?
No way to know if push notification was successfully delivered
Sure there is: have the device hit your server upon receipt of the push message. You might need to do that anyway, if the payload is bigger than 4K.
Scaling push notification delivery can be a pain
It works for fairly large user bases (e.g., RememberTheMilk), and that was even before the XMPP based persistent socket solution.
Are there any other reasons to avoid Push Notifications and use Polling for this usecase?
GCM has no service level guarantee. GCM is Android-specific; you might consider a wrapper around it, like Amazon SNS, if you are looking for something that will handle other client operating systems. Push solutions involving third parties, like Google, means that your raw push message payload will be visible to those third parties' servers; please use suitable app-level encryption if this is a concern (and it should be).
Are there any other reasons to avoid Polling and use Push Notifications for this usecase?
A five-second poll makes $BABY_DEITY cry.
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).