incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: State of battery API
Date Fri, 20 Jan 2012 21:32:55 GMT
+1

I think we should leave it be too. Would rather we focus our
synergies[1] on some of the other projects in the roadmap [2].

[1] I'm totally getting the hang of this big company thing!
[2] http://wiki.apache.org/cordova/RoadmapProjects


On Fri, Jan 20, 2012 at 12:50 PM, Simon MacDonald
<simon.macdonald@gmail.com> wrote:
> UPON FUTHER REVIEW...
>
> Okay in the hour and a bit since our call ended I've researched the
> new battery status API and did a quick implementation on Android and
> here are the pros and cons:
>
> Pros
> * Implemented the latest Battery specification according to W3C.
>
> Cons
> * Code is constantly running in the background to check for battery
> changes. It probably doesn't use much cpu cycles but it is wasteful
> for app that don't need battery events.
> * It removes the ability to disable the battery listener short of
> removing it from the plugins list.
> * The old battery spec sends events with level and isPlugged. The new
> battery spec keeps a set of properties at navigator.battery including
> level, charging, chargingTime and dischargingTime. level == level and
> isPlugged == charging.
> * For the two new properties chargingTime and dischargingTime there is
> no API on Android, BB, iOS or WP7 to determine those values. So, we'd
> have to estimate these values.
>
> It is my opinion that we do not make any changes to the current
> battery code in PhoneGap and we wait until the spec finalizes. The
> battery spec has been through many changes and it is possible that it
> may radically change once again.
>
> Do we need to vote on this?
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
>
> On Wed, Jan 18, 2012 at 2:14 PM, Drew Walters <deedubbu@gmail.com> wrote:
>> It could be done in a hack in the current code by modifying the code
>> that parses plugins.xml to automatically load and start battery
>> monitoring if the battery plugin is found.  Is that what you were
>> thinking Simon?
>>
>> Problem I have with basing it off of plugins.xml is that the
>> application may only want battery monitoring for a limited time and
>> not always on.  With the latest spec though I don't see another way
>> around it.
>>
>> On Wed, Jan 18, 2012 at 1:03 PM, Filip Maj <fil@adobe.com> wrote:
>>>
>>>>I think the best way to handle the battery drain from constantly
>>>>monitoring the battery (that irony right?) is for us to handle it in
>>>>the configuration files. If application developer doesn't want to
>>>>monitor the battery level, and that is a pretty specific piece of
>>>>functionality, that they should remove the line from plugins.xml,
>>>>plist, etc.
>>>
>>> ... And so discussion turns back to plugins. :)
>>>
>>> That's predicated on the unified JS project and figuring out a (probably)
>>> package.json-based config/description file for plugins. Worth discussion
>>> in its own thread, I think.
>>>

Mime
View raw message