the current draft is treating multiple batteries as a single battery - hence you do not have ability to query different batteries, just the single virtual battery (e.g. all batteries treated as a single battery composed of the multiple batteries). regards, Frederick Frederick Hirsch, Nokia Chair DAP @fjhirsch On Jul 1, 2014, at 5:45 PM, Rick Waldron <waldron.rick@gmail.com> wrote: > > > > On Tue, Jul 1, 2014 at 5:27 PM, Domenic Denicola <domenic@domenicdenicola.com> wrote: > From: 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? > > This is a great point, and a non-normative note would be helpful. My assumption was that it was so you could lazy-load battery-related code, or perhaps that battery information is stored out of process and thus some asynchronous prep-work must be done to make it available. I have no idea though and some help from implementers would be great. > > As implemented in the latest stable Firefox, which is version 30, navigator.battery has the appearance of a pre initialized BatteryManager—though it may just be a synchronous accessor the produces the BatteryManager on [[Get]]. > > The CFC that Mounir linked to says only this "This will allow for less constrained and more efficient current and future implementations." and doesn't provide any supporting cases for this claim. Furthermore, Marcos Caceres mentions multiple batteries in a later message[0], a use case that can't be addressed by this change anyway (which battery does getBattery().then(...) resolve with???). Even multiple batteries exist before the browser loads anything, so it's still unclear why the API needs to be promise-based. > > Rick > > > > > > [0] http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0039.html > >
Received on Tuesday, 1 July 2014 22:15:08 UTC