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

Re: Vibration API: making feature detection possible

From: Rob Manson <roBman@mob-labs.com>
Date: Wed, 09 Oct 2013 03:48:12 +1100
Message-ID: <5254374C.4070801@mob-labs.com>
To: public-device-apis@w3.org


On 09/10/13 03:34, Michael van Ouwerkerk wrote:
> Hi, I'm currently working on implementing the Vibration API in Blink and
> Chromium, and I'd like to propose making feature detection possible.
> In its current form, the Vibration API exposes the navigator.vibrate
> method. When you call it with valid arguments, it returns true. However,
> this only indicates that the arguments were valid. It does not mean any
> vibrations have been scheduled. Nothing might happen, perhaps because
> there is no hardware for it. Do all phones have such hardware? How about
> tablets, or laptops? Or, perhaps there is no permission for vibrating
> right now.
> To give web developers an opportunity to provide a fallback for their
> users, I think it should be possible to detect when they will not be
> able to vibrate the device.
> The simplest approach might appear to just not expose navigator.vibrate
> when vibration is not available. However, this would require that the
> browser detect availability of vibration in the startup path. It might
> be an asynchronous process as well. This is a problem for implementation
> in the browser.
> My proposal is that we make use of Promises, so that the setup is
> asynchronous, and it is clear how to handle failure.
> In JavaScript, it would look something like this:
> window.navigator.getVibrator().then(function(vibrator) {
>    vibrator.vibrate([100, 0, 50]);
> }, function() {
>    // No vibrator is available. Provide fallback or exit.
> });
> What do you think?
> Regards,
> Michael van Ouwerkerk
Received on Tuesday, 8 October 2013 16:48:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC