I don’t particularly like binding libraries. Whenever I work on a UI, there is a near-100% chance that I’m going to read the view’s code anyways – the fragment’s code (let’s say we use fragments). And it makes it very convenient to have all the references to all the views on my screen to be declared as class properties in that fragment’s class. I don’t want to navigate through the [Fragment —> XML —> ViewModel] path just to find a button’s handler definition. So, DataBinding effectively causes the view’s logic to be spread across XML and Fragment files. Without DataBidning, the XML files used to contain just the layout and styles, all the logic tended to be in the fragment file. And I don’t see what’s the problem with that.
You may argue that a binding library allows us to omit referencing android.view.View classes in our fragment and instead have “pure” value properties like booleans and strings… Yes, sure. What I struggle to understand is how that purity benefits us exactly. See the difference: in the old days, I only needed to refer to the XML file to define the initial layout and styles. For everything else, I could stay in the Fragment.kt/java. And I would argue that dealing with one file is simpler than dealing with more than one file. Once I reference the element of my layout in my fragment code, I’m pretty much done with dealing with the XML (until someone changes the requirements for the layout).
Now however, when using binding libs, I find myself jumping back and forth every time I need to add to my widgets behaviors, such as click handlers, visibility state changes, and so on.
I’m not getting it. I’m not getting it almost as much as I’m not getting storyboards for an iOS app which isn’t a throw-away prototype consisting of 2-3 simple screens.