- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 06 Nov 2012 08:46:34 +0100
- To: Marcos Caceres <w3c@marcosc.com>
- CC: public-device-apis@w3.org
Hi Marcos, Le 06/11/2012 00:05, Marcos Caceres a écrit : >> I >> assume knowing when the device stopped vibrating is an important >> information when you want your user to have a compelling experience. > Maybe, what's the use case you were thinking of? I think it's deliberately designed to be "fire and forget". I want to wait for a vibration pattern to end before starting a new one. I want the previous to end to offer a consistent experience; I don't want to randomly cut a vibration pattern because I'm starting the new one. >> Step 3, 5 and 7 of the processing vibration patterns algorithm mention >> implementation-dependent limits and throw according to these. However, >> an application has no way to know these limits, so an application can't >> adapt its behavior to different implementation limits. I think it would >> be nice of the implementation to provide these limits as constants. >> I'm afraid that from an application author perspective, the only >> alternative is try out values to figure out the limits and "try out >> values" means actually vibrating or do weird hacks like: >> >> try{ >> navigator.vibrate(10000); >> navigator.vibrate(0); // cancel vibration if it occured > What use case did you have in mind for knowing the limits? Using the API and being sure it will actually vibrate the way I intend to? If, for some reason, the device can't vibrate for 2 seconds and that's I want to do, I wish I knew it before getting in a situation where I need to vibrate 2 seconds, so that I can define a fallback behavior instead, for instance. To authors, the spec is saying "use this function to vibrate, but it will throw for some implementation-independent values, but you have no way to know them, good luck!" Also, in the physical world, I doubt devices can vibrate for durations as low as one millisecond. If that's the case, I might be worthwhile exposing a minimum time. David
Received on Tuesday, 6 November 2012 07:47:13 UTC