Hacker News Reader

Comment by on_and_off | Hacker News Reader

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.

View on HN

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

It is called CV driven development.

This made me laugh.

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

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

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?

That is true. Now imagine how bad it can get with React Native apps. I'm struggling to keep everything contained.

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.

Reply on news.ycombinator.com