W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2014

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

From: Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Mon, 04 Aug 2014 19:32:39 +0000
Message-Id: <E1XENzr-0002lA-8l@stuart.w3.org>
To: public-device-apis@w3.org
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:11 UTC