This code tutorial tells you which lines to add to your build script to import the library, and tells you what classes to use, but does not tell you what imports to use to get the classes into scope *starts throwing things*
Every day I do Android development is a bad day
What I think was happening here
- There is a tab in current Android Studio, "Build Analyzer", and they moved the full gradle logs (such as would allow you to debug an error in your build.gradle) there
- However if the failure in build.gradle occurs "too early", for example if there is a toplevel variable def which throws an exception, then Build Analyzer does not appear
- Shrug emoji the size of the moon
Looks like this is still not fixed.
A "cool" thing about building for Android is that if there is an error in your gradle script, the backtrace doesn't show where in *your gradle code* the error occurred, instead it shows where in the Java code of the gradle executable you can find the place where the error is printed out.
My hatred for Android Studio only grows every day. The only program I hate more, I think, is git, which makes today's problem, *which is about the interaction between Android Studio and git*, all the more infuriating
(Android Studio is failing because it is invoking git, which is not installed, and I cannot fix the problem because Android Studio cannot tell me why it is invoking git. Humiliatingly, I have lost an entire workday to this.)
Incidentally, re: the problem here https://mastodon.social/@mcc/109842751686859648 where it appears(?) to be cutting off the stacktrace before actually telling me where in my code the error is occurring, it turns out there's a --full-stacktrace option if you use the Gradle command line. --full-stacktrace causes it to print out *slightly more* of the stacktrace, but not the full stacktrace or even enough to identify where the problem is occurring
Okay. The problem is solved. The problem is org.gradle.process.internal.ExecException is not an Exception, it is an Error, and it was escaping my try { } catch (Exception e) { }. This is a rookie mistake I should not have made, but in my defense, somehow the same basic code was throwing a different exception during `gradle sync` than it was during `gradle build` (?!), so since the try { } worked in sync I assumed the problem had to be some other git invocation somewhere else I had not yet found
Java !!!
Final update: The note about ExecException above is wrong. The problem was that, somehow, during some stages of build, gradle/Android Studio were executing the wrong version of the code. I thought that changing "Exception" to "Throwable" had fixed it, but in fact what fixed it was making a change (any change) to build.gradle in Android Studio. Renaming "git" to "lit" also fixes the problem, in testing. This somehow does something a gradle sync & clean build didn't.
Android Studio is TERRIFYING.
…no…no, no it's not over. It's even stranger and more unfathomable than I thought.
On the first build after checkout, clean, git clean, or any change to build.gradle, it works.
On the *second* build, it fails, with an exception that's clearly, unambiguously, inside a try-catch that should catch it. Catching "Throwable" instead of "Exception" doesn't help. This is the Terminator Exception, it can't be caught, it can't be stopped, and it only flags on every *other* build.
In the *build script*.
@mcc Every so often I wonder why almost every Android apps isn't as polished as the average iOS app and your struggle with Android dev answer that in a funny (if sad) way
@mcc @vikxin The horror stories I heard from the Android devs at work... shit like
"Oh yeah this bug is only exclusive to Samsung phones because they re-implemented this API in a stupid way"
or
"Oh yeah that flagship phone that costs 800$? It has a shitty I/O controller so caching shit is awfully slow"
Boggles my mind
@Eramdam @vikxin I mean, device fragmentation is a separate problem. If your platform is fragmented, that is a "real" problem. You'd have to work very hard to solve that problem, if you solved it at all. That is not a problem Android *created for itself*. It's a problem that comes naturally from being the platform that isn't locked down and single-vendor.
@Eramdam @mcc the absolute shitshow that is non-flagship handsets, even compared to 3 year old flagships, is absolutely terrifying. Beyond just the "there are too many SKUs that we can't support them all", the sheer disdain for any sort of quality, completely separately from specs, on lower end models is appalling. It's no wonder Apple has relatively few models.
@mcc i did android development in university once and that is what convinced me to buy an iphone (i don’t know if iOS development is any good but at least I don’t know for sure that it‘s terrible)
@technomancy @mcc i don’t need to know!! I don’t need to know!!!
@halcy @mcc iOS development can be a pain in the ass but it really is an orders-of-magnitude difference when it comes to Android. It feels like at every possible fork in the road, Google selected the option labeled "MOST CONFUSING FOR NO GOOD REASON".
Even Android Studio itself feels like the platform is actively flinging feces at your face while you try to build for it. It's just… _inexplicably_ bad.
@halcy Inspired by @mcc's earlier post, I decided to try to compile Tusky with https://www.heap.io installed, 'cause hey, that's my day job.
What I like about Android Studio's compile-time errors is that they're concise and actionable.
@mcc I’ve never done android dev. Does it involve Java?
@mcc I knew I would never be able to tolerate Java the first time
I had to type “.equals()”
(Of course, it was my job for several years, and I still couldn’t make myself learn it because I hated it so much, and I think I’ve managed to forget most of it already.)
I had assumed as much but had never looked into alternate development platforms for it.
@mcc My impression is that Build Analyzer is for something entirely different. It was giving me advice on what was taking a long time during the build
@mcc Yeah, that happens disconcertingly often...
Yesterday I found out that breakpoints no longer work, and I don't know what to do about it
@mcc I'm always a bit surprised by such visceral hatred of git, but typically assume good reasons. Have you elaborated on the topic anywhere?
@mcc what is this twitter dot com does it even exist
@mcc within a dream
@blakeyrat @mcc yeah, definitely true for me. Years ago I used subversion for a contribution on a small project that I don't know anyone else was seriously working on in parallel, apart from that it all was git, which I expect to be a pretty common phenomenon these days. So yeah, I'm surprised because I don't feel I suffer that much, but maybe I really just think sand is comfortable because I've never known a bed. Genuinely interested.
@hllizi @mcc You could probably make a good argument that Git is better than Subversion, which had all of the same mistakes Git makes but ran a bit slower.
Personally I liked TFS, and it makes me cry to think its development is canned forever because Microsoft went all "open source-y" and stopped development on it.
@blakeyrat @mcc unfortunately you never get to try the alternatives unless you're extremely lucky, because the network effects trump everything. I'd like to try darcs. And recently someone here mentioned a system, I've forgotten the name, that supposedly is very good with binary files.
@hllizi @mcc Actually I take-back what I just said: I could develop Skyrim add-ins using Subversion because it allowed you to only check in a few files without requiring you to check in entire folders. For stuff like game mods, you need to check in the 4-5 files of your mod and not the 17 GB of the rest of the game, even though Gamebryo requires them all in the same folder.
@hllizi BTW even if you don't personally suffer from it much, it's a badly-written piece of software. Even people who like it admit the UX is crummy. And it doesn't separate the user interface from the scripting interface, so people who want to write quality GUIs for it are limited to what the UI supports-- some of which is impossible to represent cleanly in a GUI (for example, pre-commit hooks)
@hllizi Made worse, my initial experiences with it were on Windows, where it was buggy as hell until Microsoft swooped in and fixed everything-- even if you did nothing wrong you got constant "detached head" errors, because that "quality" Git product was "ported" to Windows without doing anything to address Windows' file-locking strategy. Where "port" is defined as: doing the bare-assed minimum to make it kind of sort of work, a bit.
@hllizi Anyway sorry I'll stop spamming you, I could talk about how bad Git is for hours.
@blakeyrat it's OK, it's what I asked for, after all.
@hllizi Someday I'll write a blog or something about it but probably not any time when I'm required to use it for work because it just makes me red-faced angry.
@mcc wait, we're allowed to criticize <undeserved holy choral montage> git?
I feel seen
@mcc one of the things you like, I suppose?
@mcc But Kotlin is there, too, and it has type inference. Upside for me: don't have to use either. Downside for me: have to use PHP.
@mcc
Ah, OK!
@mcc i remember you making these posts about how fucking terrible android deveopment was, what, like half a decade ago? more?
it never changed, huh
@Xkeeper It never gets better. I'm not this time anymore running weird unsupported things like NDK or command line gradle. I'm using the brand new shiny "kotlin" language Google replaced Java with on the newest stable version of Android Studio. Everything is still fucking broken at the lowest, most core levels. I'm still getting screwed over by whatever "gradle" is.
@mcc guess you can give it a failing gradle! haaaaaaaaaa :(
@mcc I picked up android development for the first time in nearly a decade and I am absolutely hating it
What a nice thread to accidentally stumble upon as I open my socials ha ha ha