What does it even mean for an XML layout to be type and null safe? This reads like a parody. XML resources give you orientation/screen size resolution and component re use. I haven't drunk the MVP kool aid that's the new hotness, but this is far too much in the other direction. If you're setting margins in code you're probably doing something wrong.
Let me try to answer it. I'm sure that I won't change your mind, but when I published Anvil (a similar library for Java) - I got lots of questions like yours.
- XMLs are not type safe, I can type any tag name in there, and I can set almost any value to my attributes - AAPT won't even notice (yes, Android Studio is much smarter these days, it may give a warning, but it won't be a compiler warning, so it won't be in your automated build logs. You will also miss it when using other text editor or IDE). I can put a view inside another view (not a viewgroup) - and it will pass as well. Since we waste CPU time on XMLs preprocessing - it would be nice if they also warned us about our errors at this stage, not crashes in runtime.
- The file hierarchy is terrible. All XMLs must be in the same folder, no nested folders. Having a large project makes you have dozens of XMLs on the same layer of hierarchy. Since we have OS with directories - it would be nice to use that feature like we use it for java packages.
- There are some styles, but they are too limited comparing to, say, CSS. If one ever tried LESS or SASS - he will love the mixing, variables, calculated expressions etc. It's fast to write, it's easy to read, it's reusable. You don't have to jump around multiple closely related files to tie it all together in your head. You have them in one place. Since XMLs are processed - it would be nice if I could write something like "android:background=darken(@color/mycolor, 30%)"
- There is some responsiveness, but it's too limited. If you have 3 nested views, and the topmost has margin in landscape and no margin in portrait - you have to have two (almost identical) files. Or three, if you want to use merge/include. In fact now they are all in different folders, despite they are very closely related!
- There is no way to merge with unique ids (child layout will have the duplicated ids when included twice).
- There is no mixins or macros. If I have layout with textview+button pairs - I will end up copying those two tags everywhere. If I have macros - I would write it once, and then would only type `<TextViewWithButton text="foo" buttonText="bar">` - that is supposed to be expaded into <TextView .../><Button ..../> with some texview and button attributes substituded to the given actual values.
Thanks for the explanation. I don't really buy the wasted CPU cycles argument since any dynamic jank after lollipop is caused by inflating views at the wrong time, not really how they're inflated. The other stuff sound nice but being able to do simple arithmetic and operations in XML sounds like the major win
It looks good unless you actually use layout qualifiers frequently. Then it becomes a pain, because you now have to keep consistency among all your layout variations and with Java code. Moreover, there's no tool in Android SDK nor in Android Studio that could help you sort it out.
