I started this EARLY into my adventures gettign to understand what Object Oriented Programming is. The UI is always a rough part of the experience. I found some effective ways to deal with it. My latest way is to have the UI do nothing.
There are ways to make it A LOT worse. I think one of the most recommended styles that only adds complexity to the system is Databinding. It's abhorent. It kills simplicity, maintainability, and testability.
Saying it isn't enough. Let's walk through why I think these things, and where bigt companies recommendations are crap; screwing up application maintainability.
Now - There is a very narrow place for databinding, SIMPLE CRUD. I've never seen an example of simple CRUD app. Business logic always slips in, and there's no simplicity, maintainability, or testability in the app once you have databinding...
Don't do it - it won't last as an "easy" or "quick" solution.
High Level
Let's look at some of my high level concerns over data binding before we jump into a companies explicit recommendations.
Databinding
In presentation layers; DataBinding often comes up. Looking at the code from a pure OO perspective; there's no place for databinding in the View. Google has put out a library to do databinding for Android... I cringe at the thought of how that's going to become a painful part of any product down the road. Using data binding will cause the product to be harder to test. The product will become more fragile as changes are required. The complexity will only increase when you use this databinding.
Logic in the View layer
It becomes too easy to start including logic in the View layer. Not the View's 'code-behind' layer (also a bad idea), but into the view representation itself. In the case of Android; logic would be in the xml file. Having logic in that level of the UI definition is about as close to the highest offense I'll find with code. I'll debate quite extensively to avoid putting logic into the UI.
Removes Abstraction / Tightly Couples
Databinding readily breaks any abstractions that might be able to be in the system and forces tight coupling to what is being used. Databinding highly encourages, if not reqiures passing a data object into the view. Passing a data-bag into the highest level of the UI means that it is then tightly coupled to that representation of the data. There is no abstraction; there is no decoupling, there's no data->ui bridging. The value Object Oriented Programming brings goes away. The abstraction brought by the UI patterns, even the ones I disagree with, and the maintainability they are intended to provide - poof - gone when data binding is implemented.
Encourages violating encapsulation / UI fragile to data changes
UI databinding normally doesn't allow a large feature set in what is written to bind data. And if it does; why the hell are you writing code in the UI?!?!?! ... ahem... Since there's not a lot of codability with the databinder, it encourages violating encapsulation. You'll need to use getters or just expose the naked values. Getters are a practice I advocate against. It corrupts the encapsulation of any Domain Models, or forces databags just for the UI to interact wth.
SOLID
Let's look at some well loved principles in our industry. I'm just going to take SOLID as that's a nice simplified five of them. I really enjoy David Bernstein's Being CLEAN but it's not currently as well recognized.
Single Responsibility
This one is pretty simple; how can a UI have a single responsibility when it's doing a bunch of things. It is the UI. It should have the single responsibility for how the UI should be defined. Not what should be on or off, of displayed. That's creating many responsibilities for the UI file. I can't even call it code; most UI definitions are some form of Document Markup, some (HT|X)ML-ish (will be referred to as XML for lack of a better term) looking thing. It's not code. When you shove code it; it does many things.
Open/Closed
This is the idea that we're open for extension but closed to modification. When any code is put into the XML, it's; not open for extension. It's not anything; It's a snippet in a non-code file. We can't extend the component and change this snippet. The behavior is locked.
Liskov
It depends on what system and how it evaluates code snippets; I assume this is going to work fine.
Interface Segregation
I don't think we'll see this applied for objects that are databound. Otherwise we might have to bind the same object a few times with each of the interfaces. We're going to limit the better construction of our code classes because it'd add extra code into the UI. Lacking the interface segregation because it simplifies the UI is complicating the rest of the code, decreasing the maintainability.
Dependency Inversion
Can we have dependency inversion for the objects the UI uses? Most of the time we can't do this with the UI components. Though I've found some success by avoiding the question entirely and [having the UI do nothing](LINK TO POST).
Databinding is going to make this even harder. The backing code file is going to need references to access on creation... We can't inject those objects (ignoring things like Dagger, which I find a number of negative impacts from using) and we're left with behavior and untested code in our product.
Result
Out of these five principles, I don't see any detriment to just one of them. Which can only be enforced in a static typing system.
One out of five principles aren't, potentially, negatively impacted by data binding. I'd rather not use a technology that throws out 80% of recognized good practices because... Why? I never had a great love of databinding. It's always been more of a pain to me than it was worth; and with current practices, it's destructive to maintainability.
Summary
THis is my high level feelings on Databinding. It's not the only feelings.
Google and Microsoft both have their recommendations on databinding. It's a standard for microsoft and there's a specific library for Android... Their recommendations result in horrible object oriented code. I'm going to go through their recommendations in future posts.