Not really a programming question, but I'm currently researching battery life and PUSH notifications on Android for an assignment.
I'm aware that third-party apps are able to use C2DM to be able to respond to PUSH notifications even while the phone is sleeping.
Besides responding to an SMS, is there any other way for third-party apps to listen for PUSH notifications without running as a service and keeping the phone awake?
How does the built in Exchange e-mail in ICS work? It seems that the phone is able to sleep even with an Exchange account set to use PUSH. Does this mean that the exchange service goes through Google's C2DM framework, or is it implemented in some other way? E.g. the phone has an idle connection directly with the given Exchange server but is still somehow able to sleep between incoming packets?
Related
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 trying to use GCM service, Every thing is OK except of the long delay that GCM push notification or deliver payload... some times it take to my App 5 minutes receive notification or payload.
I need Immediate delivering...
I know about the roles of GCM, that wait until the other device got online, but in my case I hold two devices and they are online, but I got Delayed notifications!
How does WhatsApp(as example of app that uses GCM) overcome this problem.. and send Immediately?
[ i.e (message of the type: typing, online - last seen) cannot be delayed...]
the GCM Delayed Push is known problem : this issue
my question is: How other app that use GCM overcome this issue
The big players
Lets focus on WhatsApp from a scale point of view. Their scale is global and one of the largest in terms of the market share. For players like these it becomes necessary to provide a consistent and smooth user experience no matter what the circumstances are. This means that the "small fish developers" like us are left with pre-defined rules by the big fish companies. Sometimes, it is the implementation that is challenging enough that a lot of the small time developers have to do with whatever is available.
I would like to take WhatsApp's Push Notification as an example to illustrate the above.
First of all, we must stop associating Push notification with Google's services(i.e, Google Play Services) exclusively. Would a device without Google Play services won't receive Push notifications? No, of course it can -- try focusing on the core mechanism of a push notification
How do Push Notifications work - Sockets!
Contrary to a protocol like HTTP which assumes a client-server architecture and is a uni-directional protocol(server can't initiate communication by itself), a plain socket enables communication bi-directionally.
You want to implement your own File transfer protocol over socket? You can!
You want to implement your own Chatting protocol over socket? You can!
You want to implement your own Push notifications protocol over socket? You can!
A socket is the canvas of communication over a network. You can pretty much do anything. Personally we have developed a custom request-response protocol in our organization.
Multiple implementations
Don't stick with default GCM/FCM notification messages protocol or implementation. You can deploy a mechanism to maintain a persistent socket connection with the device and can listen to whatever the server wants to push.
WhatsApp uses both GCM/FCM as well as their proprietary XMPP server implementation for Push notifications
WhatsApp(and several other Apps) rely upon GCM/FCM(as option 1 - the default) as it is present as a system App on lot of devices and therefore holds a special status where it is very less likely to be killed unlike a normal App.
For devices that do not have play services, your custom socket connection is relied upon. It may be that FCM is preferred over socket when the former is available but those are upto you to manage.
From WhatsApp's latest build(2.19.203):
Notice that the relevant permission for FCM is present.
Suspected socket implementation: https://android.stackexchange.com/questions/43970/how-is-whatsapp-able-to-receive-messages-when-not-in-use
XMPP based Push Notifications
From, https://www.quora.com/Does-WhatsApp-use-GCM-to-exchange-messages
No, whatsapp doesn't use GCM[NOT entirely true]. It uses a modified version of XMPP
called FunXMPP instead. It changes the XML keywords in message frames
to save bandwidth as it's users aka mostly mobile network users,
doesn't have a good internet connection. The replacements can be found
here: mgp25/Chat-API (I am not the author though)
They have even asked for whitelisting of any port(custom) in use by them.
So, WhatsApp does it. Facebook does it. Google does it. A lot of these companies do this. You can do it as well(to an extent) using Ejjaberd, Openfire or some other technology and having a proper client side implementation for the same.
Chinese ROMs
Some chinese ROMs have taken it even further and radically changed the way the memory and processes are managed in Android. As an example, in Oppo if the Application doesn't have Auto Start turned on, it will not let you do anything once your App is killed. No hopes of any experience whatsoever except hoping that the user will open the App again. In these cases, these OEMs have whitelisted WhatsApp, Facebook, Google and other players selectively. So, who suffers?
Us. Period.
When sending your notification you could set the priority-parameter to "high".
From the docs:
By default, messages are sent with normal priority. Normal priority optimizes the client app's battery consumption, and should be used unless immediate delivery is required. For messages with normal priority, the app may receive the message with unspecified delay.
When a message is sent with high priority, it is sent immediately, and the app can wake a sleeping device and open a network connection to your server.
I know this answer comes late, nevertheless if you are still facing this issue (or anyone else) please tell me if it helps.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I would like to create an app that users can use in an area/venue where there is NO GSM/3G or any kind of cell reception. We also only provide a closed WiFi network without an internet uplink, so it's a LAN where devices (PC's and Smartphones) can communicate with each other but not with the outside world (don't ask why :)
The users will be instructed to download the app before they come to the venue.
My app needs to be able to receive push notification but of course it cannot reach Apple's APNS or Google cloud messaging services. The app however does register to our central server on the LAN with an IP. (it logs in when the user is connected to the WiFi network and we have the phonenumber that belongs to a registered phone.)
Now my question is: is there a way to send a push notification when an event is triggered and the app needs to wake up without using or connecting to Apple's or Google's online notification services?? E.g. an on premises push notification service that can be used to send a notification to a users phone based on an event that is triggered by our server?
Any suggestions?
Update: Just to clarify, it's a simple VoiP app that connects to our sip server and let's users call each other so it needs to be fairly real time for the two calls to connect. But apparently you can only wake the app up by push notification and therefor need internet.
E.g. an on premises push notification service that can be used to send a notification to a users phone based on an event that is triggered by our server?
With respect to Android, the answer is "not really". Your options are:
Implement your "push" mechanism in the form of some message queue, where the devices poll looking for messages every so often, or
Use a WakeLock and WifiLock to keep the device (and WiFi) powered on constantly, then use something like MQTT for the push message
Either of these will be bad for the battery, though the first one is more configurable in terms of power drain (e.g., if you only check for messages once per hour, it won't be bad).
The reason why GCM can keep the power drain low is because of special hooks for mobile data connections within the OS and chipset, such that the CPU can power down while retaining an open socket connection to the push server, where incoming packets from that server will wake up the device. This is not available for WiFi.
And for iOS the answer is NO. You cannot push notify a device without utilizing Apple's APNS server. Your only option would be local notifications triggered in some other fashion on the device via WiFi although you would still need to keep the device awake to receive these or perhaps add VOIP service or another compatible service to allow for continuous background processing.
Local Notifications iOS
Receiving Voice and Text Communications on a Local Network added in iOS 14
Refer Apple Docs: https://developer.apple.com/documentation/networkextension/local_push_connectivity/receiving_voice_and_text_communications_on_a_local_network
You've probably long since solved or given up on your specific problem. But for reference iOS has evolved over the years and now supports the exact type of VOIP functionality you describe.
A Voice over Internet Protocol (VoIP) app allows the user to make
phone calls using an Internet connection instead of the device’s
cellular service. Such an app needs to maintain a persistent network
connection to its associated service so that it can receive incoming
calls and other relevant data. Rather than keep VoIP apps awake all
the time, the system allows them to be suspended and provides
facilities for monitoring their sockets for them. When incoming
traffic is detected, the system wakes up the VoIP app and returns
control of its sockets to it.
I answered this elsewhere, but this question is older
No. Without the internet, it is not possible to stimulate the OS Push
Notification triggering system manually separate to the official OS
vendor infrastructure.
You can find a list of workaround options on my answer
I have already implemented a push notification system for the android. My system works as following: From my server I communicate through the Http protocol with the google servers. Then the google servers are sending the notification to the mobiles. So, I was wondering if there are any alternatives ways to implement this functionality. However, I want something which will be reliable.
P.S. I would like to hear opinions from people that they implement something similar.
Not sure why you're looking for something else, if you've already got it working through the Google servers, but a good system to send push notifications easily is Urban Airship.
I was working with some Chinese tablets that could not receive android push notifs (very annoying). I had to implement a Comet like system on android.
Basically, on the android device, I created a service which essentially polled a URL. But since polling is very battery intensive, I used a push technique called long-polling. I had the Android http client set a very long timeout. I then on the server side had the server hold the connection open also for a very long time. What would end up happening is that as soon as a message had to be passed, the connection would finish, and the android device would get the message immediately. This is just an additional method of "push" technology.
The only other option not discussed here is a persistant TCP/IP connection. This can be very dicey because Android could kill the service at will, and it can be somewhat battery intensive as well.
From my experience, GCM is the best method out there, and I wish there was something as good as it available for iOS Devices!
I installed today from Market, the Yahoo Mail application and I was reading it offers push message notification technique. Indeed it works, as I got exactly the same moment the alert on my desktop computer and my mobile mail client.
How is it accomplished?
There already is another question discussing how to implement push notification without the cloud to device messaging in older system.
There are several frameworks that give you push abillity. They all require a running a small background thread that is polling a server at a very short interval(Bad for data rate and battery) or keep an open connection to a server that is kept alive somehow and the client is notified every time a new message is waiting on the server.
Have a look at the question and maybe choose on of the mentioned frameworks, the frameworks will reuse the same service for all applications that are installed on the phone using the same framework and therefore save battery and general system usage.
Soon, you will be able to use the Cloud-to-Device Messaging (C2DM) system, though it will require Android 2.2 or higher. You might also want to watch the Google I|O 2010 conference presentation on it, which gives a few clues as to how they implemented it.
Without installing the app, setting up my router to capture packets, and doing some packet inspection I can't tell you exactly how they do it. At the lowest level it's as simple as keeping an open TCP connect to a remote server and having the server sending the client a packet when it needs to do something. My educated guess on the specific way they are doing it is either with IMAP IDLE, or XMPP.