4 Reasons I’m Not Using Android Data Binding

Update May 14 of 2017: I no longer use ButterKnife. Since I adopted Kotlin as my main Android development language I’ve been using Kotlin Android Extensions, which eliminate the need of using ButterKnife.

Update September 29: Updated the reason #3 and added the #5.

Disclaimer: This article is based on personal experience and facts that could be easily refuted, take my opinion with a grain of salt and decide by yourself.

#1 Experts don’t recommend it

Jake is the author of ButterKnife and goes straight to the point in this GitHub question.

The data binding might be useful in the most trivial cases, but there was no innovation done so it’ll be equally as painful as similar solutions on other platforms when complexity increases (e.g., XAML). This library scales to the advanced cases since it forces you to keep binding logic in code where it more correctly belongs.

Indeed, I agree with two points here:

  • It does not scale well.
  • Business logic belongs in code.

#2 It pushes you to create Spaghetti Code

As soon as we start implementing complex layouts, we will start adding more and more complexity to our Data Binding solution.

Some of the first caveats that we will face are:

  • Layout includes require you to pass the data source to each of them.
  • Or you may want to create a different data source for your includes.
  • Same thing with ViewStubs.
  • Loading images (with Picasso) will require you to implement a custom data binding adapter. That you can’t mock or inject as dependency.

And we may be tempted to do more complex things like:

  • Adding presentation logic on the layout.
<TextView
android:text="@{user.lastName}"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:visibility="@{user.isAdult ? View.VISIBLE : View.GONE}"/>
  • Add Lambda expressions on the listeners.
android:onLongClick="@{(theView) -> presenter.onLongClick(theView, task)}"
  • Import classes into the layouts to use them.
<data>
<import type="android.view.View"/>
</data>

How long until we have part of the logic on code and part on the layout? This can become a nightmare pretty quickly and smells like Spaghetti Code.

#3 Unit Testing is broken

Update: Seems like unit tests would be possible by running executePendingBindings to force the UI to synchronize, but I haven’t tried. If you did, let me know.

I love Robolectric and Mockito, they save me so much time creating and running tests that I won’t be able to work on Android without them.

The Data Binding library has a feature that it’s a bug for me: The update of the layout occurs asynchronously, which means that on a Unit Test with Robolectric I won’t be able to verify the values of my views right after I set the binding.

Google implemented the testing architecture with Espresso in mind. But I prefer to keep the UI tests as Unit Tests when possible, and I like to test my Activities, Fragments and Views individually rather than load them all together on a big Instrumentation Test.

#4 It offers less than ButterKnife

There are many great features of ButterKnife that some forget about:

  • Resource Binding.
  • View lists.
  • Multiple listener binding.

Resource binding is specially useful when we start doing advanced things with custom views and we need to access to Dimensions or Drawables.

View lists and multiple listener binding save a lot of code when we have series of views that perform the same actions, for example, a list of EditText or Buttons.

You don’t get any of these with the Data Binding library.

#5 Having different layouts for different screen sizes would force you to duplicate data binding code and keep the two layouts updated.

In most of my projects, where I have to support API 16, but we want to give a greater UX for +21 users, sometimes I have duplicated layouts for different API versions.

Keeping the layouts up to date to design changes is already hard, so I cannot imagine how painful needs to be to keep also Data Binding changes.


Why you may want to use Data Binding

#1 I can develop things faster

Faster is not always better on the long run. When we develop apps, we are running a marathon, not a sprint… or are we? If the opportunity is better than the long run, it may make sense to use the tools that get the job done quicker.

#2 It’s already there

No third party dependency is always a good thing. If you are landing into a big project which already has problems with function number limitations, the lead developer may not like adding a new library to it.

#3 I am following MVVM pattern

If you are properly implementing MVVM with an observer pattern, the Data Binding library may help you implement the Observer pattern on the views.


Thanks for getting this far! I hope you enjoyed this publication. If you think it was worth reading, please share it and more people will benefit from it. You can also click on the Recommend button if you are Medium user. And of course, feel free to leave your feedback!

You can follow my updates on Twitter and LinkedIn. And find more code examples in my GitHub page.