It's still a great write-up, but that part hurt me.
I later understood that, it was because they wanted to use the J2ME-to-android bridge I develop for their other J2ME apps and XML layout dependencies would have been a hindrance. Since, this was very early in the android development ecosystem and many devs were Java developers before; usage of XML layouts for UI wasn't strictly mandated as it is now. I did complete the bridge in 3 months and the application performed as it should.
But, I'm glad I never had to do everything related to UI programatically on Android ever after.
I know I'm a thoroughly inadequate Android developer because I've only ever worked on a small team at a small company and have had 0 tutelage, but what I've taught myself in the past 3 years boils down to:
Libraries to use: Retrofit, RxJava, Dagger2, Room
Use AndroidX over support/compat whenever you can.
Kotlin is amazing, though I'm still learning. If you know Java then Kotlin makes a lot of sense.
Use constraint layouts so that when you try to dabble with AndroidX motion layouts you'll have an easier time.
MVVM is commonly accepted architecture, and I like it personally.
Use single activity architecture: 1 activity with many fragments is the industry standard (or it should be). Some exceptions exist but mostly that's how it works.
XML files are your friends and editing them directly is faster and often easier than the Visual Builder in Android Studio.
Be sure that when you install the emulator you have it integrating with HAXM or HyperV or whatever they have it integrate with these days: it'll make debugging on the emu a lot less painful.
In React Native or Flutter I can just declaratively go from an array to rows of UI. It will be a few lines of code and will be incredibly clear (and easy to change).
In Android or iOS I can either do something procedural (which is messy, hard to reason about etc) or do something horrifyingly boilerplate-y (as you suggest), spreading things across multiple files and greatly increasing cognitive load.
I've worked with native Android, native iOS, React Native and (a tiny bit) with Flutter. I really wouldn't use vanilla native Android or iOS (even for a single platform app) unless there were some particular requirements around perf or whatever; so much more tedious, slower and (this one is subtle and will be missed by simple comparisons) so, so much harder to go back and make changes or additions to.
SwiftUI and Jetpack compose look promising for the future. But neither are ready for mainstream (enterprise?) use today.
This has the added benefit of being able to see the views without having to compile your code.
Also, in Flutter and React Native you don’t (typically) have to wait for your code to compile as they do hot reload.
Everyone loves to talk about "hot reloading" and obsess over reducing build times incrementally as if that's the only way to develop anything faster. No matter how fast your "hot reload" is, it'll never beat the layout preview panel in Android Studio, which is directly rendering your xml in real time, without compiling or building anything.
You get both with Android Native, layout preview and hot reloading.
If anything, they would have had a way easier time using Compose, since its principles are reminiscent of the ones of flutter.
Or if they had just read a beginner guide or two :/