Re: [vibra] Vibration API -- the first stab

On 31.10.2011, at 9.15, ext Jonas Sicking wrote:

> I personally prefer to skip the middle man here and just go with
> navigator.vibrate(). The only harm that I can see in having a lot of
> API directly on navigator would be if we end up with name collisions,
> but I don't think there's a big risk of that. Long names is something
> which people continuously complain about.

I agree developer ergonomics is better without the middle man. I changed the spec accordingly.

>>>> * two event handlers added: onvibrationstart and onvibrationend
>>> 
>>> What are the use cases for these events?
>> 
>> This comes from a game developer:
>> 
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=679966#c25
>> 
>> Paul Bakaus doesn't mention any use cases, but I could see how having a one-to-many dependency between the vibration and other objects could be useful. For example, lets say there are N angry trolls on the screen, and each of the trolls acts differently when the device vibrates. Being able to notify N objects automatically seems useful.
> 
> As you mention, that link doesn't contain any use cases. I don't think
> we should add these events until we have such use cases.
> 
> I do agree that if we should have a callback for when the vibrator is
> turned on, it should be DOM-Event based as to allow multiple
> listeners. However until we have such use cases, I don't think we add
> any callbacks at all.
> 
> It sounds strange to me to have elements of the game act differently
> when the device vibrates given that the device vibrating is in direct
> control of the page. It would be like having elements of the game act
> differently depending on what the background color of the app is.
> 
> It seems more likely that the game would call a function which turns
> on the vibrator and then makes all the trolls fall over.

I dropped the handlers for now. Lets consider adding them back if people come up with high value use cases for them.

>>>> * the exceptions raised by vibrate() are 'SyntaxError' and 'NotSupportedError'
>>> 
>>> I think the SyntaxError exception is not needed, since Web IDL gives use
>>> TypeError for free in these cases.
>> 
>> That'd be great. How would you describe that in WebIDL exactly? Mozilla's implementation states:
> 
> I think something like the following would work:
> 
> partial interface Navigator {
>  void vibrate(long[] pattern);
>  void vibrate(long time);
> }
> 
> The first signature would be number of milliseconds on, number of
> milliseconds off, etc. The second signature would simply be number of
> milliseconds on.
> 
> Any call to either of these functions would first cancel any already
> existing vibration. Hence vibrate(0) or vibrate([]) would both cancel
> any existing vibrations.

Updated the IDL and the 'processing vibration patterns' algorithm accordingly:

  http://dev.w3.org/2009/dap/vibration/

Thanks again for the feedback!

-Anssi

Received on Tuesday, 1 November 2011 21:59:37 UTC