can somebody explain to me how googles Push Service work?
I know google has a persistent connection to its servers but how come that a persistent connection doesnt drain the battery for no good?
I understand polling on the otherside constantly wake up the system and boot up the radio. But how is this different from a constant connection to a googleserver?
For my understanding you need a permanent active radio to hold that connection?
How can this be more efficient in battery usage than polling?
thanks
If you want some flowcharts here you go.
UPDATE since i saw your comment.
C2DM is not battery efficient by it self. It does the same thing you whould do if implemented your own. The key difference is that your device is already connected by default with C2DM with services like Gmail Android Market .. generally googleApps. So C2DM is providing you the opportunity to use that "ASYNC" notifier with build in intervals for your application too.
For efficiency you should trust google to that. But having 1 polling service is better that adding another one too
Related
I am developing an android app for our custom healthcare hardware device that, among other things, should receive data from 5 sensos. The sensor data are sent via Bluetooth and is received using delegates that fire at 64Hz, 1000Hz, 4Hz,4Hz, and 32Hz respectively. I have successfully created an app that received the sensor data. Unfortunately, at the moment, the sensor acquisition runs on the main UI thread. This is unacceptable because it is expected that the app should keep recording the data uninterrupted throughout the day. After spending some time exploring my options, many tutorial online suggest to use a service to achieve this. However, there are many types of services (IntentServices, foreground services, background services...) to choice from and I am not sure what is the best approach. Also, my app will target android O and it seems that using background services are somehow discouraged. Would any experienced android developer gives some suggestion on how to tackle this problem? Please note that, at the moment, this is just a demo and the battery and other resource usage is not an issue.
Best approach for things that you want to achieve is to use Foreground Service, that will keep connection with ble device and get notifications from gatt services. Also you will need to use WakeLock to keep your service alive in sleep mode.
One year ago was making sample app for internal ble device. Check bluetooth/gatt package, was really useful such implementation.(project isn't good for production, but as sample/demo is pretty nice)
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 currently making an app in Android that is checking an API which returns two things. Some text and a colour.
However I want this to be checked for updates every 15 minutes in the background and check every 5 seconds when the app is open. When running in the background it should give a notification if the status is changed.
Now I have checked numerous stackoverflow q&a's and forums, docs etc.. But I can't seem to find a good baseline for what I need. So many documentation that contradicts eachother.. I think that I need an Alarm Manager or a Service... but what do you guys suggest for my problem? The app may not harm the battery too much.
What I really would like to have is that the application doesn't have to "poll" the server every 15 minutes but that the application gets interrupted like.. "hey, there is a new status update". I can't imagine that messaging apps are constantly polling a server for updates? I haven't found much information about that topic... Any help is appreciated. Not asking for code but directions to get where I want to go.
Many thanks
If you're looking to poll the server every X seconds/minutes, AlarmManager(android guide, tutorial) is exactly what you need. However, as you point out this is probably not the best way to go about things. While the app is open you may want to look in to passing messages between the device and server via an open Web Socket. Once your app is closed you could, instead of the app polling the server, have the server push a notification, via GCM or some such, to the app when an update is available.
If you are doing both the server side project and the mobile application, You can use Any messaging service rather than polling for the server, Because there has to be a pusher implementation from the server side to push the status to the MS.
For now GMS is free, I hope it will remain the same :). Otherwise, You can use AlarmManager and IntentService to achieve your goal.
I need my app to receive notifications, but my boss does not want to rely on Google Cloud Messaging so I will use httpPost in a background service instead for periodically check for new messages.
My question is: will that be too demanding for the battery and data consumption? Do you know a better option?
Thank you.
Edit:
This is an app for a delivery store. The messaging starts when you ask for something and ends when you receive the item. The message query will be every minute for about 10 or 20 minutes.
In general, this would not seem like a good idea. The scenario you describe seems like a perfect fit for GCM. I would first try to convince your boss to reconsider. :)
"Polling" a server, even for a brief connection which transmits hardly any content, means the device must be woken (from a low power state) and the radio turned on, and it will stay on for a significant time. The impact on data consumption will probably be insignificant, but battery usage will be a concern.
In case it cannot be avoided, you should check Minimizing the Effect of Regular Updates section of the Efficient Downloads referenced by #CommonsWare in the comments.
Also, Reto Meier gave an excellent talk on this subject at the 2012 Google I/O. His series on Efficient Data Transfers is also very informative. Hope it's helpful.
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."