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. ==Proposal== - 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 (foo.bar)" 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... -Rob [1] https://github.com/apache/cordova-plugin-camera#cameraoptions --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
