Action Item Follow Up (Vibration API)

I had an action item to check Vibration API versus the HW implementation.  I checked it versus the QuIC (Qualcomm Innovation Center) Linux driver.  A couple of things popped out:


a)      The Android Java API (with which the driver is normally verified) has a slightly different interpretation of index 0 in the pattern.

a.       Android: As per online documentation on vibration pattern (http://developer.android.com/reference/android/os/Vibrator.html):



" The first value indicates the number of milliseconds to wait before turning the vibrator on. The next value indicates the number of milliseconds for which to keep the vibrator on before turning it off. Subsequent values alternate between durations in milliseconds to turn the vibrator off or to turn the vibrator on. "



Comparing to the relevant text in the latest version of the W3C spec (http://dev.w3.org/2009/dap/vibration/):

"12. For each time in pattern, run the following substeps:

1. If the index of time is even (the first entry has index 0), vibrate the device for time milliseconds.

2. Otherwise wait for time milliseconds."



Since index 0 is even, this seems to not be consistent with how the vibration pattern is interpreted in Android because in Android the first value indicates the amount of time to wait before the vibrator is turned on.  This is just something for implementers to be aware of, but the W3C specification should not change as a result.



b)      The current W3C spec also has the following text:

“10. If there is a pre-existing instance of the processing vibration patterns algorithm running for this browsing context, run the following substeps:



                Cancel the pre-existing instance of the processing vibration patterns algorithm, if any.

If pattern is an empty list, or if the device does not provide a vibration mechanism (or it is disabled), then return true and terminate these steps.”



Android (Java API) does not return anything upon invocation of the Vibrator, so there is no direct indication of success/failure to the developer.  The spec as written seems to mimic this, but I believe the wording is not complete.  The device vibration mechanism may simply be busy, and it is possible to get this state information from the driver depending on if the browser is implementing vibration natively (as opposed to the implementing using the Android Java API, which will not provide this information).  FJH had suggested changing the wording of the spec on this morning’s DAP call to “ …  , or if device is unable to vibrate, then return true …”, which should resolve any ambiguity.



-Giri Mandyam, Qualcomm Innovation Center