Hacker News Reader

Comment by matchbok | Hacker News Reader

Ha, I wish. 10 years, and Android still doesn't have a good way to accomplish navigation, view models, state retention, or anything. 10 different support libraries, everything deprecated once a year, etc. The entire platform is a mess.

View on HN

I haven't done Android dev in a few years, but last time I did the best advice a new dev could get was, "ignore any best-practice or how-to element of Google's Android docs. Ignore the old, official way of doing [thing]. Definitely ignore the new, official way of doing [thing]. Instead, use Square's Android libraries, read their blog posts, and do exactly what they do."

Sounds like a very Open-Source approach. Ignore the documentation, ignore the tutorials, grab the Repo of a working project close to what you want and read the code, until you can modify it.

Kinda, but Square actually had an alternative way of managing UI flow, enabled by a couple libraries they wrote, and a bunch of other support libraries for basic stuff like making HTTP requests, all of which was so much saner than Google's standard way(s) of doing things. You'd end up writing Square/Android, in the sense of GNU/Linux, if that makes sense. Why Square, of all places, straight-up killed it on that particular platform, I have no idea (no shade intended to folks at Square, it's just unexpected situation). It's not like they just had a really good project template or something.

> but Square actually had an alternative way of managing UI flow

Are you talking about Flow/Mortar? Those were pretty much abandoned and were, imo, overly complex.

That said, the Android UI flow was pretty bad before. Hopefully Compose makes it better.

IIRC Square had a technical manager (maybe CTO level?) who came from Android at Google, which may have helped. Square also open sourced early iOS tools like PonyDebugger which were ahead of the game when they came out. When they hired Jake Wharton they got a stellar champion of open source software creation whose focus was Android.

This has pretty much stopped a few years ago, most of the community has now standardized on AndroidX set of Google helper libraries for UI, UI state management, on-device storage and async code.

Jetpack Compose subsumes many of those and in a very elegant, coherent way, much like Swift UI, but IMHO better because it's based on pure composable functions.

All well and good, but only if you're just starting to build your app literally today. If your app was built more than ~6 months before the current iteration of Jetpack/AndroidX/etc, you'll never finish catching up with converting your code to the latest new patterns that they introduce.

We regularly update our apps when these libraries update, even for projects 5+ years old. You don't need to switch to the latest "architecture" all the time.

It's trivial to add Compose to mature apps, you don't need to convert the entire app immediately.

Well sure, thankfully all these myriad ways of doing the same thing coexist without much issues, since they're all just wrappers around findViewById(). But I just wish they'd settle on a pattern that will endure for more than a single major version of the library.

That’s the problem. Once you’ve started adding Compose to your app and are finally midway through it there will this new shiny toy and the entire herd will be playing with it. Then what? Finish compose or leave it there and start with the new toy?

While there’s always a fundamental way of doing it - you just need the damn view! But no! To avoid even writing exactly 3-4 lines of findViewById per class on an average someone decided it’s revolutionary to add Butter Knife to the project and so on.. Or maybe there’s some one who gets kicks from seeing so many annotations in the classes!

Android ecosystem is really plagued by this fad culture imho.

PS. Nothing could make me an iPhone user. But finally being an Android developer did that! Really that’s the reason.

I seriously don't understand this reasoning - why do you need to follow the herd?

Even on iPhone you're so happily plugging away here - we're still using ObjC with their views instead of new SwiftUI hotness because it still makes sense there. What makes you run after every single shiny thing for no reason? Who's paying for all that developer time?

iOS has similar issues but the tools are much worse and backporting is nigh impossible.

Android dev is doing pretty well from my perspective - Compose works on Android versions years old while SwiftUI barely functions on iOS 13 and does not work on iOS 12.

Reply on news.ycombinator.com