Earlier quoted context omitted.
It's slow, underdocumented, and unreliable. There are too many ways to do anything, and it's too easy to add a "1-line fix" that does something unmaintainable. It's better than ant, but a lot worse than maven.
Define better? Ant was unquestionably faster and extensible via custom tasks which the Android team could have done. Gradle will never be a fast build tool due to its design goals. It was a clear mistake to switch to them if you applied any knowledge of build tools.
It’s Been Real, Android: Why I’m Retiring from Android
301–310 of 342 posts
Re: It’s Been Real, Android: Why I’m Retiring from Android
#302Earlier quoted context omitted.
> Gradle badly needs performance improvement gradle --daemon is a hack, I guess, but I always use it for my builds (even aliased gradle to gradle --daemon). It's far too slow otherwise. On newer gradle releases I believe the daemon is enabled by default.
My problem with gradle is the built in Java dependency resolution is way too aggressive. If you change a class with a static constant it recompiles everything. Even if you don't, it will compile the whole dependency graph to handle some theoretical edge case when it would be enough to compile just the modified file 99% of the time. Oh well.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#303Just like the web platform, Android is hugely improved when you leverage the community libraries and tools they provided. Gradle actually helps a lot with that, since its clear dependency management makes use of external libraries a breeze. If in 2016 you're still complaining about AsyncTasks and its management, you certanly have missed a lot of progress in the last few years. It's not unlike having people complain a…
"All-in-all, I honestly think the author didn't really look into Android all that much to have complaints that he had." The author states pretty plainly the biggest reason for leaving Android development was he didn't have time to keep up with all the developments in both Android and iOS communities.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#304Developers do need to pick a set of core technologies, and stick to it or a career can fall apart I bet. I don't know from experience. I've been a Java DEV ever since MSFT tried to hijack the Java language with a proprietary version back in 1998, and I abandoned MSFT and never went back. I can imagine trying to be both iOS and Android developer would be about as insane as trying to be both .NET and Java developer. Oi…
Re: It’s Been Real, Android: Why I’m Retiring from Android
#305Earlier quoted context omitted.
"All-in-all, I honestly think the author didn't really look into Android all that much to have complaints that he had." The author states pretty plainly the biggest reason for leaving Android development was he didn't have time to keep up with all the developments in both Android and iOS communities.
Then he's not a very good programmer. This is technology: at the rate it's advancing, even tools from 5 years ago are out of date. You have to constantly keep up with the latest advances in programming if you want to stay relevant.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#306Earlier quoted context omitted.
Did you try profiling your build? https://docs.gradle.org/current/userguide/tutorial_gradle_co... If not then you shouldn't assume it's Gradle's fault. A lot of Android Gradle builds are slow because they proguard lots of class files, merge large dex files, etc. Which is all optional functionality of the Android plugin, not inherent to gradle.
Do you realise how insane it sounds to tell someone to profile their build config? The fact that people need to do this is the problem.
- The build might have dependencies with dynamic versions or changing modules (aka snapshots), meaning that Gradle periodically has to download the latest version.
- The project might have proguard enabled for dev builds, which isn't really necessary. (As long as you smoke test release builds, which is a good idea anyway.)
- The project might have dex merging enabled for dev builds, which isn't necessary unless you need to test something on a pre-ART device.
- Engineers might be passing --clean or --refresh-dependencies, out of habit, when they're not needed.
You could criticize Android's architecture for not being conducive to incremental builds, or you could criticize Android Studio for generating build files with some expensive functionality enabled. But none of this has much to do with Gradle.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#307Earlier quoted context omitted.
You are confusing scopes here. The parent almost surely meant those approaches applied to a single task (meaning a few hours to a day of work), not to building an application.
Being pedantic - the parent was commenting on the article, not on a comment here dealing with a single task or one small piece worth a day's work. I see no indication on how you could make a statement saying "...almost surely meant..." Based on the information available, either of our premises could be true.
You could start with a small ten minute fix, then work your way up. The feeling when it compiles and just works on the first try is amazing.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#308Earlier quoted context omitted.
> The only thing worse than gradle is ANT, which it replaced. What's wrong with ant? I liked it.. It was simple to understand for the most part. It also made it easy to develop without an IDE, although I'll admit I don't know how easy it is now as I stopped doing Android a year ago
And that's about all it does. Gradle has proper dependency managment with Maven repository support (add one line and your library is in, no fsckery with JARs and whatnot), has scripting in an imperative language instead of craziness of XML (we use it to automate releases, uploads, Git commits, etc.) and really good plugin support. It's also slow as arse unfortunately.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#309Earlier quoted context omitted.
"All-in-all, I honestly think the author didn't really look into Android all that much to have complaints that he had." The author states pretty plainly the biggest reason for leaving Android development was he didn't have time to keep up with all the developments in both Android and iOS communities.
Then he's not a very good programmer. This is technology: at the rate it's advancing, even tools from 5 years ago are out of date. You have to constantly keep up with the latest advances in programming if you want to stay relevant.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#310Earlier quoted context omitted.
My problem with gradle is the built in Java dependency resolution is way too aggressive. If you change a class with a static constant it recompiles everything. Even if you don't, it will compile the whole dependency graph to handle some theoretical edge case when it would be enough to compile just the modified file 99% of the time. Oh well.
Personally, I would rather builds be slow than have my build mysteriously break when I'm in that 1%.