This is super interesting, but the problem I have is that this guy's eye for design leaves a lot to be desired. When was the last time someone built a clunky table directly into the UI and added fully styled table rows dynamically? Why not modernize the design, and use a styled list view with a data adapter and try this again on each platform? It didn't surprise me at all that he struggled with the table in basically every scenario. There's a reason (or two) they've fallen out of fashion, imo, and it sort of clouded the assessment of everything for me, since he kept mentioning struggling with the table.
As an Android developer I looked at the code he wrote and felt bad for him. Of course it was painful trying to set all your styling up programmatically for the table! Use a viewholder pattern and a recyclerview/adapter then throw your data into the adapter. Make a simple xml file for your rows and inflate those into the viewholder then you're good to go! None of these clumsy declarative attempts to do what xml does well.
It's still a great write-up, but that part hurt me.
This is exactly the kind of thing that is unnecessarily hard in non-React-like UI frameworks. XML definitely does not do this well!
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.
I mean if you want 3 identical rows to just statically be at the bottom of a view you can always define the row in XML then put it in a vertical LinearLayout at the bottom using the <include> tag. You maintain modularity without cumbersome code to deal with.
This has the added benefit of being able to see the views without having to compile your code.
Please try out one of Flutter or React Native. I think you’ll be surprised how much nicer they are for anything like this. The code is certainly not cumbersome when compared to the equivalent XML.
Also, in Flutter and React Native you don’t (typically) have to wait for your code to compile as they do hot reload.
You, and everyone else who makes this argument seems to blatantly dismiss the tooling around Android, specifically Android Studio and the layout preview panel. The person you are responding to is talking about editing UI layouts in XML, using the preview panel, without building the project at all.
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.
For static layouts this can work pretty well. I think it is still typically a bit slower/more awkward. And often harder to change. (I actually have most experience with native Android.)
In my first job as android developer (circa 2010) I was tasked with porting a J2ME application with 30,000 lines of code in total to Android. Their primary condition was 'I shouldn't use any XML for layouts and any UI element should be defined only via code'.
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.
Hi, slightly unrelated to the thread, but do you have any resources you can recommend for modern Android UI development? (besides the basic google resources/ codelabs...etc)
Unfortunately I cannot. I've mostly taught myself by reading exactly those same specs you're talking about and watching a lot of YouTube.
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.
This. Unless you work on internal projects, more than likely you’re going to have to dig much deeper to achieve custom styling and animations. I only have experience in iOS, Android and react native, but it’s so much easier to get there with react native. It would have been more useful to see how other cross platform solutions deal with custom styles and come to a conclusion that includes trade offs between them.
