I've stopped counting how many times I came back to an Android project after only a few months, only to have Android Studio force me to update Gradle and dependencies and whatnot, and break everything.
* Of course one could blame me for not learning the ins and outs of the build system!
Unfortunately this doesn't actually protect you from that since you still have to deal with that for both the actual "make an APK" step as well as the Java bindings for critical features.
This. And people are surprised that many just wrap websites as apps on Android.
Try and do it. if you run into a deal breaking issue with PWA features, then wrap it in a minimalist app shell.
Best case: everything works on Android and iOS and it's also a website.
Worst case: you will end up doing some platform specific code and dealing with the app stores like you were going to do anyway.
Average Case: everything will work on android and some things will be broken on iOS.
Unfortunately you can't just ship a PWA with no wrapper. You have to build a special wrapper app that hosts the PWA and you have to use Android Studio and Gradle and all that crap.
Updating the wrapper is surely still easier than a whole app, but it's nontrivial and it's frustrating to still have to deal with the platform BS for a pure web app that uses no platform APIs at all. More work than I wanted to deal with for a hobby project, anyway.
You can… but it won’t be in the Play Store. Disqualifying for many, but not all.
I don't think so.
Even now if I need a "native" app I'm looking very seriously at React Native first before rolling two totally separate apps in different languages.
All development work takes place in VS code, including the incredibly incredibly convenient and performant hot code reload, as well as the final step of "flutter build ios"/"flutter build aab"
It is an experience with very few pain points* and I find it to be very enjoyable.
*except for the random Cocoa Pods error every few months which can be solved by random helpless googling and then deleting the podfile.lock
VSCode isn't bad but disliking Android Studio just feels like you started with it and didn't want to learn a different tool.
It's a native Android app (Kotlin) which isn't developed using Android Studio. Gradle only.
In other cases, updating Gradle won't give any problem. You can build the APK fine. Debugging the build system is annoying :D
This used to be 5-6 years back. These days it is very stable.
I actually _like_ Java, so it's not that I hate Android, but frankly, I have no idea what it is even doing downloading and generating gigabytes of crap with inscrutable huge log files. Most of my applications' Java/GUI parts are no more complex than a hello world -- many times I find it easier to just rewrite them from scratch than even try "upgrading" them using Android Studio.
The Android tooling is basically a textbook definition of oversized enterprisey software. I really wish there was just a frigging (resource) compiler, linker and maybe packer that I could invoke from the command line in simple steps.
Yeah, I feel the same. There are CLI approaches that I have encapsulated into Makefile ( https://ashishb.net/all/use-makefile-for-android) and GitHub Actions (https://github.com/ashishb/gabo/blob/master/src/gabo/interna...) but they do require time to set up.
As a Gradle veteran, I've written in detail about this previously:
https://news.ycombinator.com/item?id=38875936
TL;DR: Gradle is too powerful (which is fun and seems valuable at first!) with too many footguns. Combine this with the mandatory update migrations and you're literally signing up for future pain compared to using a lower change-rate build tool like Maven. Do you really need to run arbitrary commands to build your app? If so, take a deep gaze in the mirror and reflect on what you're doing with your life.
Had it not been for Android replacing Ant with Gradle, and most folks wouldn't even remember Gradle.
Gradle is not too powerful, it builds a build graph based on the .gradle file, and the building itself happens imperatively — but the actual execution is static, based on that fixed build graph. This configuration is cached and subsequent executions will all refer to this static graph to know what requires rebuilding.
This is the minimum required complexity/generality for a build system that is not “hardcoded” for a given task (e.g. to a degree maven, but cargo, go’s build tool etc all can only compile their respective languages on their own. “Plugins” can let them do more, but at that point plugins have to re-develop all the functionality of a build system - caching and parallelization), and as I mentioned there really are only a handful of tools capable of that.
As for valid criticisms of gradle - it’s API historically experiencing constant breakages, used to be dependent on JDK version (and lagged behind for a long time due to Groovy), which is more or less fixed now with toolchains, and the model not being clear enough for people not wanting to dive deep. E.g. I can count on a single hand how many people knows that doFirst/doLast should be used for the actual task itself, anything else will happen at the config build time which is not what you want.
Proguard is fun too, with how it'll carve out or break chunks of functional code if you don't spell out precisely what shouldn't get deleted/obfuscated.
Each time I have to touch it, it results in problems... Oh, you updated JDK? Gradle won't work. There is new Gradle? Tough luck it will break your build..
And with Maven it can update and the build keeps working just fine.
To that end I mostly ignore prompt "update gradle!" in Android Studio to avoid any issues...
Maven is virtually infinite extensibility via plugins. The difference is that gradle is easier to "hack" and put the build logic in your configuration...
> E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts.
This is not build shortcoming but rather detection what requires rebuild and what not but in the worst case scenario it rebuilds everything…
> Gradle can always keeps track of tasks correctly.
LOL, from my experience that is not true.
Also, if you have multiple projects using different gradle version this results in multiple daemons running in the background. Besides gradle builds as as slow as maven...
Losing the only task of a build tool, caching and parallelization.
No, the problem is that maven doesn’t rebuild everything. It is actually quite common in code bases that I had to run clean build instead of build to actually recompile everything that changed. I guess maven just doesn’t have an accurate build graph?
> LOL, from my experience that is not true
In what way is it not true?
Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant.
And multiple daemons — you can disable them, and they will go away if unused.
You are aware that Maven does offer paralle build, right?
> I guess maven just doesn’t have an accurate build graph?
You guess wrong? then
>> LOL, from my experience that is not true
> In what way is it not true?
Consistency of gradle build. You yourself stated just a paragraph above that sometimes you have to run "clean" xD
> Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant.
Again, learn the tool. Maven does offer parallel builds and is comparably fast…
> And multiple daemons — you can disable them, and they will go away if unused.
"but you are turning off the only feature of a build!!!"
Also - I had a setup open with gradle/kotlin-multiplatform project (shell with "gradlew" and Android Studio) and magically it fails to build with "Unresolved reference: kotlinx" even though I haven't done anything to the project and no ammount of running "gradlew clean" solves it... what a lovely tool....
That was in reference to maven..
Also, feel free to show me any benchmark showing maven being as fast as gradle. https://gradle.org/gradle-vs-maven-performance/
I tried and * commons took more than 2,5 minutes to build (they show 70s?) * tried their tests (medium project, https://github.com/gradle/performance-comparisons/tree/maste...) and maven compiled it in 4s and usual "clean install" took 14s but they don't enable paralel test run); then I tried running "gradle build" and... got an error:
``` FAILURE: Build failed with an exception.
* Where: Build file '/Users/wojtek/dev/tmps/performance-comparisons/single-medium-project/build.gradle' line: 16
* What went wrong: A problem occurred evaluating root project 'single-medium-project'. > Could not find method compile() for arguments [commons-lang:commons-lang:2.5] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler. ```
It's so nice that even gradle team themselves can keep up with their crap xD but of course it's probably due to convoluted setup... again - with maven you just clone and build and be done with it, with gradle you have to "stand on your head" to figure how to make any progress... I updated the build.gradle (according to https://docs.gradle.org/current/userguide/declaring_dependen...) and `gradle build` finished in 19s...
So your beloved gradle is 25% slower and can't even be compatible with itself...
I took a look at "large-multimodule" to have something more challenging but: they setup each project individually and for some convoluted reason configure maven compiler with `<source>1.5</source>` (and JDK21 complains) and same goes for gradle modules with broken `dependencies`. I adjusted it but then it turned out that the sources can't even compile (due to wrong arguments in tests) ffs...
Almost no other build tool has had so many conference talks regarding performance issues, and dealing with its gotchas as Gradle.
I am absolutely not bothered by XML and alia (btw, there are maven frontends in json/yaml, etc for those who are), and throwing out valid criticism over some straw man is not really productive.
Context: I worked on a Spring app many years ago and am picking Java back up.
But I have run into issues with multi-module projects and the like, and it can be very frustrating to realize that you are trying out some corrupt version. Nonetheless, maven is also a cool and stable tool, but you are better off adding a clean step from time to time.