4

I have found numerous sources for monitoring battery levels, but none of them describe how to check it at a fixed time interval. Suppose I want to check the battery every n seconds. What is the most efficient way to do this?

Currently, I create a BroadcastReceiver and register it in my service with a filter. I then use a ScheduledExecutor to "fetch" the information from the battery. If I understand what's going on correctly, the BroadcastReceiver I made receives all broadcasts from the battery rather at a dynamic rate as they come in, rather than the constant rate I want to check it at.

It appears that when I create the BroadcastReceiver, it receives an "initial" message with the current info. Would it be more efficient to create a receiver object every so often, receive this initial message, then destroy it every time I want to check it? Or, is there a different way that I haven't thought about?

Sources that I used for monitoring the battery, in case if anybody is interested:

Community
  • 1
  • 1
Brandon Amos
  • 940
  • 1
  • 9
  • 19
  • Isn't the whole point of listening to the ACTION_BATTERY_CHANGED broadcast only being notified about **changes** of the battery charge level? What's the point in figuring out every two minutes that the charge is still the same? – tiguchi Jun 25 '12 at 23:16
  • Yes, correct. If I want to check the battery every 5 minutes and the BroadcastReceiver is receiving something every minute, wouldn't it be better to check it every 5 minutes? These numbers are arbitrary, but the point is that more messages could be sent with the BroadcastReceiver constantly listening. Even if it's not better in my specific implementation, I'm still curious if there's a better way to check. – Brandon Amos Jun 25 '12 at 23:25

1 Answers1

2

Suppose I want to check the battery every n seconds. What is the most efficient way to do this?

Unless n is measured in hundreds or thousands of seconds, you may well be the #1 consumer of battery life. Given your comment, I will assume that you really mean "every n minutes".

Step #1: Set up an AlarmManager schedule to invoke an IntentService every n minutes (preferably not with a _WAKEUP alarm type).

Step #2: In that IntentService, call registerReceiver() with a null BroadcastReceiver and an IntentFilter that is for ACTION_BATTERY_CHANGED. The return value will be the last Intent broadcast for this event.

Step #3: Do something with the data.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Use an inexact repeating alarm so that your activity can be combined with other activities, for which the system is going to wake up anyhow. – Sparky Jun 25 '12 at 23:48
  • Okay, after reading the documentation for registerReceiver, this makes sense. Thanks! Just checking: it would be the same to put this in the run method on my ScheduledExecutorService that I already have rather than creating a new alarm manager, correct? (I'll remember to upvote when I get enough reputation! - I'm putting this here to remind me.) – Brandon Amos Jun 26 '12 at 01:42
  • Wouldn't it be more efficient to spin up a thread that runs in the background and just spends most of its time asleep? It seems like there'd be less overhead in having the thread periodically wake up and check the battery life than in having the OS manage a timer and call back into the app code. – aroth Jun 26 '12 at 01:51
  • @goldenfib: "it would be the same to put this in the run method on my ScheduledExecutorService that I already have rather than creating a new alarm manager, correct?" -- only if you want your users to attack you with task killers and Force Closes (not to mention the subsequent ratings on the Play Store). Please do not have a service running all of the time without adequate justification. That is why I said to use an `IntentService`, so the service can go away between battery checks. – CommonsWare Jun 26 '12 at 10:27
  • @aroth: Efficiency has many metrics. Your solution requires a service to be running constantly, which ties up RAM constantly. Users have voted with task killers, Force Close in Settings, and innumerable blog posts/comments, that they do not like everlasting services in general. The question then becomes: is what you save in battery worth having a subset of your users dislike your app's behavior? – CommonsWare Jun 26 '12 at 10:29