It seems to me that in the past, there was GCM (Google Cloud Messaging) which I understand as an endpoint one could send request to and if source and target are properly setup, a push notification is shown on target Android device.
Nowadays, GCM is deprecated and FCM (Firebase Cloud Messaging) is offered everywhere. It seems to me that FCM contains one more layer - FCM Backend (including logic to use Apple's APNs or web push).
Besides the contradicting information that FCM "delivers messages at no cost" and "firebase pricing plan" page where "no cost" means only "up to some limits", I would be interested:
Is there any possibility to send the push notification "the old way" (similarly to APNs) by just utilizing the Android Transport Layer (as specified on the FCM Architectural Overview) at no cost with no limits (thus not using the FCM Backend with the added value)?
There is no cost to calling FCM to send messages, and the only usage limits are to protect misuse of the service from affecting other users.
I don't think there ever was a way to send device-to-device messages through GCM, but definitely hasn't existed in FCM since its introduction in 2016.
You can send messages from a trusted environment which then delivers them to the targeted devices, and you can (much less common) send messages from a device to FCM and from there to your server.
Sending messages needs to devices needs to happen from a trusted environment, to prevent a malicious user from being able to send whatever message they want to all of your users.
Related
I use FCM in my social messaging app. Sometimes FCM messages can not be delivered from the server to client.
Is there any benefit to using OneSignal when I've got to do the full FCM setup as well in server and client sides?
I reviewed OneSignal documents this link: https://documentation.onesignal.com/docs/product-overview
but I could not understand which was more useful.
I help work on OneSignal. Here are some reasons that OneSignal could be useful in this case.
OneSignal provides a single API and management interface for APNS (iOS notifications) and FCM (Android notifications).
OneSignal tracks notification click-rate for individual messages and campaigns.
OneSignal provides an SDK that takes care of reliably displaying messages that are received, restoring messages after an app update (on Android), and making it easy to customize notification categories, sounds, LED color, and Lockscreen visibility.
OneSignal stays up to date with any changes made to the operating system or notification APIs so you get access to the latest platform features without any additional engineering work.
FCM has two types of messages.Notification message which deliver in most cases, and data message which doesn't sometimes. A possible solution is to set priority of data message to HIGH while sending from server side.
https://firebase.google.com/docs/cloud-messaging/concept-options
I am looking into incorporating Google Cloud Messaging into my app. I would like to send messages to all devices associated with a user. At first, it looked like GCM's device group messaging would be the way to go. But that requires managing registration IDs and notification keys on my server. It seems like it'd be easier to use GCM's topic messaging where the topic is keyed on some shared user information like a user ID.
I intend to use GCM to send data to both Android and iOS apps. I will be sending both background "content available" (to use the Apple Push Notification terminology) messages and user-visible notifications.
What advantages are there, if any, of device group messaging over topic messaging?
I think the first point below is the only thing that makes any difference
https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
Topic messages are optimized for throughput rather than latency. For
fast, secure delivery to single devices or small groups of devices,
target messages to registration tokens, not topics.
If you need to
send messages to multiple devices per user, consider device group
messaging for those use cases.
I have an android application where a user can insert data into web sql server. I want all the users to receive push notifications when someone inserts a row into database. How to implement.
You can use Google Cloud Messaging (GCM)
Google Cloud Messaging (GCM) for Android is a service that allows you
to send data from your server to your users' Android-powered device,
and also to receive messages from devices on the same connection. The
GCM service handles all aspects of queueing of messages and delivery
to the target Android application running on the target device, and it
is completely free.
For more info on how to use it, refer to developer.android.com
Try this tutorial (or the official documentation) for specifics, but in overview you maintain a list of registration tokens for your users, and send the list of tokens for users you want to get a notification to Google and the send it out. Google will tell you afterward if any of those tokens are now invalid--those should be removed from your system at that point.
http://www.tutorialspoint.com/android/android_push_notification.htm
I am developing mobile client for emailing service. One of the key features is notifications about new messages in the mailbox. As recommended by GCM architecture guidelines we are using a "Pusher" that is responsible for sending messages to the Google servers once we received a new message. The issue is that testing process has reported about serious problems with push notification delivery to devices.
So the question: is there an approaches for monitoring average statistics about push notification delivery percentage, time etc? Or maybe somebody have experience in how to set up test environment for efficient monitoring of how much notifications are getting lost during the application work?
All the "tips&tricks" related to the improving Android GCM experience are welcome.
Google claims that the processing at their GCM server takes less than a millisecond. Link below for a great video on GCM from Google's developer. And it's believable coz I could get push notifications almost instantaneously using my company's server to my device now.
http://www.youtube.com/watch?v=YoaP6hcDctM
They don't guarantee delivery, but they try for a max of 4 weeks to deliver the message depending on the duration you set in the message you send to Google's GCM servers and if you wish to let Google keep the data for eventual delivery of message to the device in case the device was offline when the message was to be delivered.
However, there are certain conditions under which the GCM messages are not delivered.
Background data is unchecked under Account and Sync settings.
Prior to 4.0.4.(ICS), a Google account on the device is a pre-requisite for GCM. Maybe, Users are not logged into their Google account.
The only way to do so is to report back to your server with the timestamp of the received push.
You can either
Report back to the server once you receive the notification in your GCM service. To implement, you will have to add a push id for your push notifications and send the id along with the push data. The client will have to get the timestamp once it receive the message and send it back along with the notification id. A simple php script can be done (when you send a push notification, you set the time of the send-notification and once it receives the device's timestamp it sets the receive-notification. This boils down to two fields in your database (marked in bold). In this approach you will probably not so much care about errors since it is very probable that the device will have a connection when it receives the notification and as such its request to your server will go through.
Keep a list of notifications received in your app and their timestamps. And when the sync is done, send the this data in your sync operation. This is ultimately the same approach but your server's data won't be as realtime as the first approach. However, the extra request is not required from the client's side but saving the received notifications and their timestamps is.
All in all, you will have to keep track of the notifications sent using a notification-id and their sending time (send-notification) and their receive time (receive-notification). A simple query will help you analyze this data.
Google has added support so that you can receive delivery receipts from Cloud Connection Server (CCS):
You can use upstream messaging to get delivery receipts (sent from CCS to your 3rd party app server) when a device confirms that it received a message sent by CCS.
To enable this feature, the message your 3rd-party app server sends to CCS must include a field called "delivery_receipt_requested". When this field is set to true, CCS sends a delivery receipt when a device confirms that it received a particular message.
https://developer.android.com/google/gcm/ccs.html#receipts
Google does not make these statistics available to you. There are some statistics available on the android developer console. This only shows the number of messages and registrations.
You would have to implement your own data collection, which could be done fairly easily. You could record the time & id of each message sent and have your android client report back to your server with the time of message receipt. You could then store the data on your server and query as needed.
Since that time Google has provided developers with advanced monitoring tool.
The Gcm Diagnostic Tool is available in Google Play developer console. Additional information is here https://support.google.com/googleplay/android-developer/answer/2663268
So you can easily track the particular message status via registration token.
Is it true that if a user does not have Cloud to Device Messaging (C2DM) in his account the C2DM will not work?
If so, how can I do push notifications without a Google account?
The different techniques to send push notifications can be listed as follows
Android Cloud to Device Messaging (C2DM) on OS2.2+
Other techniques for pre OS2.2 Devices.
Cloud to Device Messaging (C2DM) OS2.2+: The standard push notification method used in the android platform is called Android Cloud to Device Messaging (C2DM). The service provides a simple, lightweight mechanism that a server can use to tell an app to contact the server directly, to fetch updated data.
C2DM allows to send lightweight messages to android apps. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the apps that there is new alert on the server, so that the application can fetch it.
C2DM limitations:
The message size limit is 1024 bytes.
Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device
C2DM makes no guarantees about delivery or the order of messages
C2DM requires users to set up their Google account on their mobile devices.
C2DM requires devices running Android 2.2 or higher that also have the Market application installed
Server should be
Able to use HTTPS to communicate with C2DM Server.
Able to communicate with our client.
Able to fire off HTTP requests to the C2DM server.
Able to handle requests and queue data as needed. For example, it should be able to perform exponential back off.
Able to store the ClientLogin Auth token and client registration IDs. The ClientLogin Auth token is included in the header of POST requests that send messages. For more discussion of this topic, see ClientLogin for Installed Applications. The server should store the token and have a policy to refresh it periodically.
Other techniques for pre OS2.2 Devices:
Poll rather than push
SMS
Persistent TCP/IP
Third-party offerings
Poll rather than push: Android app can periodically poll the server for new messages from a background local service. The more often you poll the closer you get to the real-time push.
Adv: Easy to implement.
Disadv: Not real-time.Will kill the battery.
SMS: Android apps can intercept text messages in the android phone.So if a server can send an sms when there is a notification, the android app can receive the sms and then check for new data at server.
Adv: easy to implement. Fully real-time updates.
Disadv: Can be costly to do.
Ericsson labs provide a hosted service which allows upto 2000Sms's to be sent.
Persistent TCP/IP: The android app initiates a long-lived mostly idle TCP/IP connection with the server and maintains it by occasionally sending keepalive messages. Whenever there is something new on the server, it sends a messages to the phone over the TCP connection.
Adv: Fully real-time updates.
Disadv: Hard to implement a reliable service on both the phone and the server side. The Android OS is known to be able to kill services when it’s running low on memory, so our notifications service can easily disappear. What happens when our phone goes to sleep? Imagine if all the apps use the same technique . there will be plenty of open connetions which will drain the battery.
Third-party offerings
Urban Airship Push : The big disadvantage is that it requires the user install the AirMail app onto their device.
The deacon project
xtify
pushdroid.org