There are a couple different ways to go about this, but ultimately the mechanisms are already there.
1. WaitForInit If you look at the cordova-device plugin, it pre-populates data about the device it is running on, and this info is available when the deviceready event fires. Essentially the plugin creates a channel, and specifies that this channel must fire BEFORE the deviceready channel can fire, via the call channel.waitForInitialization('onCordovaInfoReady'); //[1] 2. addConstructor The window.cordova object defines an addConstructor method to allow a plugin to do some pre-deviceready work. All functions passed in to cordova.addConstructor will be called at the 'cordovaready' stage which is guaranteed to happen after 'nativeready' and before 'deviceready' [2] Another approach may be to add a getDeviceCapabilites async call to a plugin like Camera that has many varied capabilities depending on where it is running. We could simply instruct users to call this method ( after deviceready ) to know for certain what capabilities are available. The plugin (js) could also cache this info so later calls would not require a round trip. This would allow the app to be active as soon as possible, and place the responsibility on the app developer, especially relevant if the camera api is a small subset of the functionality of the app, and the capabilities are not essential at launch time. [1] https://github.com/apache/cordova-plugin-device/blob/master/www/device.js#L28 [2] https://github.com/apache/cordova-js/blob/master/src/cordova.js#L233 My team is hiring! @purplecabbage risingj.com On Mon, Jul 20, 2015 at 11:34 AM, Rob Paveza <rob.pav...@microsoft.com> wrote: > 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 > >