I implemented push notification system and I noticed that push messages do not ever come when I am on 3G or 4G (mobile Internet).
When I connect to wifi, they come regularly.
Is this behavior bound to Android OS or we can write a code to change it?
I implemented Parse.com 3rd party library. Regardless of myself, I noticed that push messages from other apps do not come unless I am connected to wifi.
If you see the same behavior with stuff from Google (Gmail, Google Play app updates, etc.), then the problem lies with your phone or carrier. If the Google stuff works (they use what amounts to GCM), then your problem lies with Parse.com and whatever the other apps are using for push.
GCM (and the C2DM precursor) work over mobile data or WiFi. It is a bit tricky to implement a push system as a third-party library, which is why I recommend firmware solutions (GCM, Amazon's just-announced Kindle Fire equivalent, etc.). In particular, maintaining a mobile data connection to the push server, with enough heartbeats to keep the connection alive without really draining the battery, is difficult to get right, particularly given subtle mobile carrier or device variations. Google has more experience with this than do most firms, and Amazon only has to worry about a handful of Kindle Fire models.
Related
Edit: I've noticed that StackExchange has prefaced this question with Android but it applies for both iOS and Android.
We have a client side iOS/Android application that we expect to run (in remote Australia) with very limited internet connectivity. However, the application can expect to have very good connectivity to its local network, which is not on the net.
I've been looking into ways of waking a phone up with a notification of some sort whenever an event happens on the local server.
From what I've researched:
Web push is no good as even the newer VAPID based protocol still wants to route some data through the browser vendor's notifications server.
iOS Apple Notifications essentially have the same requirements as Web Push.
A background task which periodically polls the server/wakes up a Websockets connection can work, but could end up with pretty long delays between polls.
SMS is an option, as although 3G is limited, basic phone connectivity is sometimes available.
Are there any other ways of being able to wake up a locked mobile device with a server-sent event that I haven't listed? Given the operational situation having App Store compliance is not necessarily a requirement.
Cheers
After doing a fair bit of research, the answer (as of early 2018) is a pretty solid no, at least for a cross platform usecase.
iOS requires that an external notification that can wake the device come from a recognised internet-based source (APNS, and maybe in future the standardised VAPID based Push), from the mobile interface if available, or from the device itself which is limited by background execution restrictions.
I've always used GCM for push notifications in android apps, but for security constraint i'm obliged to avoid GCM and use local push server, i've found a lot of answers for this question but none of them is well structured, i hope to get a clear answer for step by step process to use some XMPP server and client libraries for this topic
You may not fully understand what is GCM and what GCM was designed for.
Traditionally, each desktop applications establish its own TCP connection to its own server, just like you can connect to your Openfire instance and send/receive messages when you want without any third-party services.
This approach have many issues in mobile environment:
mobile devices are resource limited: when you have many TCP connections open it will drain your battery fast
mobile devices are not have persistent network connection: you should care about cellular and/or wifi network changes (and it also have battery impact) and you should not lose any messages in these unstable environment.
To solve these problems, Apple, Google (and also their minor competitors) provide "notification services". They are consists of:
System-wide background application ("service") which keeps connection to Apple/Google "notifications" infrastructure servers.
API for developers, to "register" their applications both on server and client side: your server-side application send all events to Apple/Google, and you client app receive "pushes" from that system service, you no need to care about network outages and battery impacts - all issues are handled by OS manufacturer.
But when you are trying to "avoid GCM" you getting all things to be cared by you, plus:
Your "handmade" persistent network service will interfere with Google's one, and will at least double network and battery usage (or even more, just because your implementation will have errors/other corner cases which are already where solved by Apple/Google big engineering teams)
Your application will dramatically more complex, and you will have much more security issues (as security issues are now handled by you, too) and poor user experience (applications with "own" networking are often have bad UX design, prompting and boring end user with network error messages, for example).
So, to sum up:
Yes, technically, you can take smack library and connect to Openfire server. Basically it the same as GCM works.
No, in 99.9999% of cases you should not go this way. Unless you are a big company which develops competing mobile platform.
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.
First of all, I know GCM service and I have questions about it too.
If I want to implement a push service, is this the right way; Server waits for connections, Android client connects server and waits for data all the time. So server can send data anytime. Connection is always open with keep alive messages.
About GCM;
Is GCM uses this logic?
Is GCM works on all Android devices? I mean is it guaranteed that if a device using Android OS, it also supports this Google service?
If GCM is not a guaranteed service on Android, how should I handle the case that there is no GCM support on device. Or is this a negligible case?
Is GCM uses this logic?
Generally yes, though bear in mind that there are a lot more details.
is it guaranteed that if a device using Android OS, it also supports this Google service?
No. It is only going to be on devices that legitimately have the Play Store and the rest of Google's proprietary app suite. It will not be on the Kindle Fire, the OUYA, or other devices that are using Android purely from the open source project.
how should I handle the case that there is no GCM support on device
Amazon has a GCM equivalent for the Kindle Fire series, IIRC.
Beyond that, since GCM is not a guaranteed delivery service, you need a fallback plan even for "normal" Android devices.
For example, let's suppose that you are writing an app to show news headlines to the user. In the absence of any push notification, you poll for new headlines every four hours, or when the user presses a "refresh" button in the UI. With GCM, your server can push down headlines as they arrive, which your app can pick up. This gives users on "normal" devices fresher data, but still covers cases where you miss some GCM messages or for devices that do not support GCM.
Adding to what CommonsWare mentions about GCM, you may want to look at MQTT as another pub/sub mechanism; It works on any device that can run Java. Here is a link where I try to explain how it works.
That links applies to LAN messaging but it works over the internet as well. It is the mechanism that the Facebook chat app uses. On that link you will find another link to a git where I show MQTT in use on a simple home automation project. If you have any questions, I can try to answer them.
There are currently push notifications available for iPhones, Palm Pre and Blackberries each provided by their respective manufacturer. However I have heard nothing for Androids (probably because google does not actually sell the phones themselves. Are there any solutions out there at all?
Was looking for same. Xtify is doing this now. developer.xtify.com. has a lot more than just push, but you can do just push if you want. I had a back and forth with one of their devs - he said soon you will be able to have iphone push (much less rich and no geo though) as well off of their platform, but for now, I just use for Android.
Android doesn't have the same limitations that the operating systems of the devices from the various other manufacturers listed incur. So it's likely that the data or notifications already exist as an intent and you just need to register for a given intent in your application.
The methodology in your case would be the same as you would use on normal computer systems.
You could have your server broadcast or stream events to a background process you create on the android device.
In all of the looking I've done around, there aren't any services doing this today. The last-mile piece is a little tricky and it presents some interesting issues for both the handset manufacturers (imagine every app firing up their own phone-home daemon) and carriers (that's a lot of back-and-forth when you've got lots of clients keeping connections open).
I'm at a company called Urban Airship and we do push notification services for the iPhone and have gotten a lot of questions about doing this for the Android platform. I'd be curious to know if others would be interested in a service like this? Something that would have an (ideally) open source library coupled with the last-mile cloud infrastructure providing the notifications to the devices and apps themselves?
Why dont you go with the XMPP implementation. right now there are so many public servers available including gtalk, jabber, citadel etc. For Android there is one SDK is also available named as SMACK. This we cant say a push notification but using the XMPP you can keep a connection open between client and server which will allow a two way communication. Means Android client and server both can communicate to each other. At present this will fulfill the need of Push in android. I have implemented a sample code and it really works great.