I have a Service which performs some file I/O. I would like to display the file which the Service is currently working with in the notification of the Service. I can update the notification according to
http://developer.android.com/guide/topics/ui/notifiers/notifications.html#Updating
but as this blog post says, I should be careful about too frequent updates (which might occur for small files). So what is a good solution? I don't even need the updates if the user hasn't pulled down the notification area. Should I check for this? Should I use an updating time?
The more frequent the updates are the better (for the user to see the most recent activity of the service), but higher CPU load is worse.
Is there a standard pattern to work with?
Since you are already putting heavy load on the CPU with your IO activity, your notifications won't be much of an extra burden.
The recommendation against too-frequent updates applies mostly to situations when the phone is in standby and needs to be woken up to process each notifications, which drains the battery.
However, if you are processing lots of small files, the updates are too fast for the user to read and may appear as a flicker, so for that reason you may want to only update every few seconds.
Related
I've been using WorkManager to create notifications for my app. For my purposes I figured PeriodicWorkRequest is the most fitting, but after a bit of testing and reading online it's seems extremely unreliable. Using the minimal interval (15 minutes), and the app being closed, the worker woke up 5-6 times and then seems to be killed.
So how does one go about creating background work that wakes up in reasonable time intervals? What is the best approach for creating event-based notification? My idea was checking for the event (for example, checking for something new in the database) in small time intervals (with 15 minutes also being less than ideal), but seeing as it doesn't work well with PeriodicWorkRequest and is also the recommended approach as per the documentation, what exactly are my options?
Basically, the idea of Android is for you not to be able to do what you want to do because we as developers try to kill the battery.
You need to see how the evolution of the restrictions goes:
Version 6 - Doze:
https://developer.android.com/training/monitoring-device-state/doze-standby
https://developer.android.com/about/versions/marshmallow/android-6.0-changes#behavior-power
Version 7 Another state of Doze with even more restrictions:
https://developer.android.com/about/versions/nougat/android-7.0-changes#perf
Broadcast Restrictions:
https://developer.android.com/guide/components/broadcasts
https://developer.android.com/about/versions/nougat/android-7.0-changes#bg-opt
Version 8.0 Background execution limits:
https://developer.android.com/about/versions/oreo/background#services
Version 9 StandBy Buckets - where depending on how the app is used you have different resources to use - like time to wake up the app, time to use the Network, etc
https://developer.android.com/about/versions/pie/power#buckets
https://developer.android.com/about/versions/12/behavior-changes-all#restrictive-app-standby-bucket
https://developer.android.com/topic/performance/appstandby
Battery Save improvements:
https://developer.android.com/about/versions/pie/power#battery-saver
Power Management Restrictions - really important.
https://developer.android.com/topic/performance/power/power-details
Version 11 and 12 App hibernation
https://developer.android.com/topic/performance/app-hibernation
Long story short - you need to prevent all these restrictions to harm your work. But you need to comply because it is better for the user.
But there is no API that will just say - "f**k all these restrictions and do whatever the dev wants to do."
If you need exact timing - you need AlarmManager.
If you do not know when you need to do your work and depend on the outside - Push Notifications which then can transfer the work to the WorkManager.
If you need periodic work that is not time-critical - you might not use the AlarmMangaer and be sure that the work is finished, but you can't be sure when, because there are many restrictions and the priority will be saving the resources.
Also, you can ask the user to be exempted from Battery Optimization:
https://developer.android.com/training/monitoring-device-state/doze-standby#support_for_other_use_cases
If you want to know why exactly the work is not executed you need to check the JS dump and see what restriction is not satisfied:
https://developer.android.com/topic/libraries/architecture/workmanager/how-to/debugging#use-alb-shell0dumpsys-jobscheduler
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 want to be reassured that I'm doing this the best practice way :
I have a list which order is changing on the server, therefore, I want every 20-30 sec. to perform a request to see if there were any changes in the order. So, I've created a Service which is bound to the Activity with the ListView, and the service every 20-30 sec. performs a request with an AsyncTask.
I chose to perform it with a Service because I want the list to be updated constantly, even when the application is in the background, And the AsyncTask is because I don't want it to be performed on the main thread.
Is this the right way to do it?
Thank you in advance,
Dan.
It will work, but your app will do a lot of unnecessary work. This will affect battery life. Besides that, according to documentation, if you use device radio, it stays full-powered at least for 20 seconds, which is also no good for battery. You have the following options:
Use Google Cloud Messaging. It will allow you to perform update only when this is really necessary.
If you don't want or cannot use GCM, follow this guide to optimize network access. Start with increasing the update interval (to 4 minutes at least).
The Android GenieWidget (also known as News & Weather Widget) updates very often (every few seconds). Now the time interval for updating a widget can currently not be shorter than half an hour. It is possible to create a service or use AlarmManager that updates it more often, but this is discouraged because of the drain of system resources.
I am considering making a similar application. My question is, how is it (probably) done in GenieWidget? Is it some clever trick, or does it just update more frequently (and is therefore battery drainer)? That would be weird since it is Google application and one expects some quality there.
I don't know where you're getting the information that the Widget checks data more often than 30 minutes. Just check the interval in the settings.
But if you have to do that - why not use another event except a scheduled interval like display turned on?
After some research I think most likely scenario is this:
Updates of news and weather data from the Internet (news.google.com and other sites) every hour
Frequent updates to the widget (every few seconds) by a service that is probably started on receiving the ACTION_SCREEN_ON intent (which however should not be used lightly as its excessive use by applications and services could significantly slow down the system when turnin screen on).
in numerous places, it is mentioned that app widgets should not get updated often, to minimize power consumption.
But, let's consider that an application is doing something important (such as audio recording) for a short period of time, say 30min.
In this case, is it acceptable to update the widget every second from a service?
How can it be that this would consume so much power?
Please consider that this is different from a widget which would update very often during the whole day.
And in my case, such frequent updates would be meant to allow the user to monitor that the operation is being performed continuously and correctly. It's not for fancy visual effects and such.
I don't see a problem with doing this; if you're keeping the phone awake with a long-running background task (audio recording in this case), then the phone can't sleep anyway. I wouldn't expect updating the widget to have a significant impact on battery use in this case.
Of course, the best thing to do is to run some tests on a real device, and compare battery use with and without widget updates, and make widget update interval a user preference.
The main reason widgets shouldn't update constantly is because of the battery consumption used to get the latest data from a server. Since the device will be on anyway, and the update is local to your data, it shouldn't have an impact that is noticeable.
If you were hitting a server instead of local data every second for that long, you would notice a significant draw on the battery.