| Re: [andmore-dev] How out of date is Andmore |
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.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.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.All that said, I don't know enough about the internals of either Eclipse or the existing ADT code to know how much work this is. My guess is, quite a substantial amount. Is the ADT codebase even flexible enough to be altered this way or does this entail a from-scratch rewrite that simply takes bits and pieces from ADT?On Sat, Jan 16, 2016 at 11:05 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:So I installed the latest ADT (which is getting really hard to find) and I get the same errors except for the layout editor which makes sense. Yeah, this path seems pretty doomed IMHO.Having said that, I know people in the community really want to do Android development in Eclipse and not everyone appreciates Android Studio. It's worth the community investing in, but it's got to be in a path that will lead to success. I have some ideas which I mentioned earlier in this thread, but I'm interested in what people following this list think.Doug.On Sat, Jan 16, 2016 at 7:40 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:I tried the latest layoutlib-api jar and after fixing up the compile errors that caused, I'm still getting these errors on startup:Error: Error parsing /Users/dschaefer/android/android-sdk-macosx/system-images/android-23/android-wear/x86/devices.xml
cvc-complex-type.2.4.d: Invalid content was found starting with element 'd:skin'. No child element is expected at this point.and build:
[2016-01-16 19:23:19 - DougTest] /Users/dschaefer/eclipse/workspaces/ide/.runtime-AndroidTest/DougTest/res/values/styles.xml:7: error: Error retrieving parent for item: No resource found that matches the given name 'Theme.AppCompat.Light'.
as well as the layout editor telling me:
This version of the rendering library is more recent than your version of ADT plug-in. Please update ADT plug-in
I'll keep digging at these but even then, I'd prefer we have have project templates that generate projects that look like the ones generated by Android Studio, and yes, that includes building with Gradle.
In other words, unless other people aren't seeing these errors, I'm not sure how we release anything sane for Neon.
Doug.
On Mon, Jan 4, 2016 at 11:47 AM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:Cool. Thanks Xavier. Makes sense. I'll check that.Doug.On Mon, Jan 4, 2016 at 11:35 AM, Xavier Ducrohet <xav@xxxxxxxxxxx> wrote:layoutlib.jar is indeed loaded dynamically. There is one per API level of the platform, so we don't bundle it with the IDE.layoutlib_api.jar is the one that's bundled with the IDE and it's the one that has an "API level". It allows the editors to load and access the code from layoutlib.jar. Whenever we want to add new features (or fix issue) that requires an API change in, we rev the API level, and this is built-in the layoutlib.jar.Making Eclipse support the new API level of layoutlib might be as easy as updating to the new layoutlib_api.jar. In some case we mostly add new APIs rather than change the existing ones.On Mon, Jan 4, 2016 at 8:27 AM, David Carver <d_a_carver@xxxxxxxxx> wrote:I think it is already being loaded based on the API level in use from the graphical editor. I've copied Xavier on this to get some background history. The last time I updated the JARs included from Android Tools was in API 20, so we are a couple versions behind.
Dave
On 1/4/16 10:32 AM, Doug Schaefer wrote:
Thanks, Dave. I was wondering about that. It could possible be a simple as having an old layoutlib jar file. I didn't see much change in the Eclipse code over the last few weeks.
Has anyone investigated dynamically loading this jar from the SDK directory? I'm sure it's not easy and likely pretty error prone. But it might be a way to keep up.
On Mon, Jan 4, 2016 at 10:21 AM, David Carver <kingargyle@xxxxxxxxx> wrote:
Sorry was unplugged from the net for most of the holiday breaks.
The API 22 issue you see is because of the underlying layoutlib changing and there being checks within the code for compatibility. Andmore like ADT calls out and uses what ever API level you specify. If you change the API from 22 to say 19 or 20, it should then render the layout correctly in the editor. I started to trace through this, but I think there is some specific information that needs to be passed to the layoutlib when it's api is being called. I never really got far into checking it to see what was needed to get this working.
We probably do need to check to see what has been changed that we use within Andmore from the Android Tooling project and update appropriately. I know that some of the supporting libraries they also use have changed, so it is not an easy under taking.
Dave
On 1/4/16 10:05 AM, Doug Schaefer wrote:
So at worse, you're going to get gradle building and not using the JDT build output, taking a few seconds longer each time you launch. I think that's the starting point though.
I have lots of experience calling out to external tools to do builds and launch. I have the Android command-line tools running, at least for build, install, and launch using 'android' and adb, including creating a new gradle-based project using android create project. They're are a bit sloppy, e.g. it grabs a really old version of gradle. But it gives a start.
Anyway, I'll have a quick and demo ready for EclipseCon of this. I need it to show off my IoT toolchain. If it's dumb, we can simply drop it and refocus on the existing clone. (Sorry, it's not really a fork since we can't simply apply updates to it). I think at the end of the day, it's going to be about the same amount of work.
- Doug.
On Mon, Jan 4, 2016 at 5:18 AM, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:
Neither the JDT nor Gradle plugins are currently flexible enough to support
Google's use of Gradle afaik.If you find a way to make it work I'm all ears!
/max
Crazy thought of the day and the reason I can't get to sleep tonight: Start
over. From scratch. Toss the legacy and create a new set of plug-ins that
use Gradle off the bat, focus on the using the LaunchBar to launch, blend
in with the other IDE plug-ins. Steal stuff from the code we forked from
ADT that we figure we couldn't do a better job of, like the layout editor.
Start small, support basic use cases and grow from there. Make it a real
community thing built by the community, give them a real sense of ownership
over it.I'm going to give this some though. I'm heavily into building IDE mode
lately with the work I've done with the LaunchBar and Qt and Arduino build
and launch support in CDT. All that is fresh on my mind. Just need to
figure out how to set up JDT properly. I think it can be done and done
well. I'll see if I call my own bluff before you guys do :). At the very
least, I'm going to start prototyping and see where it leads.
- Doug.
On Fri, Jan 1, 2016 at 9:43 PM, Doug Schaefer cdtdoug@xxxxxxxxx wrote:
Hey gang,
I have to apologize, but a year or so later I'm finally getting around to
trying out Andmore looking for things to fix up. It turns out to be pretty
easy to find things that are broken.So my first question comes as I try to create a new project targeting my
Priv which is 5.1.1 which is API 22. The layout editor complains "This
version of the rendering library is more recent than your version of ADT
plug-in. Please update ADT plug-in." And I see bug 462620
https://bugs.eclipse.org/bugs/show_bug.cgi?id=462620 stating that we
don't actually support that level and 23.Have we updated Andmore with the latest patches to ADT? ADT is clearly
evolving at least a little to keep up with API releases. What is our plan
to keep up with it? Is it as simple as seeing what they've done and
applying the same code fixes albeit with the new package names?To take that thought even further, did we really hurt ourselves by
changing the package names, and thus file paths, in the code making it
almost near impossible to keep up? I fully expect Google to keep ADT at
least up to date with API releases which means we will need to update
Andmore as well.I love the fact I can easily clean up things in Andmore that violate
Eclipse IDE UX especially when combined with other plug-ins for Web and IoT
development. But it's really unusable if we can't keep it up to date easily
with API releases.Thoughts on how we can fix this? Do we need to redo the fork and keep it
as a fork and not update so much?Thanks!
Doug.
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________ andmore-dev mailing list andmore-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________ andmore-dev mailing list andmore-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
--Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com
Please do not send me questions directly. Thanks!
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev