Re: [battery] Alternative design proposal (was: addEventListener side effects, ordering & boundary crossing ...)

Technically a device can go from:
Corded + no battery (laptop w/ battery removed)
To
Corded + battery (user inserts in preparation for travel)
To
Battery (user unplugs)

If an app inits once (likely), then returning null for the first case would yield bad results for the session lifetime

----- Original Message -----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
Sent: Friday, September 09, 2011 08:15 AM
To: dom@w3.org <dom@w3.org>
Cc: Frederick.Hirsch@nokia.com <Frederick.Hirsch@nokia.com>; anssi.kostiainen@nokia.com <anssi.kostiainen@nokia.com>; public-device-apis@w3.org <public-device-apis@w3.org>; annevk@opera.com <annevk@opera.com>
Subject: Re: [battery] Alternative design proposal (was: addEventListener   side effects, ordering & boundary crossing ...)

+1 for the reasons Dom mentions.

if there is no battery would it make sense for b to be null?

regards, Frederick

Frederick Hirsch
Nokia



On Sep 9, 2011, at 2:46 AM, ext Dominique Hazael-Massieux wrote:

> Le vendredi 09 septembre 2011 à 09:01 +0300, Anssi Kostiainen a écrit :
>> Here's a summary of discussed alternatives:
>> 
>> var b = new BatteryStatusEventSource();
>> b.onbatterystatus = function () {};
>> 
>> navigator.battery.start();
>> navigator.battery.onbatterystatus = function () {};
>> 
>> var b = navigator.getBattery();
>> b.onbatterystatus = function () {};
>> 
>> Which one is your favorite, and why?
> 
> I think the last one is probably my favorite, but mostly for cosmetic
> reason: it doesn't add a constructor (which for a singleton seems
> awkward), and it doesn't need the start() method (which reads weird: it
> feels like you're starting the battery itself).
> 
> Dom
> 
> 
> 



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Friday, 9 September 2011 12:27:57 UTC