cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Android Plugin API
Date Thu, 29 May 2014 19:29:54 GMT
Erik,

I think it should be possible leave the platform plugin interface as-is,
and publish a plugin that does nothing but implement
reflection-based-execute.  Then, plugin authors can opt to use that as a
base class for plugin development.

I hesitate to give opinions on this topic, except to say that its also
something I've thought would be useful, but not enough of a big deal to
make a stink over it.

Andrew also points out that there are plugins that have been published that
use this approach, i.e.:
https://github.com/wf9a5m75/phonegap-googlemaps-plugin/blob/master/src/android/plugin/google/maps/MyPlugin.java#L45-L57


On Thu, May 29, 2014 at 3:01 PM, Joe Bowser <bowserj@gmail.com> wrote:

> On Thu, May 29, 2014 at 11:46 AM, Erik Jan de Wit <edewit@redhat.com>
> wrote:
> >
> >> What is the benefit of using this logic?  I personally don't see any
> >> benefit, since this makes our code more complex.
> >
> > It would benefit the users as they don’t have to implement this
> boilerplate code of dispatching based on the string. And this logic will be
> then on the android side where it’s implemented once instead of each time
> one is building a plugin.
>
> Except that now every method exposed has to have a particular
> signature.  I personally would rather see us use a Map as what Andrew
> suggested, and I really don't want this to happen.  This is going to
> cause a lot more problems than it's going to solve since plugins that
> already throw exceptions may end up having it caught by the try/catch
> which will surround this whole thing.  This is a BIG change in the
> API, and I don't think your reason justifies breaking every plugin
> that currently exists.
>

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