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’.