W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2013

Re: Vibration: throwing and pause

From: David Bruant <bruant.d@gmail.com>
Date: Sun, 14 Apr 2013 14:43:18 +0200
Message-ID: <516AA466.6030306@gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
CC: Justin Lebar <justin.lebar@gmail.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Le 13/04/2013 10:24, Anne van Kesteren a écrit :
> On Fri, Apr 12, 2013 at 9:57 PM, Justin Lebar <justin.lebar@gmail.com> wrote:
>> The method is definitely not intended to be synchronous in Firefox's
>> implementation.
>> I don't even know what it means to synchronously do an operation like this.
>> Obviously the vibrate() call doesn't block until the phone starts
>> moving, or something like that.
>> Could you elaborate on how making this method sync and spinning the event loop
>> impacts content authors?  I agree with Anne that making this sync seems Very
>> Bad.
> Yeah, it should simply return early and then asynchronously do the
> vibration bits.
The API itself doesn't make this straightforward, but that's what it 
does. I recommend reading the thread starting at [1] as some points 
overlap with this thread.

To summarize what happened on the linked thread:
* The vibration API is "fire-and-forget" style, that is you call 
vibrate(), it returns as soon as possible and does the vibration in 
parallel of the rest of script execution.
This behavior is apparently also the one on Android [4]. This would be 
related to the hardware API itself which forces programming to this 
style. I don't remember from this thread whether someone showed some 
proof that hardware really forces this or even will always be like this, 
but that's apparently what we have.
I would love to read from someone with mobile hardware expertise whether 
the API exposed by the hardware is or could be any different.
* I wished (and still wish) for the maximum vibration time to be exposed 
as part of the API [2]. This info can be discovered by a script anyway, 
but requires a hack that may result in poor UX [3]

Hope that helps :-)


[1] http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0003.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0027.html
[3] https://gist.github.com/DavidBruant/4066406
[4] http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0007.html
Received on Sunday, 14 April 2013 12:43:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC