shelve!
On Tue, Jun 10, 2014 at 3:35 PM, Joe Bowser <bows...@gmail.com> wrote: > Hey > > After the battery tests, I looked at the battery plugin, and we need > to shelve the battery plugin until we get a new API. Worse yet, the > W3C API proposed is terrible and should never be implemented on > Android. > > 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. > > However, a more serious bug is the fact that every time this is > triggered, it takes about 1% of battery power. 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. > > 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 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. > > Thoughts? > > Joe >
