+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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. >>>
