cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Does this plugin support the current platform?
Date Tue, 10 Feb 2015 22:11:55 GMT
Sounds like a smart change.
On Feb 10, 2015 2:10 PM, "tommy-carlos williams" <tommy@devgeeks.org> wrote:

> Nice
>
> +1
>
> One change in Cordova is a lot bette than expecting all plugins to change
> ;)
>
>
> --
> tommy-carlos williams
>
> On 11 February 2015 at 07:54:17, Andrew Grieve (agrieve@chromium.org)
> wrote:
>
> Strawman:
>
> If plugin.xml has *any* <platform>s, then only apply global tags to those
> platforms.
> If plugin.xml has *no* <platform>s, then apply global tags to all
> platforms.
>
> On Tue, Feb 10, 2015 at 2:18 PM, Tommy Williams <tommy@devgeeks.org>
> wrote:
>
> > 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
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message