On Wed, Jun 11, 2014 at 2:54 PM, Frederico Galvão
<frederico.gal...@pontoget.com.br> wrote:
> It may be a tad offtopic, but does that mean that every app/widged on
> Android suffer from the same issues, including the native ones? It's almost
> hard to believe, if it is so.
>
Yes and no. Nobody registers a receiver to ACTION_BATTERY_CHANGED,
because this will kill your battery. You can get the percentage any
time by doing this:
//It's null, so that we don't drain the battery every time we do this!
Intent batteryIntent = mCtx.registerReceiver(null, new
IntentFilter(Intent.ACTION_BATTERY_CHANGED));
int level = batteryIntent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);
int scale = batteryIntent.getIntExtra(BatteryManager.EXTRA_SCALE, 100);
However, if we were to listen to when the Battery actually changes,
it'd be this code, which is bad. Let's assume ChargeNotifier is a
BroadcastReceiver:
batteryUpdateNotifier = new ChargeNotifier();
IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
registerReceiver(batteryUpdateNotifier, ifilter);
So, what most widgets do is listen to a receive event and grab the
battery levels once. Now if you keep registering receivers, you'll
lose battery like you do every operation, the question is what would
be acceptable? I honestly think that only when the battery is low and
critical. In fact, I don't care what percentage it is, and
BATTERY_LOW is good enough for me. I also don't care about mAh rates
of charging. I don't know why these extra attributes are added to the
spec when we shouldn't be pulling the level anyway.
>
> 2014-06-11 17:38 GMT-03:00 Joe Bowser <bows...@gmail.com>:
>
>> Just wanting to throw this out there, because I'm sure people are
>> wondering how I figured this out:
>>
>> https://github.com/infil00p/ChargeNotifier
>>
>> Here's some code for a Charge Notification service in Android. When
>> the battery is low, it does a post to the CouchDB instance. When I
>> did the first run, I discovered that if I left the tablets running
>> this code, they would be dead or near dead in an hour or less. Since
>> the point of the app was to get notifications to prevent devices from
>> dying (and being unusable), this was a disaster for the project.
>> After a while, I decided to shelve the project. However, given that
>> our current battery charger code drains the battery, the experience
>> here is coming in handy.
>>
>> On Wed, Jun 11, 2014 at 1:23 PM, Joe Bowser <bows...@gmail.com> wrote:
>> > On Wed, Jun 11, 2014 at 1:01 PM, Frederico Galvão
>> > <frederico.gal...@pontoget.com.br> wrote:
>> >> If two other platforms were able to implement this on a satisfactory
>> way, I
>> >> don't think this is an issue with the spec per se (although I'm sure a
>> >> better spec would help a lot, I agree). And considering there is a
>> native
>> >> battery charge tooltip on every Android device, I'd say there is a way
>> to
>> >> subscribe to those in a safer way. With that, wouldn't the Android dev
>> >> group/bug tracker be a better place for this feedback (to make it
>> easier to
>> >> use that safe route)?
>> >>
>> >
>> >
>> http://developer.android.com/training/monitoring-device-state/battery-monitoring.html
>> >
>> http://developer.android.com/reference/android/content/Intent.html#ACTION_BATTERY_CHANGED
>> >
>> > So, using this, you can tell whether your device is charging and how
>> > it's charging, but you can't get numbers without subscribing to the
>> > ACTION_BATTERY_CHANGED intent. If you have a receiver for this
>> > intent, it will fire constantly, and this will consume battery. Not
>> > only that, this is one of the few intents that you can't connect a
>> > receiver to using the Android Manifest, because of the fact that it's
>> > not intended to be used by any process other than the
>> > battery indicator.
>> >
>> > So, the question is what interval won't kill the battery? Honestly, I
>> > don't care about the battery at all unless it's low or critical, and
>> > Android already has other actions for that, so I'm fine with this not
>> > being triggered unless the battery is actually low. However, this
>> > spec requires that we calculate charging and discharging rate as well,
>> > which I think is extra information that we don't need.
>> >
>> > The big problem is that this BatteryManager object has read-only
>> > properties that we'd have to pre-populate. I really dislike this, and
>> > would like for this plugin to be entirely async if possible.
>> >
>> >>
>> >> 2014-06-11 15:48 GMT-03:00 Marcel Kinard <cmarc...@gmail.com>:
>> >>
>> >>> And document why the current implementation is not recommended for app
>> >>> developers to use, because people tend to use things that are
>> available.
>> >>> That’s the short term answer.
>> >>>
>> >>> The long term answer is to get help from jsoref and others to give
>> >>> feedback to the W3C that their spec is unimplementable on the platform
>> that
>> >>> is the most popular in the market. I’d like to think that with an API
>> >>> alignment, Cordova is the [early] implementor of W3C specs like this,
>> and
>> >>> we should be an invaluable proving ground and source of feedback for
>> these
>> >>> things. Whether or not the W3C can adjust in a timely manner is another
>> >>> question (and not ours to answer), but we should be giving them
>> technical
>> >>> feedback on our implementation experience.
>> >>>
>> >>> On Jun 10, 2014, at 6:54 PM, Brian LeRoux <b...@brian.io> wrote:
>> >>>
>> >>> > shelve!
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> *Frederico Galvão*
>> >>
>> >> Diretor de Tecnologia
>> >>
>> >> PontoGet Inovação Web
>> >>
>> >>
>> >> ( +55(62) 8131-5720
>> >>
>> >> * www.pontoget.com.br <http://www.pontoget.com/>
>>
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
