- From: Marcos Caceres <w3c@marcosc.com>
- Date: Mon, 5 Nov 2012 23:05:58 +0000
- To: David Bruant <bruant.d@gmail.com>
- Cc: public-device-apis@w3.org
Hi David,
On Monday, 5 November 2012 at 17:46, David Bruant wrote:
>
> What happens?
> 1) The device vibrates for a second then logs 'yo'
Nope.
> 2) The device starts vibrating, logs 'yo' while vibrating and ends vibrating
yep.
> 3) something else (explain)
>
> Case 1 would be an aberrant waste of CPU time especially for long
> sequences of vibrate/idle. Also games are known to use UX trick to
> compute things in the background. Vibrating to deconcentrate the user
> may be one of these tricks.
Yep, it's async.
>
> In case of 2, how do you know when the device stopped vibrating?
I don't think that information is available, unfortunately.
> 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".
> 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?
Received on Monday, 5 November 2012 23:06:28 UTC