I am pretty new in the push notifications issue, i want to develop an application
for both android and IOS devices, the application should be able to receive real-time push notifications.
The number of users for this app may reach more than 1,000,000 users, i am searching for a good tool for push-notifications.
The most important thing i am concerned of when sending notifications is low-latency, i want to reach a large number of users as fast as possible.
I saw that the service of Google cloud messaging is limited to 1000 users for each request. and any number of users that exceeds this number is sent with batches of 1000, does this effect the speed?
If yes, do you suggest a good push-notifications tool for that purpose?
I would suggest you to use
OneSignal
Best and easy to use API of GCM for Android and IOS and much more. This will fulfill all your requirements
We use GCM with our application.
With GCM one notification can send only to 1000 devices (GCM limit). So you must split your array of devices.
For fastest delivery of Notifications: 1. delay_while_idle - set to false 2. time_to_live - set to zero (But you might want to set this higher if their device is offline) 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.
I also recommend
airbop (Android Only)
Pushy
Related
I'm planning to send push notification to targeted users. I understand that this can be achieved by targeting by the player ids. But going for this approach would require my database to introduce dependency with OneSignal which is something that I'm trying to avoid.
I'm thinking is it possible to target players by username. What I mean when the app initializes it would update OneSignal saying that 'my username is user1' and when the server sends out notification it can target 'user1' (again, without using the player id approach).
The closest way that I could think of is tagging where the user could register themselves with username as the tag and server could target the user by using the tags. But from the documentation it seems like with this approach we can only target 200 users at once which is not feasible to me as well - I might be sending to thousands of users.
Any advice?
As you suggested, tags are the best way to achieve this without storing OneSignal IDs.
Although this is limited to 200 at a time, you can make multiple API calls to deliver to a larger number of total users. OneSignal's average API response time for this method is below 50 milliseconds, so this method will allow you to reach 4,000 users per second if you make the API calls in sequence.
OneSignal is a wrapper to Firebase Cloud Messaging or FCM (previously Google Cloud Messaging or GCM) on Android. If you don't want to rely on OneSignal internal device ID (or Player ID), you could still use FCM/GCM Registration IDs directly (also called push tokens) to target users with notifications. But in that case, you still have to store new IDs on your servers (instead of using your owns) and more importantly, you'll have to deal with FCM/GCM tokens complexity by yourself (managing errors, canonicals etc.)..
A better solution would be to use a third party like Batch.com (disclosure: I'm a co-founder). We allow developers to provide their own User ID (it's called a Custom User ID, you can set it from the app code) and then use it with our Transactional API to send push notification to one or more users (recipients can be push tokens, Batch installation IDs or your own User/Custom ID).
After discovering that WhatsApp probably updates notifications about every second I began to wonder what the best combination of battery life and keeping users up to date by notifications is.
The company where I work right now is really afraid of sucking the battery life. So they want the fastest sync to be around a quarter. Meanwhile WhatsApp updates every second. So is what our company doing the right thing? Or can we just like WhatsApp check for new updates every second because it doesn't suck that much battery life?
That extensive network usage will surely be very expensive for battery and even for data usage. If you need frequently updated data in your app, in most of the cases it's a bad practice to send HTTP request once per 1 (2 or even 5) seconds.
A good way to receive and update any kind of notification (wether it's Android system notification or some notification badge inside your app) is using Google Cloud Messaging. You'll have to implement it on both server and client side. You will need to register your app package name in Google Developer Console and retrieve an API key. After you do that, your app will be able to receive push notification from GCM server. The flow of receiving a push notification looks like this:
You register current device to GCM system using provided SDK and it generates you GCM unique identifier of current device
You upload this key to your server (if you have user profiles in your app architecture, it's a good idea to store it in current user profile)
Once something important happens on server, say, user gets a new unread message, your server takes the GCM unique identifier from user profile and sends a notification to GCM server
GCM server sends this data to user's device by using this identifier and delivers the notification to your implementation of a BroadcastReciever. After that it's up to you what to do with this data: create a system notification or/and use this information to update UI of your app.
It is just an overview of how does Google Cloud Messaging work, there are tons of articles about how to set it up and implement into your project, for example, this one. This solution might look way more complicated than just sending HTTP request every second, but your potential users will be thankful for saved battery and data limit.
Also, if you want to make Android system notifications, you may want to use Parse library which wraps GCM and makes implementation a bit easier.
We're building an application server which will be used to send push notifications to android and ios clients via GCM connection server. Our plan is to use HTTP interface to connect with GCM as we only want downstream messaging. could you please tell me what is the performance of GCM for HTTP interface? I'm looking for some kind of performance data like how many push notifications messages per second GCM can support? I checked GCM site but couldn't find this. Please help to guide from where i can get such data?
as per the official Google answer
The rate limit exception code indicates that you are sending messages from a backend server too frequently. To ensure a stable service, there is a per minute / per device app upper limit on the number of messages that can be sent from a backend server. This limit is set high so most well behaving apps should not be affected, all apps should however be prepared to receive this error code.
They do not specify the "actual limit" but they do say This limit is set high so most well behaving apps should not be affected so as long as you re not spamming a single device like crazy you should be ok with whatever you send at it.
However please note that you can get throttled and have the messages be delayed
I am currently building a messaging application that allows users to send and receive messages on their Android mobile phones over an internet connection to each other. I have decided that I do not want to use polling because it means that a user may not receive another user's messages as instant as possible. I have my own server available for use.
I am currently tied between using Google's Cloud Messaging for Android platform in order to send the notifications from the server to the Android device. The other option is to keep a live TCP connection between my server and the Android device via a service, and send 'keep alive' messages every 5 minutes for example.
From your best opinion, what is the best way to do this - or is there a better way? I don't want to use third parties apart from Google to do this. There are similar answers available, but they don't address this specifically.
Alex
using Google's Cloud Messaging for Android platform in order to send the notifications from the server to the Android device.
This is not a realtime notification either; the notifications may be delayed longer than you experienced with polling. Also GCM is meant for broadcasting messages to a number of users, not for targeting a message to one specific user.
The other option is to keep a live TCP connection between my server and the Android device via a service
I don't know how many users you are expecting, but this may not scale. You are limited in the number of TCP connections to one server.
No need to re-invent the wheel here, use an existing implementation such as XMPP.
Take a look at this:
https://pusher.com/docs/client_libraries
https://github.com/pusher/pusher-test-android
It may be what you're looking for
I planning the application pushes a newsletter to all registered users.
Number of users is approximately 200,000 ~ 300,000.
I'm caring about the traffic issue with google c2dm server.
Can I request to c2dm server in a loop with large number of users using HttpURLConnection?
Will I banned?
I heard something about in this case I must use http 1.1 protocol with keepAlive set true.
C2DM does have quotas, both on the messages per device and total number of messages. you can find the details here:
http://code.google.com/android/c2dm/quotas.html
as it says, 200k is the default limit but you can request a larger quota. i've done this at a company and it was no problem, but i can't say for sure how helpful they will be to the average developer.
as far as i know, there's no quota on the rate that you send them. you can send them as fast as the google servers will accept your requests.
I planning the application pushes a newsletter to all registered
users.
you should make sure you aren't trying to push a payload through C2DM. that's clearly a misuse of the service. C2DM must be used to wake up the device only. in your case, the message itself should be "hey device there's a new newsletter on the server, go get it". assuming that's happening but a few times a day at most, it will be within the accepted use for C2DM.