Hey So, last call for this is on Friday! Josh, can anyone directly involved send in the -1 to this spec, or do you have to be involved somehow. Otherwise, there's no way that Cordova can implement this on Android, and we'll be stuck with a plugin that has to be divergent.
Joe On Tue, Jun 10, 2014 at 4:27 PM, Josh Soref <jso...@blackberry.com> wrote: > 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).
