Intent to Implement: Battery Status API

[Venkateswaran, Srinivasa Ragavan]

Contact emails:

srinivasa.ragav...@intel.com

Spec

https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html

Summary

Add Battery status support, re use much of the existing code and revisit every concern/design/issue with the previous implementation.

http://codereview.chromium.org/10024013/

https://bugs.webkit.org/show_bug.cgi?id=90538

The current implementation take a status-per-view model where as I would like to make it a single client interface on the platform and multiplexing to be on the web core level as suggested over the discussions on the bug. There were a few comments on the spec as well and I expect to

have good discussion on this and want to take it forward in the right direction.

Motivation

The Battery Status API defines a means for developers to determine the battery status of the hosting device to make decisions to whether defer or scale back an operation. It is highly useful in cases of timer based operations like repeated checking for new emails on a timer etc.

Compatibility Risk

Low.

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=122593

Link to entry on the feature dashboard

http://www.chromestatus.com/features/4537134732017664

Requesting approval to ship?

No.

Thanks,

-Srini.

[Peter Beverloo]

+blink-dev, chromium-dev to bcc: since this concerns a Blink feature.

Hi Srini,

Thanks for your interest in implementing this!  Please be sure to read this issue which contains quite a bit of discussion on the Battery Status API:

    https://code.google.com/p/chromium/issues/detail?id=122593

Comment 50 has some open questions on the API itself, and I'd be very interested in hearing your take on them.

    1) What real-life use-cases do you expect the Battery Status API to address?

It's a nice-to-have, but most of the use-cases are debatable or ideological at best.  I have doubts about whether anyone would *actually* use them, especially since browsers already implement some throttling behavior -- albeit based on the Page Visibility API.

    2) The API specifies a number of properties which have to be synchronously available.

What is your plan for implementing support for them?  Using synchronous IPCs isn't a very nice solution, and I don't think it's worth continuously monitoring battery status and preemptively informing the renderer about it given the (expected?) low usage.  Specifically for Android, supporting the {chargingTime, dischargingTime} properties will be challenging as well.

Thanks,

Peter

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Chris Harrelson]

On Mon, Jan 6, 2014 at 9:27 AM, Peter Beverloo <pe...@chromium.org> wrote:

+blink-dev, chromium-dev to bcc: since this concerns a Blink feature.

Hi Srini,

Thanks for your interest in implementing this!  Please be sure to read this issue which contains quite a bit of discussion on the Battery Status API:

    https://code.google.com/p/chromium/issues/detail?id=122593

Comment 50 has some open questions on the API itself, and I'd be very interested in hearing your take on them.

    1) What real-life use-cases do you expect the Battery Status API to address?

It's a nice-to-have, but most of the use-cases are debatable or ideological at best.  I have doubts about whether anyone would *actually* use them, especially since browsers already implement some throttling behavior -- albeit based on the Page Visibility API.

This is an interesting question. Native Android and iOS apps already have such an API. Does anyone know what the primary use cases of those apps are in the wild?

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alex Russell]

This api needs promises badly. We should not implement as-is.

[Elliott Sprehn]

Why does this need promises? These aren't one time events, these happen repeatedly:

                attribute EventHandler        onchargingchange;

                attribute EventHandler        onchargingtimechange;

                attribute EventHandler        ondischargingtimechange;

                attribute EventHandler        onlevelchange;

You shouldn't need to keep getting a new Promise each time you want to get the next value.

It does seem like there should just be one onchange event though and you should deal with looking at the values you're interested in when they change. This is just like the page visibility API. That shouldn't be promises either.

How does onlevelchange work though? We don't want to fire an event for ever 1% of battery discharged, that just means the page never sleeps.

[Elliott Sprehn]

More specifically this API really wants:

navigator.onbatterystatechanged = function(ChargeEvent e) {

  e.chargeLevel // etc.

  e.chargerType // "battery" or ...

};

and we only need to notify the renderer of state changes as often as we see fit (ex. every 10% or even less often). The static properties shouldn't exist at all beyond the arguments to the event.

[Philip Rogers]

On Mon, Jan 6, 2014 at 4:31 PM, Elliott Sprehn <esp...@chromium.org> wrote:

How does onlevelchange work though? We don't want to fire an event for ever 1% of battery discharged, that just means the page never sleeps.

On a full battery this would only be 100 events. 100 seems like it would be in the noise compared to all of the extra mouse events we throw on mobile.

[Elliott Sprehn]

On Mon, Jan 6, 2014 at 4:36 PM, Philip Rogers <p...@chromium.org> wrote:

On Mon, Jan 6, 2014 at 4:31 PM, Elliott Sprehn <esp...@chromium.org> wrote:

How does onlevelchange work though? We don't want to fire an event for ever 1% of battery discharged, that just means the page never sleeps.

On a full battery this would only be 100 events. 100 seems like it would be in the noise compared to all of the extra mouse events we throw on mobile.

It seems Android doesn't actually support getting notified of battery changes all the time without polling. It will send broadcast intents, but it doesn't send them for every 1%. iOS supports a similar model and will only notify you once per minute of the battery state.

I think it's fine to send events about this, we just probably will only get 5% resolution. I also think we should fix the API to not have one event per property and instead have a single change event. That's how the native APIs work too.

[Venkateswaran, Srinivasa Ragavan]

Hi Peter,

On Mon, Jan 6, 2014 at 10:57 PM, Peter Beverloo <pe...@chromium.org> wrote:

+blink-dev, chromium-dev to bcc: since this concerns a Blink feature.

Hi Srini,

Thanks for your interest in implementing this!  Please be sure to read this issue which contains quite a bit of discussion on the Battery Status API:

    https://code.google.com/p/chromium/issues/detail?id=122593

Comment 50 has some open questions on the API itself, and I'd be very interested in hearing your take on them.

    1) What real-life use-cases do you expect the Battery Status API to address?

It's a nice-to-have, but most of the use-cases are debatable or ideological at best.  I have doubts about whether anyone would *actually* use them, especially since browsers already implement some throttling behavior -- albeit based on the Page Visibility API.

Real-life cases are any situations that needs periodic refreshes like checking for new emails or refreshing a state of an object/file from the server etc. I'm not debating if any one would actually use them, because there could be alternate solutions available in the lack of a solution like designing the page/app with better knowledge of the system's battery status. 

    2) The API specifies a number of properties which have to be synchronously available.

What is your plan for implementing support for them?  Using synchronous IPCs isn't a very nice solution, and I don't think it's worth continuously monitoring battery status and preemptively informing the renderer about it given the (expected?) low usage.  Specifically for Android, supporting the {chargingTime, dischargingTime} properties will be challenging as well.

I think on the bug Anssi (the API author) replied but it didn't get any further. The attribute fetching has to be done in a way of callback and not synchronous (There was a similar suggestion from tony also iirc). About the number of events/continuous, Elliott Sprehn's single event (ChargeEvent) is a very good idea to take the discussion . The API leaves the duration of events firing to implementation. IOS's max-one event per minute is a good idea and if required it can be further tuned to the need.

 

Thanks,

-Srini.

[Kenneth Rohde Christiansen]

I am cc'ing the editor Anssi, as this is already a Candidate
Recommendation: http://www.w3.org/TR/battery-status/

Cheers
Kenneth

--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆

[Robin Berjon]

On 07/01/2014 01:31 , Elliott Sprehn wrote:
> It does seem like there should just be one onchange event though and you
> should deal with looking at the values you're interested in when they
> change. This is just like the page visibility API. That shouldn't be
> promises either.

IIRC the events are more granular so as to help the implementation fire
fewer of them, thereby making it easier to support sleeping. For
instance if you're only interested in charging status you don't get
notified for every level change.

> How does onlevelchange work though? We don't want to fire an event for
> ever 1% of battery discharged, that just means the page never sleeps.

The specification explicitly allows the implementation to decide how
often to emit events here.

--
Robin Berjon - http://berjon.com/ - @robinberjon

[Peter Beverloo]

On Tue, Jan 7, 2014 at 12:02 PM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

I am cc'ing the editor Anssi, as this is already a Candidate
Recommendation: http://www.w3.org/TR/battery-status/

I don't think that's very relevant in this case -- the spec needs to implementations in order to advance towards a PR/R, and currently there is only major browser shipping it.  While it's unfortunate that Mozilla already unprefixed their implementation in Firefox 16, it will still be possible to make changes without forcing them to (significantly) break backwards compatibility. 

On Tue, Jan 7, 2014 at 12:31 AM, Elliott Sprehn <esp...@chromium.org> wrote:

How does onlevelchange work though? We don't want to fire an event for ever 1% of battery discharged, that just means the page never sleeps.

For mobile devices (assuming ~20 hours of battery life), this would yield an event every 12 minutes. For a laptop (assuming ~4 hours of battery life), it would yield an event every 2:30 minutes. I don't think that's unreasonable.

Peter

[Kostiainen, Anssi]

Hi Peter, Srini,

On 07 Jan 2014, at 07:58, Venkateswaran, Srinivasa Ragavan <srinivasa.ragav...@intel.com> wrote:

> On Mon, Jan 6, 2014 at 10:57 PM, Peter Beverloo <pe...@chromium.org> wrote:
> +blink-dev, chromium-dev to bcc: since this concerns a Blink feature.
>

> Thanks for your interest in implementing this! Please be sure to read this issue which contains quite a bit of discussion on the Battery Status API:
> https://code.google.com/p/chromium/issues/detail?id=122593

Srini, thanks for starting the thread. And thanks Peter for raising the issues.

> Comment 50 has some open questions on the API itself, and I'd be very interested in hearing your take on them.

I addressed the API design concerns in #56 as per the discussion we had in W3C group while spec’ing this API.

> 1) What real-life use-cases do you expect the Battery Status API to address?
>
> It's a nice-to-have, but most of the use-cases are debatable or ideological at best. I have doubts about whether anyone would *actually* use them, especially since browsers already implement some throttling behavior -- albeit based on the Page Visibility API.

While throttling based on the page visibility works for some use cases, there are real-life use cases that do not depend on the visibility state. For example:

A web-based video player informs the user, that in order to watch a 60 minute long video completely she may need to plug her device in, as the battery only lasts for ~30 minutes. Or a user wants to transcode a lengthy video she has captured and upload it to the cloud-based video service. The transcode takes 30 minutes to complete but the battery only lasts for ~20 minutes. Generally, any long-running operation whose [estimated] execution time is known in advance, and an estimation whether the operation can be completed before the battery runs out is useful information.

* Ensure a software update can be downloaded and installed or a large file uploaded while on battery power. Generally, any operation that runs for a long period of time and/or consumes the battery significantly, and cannot be disrupted while running. Any operation that should commence only, if the device is plugged in.

* Fetch the big mail attachments over the network only if plugged in or enough battery left. Or poll the network less often for new mails if on battery. Do not use whiz-bang effects or high-resolution textures in a game if on battery. Generally, adapt the application’s behaviour according to the power profile.

> Real-life cases are any situations that needs periodic refreshes like checking for new emails or refreshing a state of an object/file from the server etc. I'm not debating if any one would actually use them, because there could be alternate solutions available in the lack of a solution like designing the page/app with better knowledge of the system's battery status.

Ditto.

> 2) The API specifies a number of properties which have to be synchronously available.
>
> What is your plan for implementing support for them? Using synchronous IPCs isn't a very nice solution, and I don't think it's worth continuously monitoring battery status and preemptively informing the renderer about it given the (expected?) low usage. Specifically for Android, supporting the {chargingTime, dischargingTime} properties will be challenging as well.

This particular concern was raised when this spec was written, and thus the spec has that particular edge case covered:

[[

The chargingTime attribute must be set to 0, if [...] the implementation is unable to report the remaining charging time.

[. ..]

The dischargingTime attribute must be set to the value positive Infinity, if [...] the implementation is unable to report the remaining discharging time.

]]

> I think on the bug Anssi (the API author) replied but it didn't get any further. The attribute fetching has to be done in a way of callback and not synchronous (There was a similar suggestion from tony also iirc). About the number of events/continuous, Elliott Sprehn's single event (ChargeEvent) is a very good idea to take the discussion .

An unprefixed implementation of this API has shipped in Firefox since v16 (Oct 2012) on Android, Windows, Linux, and on OS X since v18. While a single event proposal sounds interesting, my recommendation is we do not change the API in a way that breaks backward compatibility. Furthermore, the spec reached its Candidate Rec maturity level in May 2012.

> The API leaves the duration of events firing to implementation. IOS's max-one event per minute is a good idea and if required it can be further tuned to the need.

This is good implementation approach. Each implementation can choose the duration, and also heuristics for choosing the duration. The duration may also be dynamic and change as needed. For example, it may make sense to fire less often if the battery is nearly full. The spec has the following note on purpose to meet the requirements of various platforms:

[[

The definition of how often the chargingtimechange, dischargingtimechange, and levelchange events are fired is left to the implementation.

]]

Thanks,

-Anssi

[Kostiainen, Anssi]

On 07 Jan 2014, at 14:28, Robin Berjon <robin....@gmail.com> wrote:

> On 07/01/2014 01:31 , Elliott Sprehn wrote:
>> It does seem like there should just be one onchange event though and you
>> should deal with looking at the values you're interested in when they
>> change. This is just like the page visibility API. That shouldn't be
>> promises either.
>
> IIRC the events are more granular so as to help the implementation fire fewer of them, thereby making it easier to support sleeping. For instance if you're only interested in charging status you don't get notified for every level change.

As the editor of the spec, I can confirm, that this was indeed part of the rationale for the design discussed at the time the spec was written.

>> How does onlevelchange work though? We don't want to fire an event for
>> ever 1% of battery discharged, that just means the page never sleeps.
>
> The specification explicitly allows the implementation to decide how often to emit events here.

Yes, this is an implementation detail on purpose.

Thanks,

-Anssi

[Alexis Menard]

Hi,

On Mon, Jan 6, 2014 at 2:27 PM, Peter Beverloo <pe...@chromium.org> wrote:

+blink-dev, chromium-dev to bcc: since this concerns a Blink feature.

Hi Srini,

Thanks for your interest in implementing this!  Please be sure to read this issue which contains quite a bit of discussion on the Battery Status API:

    https://code.google.com/p/chromium/issues/detail?id=122593

Comment 50 has some open questions on the API itself, and I'd be very interested in hearing your take on them.

    1) What real-life use-cases do you expect the Battery Status API to address?

It's a nice-to-have, but most of the use-cases are debatable or ideological at best.  I have doubts about whether anyone would *actually* use them, especially since browsers already implement some throttling behavior -- albeit based on the Page Visibility API.

If native offers it it's because it's needed (not that this doesn't necessarily apply to everything). Android offers it with Java, iOS offers it with Objective C and I believe all desktop operating systems offer it.

Now keep in mind that not all web apps/websites are meant to be run in a browser. It exists OSes (released!) entirely based on the web platform and you need this kind of features.

Say you're implementing the dialog that launch the OTA of the phone and before you launch the OTA process you want to verify the battery level. Say you're implementing the brightness setting dialog and you want to access the battery status to help the user setting it correctly (you may want to "lock" the slider if the battery is low). 

Other use case. Say I write an app for these OSes that help managing my battery (there are plenty on iOS and Android stores) that for example switch on or off the 3G/wifi signals and so forth. How I would code that with the web platform if I don't have the battery information?

These are just example coming in my mind but there are probably more.

Remember that the Chromium stack is not just shipped in Chrome, Chrome for Android and Chrome OS. Beside OSes based on the web platform, I know an HTML5 app launcher that has a purpose of creating full fledged web apps (not inside the browser) that can compete with the native offering both in terms of performance and features.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Miguel Garcia]

> Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
> Yes

Assuming the issues with the spec itself are cleared will you be
providing implementations for all platforms? or are you starting with
a subset of them initially? If the API is finally cleared to go I'd
like to discuss the android support on a parallel thread (in
chromium-dev perhaps unless people think it's too noisy).

[Venkateswaran, Srinivasa Ragavan]

On Wed, Jan 8, 2014 at 2:44 PM, Miguel Garcia <mig...@chromium.org> wrote:

> Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
> Yes

Assuming the issues with the spec itself are cleared will you be
providing implementations for all platforms? or are you starting with
a subset of them initially? If the API is finally cleared to go I'd
like to discuss the android support on a parallel thread (in
chromium-dev perhaps unless people think it's too noisy).

Of course, I want to start with a subset (just to say, may be Linux/Mac first ) and over time go over the complete set. I'd welcome if there is additional help to make this happen in parallel. And to say I'd be interested to hear about the android support may be in a separate thread once we have the clearance.

Thanks,

-Srini

[Venkateswaran, Srinivasa Ragavan]

Hi,

On Tue, Jan 7, 2014 at 7:02 PM, Kostiainen, Anssi <anssi.ko...@intel.com> wrote:

Hi Peter, Srini,

On 07 Jan 2014, at 07:58, Venkateswaran, Srinivasa Ragavan <srinivasa.ragav...@intel.com> wrote:

> On Mon, Jan 6, 2014 at 10:57 PM, Peter Beverloo <pe...@chromium.org> wrote:
> +blink-dev, chromium-dev to bcc: since this concerns a Blink feature.
>

> Thanks for your interest in implementing this!  Please be sure to read this issue which contains quite a bit of discussion on the Battery Status API:
>     https://code.google.com/p/chromium/issues/detail?id=122593

Srini, thanks for starting the thread. And thanks Peter for raising the issues.

Thx Anssi for joining and replying to queries on the list. Sorry for creating noise, I wanted to see if there are any other important concerns/issues around this or else I'd like to go ahead to try it and see.

Thanks,

-Srini.

[Venkateswaran, Srinivasa Ragavan]

On Tue, Jan 14, 2014 at 4:32 PM, Venkateswaran, Srinivasa Ragavan <srinivasa.ragav...@intel.com> wrote:

Hi,

On Tue, Jan 7, 2014 at 7:02 PM, Kostiainen, Anssi <anssi.ko...@intel.com> wrote:

Hi Peter, Srini,

On 07 Jan 2014, at 07:58, Venkateswaran, Srinivasa Ragavan <srinivasa.ragav...@intel.com> wrote:

> On Mon, Jan 6, 2014 at 10:57 PM, Peter Beverloo <pe...@chromium.org> wrote:
> +blink-dev, chromium-dev to bcc: since this concerns a Blink feature.
>

> Thanks for your interest in implementing this!  Please be sure to read this issue which contains quite a bit of discussion on the Battery Status API:
>     https://code.google.com/p/chromium/issues/detail?id=122593

Srini, thanks for starting the thread. And thanks Peter for raising the issues.

Thx Anssi for joining and replying to queries on the list. Sorry for creating noise, I wanted to see if there are any other important concerns/issues around this or else I'd like to go ahead to try it and see.

It could be a stupid question. But I wanted to know whom I should add as reviewers to review the blink part and the chromium part of the patch and the API in general.

Thanks,

-Srini.

[Tim Volodine]

FYI, To make sure we are on the same page.

Srini has made some good progress on the Blink side of the API. I am currently investigating the best way to implement this in chrome, see design doc. As a first step will provide implementation for Android.

In parallel we are discussing the possibility of making this API completely asynchronous to avoid any potentially blocking calls like navigator.battery.level.

----------------------------------------------------

Intent to implement Battery Status API in chrome

(in addition to the intent already mentioned in the thread)

Contact emails:

timvo...@chromium.org

OWP team london

Spec:

http://www.w3.org/TR/battery-status/

Design doc:

https://docs.google.com/a/google.com/document/d/1o4ycLCw3VKdUlPexRjMyK9VzDhLTbMvnUkG7ykEWZSM/edit?usp=sharing

Compatibility Risk:

Already shipped in Firefox.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes (Android first, initially behind a flag).

Requesting Approval to Ship:

No

----------------------------------------------------

[Kostiainen, Anssi]

Hi Tim,

On 11 Apr 2014, at 14:20, Tim Volodine <timvo...@google.com<mailto:timvo...@google.com>> wrote:

FYI, To make sure we are on the same page.

Srini has made some good progress on the Blink side of the API. I am currently investigating the best way to implement this in chrome, see design doc<https://docs.google.com/a/google.com/document/d/1o4ycLCw3VKdUlPexRjMyK9VzDhLTbMvnUkG7ykEWZSM/edit?usp=sharing>. As a first step will provide implementation for Android.

Thanks for your help with the Chrome side implementation. Would it be possible to share the design doc publicly?

Thanks,

-Anssi

[Tim Volodine]

Hi Anssi,

It appears it's not possible to open it up to everybody, so I am adding interested people on a case-by-case basis. I've shared it with you.

Tim

[Miguel Garcia]

Tim, can you move the document to a new one created in the
chromium.org domain so it can be shared publicly?

Thanks

Miguel

On Wed, Apr 23, 2014 at 7:23 PM, 'Tim Volodine
<timvo...@google.com>' via blink-dev <blin...@chromium.org>
wrote:

[Tim Volodine]

ok, I've moved the document to a chromium.org account so it's world-commentable now (new doc). A bit of comments were lost in the process though.

Tim