[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [andmore-dev] How out of date is Andmore
|
Doug touched on most of these, so I'm just going to answer a couple in line.
On 1/17/16 12:18 PM, Thomas Golden wrote:
As an Android developer who has reluctantly moved to Gradle+Android
Studio, here's what I think are table stakes for an Eclipse-based
solution:
1. Acknowledge that for better or worse, the Gradle build system has
won. Any Andmore solution should be capable of importing an Android
Gradle project successfully. This probably means doing a lot of work
on Eclipse's Gradle support, which is shoddy the last time I looked.
This also means things like build variants and flavors.
2. As part of 1, ensure that AAR dependencies are first-class
citizens. Eclipse/ADT can't handle them at all. The android-maven
plugin team did some great work making it function from the command
line but it's useless if it can't be done in the IDE. A lot of useful
libraries (RxAndroid and RxBindings, Play Services, etc) are
distributed as AARs, not JARs.
Yes, these are top priorities, but the problem from my end has been
finding the time necessary to start working on it. Also, there are
still hooks we need from the Eclipse Gradle team for us too capture
some of this information. Regardless we do need the AAR container
support which can be done separetely to at least allow the Maven Tooling
to work with it. m2e android stuff works fairly well, but AAR support
is also one of their most requested features as well.
3. Also related to 1, ensure that Andmore can build multidex projects.
ADT was totally incapable of doing this, meaning I had to build and
deploy from the command line, and attach a debugger after the fact.
This KILLS momentum during development. In a perfect world multidex
wouldn't be necessary, but it is.
Multi-dex support was recently added by a community memember. I think
you have to go into the project settings, and enable it directly for a
particular project. If it isn't working then it needs a bug report so
it can be investigated eventually.
Some nice-to-haves:
* Eclipse/ADT had some hard-coded language levels that prevented the
use of Retrolambda to use Java 8 syntax in projects - even if it was
configured in your build properly, the IDE just would not let you set
the source level to 8 and flagged all instances of those syntax
features as compile errors.
* Steal shamelessly some of the editor features Android Studio has
such as showing the actual String value of R.string ints in the editor.
You should be able to specify Java 8 as an api level. I think I removed
most of those restrictions a while ago. However, I haven't tested it or
the dexing support when these are enabled. The default is Java 1.7, at
least until the android dexers support java 8 and those libraries come
from the AOSP.