[muzani]

I've been developing Android since 2012. It was worse then. Still sucks now but isn't as bad. Esoteric errors are still the norm. With 10 years of experience you only have to swear a whole day when updating a library, instead of spending a week.

GPT does poorly with beginners - it's definitely something humans have advantage with AI and I expect the gap to get bigger.

I do not touch legacy projects anymore because they're always horribly broken, half the libraries no longer exist. Many of them are easier to rewrite than fix. You get weird bugs where A needs to be 1.71.0 but B needs A at 1.69.0 or 2+. Upgrading A to 2.0.1 will fix A and B but break CDEFG. Upgrading everything to max breaks switch-case, turns some of your brackets to lambdas, requires you to change your UI from XML to Kotlin, etc, etc.

If you want something to hack stuff with, I made this: https://github.com/smuzani/android-minimalist-template

Originally it was designed for AI with smaller context windows. But it works as a simplified version of our production codebase. The principle behind this is that you should have good peripheral vision and that the shape of the code resembles what it's trying to build.

[iiJDSii]

Funny enough I actually did Android development contract work circa 2012-2014. I never did anything more complex than working with internal phone components (bluetooth, accelerometer/gyroscope, GUI/text, etc) and SQLite, but even so I quickly decided I wanted nothing to do with that platform.

Coming back a decade later for a side project, I guess I have the same opinion.

Now with the help of GPT-like assistants, I'm sure I could slog through some fairly vanilla development tasks like I did in the past, but when it comes to building anything a bit 'outside the box', no thanks.

Thankfully there are hardware equivalent packages (mini linux development machines like raspberry pi) that fit the bill, but they aren't as ubiquitous or nicely packaged as a modern smartphone unfortunately.

One wonders if there's some opportunity there, take all this great generic smartphone hardware (a $100 phone now is crazy) and package it with a developer-first OS. It could just be a linux system with a dumb, button-focused frontend for users to mimic Android/iOS.

[jinushaun]

I hit the same thing over a decade ago. Stick with Android and make a lot of money but hate life, or switch to something else and be happier.

[llmblockchain]

> You get weird bugs where A needs to be 1.71.0 but B needs A at 1.69.0 or 2+. Upgrading A to 2.0.1 will fix A and B but break CDEFG.

Sounds like "modern" web development.

[vdfs]

It would be interesting to see where this doesn't happen, you can't just update stuff without considering breaking changes and new bugs in new updates

[deprecative]

Difference is that you only have to take your lunch break for it to happen in web dev. By the time you get back to work the following day the framework you're using is deprecated. At least with other platforms there tends to be a bit more stability.

[prothy]

Web libraries don't update more or less quickly than any other platform. The "issue" with web is the pace at which new frameworks are released but at this point even React is over ten years old. It's not that bad. Things are more stable than they used to be and new concepts are quickly adopted by each framework so you aren't forced to switch to something new, see for instance signals.

[nvy]

For someone who has never written an Android app before but knows Java, what's the "happy path" to getting a native MVP out the door in 2024? Must I learn Kotlin? Is there a "blessed API" or design pattern these days that's better supported than the others?

[muzani]

You don't have to learn Kotlin. It cut down LOC by about 40% by the time I picked it up, but today's Java has become more efficient and supports things like @nullable. Kotlin is nice though, and it leads into more advanced things like Jetpack Compose for UI and Kotlin Flow which is a nice way to do reactive programming.

Reactive programming is useful for front end because the UI will update as soon as the data downloads, so it scales linearly with complexity and API calls, instead of an exponential mess of if-else.

You can use the github repo I linked. I designed it to be complex enough to handle the harder tasks but simple enough for a beginner to reverse engineer. Just download, run to see it work, and hack it into what you need.

[nvy]

Thanks!

[Vanit]

Hearing about this is very reminiscent of current day React web dev as well.

[jfengel]

Oh, are GUIs not XML any more? Good. I am a programmer. Don't make me learn yet another language with no debugging tools. Just write the UI in the same language as the rest of my work.

(I look in on Android every few years, but I haven't done any real work in it.)

[muzani]

Haven't used XML for them in over 2 years (excluding replacing legacy code and fixing typos). They went deep into XML+data binding which people liked for a while, because you could do UI tests without building the whole UI and such. But it wasn't so good in production because building everything from XML was making build times long. So while you could test that it's outputting the correct UI content within 2 minutes instead of 12, it also meant assert(1+1==2) took 2 minutes too.

I believe deprecating kapt now also breaks data binding, though I don't know if it breaks all the other basic XML layout stuff.