cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Paveza <>
Subject Plugin discussion: Feature detection
Date Mon, 20 Jul 2015 18:34:32 GMT
We chatted briefly about this at the hangout last week, and I wanted to continue on the discussion.
 I gave the example that the "Quirks" section of CameraOptions [1] is longer than the actual
API documentation.  I like to pick on the Camera plugin because it's one of the most-used
and is very well-documented, so its holes are easy to understand.

I looked at a request to, for example, support the <plugin> element within a <platform>
element in config.xml.  When we drilled down into the request, it was because the plugin wasn't
well-supported on Windows, so the developer wanted to be able to do feature detection and
bypass using the plugin there.  Presently, Cordova.js doesn't support this; the proxy doesn't
have an opportunity to talk to native until the `deviceready` event, at which point, mutating
the public API surface of the proxy would result in a race condition (because you're not sure
who subscribed to `deviceready` first).

I think it's important to note that **how the API can support feature detection should be
up to the plugin author**.  If the plugin is trying to mimic a W3C standard, then it can do
so; if it's just trying to fill a feature gap, it can do that, too.  The plugin developer
can choose what fits best.

 - I'll make a change to Cordova.js that will create a new event for plugins to listen to.
 This will delay the invocation of `deviceready` until all plugins have signaled completion
(we'll avoid breaking compatibility by having plugins opt-in to this behavior; if they don't
opt in, we'll treat them like they don't need to do anything).  Once the plugin initialization
code has been run and the plugins have signaled readiness, we'll then fire `deviceready`.
 - I'd also like to go through the plugins at least in mobilespec and make some targeted proposals
about where we can refactor to improve feature-detectability.  The File Plugin is tough because
it's standards-based on a standard that is defunct, but the Camera plugin might have some
opportunities, as well as Vibration, etc (e.g., vibration is supported on Windows mobile devices,
but not on desktop PCs).

== Guiding Principles ==
 - Feature detection should be based on the availability of the platform API, not the availability
of the platform to do the work.  
  - For example, if we created a Printer plugin, and the device can support printing but no
printers are attached, then the print() API should be available.  
  - In such a case, calling print() should result in a runtime error.  The plugin author should
provide a way to query for attached printers.
  - This allows for a printer to be attached at a later time.
 - Features should be in some way able to be queried by code at runtime.
  - Whether that's via a "foo.hasFeature(bar)" method or "if (" truthy check, we should
try our best to follow web principles in making these decisions and enable it to be similar
to known practices on the web.

Looking forward to hearing your thoughts...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message