[Vibration] Feedback on the Vibration API

Hi,

Sorry, I'm arriving late to the party, but a couple of things are 
unclear to me in the spec.
In the following case:

     navigator.vibrate(1000);
     console.log('yo');

What happens?
1) The device vibrates for a second then logs 'yo'
2) The device starts vibrating, logs 'yo' while vibrating and ends vibrating
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.

In case of 2, how do you know when the device stopped vibrating? I 
assume knowing when the device stopped vibrating is an important 
information when you want your user to have a compelling experience.


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
     }
     catch(e){
         // too high of a value
     }


Based on how the API is designed, it seems that it is unusable in 
WebWorkers. The API seems to assume that there is only one "vibration 
resource". If 2 WebWorkers were to use the API concurrently, they would 
probably cancel each other vibrations out resulting in a poor user 
experience.
Is using the API in a WebWorker a planned use case or is it on purpose 
that it's completely banned?

Thanks,

David

Received on Monday, 5 November 2012 17:47:30 UTC