cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Android Project Structures, Libraries and the Embedded Case
Date Thu, 13 Aug 2015 18:05:58 GMT

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.



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