5 ms·

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 o

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.

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.