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

Hi,

On 9.9.2011, at 9.46, 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).

I also do like the last one for the same reasons, but I have one concern in using it and that is the lack of consistency with other similar APIs hanging off of navigator, e.g.:

// both are asynchronous and return void
navigator.getUserMedia(options, success, error);
navigator.geolocation.getCurrentPosition(success, error, options);

Whereas the current design is similar to that of the EventSource.

I'm not sure how big a concern the lack of consistency would be here, given there are many differently behaving get*() methods out there on the web platform (both synchronous and asynchronous, with different order of parameters despite similar names etc.). 

Perhaps this is a non-issue?

-Anssi

Received on Wednesday, 14 September 2011 12:28:34 UTC