5 ms·

Very interesting to read this from the other side of the pond (Android dev). Android has a bit of a different architecture history : at first the framework tea

Very interesting to read this from the other side of the pond (Android dev). Android has a bit of a different architecture history : at first the framework team has built it as modular components (IIRC you were not even supposed to be able to subclass Application) with no recommandation on how to architect your app code outside of that. It lead to MVC with all the business logic in massive activities .. at least for most companies. We now have the same jungle of really abstracted patterns with some of them actively fighting against the framework by rewriting it. To be fair, parts of the framework like fragments have been a disappointment (and again to be fair Google is hard working at addressing this). I just want the minimum amount of abstraction that gives me the advantages I want (separation of concerns, testability) and not rewrite everything from scratch.

gumballhead 9y ago
Exactly what I was thinking when I read that. Original Android didn't go far enough, then RxJava and clean architecture went way too far. Fortunately the new architecture components like LiveData and ViewModel coupled with kotlin (especially coroutines, wow where have those been all my life) are simple to use and understand while providing the right level of abstraction. Android development has become really nice lately.
nsainsbury 9y ago
Yes, I've noticed this a lot with Android projects too. Recently I looked at a project that openly bragged about using: RxJava 2/AutoDispose, Conductor, AutoValue, Glide, ThreetenABP, Inspector, PSync, Chuck, Scalpel, Stetho, Room, Firebase, Butter Knife Look, not all of those things are bad but jesus fucking christ, what happened to exercising restraint and good judgement with introducing dependencies in to your projects? Dependencies are a LIABILITY and for something to be introduced it has to be worth it, not just provide some minor syntactical convenience (like Butter Knife, etc.)
- pjmlp 9y ago
  It is called CV driven development.
  - amigoingtodie 9y ago
    This made me laugh.
- brendanw 9y ago
  +1 Butterknife doesn't reduce lines of code, introduces new syntax to learn, and carries additional risk (eg it has introduced unexpected issues). I believe some of the framework+library bloat is intellectual signaling.
  - on_and_off 9y ago
    I have just arrived in a new company where they use BK. I have always been doubtful of its benefits but after giving it a fair chance, that's still the case :/ It removes a tiny bit of code, that does not seem that helpful to me. I still have to add the id in the java code, and I would have to count to know how many characters I save that way. Not many. And now I need to worry about how the bk magic happens to be sure to do not leak that way. I am used to databinding, where I initially had the same reaction .. but after some use it allows you to gain a lot of time with two ways binding and binding adapters while staying at a sane level of abstraction IMO (it just writes the boilerplate code for you) .
- hoskdoug 9y ago
  Odd example; Butterknife greatly reduces boilerplate around accessing views in Android. Why wouldn't you use it? Don't you use Retrofit for your network API code?
- pvinis 9y ago
  That is true. Now imagine how bad it can get with React Native apps. I'm struggling to keep everything contained.

gumballhead 9y ago

Exactly what I was thinking when I read that. Original Android didn't go far enough, then RxJava and clean architecture went way too far. Fortunately the new architecture components like LiveData and ViewModel coupled with kotlin (especially coroutines, wow where have those been all my life) are simple to use and understand while providing the right level of abstraction. Android development has become really nice lately.

nsainsbury 9y ago

Yes, I've noticed this a lot with Android projects too. Recently I looked at a project that openly bragged about using: RxJava 2/AutoDispose, Conductor, AutoValue, Glide, ThreetenABP, Inspector, PSync, Chuck, Scalpel, Stetho, Room, Firebase, Butter Knife Look, not all of those things are bad but jesus fucking christ, what happened to exercising restraint and good judgement with introducing dependencies in to your projects? Dependencies are a LIABILITY and for something to be introduced it has to be worth it, not just provide some minor syntactical convenience (like Butter Knife, etc.)

pjmlp 9y ago
It is called CV driven development.
- amigoingtodie 9y ago
  This made me laugh.
brendanw 9y ago
+1 Butterknife doesn't reduce lines of code, introduces new syntax to learn, and carries additional risk (eg it has introduced unexpected issues). I believe some of the framework+library bloat is intellectual signaling.
- on_and_off 9y ago
  I have just arrived in a new company where they use BK. I have always been doubtful of its benefits but after giving it a fair chance, that's still the case :/ It removes a tiny bit of code, that does not seem that helpful to me. I still have to add the id in the java code, and I would have to count to know how many characters I save that way. Not many. And now I need to worry about how the bk magic happens to be sure to do not leak that way. I am used to databinding, where I initially had the same reaction .. but after some use it allows you to gain a lot of time with two ways binding and binding adapters while staying at a sane level of abstraction IMO (it just writes the boilerplate code for you) .
hoskdoug 9y ago
Odd example; Butterknife greatly reduces boilerplate around accessing views in Android. Why wouldn't you use it? Don't you use Retrofit for your network API code?
pvinis 9y ago
That is true. Now imagine how bad it can get with React Native apps. I'm struggling to keep everything contained.