Re: [battery] addEventListener side effects, ordering & boundary crossing of battery{low, critical}, window.on*

On , Anssi Kostiainen <anssi.kostiainen@nokia.com> wrote:

> Hi,
>
> On 2.9.2011, at 12.35, ext Anne van Kesteren wrote:
>
>> On Thu, 01 Sep 2011 14:19:30 +0200, Anssi Kostiainen  
>> <anssi.kostiainen@nokia.com> wrote:
>>> All - Would you like the working group to make progress based on this  
>>> alternative proposal instead of the current Editor's Draft? Any  
>>> comments, bug fixes etc. are welcome.
>>
>> If the events are dispatched asynchronously you do not need a start()  
>> method as far as I can tell. You can just start the events the moment  
>> you construct BatteryStatusEventSource(). Since they are dispatched  
>> from a task queue you should have time to add event listeners in the  
>> same task you construct the object.
>
> Good point. That would simplify things and make the behavior between  
> addEventListener() and onbattery* event handlers more consistent.
>
> I guess keeping stop() makes sense so that you do not need to rely on  
> garbage collection if you want to stop firing events. We'd still need to  
> specify what happens when GC kicks in (discard tasks queued etc.), and  
> in fact, invoking stop() would essentially do the same but act  
> consistently across browsers (AFAIK not all browsers use the same GC  
> algorithm).
>

If the event listeners are unregistered, that would have similar side  
effects (user agent cleaning up what need to be).

> There's one issue I can think of in dropping start() (and keeping  
> stop()): if you stop() you'll need to construct a new  
> BatteryStatusEventSource to continue firing. If we drop stop() too that  
> would be more obvious, but there would be the GC issue mentioned above.
>
> -Anssi
>

On a general note, I do not understand well the need for  
baterrylow/critical events. Would be far simpler to just use level, and  
two extra properties in the event object like lowLevelThreshold,  
criticalLevelThreshold with the user agent's configured values. Then the  
app could just check the current level against the configured one. A  
suggestion to make it simpler.

Received on Sunday, 4 September 2011 21:42:56 UTC