Posts

Ghggghjkghjg kjhgkjhgk jgh jkghk gkjhg gk ggh # kjhgkhjgkjhgkjhgjh kjg khjg khgkg hkjgkg jkhg khjgjkhg k kg jh.

Android Don’ts: please abandon findViewById() and its pals as it breaches encapsulation # TL;DR Manipulating widgets directly is a bad habit as it breaches encapsulation and creates a tight coupling between presentation code and view layout declaration.

Android DON’Ts: life is too short for subclassing RecyclerView.

Android DOs: Data Binding adapters is a good place for custom view logic # TL;DR Custom view logic is present in almost any app, and Android Data Binding adapter is a better place for it rather than Activity, Fragment, etc.

ViewModel should be just data bag # TL;DR Since we have Data Binding, Don’t want to end up in another “Massive View Controller (Whatever)"-like situation?

Not all code is the same # Fighting the hard way for Clean Architecture and Separation of Concerns # TL;DR Code might be writing in the same language and might be residing in the same file, yet its type and character might (and will) be different, and that changes everything.

Naming is one of the most things in software development (probably, in top 3), but most developers still don’t get this.

MVI is probably not a good fit for android #

MV*: Mitigating impedance mismatch between view and model; say welcome to Mapper # TL;DR Even though it is technically possible to bind Model to view and even though there might (and possibly would) a 1:1 field correspondence between them, you should understand this is only in the beginning, so the statement is: Model and ViewModel (data to be displayed in view, whatever you call it) are two separate concerns

Design by contract: still underused and not understood # TL;DR