<>前言

本文是 Android官方架构组件 <https://blog.csdn.net/mq2553299/column/info/24151>
系列的番外篇,因为目前国内关于DataBinding双向绑定的博客,讲的实在是五花八门,很多文章看完之后仍然一头雾水,特此专门写一篇文章进行总结。

本文默认读者对DataBinding的使用有了初步的了解。

<>什么是双向绑定?

DataBinding的本身是对View层状态的一种观察者模式的实现,通过让View与ViewModel层可观察的对象(比如LiveData)进行绑定,当
ViewModel层数据发生变化,View层也会自动进行UI的更新。

上述我讲的是DataBinding最基础的用法,即 单向绑定 ,其优势在于,将View层抽象为一个纯Java的可观察者——这意味着ViewModel
层相关代码是完全可直接用于进行单元测试。

但实际的开发中,单向绑定并非是足够的,在一些特定的场景,我们也需要用到 双向绑定。

比如说,对于一个TextView的内容展示,一般情况下,我们只是用来通过将一个String类型的数据对其进行渲染:



显而易见,数据的流向是单向的,换句话说,我们认为TextView对DataSource只进行了 读 操作——如果此时进行了网络请求,我们需要用到
DataSource某个属性作为参数,我们依然可以毫无顾忌从DataSource取值。

但是换一个场景,如果我们把TextView换成一个EditText,接下来我们需要面对的则截然不同,比如登录界面:


这似乎没有什么问题,我们依然通过一个LiveData对EditText进行了单向绑定:



问题发生了,当我们对 输入框 进行编辑,EditText的UI发生了变更,但是LiveData内的数据却没有更新,当我们想要在ViewModel
层请求登录的API接口时,我们就必须要去通过editText.getText()才能获取用户输入的密码。

于是我们希望,即使是EditText的内容发生了变更,但是LiveData内的数据也能和EditText保持内容的同步——这样我们就不需要让ViewModel
层持有View层的引用,在请求接口时,直接从LiveData中取值即可:



这就是双向绑定的意义。

<>使用场景是什么

什么适合使用 双向绑定 呢,还记得上文中的一句话吗:

对于单向绑定来说,数据的流向是单向的,换句话说,我们认为TextView对DataSource只进行了 读 操作。

现在我们定义,当 不确定的操作发生时 ——通常,这种操作代表着用户对UI控件的交互,这时UI的变化需要影响到ViewModel层的数据状态(除了 数据驱动视图
之外,视图也在驱动数据,以方便作为参数将来进行网络请求等等操作),这时双向绑定 就可以大展身手了。

显然上文中的EditText的是 双向绑定 经典的使用场景之一,此外,双向绑定的使用场景非常常见,比如CheckBox:



当用户选中了CheckBox,我们当然希望ViewModel层的LiveData<Boolean>状态进行对应的更新,以便将来我们直接从LiveData
中取值作为参数进行网络请求。

而如果没有双向绑定,用户操作了UI,我们就需要 手动添加代码保证状态的同步——比如checkBox.setOnCheckChangedListener()
,否则,就会在接下来的操作中得到与预期不同的结果。



<>听起来好像很麻烦,那么究竟如何使用呢?

幸运的是,Android原生控件中,绝大多数的双向绑定使用场景,DataBinding都已经帮我们实现好了:



这意味着我们并不需要去手动实现复杂的双向绑定,以上文的EditText为例,我们只需要通过@={表达式}进行双向的绑定:
<EditText android:id="@+id/etPassword" android:layout_width="match_parent"
android:layout_height="wrap_content" android:text="@={
fragment.viewModel.password }" />
相比单向绑定,只需要多一个=符号,就能保证View层和ViewModel层的 状态同步 了。

<>难点在哪?

双向绑定定义好之后,使用起来很简单,但定义却稍微比单向绑定麻烦一些,即使原生的控件DataBinding已经帮助我们实现好了,
对于三方的控件或者自定义控件,还需要我们自己实现。

本文以SwipeRefreshLayout为例,让我们来看看其 双向绑定 实现的方式:
object SwipeRefreshLayoutBinding { @JvmStatic
@BindingAdapter("app:bind_swipeRefreshLayout_refreshing") fun
setSwipeRefreshLayoutRefreshing( swipeRefreshLayout: SwipeRefreshLayout,
newValue: Boolean ) { if (swipeRefreshLayout.isRefreshing != newValue)
swipeRefreshLayout.isRefreshing = newValue } @JvmStatic @InverseBindingAdapter(
attribute = "app:bind_swipeRefreshLayout_refreshing", event =
"app:bind_swipeRefreshLayout_refreshingAttrChanged" ) fun
isSwipeRefreshLayoutRefreshing(swipeRefreshLayout: SwipeRefreshLayout): Boolean
= swipeRefreshLayout.isRefreshing @JvmStatic @BindingAdapter(
"app:bind_swipeRefreshLayout_refreshingAttrChanged", requireAll = false ) fun
setOnRefreshListener( swipeRefreshLayout: SwipeRefreshLayout, bindingListener:
InverseBindingListener? ) { if (bindingListener != null)
swipeRefreshLayout.setOnRefreshListener { bindingListener.onChange() } } }
有点晦涩,是不是?我们先不要纠结于细节的实现,先来看看代码中是如何使用的吧:
<androidx.swiperefreshlayout.widget.SwipeRefreshLayout android:layout_width="
match_parent" android:layout_height="match_parent" app:
bind_swipeRefreshLayout_refreshing="@={ fragment.viewModel.refreshing }"> <
androidx.recyclerview.widget.RecyclerView/> </
androidx.swiperefreshlayout.widget.SwipeRefreshLayout>
refreshing实际就只是一个LiveData:
val refreshing: MutableLiveData<Boolean> = MutableLiveData()
这里的双向绑定,意义在于,当我们为LiveData手动设置值时,SwipeRefreshLayout
的UI也会发生对应的变更;同理,当用户手动下拉执行刷新操作时,LiveData的值也会对应的变成为true(代表刷新中的状态)。

相比于其它的方式,双向绑定将SwipeRefreshLayout的刷新状态抽象成为了一个LiveData<Boolean>
——我们只需要在xml中定义好,之后就可以在ViewModel中围绕这个状态进行代码的编写,不同于view.setOnRefreshListener()
的方式,这种代码是纯Java的,我们可以针对每一行代码进行纯JVM的单元测试。

本小节的所有代码你都可以在 这里
<https://github.com/qingmei2/MVVM-Rhine/blob/master/rhine/src/main/java/com/qingmei2/rhine/binding/support/SwipeRefreshLayoutBinding.kt>
获取。

<>整理思路,按部就班实现双向绑定

说了这么多,但是我们一行代码都还没有实现,不着急,因为编码只是其中的一个步骤,最重要的是 整理一个流畅的思路,这样,在接下来的编码阶段,你会如有神助。

<>1.实现单向绑定

我们知道,双向绑定的前提是单向绑定,因此,我们先配置好对应单向绑定的接口:
@JvmStatic @BindingAdapter("app:bind_swipeRefreshLayout_refreshing") fun
setSwipeRefreshLayoutRefreshing( swipeRefreshLayout: SwipeRefreshLayout,
newValue: Boolean ) { swipeRefreshLayout.isRefreshing = newValue }
我们通过将LiveData的值和DataBinding绑定在一起,每当LiveData的状态发生了变更,SwipeRefreshLayout
的刷新状态也会发生对应的更新。

我们实现了数据驱动视图的效果,接下来我们需要思考的是,我们如何才能知道用户会执行下拉操作呢?

<>2.观察View层的状态变更

只有观察到View层的状态变更,我们才能驱动LiveData进行对应的更新,其实很简单,通过
swipeRefreshlayout.setOnRefreshListener()即可:
@JvmStatic @BindingAdapter(
"app:bind_swipeRefreshLayout_refreshingAttrChanged", requireAll = false ) fun
setOnRefreshListener( swipeRefreshLayout: SwipeRefreshLayout, bindingListener:
InverseBindingListener? ) { if (bindingListener != null)
swipeRefreshLayout.setOnRefreshListener { bindingListener.onChange() // 1 } }
注意我注释了 //1的地方,每当swipeRefreshLayout刷新状态被用户的操作改变,我们都能够在这里监听到,并交给
InverseBindingListener这个 信使 去通知DataBinding:

嗨!View层的状态发生了变更,你快去通知LiveData也进行对应数据的更新呀!

新的问题来了,现在DataBinding已经知道需要去通知LiveData进行对应数据的更新了,关键是——

<>3. 我要把什么数据交给LiveData?

是的,即使LiveData需要进行更新,但是它并不知道要新的状态是什么。

LiveData: 老哥,你倒是把数据给我啊!

我们急需将SwipeRefreshLayout最新状态告诉LiveData,因此我们通过InverseBindingAdapter注解和 步骤二
中去进行对接:
@JvmStatic @InverseBindingAdapter( attribute =
"app:bind_swipeRefreshLayout_refreshing", event =
"app:bind_swipeRefreshLayout_refreshingAttrChanged" // 2 【注意!】 ) fun
isSwipeRefreshLayoutRefreshing(swipeRefreshLayout: SwipeRefreshLayout): Boolean
= swipeRefreshLayout.isRefreshing
注意到 //2 注释的那行代码没有,我们通过相同的tag(即app:bind_swipeRefreshLayout_refreshingAttrChanged
这个字符串,步骤二中我们也声明了相同的字符串),和步骤二 中的代码块形成了绑定对接。

现在,LiveData知道如何进行反向的数据更新了:

每当用户下拉刷新,InverseBindingListener通知DataBinding,LiveData就会从
swipeRefreshLayout.isRefreshing得知最新的状态,并进行数据的同步更新。

<>4.不要忘了防止死循环!

细心的你多少已经感觉到了不对劲的地方,现在的双向绑定有一个致命的问题,那就是无限循环会导致的ANR异常。

当View层UI状态被改变,ViewModel对应发生更新,同时,这个更新又回通知View层去刷新UI,这个刷新UI的操作又会通知ViewModel去更新…

因此,为了保证不会无限的死循环导致App的ANR异常的发生,我们需要在最初的代码块中加一个判断,保证,只有View状态发生了变更,才会去更新UI:
@JvmStatic @BindingAdapter("app:bind_swipeRefreshLayout_refreshing") fun
setSwipeRefreshLayoutRefreshing( swipeRefreshLayout: SwipeRefreshLayout,
newValue: Boolean ) { if (swipeRefreshLayout.isRefreshing != newValue) //
只有新老状态不同才更新UI swipeRefreshLayout.isRefreshing = newValue }
<>小结

本文的初始计划中,还有一个模块是关于 双向绑定的源码分析,写到后来又觉得没有必要了,因为即使是 源码,也只是将上文中实现的思路啰嗦复述了一遍而已。

双向绑定本身是一个极具争议的功能;事实上,DataBinding本身也极具争议——DataBinding
的好用与否,用或者不用都不重要,重要的是我们需要去正视它展现出来的思想:即如何将一个难以测试,状态多变 的View, 通过代码抽象为 易于维护和测试
的纯Java的状态?

DataBinding将烦不胜烦的View层代码抽象为了易于维护的数据状态,同时极大减少了View层向ViewModel层抽象的 胶水代码,这就是最大的优势。

当然,DataBinding并不一定就是正解,事实上,RxBinding就是另外一个优秀的解决方案,同样以SwipeRefreshLayout
为例,我依然可以将其抽象为一个可观察的Observable<Boolean>——前者通过在xml中对数据进行绑定和观察,后者通过RxJava
对View的状态抽象为一个流,但最终,两者在思想上殊途同归。

<>系列文章

争取打造 Android Jetpack 讲解的最好的博客系列:

* Android官方架构组件Lifecycle:生命周期组件详解&原理分析
<https://juejin.im/post/5c53beaf51882562e27e5ad9>
* Android官方架构组件ViewModel:从前世今生到追本溯源
<https://juejin.im/post/5c047fd3e51d45666017ff86>
* Android官方架构组件LiveData: 观察者模式领域二三事
<https://juejin.im/post/5c25753af265da61561f5335>
* Android官方架构组件Paging:分页库的设计美学
<https://juejin.im/post/5c53ad9e6fb9a049eb3c5cfd>
* Android官方架构组件Paging-Ex:为分页列表添加Header和Footer
<https://juejin.im/post/5caa0052f265da24ea7d3c2c>
* Android官方架构组件Paging-Ex:列表状态的响应式管理
<https://juejin.im/post/5ce6ba09e51d4555e372a562>
* Android官方架构组件Navigation:大巧不工的Fragment管理框架
<https://juejin.im/post/5c53be3951882562d27416c6>
* Android官方架构组件DataBinding-Ex:双向绑定篇
<https://juejin.im/post/5c3e04b7f265da611b589574>
Android Jetpack 实战篇:

* 开源项目:MVVM+Jetpack实现的Github客户端 <https://github.com/qingmei2/MVVM-Rhine>
* 开源项目:基于MVVM, MVI+Jetpack实现的Github客户端 <https://github.com/qingmei2/MVI-Rhine>
* 总结:使用MVVM尝试开发Github客户端及对编程的一些思考
<https://juejin.im/post/5be7bbd9f265da61797458cf>
<>关于我

Hello,我是却把清梅嗅 <https://github.com/qingmei2>,如果您觉得文章对您有价值,欢迎 ❤️,也欢迎关注我的个人博客
<https://juejin.im/user/588555ff1b69e600591e8462>或者Github
<https://github.com/qingmei2>。

如果您觉得文章还差了那么点东西,也请通过关注督促我写出更好的文章——万一哪天我进步了呢?

* 我的Android学习体系 <https://github.com/qingmei2/android-programming-profile>
* 关于文章纠错
<https://github.com/qingmei2/Programming-life/blob/master/error_collection.md>
* 关于知识付费
<https://github.com/qingmei2/Programming-life/blob/master/appreciation.md>

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信