5 ms·

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 librar

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.

cromwellian 5y ago
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.
- dmitrybrant 5y ago
  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.
  - myko 5y ago
    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.
    - dmitrybrant 5y ago
      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.
    - crossroadsguy 5y ago
      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.
      - izacus 5y ago
        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?
      - myko 5y ago
        iOS has similar issues but the tools are much worse and backporting is nigh impossible.
intergalplan 5y ago
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."
- PicassoCTs 5y ago
  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.
  - intergalplan 5y ago
    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.
    - myko 5y ago
      > 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.
- izacus 5y ago
myko 5y ago
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.

cromwellian 5y ago

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.

dmitrybrant 5y ago
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.
- myko 5y ago
  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.
  - dmitrybrant 5y ago
    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.
  - crossroadsguy 5y ago
    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.
    - izacus 5y ago
      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?
    - myko 5y ago
      iOS has similar issues but the tools are much worse and backporting is nigh impossible.

intergalplan 5y ago

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."

PicassoCTs 5y ago
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.
- intergalplan 5y ago
  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.
  - myko 5y ago
    > 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.
izacus 5y ago

myko 5y ago

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.