Joe wrote: > After the battery tests, I looked at the battery plugin, and we need to > shelve the battery plugin until we get a new API.
Sounds good to me. > Worse yet, the W3C API proposed is terrible and should never be implemented > on Android. I was involved, but agree. > So, as we currently implement it, we set the battery to listen to the > batteryChange event, > which is used to return the battery level, > which isn't actually a percent but some number that isn't consistent across > Android devices. > This bug has been filed. Awesome. > However, a more serious bug is the fact that every time this is triggered, it > takes about 1% of battery power. This is more or less what I expected (feared, warned about) > I've played with this event in the past on a side project, and it's killed > batteries on my devices in less than an hour. I wish you had been able to send this feedback when I was working on this stuff... > So, the proper way you monitor for battery events is by monitoring for > certain events > by adding an events receiver in the AndroidManifest.xml file, and letting > that fire an > event depending on whether there's a callbackContext assigned to it. > The problem is that we should only monitor certain manifests, > and get the values when those events happen. > We can support getting the value of the battery on demand, > but we should discourage our users from doing this. This was my main point. Roughly I saw: * You can't do anything remotely useful w/ the battery information. You don't know how much time you have before: 1. Your device loses network connectivity 2. Your user drops your device and the battery flies out / the device falls into a body of water 3. Your device panics 4. Your application crashes 5. Your device decides to terminate your application because it needs memory * I expected it to be expensive (and a heisenbug, in that the act of observing [monitoring] it changes it) * The only practical use I've seen for this is to create a battery widget, which was not a good UC in my mind > This brings us to the W3C Battery API: > http://www.w3.org/TR/battery-status/ > To me, this is unimplementable without killing the battery, > since this appears to work similarly to our device API in that we'd have to > populate this on an interval, > and that interval on Android is how fast you want your battery to die. > So, how do we want to approach this? > I have no idea why the W3C wrote a specification that is near impossible to > implement. It was written because "app authors" demanded it. > Thoughts? http://www.w3.org/2005/10/Process-20051014/tr.html#q74 7.1.2 Maturity Levels of the Recommendation Track Candidate Recommendation (CR) A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience. Proposed Recommendation (PR) A Proposed Recommendation is a mature technical report that, after wide review for technical soundness and implementability, W3C has sent to the W3C Advisory Committee for final endorsement. W3C Recommendation (REC) A W3C Recommendation is a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations. Note: W3C Recommendations are similar to the standards published by other organizations. 7.1.3 Maturity Level When Ending Work on a Technical Report Working Group Note A Working Group Note is published by a chartered Working Group to indicate that work has ended on a particular topic. A Working Group MAY publish a Working Group Note with or without its prior publication as a Working Draft. CR is the stage where implementers are supposed to be giving feedback. Put on an implementer hat (Cordova) and send feedback explaining your concerns. Ideally this feedback is precisely what is needed to get this proposal to die as a CR (dead proposals are republished as NOTES with an explanation that people should not use/implement them). I'll be glad to offer support in this area (not wearing my corporate hat).
