cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: Android - Removing the .api namespace
Date Tue, 09 Jul 2013 23:11:50 GMT
 :) okay, now let's see if I can convince you Joe.

What I've done so far was put classes in o.a.c.api that extend the actual
implementations in o.a.c. This is a bit more annoying than I'd like,
because for it work properly, most types must continue to refer to the
o.a.c.api classes, or else you'll get a type errors when dealing with
non-updated code that expects a o.a.c.api class.

Using a separate namespace (.api) to indicate which methods are a part of
our public API has the huge draw-back of not allowing us to make use of
package-private visibility with the classes in the non-.api namespace. This
is my main motivation for the change. I think Java devs often assume any
symbol that is public is a part of our API, and I think that's pretty
reasonable. Going forward, we should make an effort to convert public
symbols to package-private symbols. This will break any plugin that is
relying on the symbol, but will *not* break any plugins that are not using
the symbol. OTOH, a namespace change, as we're doing here, will break all

So... I'd like to do the complete namespace change now so that when
we privatize symbols that we don't want to be a part of our public API, it
will not break the large majority of plugins.

If you're not convinced, please say why :)

On Tue, Jul 9, 2013 at 5:33 PM, Joe Bowser <> wrote:

> Actually, on second thought, no, let's keep the compatibility classes
> in for now.  We may want to keep using this namespace post-3.0.  I
> think I misunderstood what was being asked.
> On Tue, Jul 9, 2013 at 2:28 PM, Joe Bowser <> wrote:
> > On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve <>
> wrote:
> >> Want to bring this up again.
> >>
> >> There was a bit of discussion on the bug:
> >>
> >>
> >> I've already gone ahead with creating backward-compatiblity classes in
> the
> >> .api namespace, but I think it would be better to just delete them.
> >>
> >> Main points in favour:
> >> 1. For 3.0, people will need to do some work to their plugins anyways
> (add
> >> plugin.xml + refactor their JS into modules comes to mind)
> >> 2. The change to plugins is trivial. Just replace all occurrences of
> >> "import org.apache.cordova.api" with "import org.apache.cordova".
> >>
> >
> > I'm OK with it for now, only because we don't have the time to
> > formalize the Android Plugin API.  I would have liked to keep the api
> > separation but perhaps we can revisit this 3.1 or 3.2.

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