- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Tue, 1 Nov 2011 14:58:53 -0700
- To: ext Jonas Sicking <jonas@sicking.cc>
- Cc: ext Dominique Hazael-Massieux <dom@w3.org>, "public-device-apis@w3.org WG" <public-device-apis@w3.org>, <public-device-status@w3.org>
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