Re: Feedback about Battery Status Events

Wouldn't it makes sense to treat "no battery" status  uniformly, e.g. as if laptop had the battery removed? I could see having a desktop plugged into a uninterruptible power supply with a battery and a usb connection to report battery status to the desktop, for example... (I know this isn't common but would break the "desktops never have a battery" view).

regards, Frederick

Frederick Hirsch
Nokia



On Oct 18, 2011, at 4:50 PM, ext Mounir Lamouri wrote:

> 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 Wednesday, 19 October 2011 14:30:37 UTC