Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of tommy@devgeeks.org designates
 74.125.82.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <FFD143336FEF2D41AFA4D9CE7E119BA1594F6B7D@FMSMSX112.amr.corp.intel.com>
References: 
 <CAHcDwFxL=oxntHXET4m5RZi62J1J9K6oayg_BL9pgJ-+K-BKFw@mail.gmail.com>
	<CAMSbhBjJHQxRF5QT5FWdnzqsrMMC2usw7w5MdYdRLqD3QLPOgQ@mail.gmail.com>
	<CAHcDwFyokw3WEjXz31-vtUg5JxKLqX95FULQHaf_2GnJ5cFHow@mail.gmail.com>
	<FFD143336FEF2D41AFA4D9CE7E119BA1594F6B7D@FMSMSX112.amr.corp.intel.com>
Date: Wed, 11 Feb 2015 06:18:38 +1100
Message-ID: 
 <CAPTyS6Cs0s_3FOpj1R3_0eFtwvbeSqj96EE2TBUkifKsr_8kjA@mail.gmail.com>
Subject: RE: Does this plugin support the current platform?
From: Tommy Williams <tommy@devgeeks.org>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=047d7b3a834c0441e0050ec0c1aa

--047d7b3a834c0441e0050ec0c1aa
Content-Type: text/plain; charset=UTF-8

This won't actually help right now, but that feature detection would
actually be possible if the plugin's "clobbers" was always a child of the
"platform" in plugin.xml.

Right now, most plugins have their clobbers global to all platforms,
supported or not. If the clobbers is a child of the platform, then the
relevant js function/object would be undefined on an unsupported platform.

This practice would also help in a situation where you might want different
plugins for different platforms, but exposing similar functionality on one
clobbered function/object (eg: the popular barcode scanner plugin + the
blackberry barcode scanner plugin).

Unfortunately, most plugins don't do this, even though it is possible.
The natural way to determine whether some functionality is available is to
use the "feature detection" pattern.  That is, if you want to call some
function normally found at "myobj.myfunc", you write code like this:

If (myobj && (typeof myobj.myfunc === 'function')) ...

For this to work you must take care to remove plugins that don't support
your platform before you build for that platform.  For example, before you
build for firefoxos, you must remove the barcodescanner plugin (and then
add it back when you build for supported platforms).  Granted, this is
awkward, but I think it's worse to read the package.json file.

Really the CLI should make the feature detection pattern work without
having to exclude plugins on unsupported platforms.  That is, if a plugin
doesn't support a platform, then it should contribute nothing when you
build for that platform.

    Julian

-----Original Message-----
From: Axel Nennker [mailto:ignisvulpis@gmail.com]
Sent: Tuesday, February 10, 2015 11:48 AM
To: dev
Subject: Re: Does this plugin support the current platform?

And then the app has to load that package.json ?
On Feb 10, 2015 5:28 PM, "Steven Gill" <stevengill97@gmail.com> wrote:

> Plugin.xml has a platforms tag for what platforms it supports. That
> info gets uploaded to the Cordova plugins registry when publishing.
>
> Soon this info will be available in package.json file each plugin has.
> On Feb 10, 2015 7:25 AM, "Axel Nennker" <ignisvulpis@gmail.com> wrote:
>
> > Hi,
> >
> > is there a way how an app can determine whether a plugin supports
> > the current  platform?
> >
> > E.g.: the barcodescanner plugin is not supporting firefoxos How
> > could an app know that which out hardcoding this into the app?
> >
> > If there is a standard way in Cordova then this is a userland question.
> > If not then this is a feature request to add this info to e.g.
> > cordova/plugin_list exports.metadata ?!
> >
> > -Axel
> >
>

--047d7b3a834c0441e0050ec0c1aa--