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.
Related
I want to sync the data with server between 12 am - 6 am only.
I have solutions like WorkManager and sync adapter at my disposal.
But some manufactures put restrictions on these work managers and syncadapter also.
What is a sure shot solution that a network request will can be made between these non active hours(most users are not using the app) ?
There is no sure solution. This is Android. Every vendor can do whatever they like.
What restrictions you are talking about? Because you are saying "some vendors"? In general Android applies restrictions related to how much time you can be executed per 24 hours period and how much network you can use. It is dependant on the Power Bucket you are in. And the Power Bucket itself depends on how often the user interacts with your app. Check here:
https://developer.android.com/topic/performance/power/power-details
You can implement a dialog asking the user to exempt you from Battery Optimization. This will fix the restrictions on most vendors. Check here:
https://developer.android.com/training/monitoring-device-state/doze-standby#support_for_other_use_cases
Though as a beginner, I am trying to develop an android app which is story based, i will like to know the best way to serve content to the user, i mean like a continuous update of content, just like updating news by the hour. As users will install just once, how will they get the latest content of my news or story based app.
I have access to domain names and hosting if it requires uploading such content through a domain.
from your experience, what is the best method to achieve this? I humbly await a response, thanks
So given the clarification in the comments this is the answer:
The best way is PUSHING the content to the user's device.
Generally speaking, the two ways for a new content to reach an app are :
1.polling your server (or any third-party server) for new data every,say, 20 minutes. The disadvantage of this method is that it drains the battery. Every time that the phone connects to the internet, the radio in that phone stays on (or in a standby mode) for something like 2 minutes. Those modes (on and standby) drain the battery. Another problem is that it does use data needlessly and in some countries cellular data is expensive (Canada for example).
This could be a solution if the data changes very very frequently (for example a stock's price can change many many times a day). But generally speaking method 2 is the preferred method..
2.Pushing the content to the user's phone.
Your server will send a message to the device once new data that you want to send is there (and you could also put that data in the payload of the message if it's not too much).
This means that the phone will connect only when some new data is available.
Saves battery life,and gets the information as soon as it is available!
I recommend using GCM (Google Cloud Messaging) for this purpose which is free, and simple to use. If you have no idea how to do that in Android (which is likely since you said that you are a beginner), it is explained really well in Udacity's
Advanced Android App Development. It is a free course by Udacity and Google, but the section about GCM is only about 15 minutes long.
If you know how to implement a server but don't know how to use GCM in your server (and you don't find Google's documentation helpful) do let me know..
If you don't know how to implement a server...well then it's something you will have to learn in order to get your content to your users as that's the best way.
I hope this helps! :)
I have an Android app which needs to poll a web server at 2 second intervals.
So I would like to know what the best way to do this would be. My first thought was to use an AlarmManager but I believe this is no good for anything more frequent than about 5 minute intervals. I have also considered using a service but I am concerned this will drain the battery. Are there any options I haven't considered? What is the best way to poll a server very frequently without killing the battery?
I also know that GCM is the ideal way to sync with a server but unfortunately it is not an option at this time.
Edit: ok, it seems from your comments that it is as I feared and there's no good solution for this. I will probably implement it in a service and press for a push mechanism instead. Thanks for your help.
The solution I have come to is gaining agreement to redesign so that the server pushes to the app only when the data has changed (it won't change that often, realistically).
In the meantime I have made some small changes to the service so that it cancels all requests when the app isn't in the foreground and reduced the poll time to 5 seconds (better than nothing, right).
I know this is a somewhat abstract question and that an answer depends on the device, network, user preferences and so forth. Nevertheless I'm really in need of some educated opinion with regards to how "excessive" I can allow my polling to be. Let's say one of my typical polling requests consists of an empty request body (a simple GET) and a couple of hundred kilobytes in response, would a service that polls for this every 4 hours be in the category of excessive?
I'm in the unfortunate situation of not being able to use C2DM, so please no answers suggesting this.
Let's say one of my typical polling requests consists of an empty request body (a simple GET) and a couple of hundred kilobytes in response, would a service that polls for this every 4 hours be in the category of excessive?
I wouldn't think so. Every 4 minutes would be unpleasant from a battery standpoint. Ideally (IMHO), make the polling period be configurable via a preference.
Also, you might wish to watch Reto Meier's Google I|O 2012 presentation, particularly the "Efficiency" section, which gets into lots of good low-level battery consumption stuff.
Also also, with that payload size, IMHO battery is less of an issue than the bandwidth cost for those on pay-as-you-go plans. You're talking ~1MB/day, ~30MB/month. That's probably not unreasonable, but it would be nice if the user understood why you're downloading all that data (vs., say, some sort of diff or delta approach), and it would be nice if the user could throttle your behavior within your app. Otherwise, the user might elect to throttle you from Settings on Android 4.x+ devices.
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