DAP-ISSUE-167: Should Promises be used in Battery API [Battery Status API]

DAP-ISSUE-167: Should Promises be used in Battery API [Battery Status API]


Raised by: Glenn Adams
On product: Battery Status API

Raised on behalf of Rick Waldron <waldron.rick@gmail.com> 



Is there a design history document or thread that explains the reasoning
that lead to an API that returns a promise here? The battery exists before
the browser ever loads a site and its JavaScript files, so why does
`getBattery` need to be a promise? The "latest published" Battery Status
API spec makes more sense: navigator.battery is always a single instance of
BatteryManager that exists as specified here:
http://www.w3.org/TR/battery-status/#navigatorbattery-interface . Why does
it need to be "requested" via a "getBattery" API that itself doesn't return
a BatteryManager object, but promises to produce one (and always the same

If it's always the same BatteryManager instance, it's not clear how this
API usage:

navigator.getBattery().then(function(battery) {
  battery.onlevelchange = function() {
    console.log("level changed!");

... is at all superior to this:

navigator.battery.onlevelchange = function() {
    console.log("level changed!");

Even if the argument is that not all code needs or wants to allocate the
BatteryManager, then the solution is simply to make `navigator.battery` an
accessor to the BatteryManager instance.


Received on Monday, 4 August 2014 19:32:40 UTC