Live data from Hacker News

It’s Been Real, Android: Why I’m Retiring from Android

raptureinvenice.com

301–310 of 342 posts

Re: It’s Been Real, Android: Why I’m Retiring from Android

#301
post #283

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.

Ant builds have always been unmaintainable messes IME, via the incredibly verbose syntax and difficulty of organising tasks effectively. I have many issues with gradle but it at least seems to result in reasonably concise well-factored builds most of the time.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#302

Earlier 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.

Personally, I would rather builds be slow than have my build mysteriously break when I'm in that 1%.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#303
post #141

Just 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.

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

#304

Developers 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…

Android is not open at all, "russian Google" - Yandex - tried to build their own android phones but vendors dropped them because google just came to them and say "hey guys if you will be with them - we won't allow you to use google play on your phones at all". How it is open? i have no idea why it is open.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#305
post #303

Earlier 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.

But do you want to do that on every platform?

Re: It’s Been Real, Android: Why I’m Retiring from Android

#306

Earlier 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.

I'm just suggesting that people are assigning blame in the wrong place. It's typically not Gradle's fault, but just that Gradle is being asked to perform a bunch of expensive (and often unnecessary) operations, like

- 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

#307

Earlier 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.

The authors main complain was that it takes two minutes to start the emulator. And I agree that it is a Pita. But as a mental exercise or fun experience, you should 1) Picture it in your head 2) Make a plan 3) Write it down 4) Read through it and fix errors 5) Test it on the emulator.

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

#308
post #143
post #49

Earlier 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.

So it's like make then? We've had tools to do this for 30+ years.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#309
post #303

Earlier 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.

Hahaha, no. I'm not buying for a second that you are proficient and current in every kind of programming there is.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#310
post #302

Earlier 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%.

For me it depends. If I'm in a development session with lots of iterations where build speed is the bottleneck, I'd take my chances (I do anyway, have to resort to manually compiling individual files). For production/CI/other builds it's a different story, although those usually get built clean so it's not even a consideration.
Post reply on HN