On Wed, Jun 11, 2014 at 1:01 PM, Frederico Galvão <frederico.gal...@pontoget.com.br> wrote: > If two other platforms were able to implement this on a satisfactory way, I > don't think this is an issue with the spec per se (although I'm sure a > better spec would help a lot, I agree). And considering there is a native > battery charge tooltip on every Android device, I'd say there is a way to > subscribe to those in a safer way. With that, wouldn't the Android dev > group/bug tracker be a better place for this feedback (to make it easier to > use that safe route)? >
http://developer.android.com/training/monitoring-device-state/battery-monitoring.html http://developer.android.com/reference/android/content/Intent.html#ACTION_BATTERY_CHANGED So, using this, you can tell whether your device is charging and how it's charging, but you can't get numbers without subscribing to the ACTION_BATTERY_CHANGED intent. If you have a receiver for this intent, it will fire constantly, and this will consume battery. Not only that, this is one of the few intents that you can't connect a receiver to using the Android Manifest, because of the fact that it's not intended to be used by any process other than the battery indicator. So, the question is what interval won't kill the battery? Honestly, I don't care about the battery at all unless it's low or critical, and Android already has other actions for that, so I'm fine with this not being triggered unless the battery is actually low. However, this spec requires that we calculate charging and discharging rate as well, which I think is extra information that we don't need. The big problem is that this BatteryManager object has read-only properties that we'd have to pre-populate. I really dislike this, and would like for this plugin to be entirely async if possible. > > 2014-06-11 15:48 GMT-03:00 Marcel Kinard <cmarc...@gmail.com>: > >> And document why the current implementation is not recommended for app >> developers to use, because people tend to use things that are available. >> That’s the short term answer. >> >> The long term answer is to get help from jsoref and others to give >> feedback to the W3C that their spec is unimplementable on the platform that >> is the most popular in the market. I’d like to think that with an API >> alignment, Cordova is the [early] implementor of W3C specs like this, and >> we should be an invaluable proving ground and source of feedback for these >> things. Whether or not the W3C can adjust in a timely manner is another >> question (and not ours to answer), but we should be giving them technical >> feedback on our implementation experience. >> >> On Jun 10, 2014, at 6:54 PM, Brian LeRoux <b...@brian.io> wrote: >> >> > shelve! >> >> > > > -- > > *Frederico Galvão* > > Diretor de Tecnologia > > PontoGet Inovação Web > > > ( +55(62) 8131-5720 > > * www.pontoget.com.br <http://www.pontoget.com/>
