Knowledge boost for junior Android developers — Part I
Frank
1K13

If global BindingAdapters are a problem for you, you can have instance BindingAdapters instead. Global or not, I think it’s important that they are organised in some way so other devs can easily find them and not create duplicates.

They can be tricky to write properly. I generally follow the patterns from the library source, such as:

  • Treat all parameters as nullable after the View and use null as a signal that something is being unbound (consider Kotlin for this).
  • Break traditional view event listeners down into functional/SAM interfaces with no more than 1 parameter (for cleaner syntax in XML), where each is wrapped in a real view event listener created inside the BindindAdapter that simply forwards the event.
  • For forwarding events from the view, strive for method references in XML as opposed to fully fledged lambda expressions, this may involve rewriting BindingAdapter from the library, unless your view-model method accepts a view as a parameter.
  • Don’t pass the view as a parameter to view-models.
  • Don’t return view event handlers from view-models.
  • Use ListenerUtils.trackListener if views can hold multiple event listeners.
  • If a view event listener signals the change in state of a view, where this state can also be set from the view-model via a separate BindingAdapter, consider writing an InverseBindingAdapter for cleaner XML.
  • Try to avoid ‘screen specific’ BindingAdapters where possible. For example, if you write a BindingAdapter for your custom view, but the property you are setting on the view exists in a base class, use the base class where the property originates from, thus making your BindingAdapter much more reusable, and thins out the ‘forest’.
Like what you read? Give Aidan Mcwilliams a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.