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]

http://www.w3.org/2009/dap/track/issues/167

Raised by: Glenn Adams
On product: Battery Status API

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

http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0008.html

[[

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
one)?

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