Android Developers
Published in

Android Developers

Data Binding — lessons learnt

Photo by rawpixel on Unsplash

Use the standard bindings when possible

  1. Organizing them is a pain. Unless you’re exceptionally well organised, you’re likely to have one large file containing all of your adapter methods. The antithesis of cohesive and decoupled.
  2. You need to use instrumentation to test. By definition, your binding adapters do not return a value, they take an input and then set properties on views. That means you have to use a instrumentation to test your custom logic, which makes testing slower and possibly harder to maintain.
  3. Custom binding adapter code is (usually) not optimal. If you look at the built-in text binding [here], you’ll see that it does a lot of checks to avoid calling TextView.setText(), thus saving wasted layout passes. I fell into the trap of thinking that the DB Library would automagically optimise my view updates. And it does, but only if you use the built-in binding adapters which are carefully optimised.

Make your custom binding adapters efficient

Just so you get an idea of what it does

Be careful with what you’re providing as variables

So what can you do instead?

Small wins add up



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store