Currently trying to add support for Custom View definitions for Android-Binding. Half a year ago, I have designed a Provider pattern for plugging in unsupported views. Today, when I look back to the design, while it is functional, it could be a bit too trouble for writing a new custom view; and writing custom view is actually quite very often job for working with Android, especially when dealing with MVVM.
I re-think what I have done, why I decided to go to the provider pattern, is because I don’t want to touch the source code of Android’s base system (and this would guarantee Android-Binding could support across multiple versions of Android). The basic design for Android-Binding is like the following:
- Widget (e.g. TextView)
- Attribute Collection (like Text, Background Color)
- Multicast Listeners (like onTextChange etc)
- Binding Map (the XML tags-value pair)
All three of the above are attached to the View itself via Tagging (setTag), so that the state is keep within the view, and remove with the view, just behave like the View’s own item.
Now, when it comes to custom views, it is different. We don’t need to attach all those collections (except binding map) in the custom view, but the custom view can handle, create, and invoke commands by the programmer. There’s no need to have the burden like above, but can be accessed more directly.
When I looked back to the codes, I found out I went something wrong, with the Multicast Listeners, as they are currently doing two works:
- Broadcast the captured event to multiple listeners
- Bind and invoke commands
The Second one, should not be the job of it. So, in the new design, I would remove the second job, and make those events (onClick, onTextChange etc) a subclass of ViewAttribute. Right, they should be the ViewAttributes that binds toViewModel’s command.
Above need a lot of re-coding on bindingProviders, and a number of classes will be introduced. But it also leads to some cleaner code; hope I can finish doing by next week and release it along with Custom View API.