Android Project Structures, Libraries and the Embedded Case

[Joe Bowser <bo...@gmail.com>]

Hey

So, as you know, Google switched from supporting Eclipse to supporting
their IntelliJ based Android Studio IDE, and in an effort to keep up, we
followed them, somewhat.  One thing we didn't do is update our project
structure so it works similar to an Android Studio one, and there's a
reason we didn't do that.

The reason is that Android didn't do that.  If you autogenerate an Android
project from the command line, even if you use Gradle (which should be the
default, but still isn't for some reason), you still get the old
eclipse-style structure that we're currently using.  I've been making tiny
changes so that we can use Cordova as a library, but then there's these
development problems that I really don't have the answers to:

1. Where do tests live for plugins? People who contribute want JUnit tests
to make sure the native code works.  I want them as well, but our current
plugin system has no support for this and people don't seem super
interested in changing this when I have off-list private conversations,
which is why I'm bringing it up here.

2. Should plugins be AAR/Projects instead of just code?  Honestly, I think
this would make more sense than trying to guess what the structure of a
Java project is.  I want to support users regardless of how they create
their Android project instead of just saying that using the Cordova CLI is
the one and only way, and I think people who use this in Enterprise
environments would agree with me.  Although, I haven't explicitly asked
anyone, which is why I'm bringing this up here.

3. If we keep the current way of loading Android code as plugins, how do we
support all the IDE structures? Currently cordova-lib only supports the
current Android project structure, and if I was to extend it, Android
Studio would have to be its own platform, which isn't correct, since it's
just a different project directory structure.

I'm interested in what people think in this, and whether we should bother
with these use cases, or just say that everyone has to use the old
structure until Google changes their minds, or whatever.

Thoughts?

Joe

Re: Android Project Structures, Libraries and the Embedded Case

[Joe Bowser <bo...@gmail.com>]

On Thu, Aug 13, 2015 at 12:02 PM Andrew Grieve <ag...@chromium.org> wrote:

> The structure isn't a big deal to me, because it seems to work fine in
> Android Studio how it is.
>
>
If you create a Cordova project and shove it into Android Studio, that
works.
If you have a legacy project and shove it into Android Studio, that works
If you generate from the Command Line and shove it into Android Studio,
that works.

If you create a new project in Android Studio, or migrate to the new
Android Studio project structure, then try to use Cordova, that fails.

This is based on CB-8320 that was filed a while ago when someone tried to
use the CLI to add plugins to their Android project.  I personally think
that should never work, and that this is why plugman exists.

I created a PoC of this use case here:
https://github.com/infil00p/CordovaComponentCase

It would be good if we could use plugman with this and have the people who
want to use this use case in their applications able to do so without
having to do some special case.  That being said, I don't really know the
value of this because many of Google's own libraries (i.e. Project Tango)
still use Ant, and while the PhoneGap Tango plugin shows why Gradle is
superior to Ant (i.e. upgrading my Gradle doesn't perma-break older
projects)

Moving plugins to maven as .aar files is actually possible now by using a
> maven ref in a <framework> within you plugin.xml.
>

Yes, I think this might be a good move.  If we just do this, and just add
the libraries, it might avoid the whole structure thing altogether, but I
don't know for sure.  Does anyone want this feature? Or is this a weird,
special case?



>
>

>
> On Thu, Aug 13, 2015 at 2:05 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > Hey
> >
> > So, as you know, Google switched from supporting Eclipse to supporting
> > their IntelliJ based Android Studio IDE, and in an effort to keep up, we
> > followed them, somewhat.  One thing we didn't do is update our project
> > structure so it works similar to an Android Studio one, and there's a
> > reason we didn't do that.
> >
> > The reason is that Android didn't do that.  If you autogenerate an
> Android
> > project from the command line, even if you use Gradle (which should be
> the
> > default, but still isn't for some reason), you still get the old
> > eclipse-style structure that we're currently using.  I've been making
> tiny
> > changes so that we can use Cordova as a library, but then there's these
> > development problems that I really don't have the answers to:
> >
> > 1. Where do tests live for plugins? People who contribute want JUnit
> tests
> > to make sure the native code works.  I want them as well, but our current
> > plugin system has no support for this and people don't seem super
> > interested in changing this when I have off-list private conversations,
> > which is why I'm bringing it up here.
> >
> > 2. Should plugins be AAR/Projects instead of just code?  Honestly, I
> think
> > this would make more sense than trying to guess what the structure of a
> > Java project is.  I want to support users regardless of how they create
> > their Android project instead of just saying that using the Cordova CLI
> is
> > the one and only way, and I think people who use this in Enterprise
> > environments would agree with me.  Although, I haven't explicitly asked
> > anyone, which is why I'm bringing this up here.
> >
> > 3. If we keep the current way of loading Android code as plugins, how do
> we
> > support all the IDE structures? Currently cordova-lib only supports the
> > current Android project structure, and if I was to extend it, Android
> > Studio would have to be its own platform, which isn't correct, since it's
> > just a different project directory structure.
> >
> > I'm interested in what people think in this, and whether we should bother
> > with these use cases, or just say that everyone has to use the old
> > structure until Google changes their minds, or whatever.
> >
> > Thoughts?
> >
> > Joe
> >
>

Re: Android Project Structures, Libraries and the Embedded Case

[Andrew Grieve <ag...@chromium.org>]

The structure isn't a big deal to me, because it seems to work fine in
Android Studio how it is.

Moving plugins to maven as .aar files is actually possible now by using a
maven ref in a <framework> within you plugin.xml.




On Thu, Aug 13, 2015 at 2:05 PM, Joe Bowser <bo...@gmail.com> wrote:

> Hey
>
> So, as you know, Google switched from supporting Eclipse to supporting
> their IntelliJ based Android Studio IDE, and in an effort to keep up, we
> followed them, somewhat.  One thing we didn't do is update our project
> structure so it works similar to an Android Studio one, and there's a
> reason we didn't do that.
>
> The reason is that Android didn't do that.  If you autogenerate an Android
> project from the command line, even if you use Gradle (which should be the
> default, but still isn't for some reason), you still get the old
> eclipse-style structure that we're currently using.  I've been making tiny
> changes so that we can use Cordova as a library, but then there's these
> development problems that I really don't have the answers to:
>
> 1. Where do tests live for plugins? People who contribute want JUnit tests
> to make sure the native code works.  I want them as well, but our current
> plugin system has no support for this and people don't seem super
> interested in changing this when I have off-list private conversations,
> which is why I'm bringing it up here.
>
> 2. Should plugins be AAR/Projects instead of just code?  Honestly, I think
> this would make more sense than trying to guess what the structure of a
> Java project is.  I want to support users regardless of how they create
> their Android project instead of just saying that using the Cordova CLI is
> the one and only way, and I think people who use this in Enterprise
> environments would agree with me.  Although, I haven't explicitly asked
> anyone, which is why I'm bringing this up here.
>
> 3. If we keep the current way of loading Android code as plugins, how do we
> support all the IDE structures? Currently cordova-lib only supports the
> current Android project structure, and if I was to extend it, Android
> Studio would have to be its own platform, which isn't correct, since it's
> just a different project directory structure.
>
> I'm interested in what people think in this, and whether we should bother
> with these use cases, or just say that everyone has to use the old
> structure until Google changes their minds, or whatever.
>
> Thoughts?
>
> Joe
>