Re: Feedback about Battery Status Events

On 10/18/2011 04:06 PM, Anssi Kostiainen 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.

I don't think there is any use case for bubbling. The event shouldn't 
bubble and shouldn't be cancellable.

>>> Returning null was discussed starting at [4]. Hot plugging was the main argument against returning null, it was also argued that some information about the battery should be always returned even if there's no battery (Robin may want to elaborate on that one?).
>>
>> If we do not return null when there is no battery (which I think makes sense), we should probably say that the battery is fully charged, and charging when the status is requested.
>> One downside here is we wouldn't be able to know if the device is currently using a battery or is only plugged. That information wouldn't be useful for most websites but that would be an issue if we want to build an API useful in a web as a platform point of view. Maybe we could add a "nbBatteries" attribute but in that case, we might increase fingerprinting issues.
>
> What do you mean by 'nbBatteries'?
>
> Based on what you and Jonas say, it sounds like it makes sense to set 'level' to 100 and 'charging' to true if there's no battery, similarly to uninitialized state discussed above.

'batteriesCount' if you prefer. That would return the number of 
batteries currently in the device. 0 if there is no battery (like in a 
desktop, 1 for most laptops and phones, 2+ for weird devices or maybe 
future devices?).
Using level=1 and charging=true when there is no battery fixes one use 
case: if the device has no battery, the web apps are going to provide 
full content as if the battery was full.
However, it doesn't fix another use case: showing a nice UI for the 
battery. If I'm using a desktop I do not want to see a battery icon 
telling me my battery is full. Same thing if I'm using my laptop without 
battery.

I don't know if nbBatteries/batteriesCount would be the best way to 
fulfill this use case. We probably don't care that much if the device 
has more than one battery and it would increase fingerprinting issues. 
But sure thing is we should think about it.

>> 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.

I don't think we should block adding the remaining time just because 
Android or iOS doesn't provide a direct API to get it. They obviously do 
not want to expose this given there is no technical limitation. For 
example, Android is using uevent which exposes the current power usage 
and the remaining power. Based on that, knowing the remaining time is 
pretty straightforward.
Anyhow, guessing the remaining time wouldn't be hard to implement even 
if the information isn't present: implementations could just check the 
level every time it is updated and update the remaining time 
accordingly. If the level has enough precision and is often updated, the 
precision shouldn't be bad.

>> Ideas and feedback would be more than welcome here :)
>
> Keeping low and critical statuses is a compromise for the lack of time remaining. If we add time remaining those could be dropped.

We should try to do that! :)

In addition, should we use .state with state being "charging", 
"discharging", "full" and "unknown" instead of just a boolean telling us 
if the battery is currently charging or not?
I'm wondering because it seems that most API provide at least those four 
states but I'm not really sure what would be the use cases. "unknown" 
could be for errors or uninitialized batteries but I'm not sure what are 
the use cases for "full".
Any thoughts?

Thanks,
--
Mounir

Received on Tuesday, 18 October 2011 20:50:39 UTC