Have a good feature detection story

[tobie]

@richtr pointed out issues with feature detection of DeviceOrientation giving false positives. Let's try to learn from it.

There are a number of issues here:

1. The fact that the interface is present doesn't guarantee the sensor is (e.g. it could have been unplugged in the meantime, not implemented properly, etc.).
2. Feature detection is often done upfront so you want to make sure it's non-blocking and doesn't affect perf.
3. You probably want to really get some data out of the sensor to make sure it's working properly. (This might be costly too + battery draining).

Wondering if the right strategy here isn't to promote defensive programming over feature detection.

Proposed resolution: The Sensor API must have a built-in, override-able timeout mechanism with a reasonable default.

Proposed resolution: The specification must contain a section which addresses feature detection concerns and proposes best practices.

[richtr]

See the related discussion for the current DeviceOrientation API @ w3c/deviceorientation#12.

tl;dr Platforms expose the objects but may not ever provide sensor values back to developers. Thus, developers are forced to manually code their own timeout function after which the web app should fallback to e.g. manual orientation controls. Currently DeviceOrientation feature detection has to be done like this: https://gist.github.com/richtr/eda598ad98b11f5d7660.

If we instead made Device Sensors accessible via Promises then the platform itself would implement timeout functionality and the Promise object would be rejected when that timeout is reached if a valid sensor reading (i.e. not null) has not been received from the platform before the timeout duration has been reached.

[tobie]

If we instead made Device Sensors accessible via Promises then the platform itself would implement timeout functionality and the Promise object would be rejected when that timeout is reached if a valid sensor reading (i.e. not null) has not been received from the platform before the timeout duration has been reached.

What prevents a TIMEOUT_ERROR (or related) to be thrown on the sensor object itself? E.g:

if (Sensor.Proximity) {
    var prox = new Sensor.Proximity();
    prox.onerror = function(err) {
        if (err.name == Sensor.TIMEOUT_ERROR) {
            // no sensor
        }
    }
}

Note this clearly ties in to #9.

[richtr]

This could work too.

I think we are getting in to a classic 'constructors vs callbacks vs events vs promises' discussion for initializing and accessing objects. Everyone has a different opinion on this topic and the merits of any particular pattern are seemingly endlessly debatable ;)

My personal preference would be for Promises as that is how the majority of new web platform APIs are being implemented and the benefits of Promises have been well-documented elsewhere on the web (i.e. chaining and generally producing cleaner code). YMMV on this :)

[tobie]

I think we are getting in to a classic 'constructors vs callbacks vs events vs promises' discussion for initializing and accessing objects. Everyone has a different opinion on this topic and the merits of any particular pattern are seemingly endlessly debatable ;)

I'd like to avoid discussing these patterns in the abstract, but concretely, given use cases and code examples, for the specific issue at hand (and also, preferably, in the dedicated issue #9).

The reason I opened a specific issue for feature detection, is because I think it gets increasingly complicated and costly to practice in for hardware related features. Much like with video or WebGL, there's actually little the browser can do to let you know whether a sensor is going to work properly, and is going to do so through the lifetime of the app (e.g. what if it's an external sensor plugged in through USB and it gets unplugged?).

So my question here really about whether feature-detection is a sufficient strategy for such cases. If feature detection should be used to identify whether the feature is implemented or only the API exists? Indeed what happens if you feature detect the sensor as existing on page load but it's been unplugged, or used elsewhere when you need it? Etc.

TL;DR Isn't "feature detection" really "api detection" and should we also promote defensive programming for hardware-based sensors and related features.

[borismus]

Can you give a concrete example of when the sensor unplugged case happens? I have never experienced this in practice, and curious what you have in mind.

[tobie]

Can you give a concrete example of when the sensor unplugged case happens? I have never experienced this in practice, and curious what you have in mind.

I was just thinking about literally physically unplugging something like that from my phone (should it, of course, happen to be exposed in the browser). I don't have a concrete example, but is doesn't seem like a far-fetched idea.

[tobie]

Thinking about this a bit more, it might even be desirable to allow setting a timeout on a per instance basis (e.g.: new Sensor({ frequency: 60, timeout: 10000 });) with a global or per sensor type default.

[tobie]

Overall, it seems the concerns expressed here are mostly covered in #7 and #9 with the exception of the timeout which isn't mentioned elsewhere.

I suggest the following resolutions:

The Sensor API must have a built-in, override-able timeout mechanism with a reasonable default.

The specification must contain a section which addresses feature detection concerns and suggests best practices.