The problems of in-code layout preview are a bit worse then ones of XML layouts, that’s true. The solution is to build a bridge between XML and code.
ConstraintLayout may truly be useful for some marginal cases, but replacing everything with Constraint is just fanaticism.
I still can’t see any reason to use
ConstraintLayout. It’s handy when using mouse, but my development process is keyboard-oriented. Reading constraint-based layouts in GitHub and evaluating constraints in head is inconvenient.
XML is not reusable: layout cannot receive parameters and pass them to views,
<merges> , or…
This is totally evil.
turns off tons of optimizations. You really may need to turn off some of them only of you’re targeting Android 2.x.
-keepattributes Exceptions,InnerClasses,Signature,Deprecated, SourceFile,LineNumberTable,*Annotation*,EnclosingMethod
There’s a DSL for creating layouts via code. But this is not necessary — you can create views with Java or Kotlin without any external tools/deps.
It looks weird for the first time, but gives you all the flexibility and typing from your programming language.
The most of problems (no nullability, no typing) are true for findViewById, too, and with it they are even more crutial. Global namespace is only R.id’s problem — with Kotlin Android Extensions you choose layout(s) to import.
The main mistake is to continue listening crappy advice Google gives after all this time, and to continue using XML for layouts.