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."
Related
Also is there an effective way to track, by the backend server, if the app being used by a user is in the foreground?
What are the best practices and recommended ways in mobile app development to get the latest data as soon as possible from the backend server to mobile apps being operated in the foreground?
Generally, for staying up to date, there are lots of solutions based on your case.
I'm going to divide them into two approaches:
1- You pull the new data when some specific conditions meet (eg; Intervally or based on user actions).
2- Data should be pushed to your app.
The first approach is quite obvious if you need to be up to date at some intervals, you can call networks APIs at intervals and fetch the latest changes.
In the second approach,
In iOS operating system, while app is in foreground state, There are Silent Push Notifications and WebSockets.
Silent push notifications is kind of push notification which can carry payloads and deliver to your app silently either your app is in background state or foreground.
There is some limitations to this kind of notification, based on some conditions OS will decide to deliver push notifications to your app or not. and also there is payload size limitation (up to 4Kb)
You can read more about this and its limitations in Apple Documentations
The second approach is pretty straightforward, It needs to use third-party libraries (like StarScream) to open a socket connection and get the latest updates real-time. There is no limitations in this approach for times that server pushes data to your app or the size of payload you are receiving. so you can be notified from last changes by your backend server every moment while app is in foreground and connection is alive.
Choosing between these two approaches is completely depends on your case.
If you should receive the update a lot of time in an hour and transferring lots of data so I recommend you the WebSocket approach, otherwise push notification will be sufficient and easier to implement.
I am relatively new to Android programming and invested a lot of time in reading and testing all about Services and Push-Notifications. I have the requirement for my App to deliver reliable (in terms of delivery time under one minute) Notifications for Users. For this I have some Questions, which I still haven't found an answer for:
Is FirebaseCloudMessaging (FCM) still "unreliable". In reference to this statement from 2014, the Connection refresh rate by Google is with wifi every 15 Minutes and with mobile-connection every 28 Minutes https://productforums.google.com/forum/#!msg/nexus/fslYqYrULto/lU2D3Qe1mugJ. Is this still the case? Has Firebase a more reliable connection-management than GCM? I am aware that this doesn't mean, that Notifications are pushed only after this time, but when a warning or error message has to be pushed to the user, the possibility that die connection has failed and is re-established only after 15 Minutes is not acceptable for my use-case.
What is the best way to create a Service for Android, which holds an connection to a Server and listens for Messages. My problem is, that (especially with API-Level 23 /Android 6.0 and its radical Power Management) every Service is paused or stopped nearly immediately. Even a Wake-Lock is not reliable that is is somehow released after one hour. Yes, i could try to merge all ways to reactivate the Phone or the App (Timer, Alarm, Delayed Handler, Wake-Locks, ...) to Hold a connection, but it is still possible that all these fail and my warning is not delivered. Am i missing something here?
Is is possible to create a deamon for non-rooted devices which is not likely to be killed by the System? Is is possible to create someting like a watchdog, to observe a Service and its state, and restart it, if necessary?
How is this implemented by big Apps like Facebook or Whatsapp? Is Facebook still using MQTT?
Are there any OpenSource Projects which implement such a service?
1) Notifications sent via GCM / FCM are still quite unreliable and unsuitable for real-time, mission-critical delivery. The heartbeat intervals have slightly decreased since 2014, but popular apps like WhatsApp and Facebook still make use of their own push notification solutions, implemented using the XMPP and MQTT protocols. This must mean that FCM is not reliable enough yet for mission-critical delivery.
2) Dealing with the recent power-saving optimizations in recent Android versions becomes more and more difficult in regards to maintaining a background connection for push notifications. Doze mode will kill your service's network connectivity and Background Execution Limits will terminate your service when your app goes to background.
3) A foreground service comes to mind, but this will require your app to display a non-cancelable notification while the service is running. The system will not terminate your foreground service as long as it is running, but the obvious drawback is that your app must display this notification which the user will probably find annoying. Otherwise, try using the JobScheduler APIs to adapt your service to the new battery optimization features.
4) As mentioned, WhatsApp still uses XMPP and Facebook Messenger still uses MQTT.
5) You may be able to find and piece together several open source projects to achieve this, such as the paho.mqtt.android client library and Mosquitto broker.
Alternatively, consider a paid product, Pushy (https://pushy.me/) which provides reliable push notifications via a fine-tuned MQTT socket. The SDK includes support for recent Android OS battery optimizations.
Full disclosure - I founded Pushy.
You may need to use Oksocket on your client and maybe solve the problem.
Your problem is very common in China, as FCM/GCM is prohibited in this country. Apps developed in China use OkSocket communication library, and implement Notification, Alert, or RPC based on TCP/IP transmission protocol provided by OkSocket.
https://github.com/xuuhaoo/OkSocket this is the library in Github.
I'm creating mobile application for iOS and Android. The problem is when any data has changed on server, I cannot notify mobile devices.
I have found 3 solutions, each have minus and pluses.
Use push notifications. Since iOS always shows a notification to user this is not a solution at all. Also I cannot know if the notification will go to device or when it will.
For every X seconds ask server if any change exists. I don't want to do that, because creating too many HTTP connections and closing them is not a good idea I think. Also if the data is changed right after the device asks, the info change on device will occur late.
Use web socket. My application's one time usage expectation is ~2 minutes. So web socket looks like a good choice, because app will be terminated or go to background state quickly and battery consume won't be much. Also all the server side data changes will come to the device just in time. But I don't know much about web socket. Is my opinion acceptable? Also how many concurrent connections can be done by my server. Is it a question too.
Here are my all solutions.
The document would suggest assumption 1. above is incorrect.
If you read the The Notification Payload section, you'll come across this;
The aps dictionary can also contain the content-available property. The content-available property with a value of 1 lets the remote notification act as a “silent” notification. When a silent notification arrives, iOS wakes up your app in the background so that you can get new data from your server or do background information processing. Users aren’t told about the new or changed information that results from a silent notification, but they can find out about it the next time they open your app.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
I think for the most part this depends on what your app is doing.
I would say you should use a combination of #1 and #2.
2 - At the very base level if you need information from the server you are going to have to make a request. If this information needs to be up to date then you can proceed to make a request for the information when the ViewController is loaded. If you need this information to update as the ViewController is loaded then you will need to make subsequent requests every X seconds... In addition to this if your user is interacting with this data and sending an update to the server you can check at this point if the data is up to date and alert the user as well as return the current data.
1 - Push Notifications operate off of the 'send and forget' protocol. The notification is sent and is not verified if it is received or not. This is used as a supplement to #2 and is 'nice' but should not be depended upon.
Push notification is the intended way (from both Google through Google Cloud Messaging, and Apple through Apple Push Notification Service).
Both option 2 and 3 are frowned upon as they affect battery life, and they are unnecessary as most cases scenarios can be covered by push 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).