Re: Feedback about Battery Status Events

On Tue, Oct 18, 2011 at 7:06 AM, Anssi Kostiainen
<anssi.kostiainen@nokia.com> wrote:
>>> I like your proposal's clearly named *change events (should they be prefixed with battery, e.g. statuschange is a rather generic name for an event?).
>>
>> The events are fired on the BatteryManager object. It doesn't seem useful to prefix those events with "battery" then.
>
> If the *change events do not bubble then more terse names are better. But if we want to have them bubble then wouldn't this be valid, but a bit ambiguous:
>
> window.addEventListener('levelchange', function () {}, false);
>
> Are there any use cases for bubbling? If bubbling is not needed then your proposal sounds good to me.

So note that we shouldn't really talk about bubbling vs. not bubbling.
Instead we should talk about propagation path. The reason is that
*all* events have a capture phase, which follows the propagation path.
The bubbling events just follow that propagation path the other
direction. So the question is if the window object should be in the
propagation path for events fired at the battery event.

The main reason for having propagation paths through an object is to
allow event listeners on that object to observe events fired at
multiple objects. So for example you can listen to "click" events on
the Document to observe "click" events fired at any Node in that
document.

However here there's only one battery object, so I can't think of any
reason to listen on the window object rather than directly on the
battery object.

So I would say that there's no reason to let the events propagate
anywhere other than just the battery object. This is similar to for
example XHR, EventSource, WebSocket and FileReader.

>> Knowing if the battery is low based on the power consumption is reflected in the remaining time. We should probably add a 'remaining' attribute to BatteryManager that would return the remaining time until the battery is charged/discharged.
>
> We looked into this, and it appeared time remaining is not supported on all relevant platforms:
>
>  http://lists.w3.org/Archives/Public/public-device-apis/2011May/0043.html
>
> It looks like most of the open issues would be addressed if the remaining time would be there (or if the level would be bound to the remaining time, i.e. level = 100 (cur_battery_time / max_battery_time)).
>
> I'm wondering if we could have it in the spec even if not all the relevant platforms support it. How about we make it optional and make sure the API is still useful if it's not present? We did discuss this and agreed to drop it but perhaps we need to reconsider that.

It seems like this can be generally estimated by the implementation
even if the underlying platform doesn't support it. Simply measure how
quickly the battery level is decreasing and project from there. That's
what I would expect the OS to do anyway.

/ Jonas

Received on Saturday, 22 October 2011 02:13:16 UTC