Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <8370e75cedc244068eb2591e385dc09f@DFM-DB3MBX15-05.exchange.corp.microsoft.com>
References: 
 <8370e75cedc244068eb2591e385dc09f@DFM-DB3MBX15-05.exchange.corp.microsoft.com>
Date: Tue, 21 Jul 2015 15:17:04 -0700
Message-ID: 
 <CAKP6k2vU9H+Q4t-pSL-Pq-Q=thxGB=NpjCq0hbRSuGufq0vcGg@mail.gmail.com>
Subject: Re: Plugin discussion: Feature detection
From: Jesse <purplecabbage@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a113cb98e941054051b6a0334

--001a113cb98e941054051b6a0334
Content-Type: text/plain; charset=UTF-8

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.Paveza@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

--001a113cb98e941054051b6a0334--