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

Hi,

On 7.9.2011, at 17.10, ext Dominique Hazael-Massieux wrote:

> Le mercredi 07 septembre 2011 à 14:27 +0300, Anssi Kostiainen a écrit :
>> Given the recent insightful discussion on public-device-apis and www-dom mailing lists, I decided to migrate the alternative proposal from its strawman form into an Editor's Draft for better readability:
>>  http://dev.w3.org/2009/dap/system-info/battery-status.html
>> To refer to the previous Editor's Draft, see:
> 
> I like the new approach; I wonder whether we need to allow the creation
> of new batterystatuseventsource, vs defining window.navigator.battery as
> the well-known instance of that interface.

If we use the constructor we can enable the task source silently right after instantiation as suggested by Anne (and as spec'd now). If we do navigator.battery I believe we'd need to keep start() i.e. navigator.battery.start() would need to be explicitly called (to not to cause side-effects) to start firing.

Geolocation folks seem to have thought about using a factory as follows:

  http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0042.html

That way it is more obvious you'll get a singleton, but even if a constructor is used the implementations can still cheat and give you a singleton (like in the playground demo). 

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?

-Anssi

Received on Friday, 9 September 2011 06:02:46 UTC