Skip to content

Instantly share code, notes, and snippets.

@bdiegel
Last active August 29, 2016 13:52
Show Gist options
  • Save bdiegel/0c1598b7ea6f8aac10e442bb812d9fc9 to your computer and use it in GitHub Desktop.
Save bdiegel/0c1598b7ea6f8aac10e442bb812d9fc9 to your computer and use it in GitHub Desktop.
Android Data Binding

Android Data Binding

Support for two-way data binding was recently added to Android data binding. This is an investigation into using data binding with ViewModels.

The Good: Many advantages

  1. View Models: Data binding is a natural fit. Declare your ViewModel as a variable in the layout file and bind to its properties.
  2. Type Safe: No more findViewById or casting views.
  3. View Holder: A Binding class is auto-generated from your layout file during the processing step. It acts as a view holder and providing convenient access to them. Any view that has an id will have a field in the generated binding class.
  4. Reduce Boilerplate: A lot of boilerplate code gets eliminated.
  5. Null Safe: Failure is graceful. If the bound object or fields have a null value, no worries. The library uses the default value of the field based on its type, in the case of a String this is null. This can clean up the lots of null checks.
  6. Performance: Data binding is faster than findViewById becuase it is processed once. When you run findViewById, the view hierarchy is walked each time to find it
  7. Included Layouts: Passing variable to included layouts is supported.
  8. Backwards Compatibility: Because the layout files are processed and scrubbed before compile, data binding is supported all the back to Android 2.1 (API level 7+).
  9. Custom bindings Binding adapters allow you to set any property of a view including custom attributes you create.

The Bad: A few things to look out for

  1. Expressions in XML layouts: Complex expressions are supported. But this is a pretty bad idea.
  2. Coding by convention: Uses POJO naming conventions.

The Ugly: Frustrations

  • it may not be immediately obvious from the official docs but you really must:
    • extend BaseObservable
    • explicitly fire property change events in your setters
    • annotate your getters with @Bindable to generate a resource to refer to in notifyPropertyChanged(BR.<propertyName>
  • potential for name collisions
  • build problems with Android Studio
    • try 'Invalidate Caches': Always worth a try, but it doesn't always solve the issue.
    • recommend the 'android-apt' plugin: This helps Android Studio pickup code generated by the annotation processor.

Example

Tell Gradle to enable data binding:

// build.gradle android { ... dataBinding.enabled = true }

Wrap layout file contents in a tag:

Add binding expressions (one-way) using the “@{…}” format.

Resources

Thare are a number of good blog tutorials.

Conclusion

Very proming but not ready. Review again in a few months after bugs in the tooling are ironed out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment