Re: [Vibration] Feedback on the Vibration API

Le 06/11/2012 10:50, Marcos Caceres a écrit :
> On Tuesday, 6 November 2012 at 07:46, David Bruant wrote:
>
>> 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.
> I can't claim to know if the following is true or not, but the hardware itself might be designed to be "fire and forget". Also, there may be some latency between when the request is made at the OS level, and when the hardware actually powers up and starts vibrating (which then also breaks knowing if there is a 1..1 reflection of state between software and hardware). My point being that we need to check on actual hardware if it's possible to have the level of reflection you are eluding to.
Good point.
How do we reach to hardware manufacturers to ask if it's technically 
possible? And to ask if it's possible to add this level of reflection?

> Also, I can imagine that if I set an alarm on my phone to vibrate at a given time, and that time clashes with a pattern specified by a web app… then things are gonna get ugly.
I just suggested to add an event to make a more educated choice (within 
a single application) as to when calling vibrate. I don't think what 
you're saying applies.
First, in the spec, it seems that only one app can vibrate at a time 
(the whole pagevisibility thing). So, either it can't happen or your 
alarm is a sort of privileged app and it can cancel the web app pattern 
or have any special power that are beyond the spec scope.

David

Received on Tuesday, 6 November 2012 10:08:10 UTC