android MVVM 开发模式

4,078

mvvm 是一个在 mvp 架构上修改,目标是将view的一些更改,跟model关联起来,使得model的数据改变,直接通知到view上面来,从而解决mvp架构里面的v-p之间的接口太重问题。 所以mvvm的核心解决问题为:使得v-p直接的关系弱化,使用绑定方式(dataBinding)直接将model的改变反馈到view上面。 关于完整的dataBinding讲解,请看这里 github.com/LyndonChin/…

本讲解决什么问题呢?一个方面是简单的使用dataBinding方式,一个是讲解它内部如何做到的。

mvvm的含义: mvvm指的是model view 和viewmodel。 model 就是数据实现和逻辑处理。 view 就是界面显示。 viewmodel 创建的关联,将model和view绑定起来。如此之后,我们model的更改,通过viewmodel反馈给view。(view的xml布局文件,经过特定的编写,编译工具处理后,生成的代码会接收viewmodel的数据通知消息,自动刷新界面)

说多无益,直接看例子:

1在项目的build.gradle

2在模块的build.gradle

加入dataBinding

3创建一个User类

里面有一个属性name,我们等会要用。 4 编写Activity_main.xml布局文件

布局根节点换成layout 加入data节点 写入一个变量,名字user,类型为com.xm.mvvmdemo.Model.User,也就是3这个类的位置。 在TextView的属性android:text上写入@{user.name} 这里这个动作,在编译后代码会生成类似:textview.setText(user.getName());实际有些特殊,后面再说。 5在MainActivity里面修改

替换setContentView(R.layout.activity_main)换成DataBindingUtil.setContentView(this, R.layout.activity_main),返回的是生成的绑定类ActivityMainBinding(这个就是我们的xml名字activity_main去掉连接,首字母大写,拼接一个Binding组成的。)

这里更换成这个DataBindingUtil.setContentView,内部做了哪些动作呢?在默认的setContentView动作后,做了一个绑定动作,将里面的view和数据关联起来。具体看怎么关联的,可以看ActivityMainBinding这个生成出来的类。

创建一个User,设置值。然后绑定。 通过binding.setUser(),将我们的数据传回给view,通过我们自动生成的代码,可以直接将这个值赋值过去。

现在我们捋一捋这个思路。 改变xml,编译之后,出来一个真正布局xml和一个binding代码(这里是ActivityMainBinding.java),这里ActivityMainBinding里面就是生成出来的将xml里面的绑定地方的描述改为代码:(这里android:text:”@{user.name}”)生成为

第一个参数便是我们的TextView类,第二个值我们看到是从上面的User的实例出getName的值。 第一个参数如何来的:

改变setContentView单一动作,换为DataBindingUtil.setContentView。上面已经提过这个的思路。

现在我们写好了绑定xml,替换了setContentView,这两个动作完成后,我们的绑定类已经把里面的view和需要的数据绑定起来了,这时我们是不是需要给赋值呢?

binding.setUser(user);将数据赋值过去,这样子里面则就将信息反馈给界面了。

6总结

其实使用的时候,第一印象是我xml都能写哪些东西啊,这个是我的第一个问题。 我们AS选择到Project模式下,拉到最下方的地方,看到External Libraries ,可以看到一个adapters-1.1.jar,打开就看到所有的可用属性了。

我要自己定义属性,系统的默认不够用? 好吧,自己去写标记为@BindingAdapter的一个静态方法就可以了。随意放,编译器会自己找这个注释的。

注意:绑定的编译处理过程我们不管,我们把它当做黑盒子处理,看下它处理我们的布局xml的前后对比。

这里我们看到在data节点标记了名字和类型,然后底下的去用这个名字里面的属性。我们发现,这里我们只需要约定下这个关联方法,这个就完全可以自动生成了。 因此,我们默认属性的获取都是通过get得到。这里user.name就变成uset.getName() 关于这个android:text属性呢,默认就是对应的set方法了,这里没有使用默认的,why?因为为了严谨,需要做赋值过滤。系统默认提供了具体方法:

我们看下这个布局和生成的布局之间的对比:

生成的时候直接将上面的layout和data拿掉了。将android:text也去掉了,这些去哪里呢?(答案就是这个布局xml生成一个真正的布局文件和一个管理绑定的代码啦,这里就是ActivityMainBinding)  ActivityMainBinding 主要完成几件事情1:将里面的需要绑定的view实例拿到。2:将view和model的关联代码生成出来。(也就是model该如何显示到view上) 说了这么多,再一次总结下databinding做了什么: 依据约定的xml(layout作为根节点),生成真正的xml和一个绑定类绑定类为我们做了界面里面的View和数据之间更新的规则。 然后我们用DataBindingUtil.setContentView 替换setContentView,因为它在setContentView的基础上做了一个动作,就是把这个界面里面的View和数据之间更新的规则直接交给我们的绑定类。 如此一来,我们发现我们要写的findviewbyid 和setText 被这个工具自动生成出来了,我们将这些动作写入了布局里面,让工具帮我们做了代码生成,从而让我们解放了繁琐重复的界面操作。

简介 之前讲了那么多,主要围绕着这个核心概念:绑定。 不过相对来说,我们上节讲的其实只是它的一个知识点:解决布局文件的生成和界面的绑定。数据是我们主动给到绑定类的,这个肯定不是我们的目标。主动给到绑定的动作应该只是第一次作为初始值给出,随后则需要数据直接改变,自动反馈到界面上。 所以,我们这节就来解决这个问题。 还是老样子,先看如何使用它: 1让User继承BaseObservable

BaseObservable叫可观测,也可以简单的理解成我们常说的callback回调函数,就像点击一个button注册的onclick一样,一点击,就调用回调函数。

BaseObservable是个有通知机制,我们可以借助这个来完成数据改变的反馈。

2使用@Bindable注释

@Bindable注释的目的是使得编译机制知道,这个类里面有个数据是需要通知的,因此它会生成通知和被通知的关系链。

这样说肯定会晕,因此我们说下这里的name,我们记得我们的xml里面写过

意思就是文本是需要这个name的值来显示的。我们给User的String name加上这个注释@Bindable,就是告诉编译器你给我把这两个关联起来。(这里的关联指的是在初始化设置User的时候,

将自己(ActivityMainBinding)作为User的回调,这样子我们有变化则可以给通知了) 3通知数据改变

在我们的User里面,写上

关键技术点:notifyPropertyChanged(BR.name);

通知属性改变了,这里BR类是编译生成的,主要就是@Bindable标记的属性,生成这个的目的就是为了我们去通知数据变化时候使用。

4实践

这里和上一节讲的区别在哪呢?我们看到先设置User,然后才给name赋值的,设置User过后,这时候再去设置name,然后通过notifyPropertyChanged通知数据改变,而上一节说过,ActivityMainBinding的目的就是将数据和view绑定起来,因此现在我们数据变化了,主动通知我们的绑定模块(ActivityMainBinding),从而实现数据变化直接反馈到界面了。这样子我们只需要关注数据的变化即可了。

5 代码地址

github.com/luxiaoming/…

6后记

说了mvvm的开发模式思路,我们发现它的优势是将mvp中的v-p关系简化,但是它的做法是将这个动作做到了xml里面去了,这时就看你的取舍了。喜欢写入xml,就用这个思路,其实实际中mvvm有个和mvp的折中思路,就是mvp是v-p关系太过紧密,mvvm的缺点是没有了Presenter,使得vm(ViewModel做了很多Presenter的事情)太重,因此有人就搞出来两个的优点合并,在mvp的基础上,使用ViewModel,两个混合着用,可以达到两者的优点共存,google官方例子也是如此推荐使用的。

常用的开发模式 mvp+dagger2 或者就是mvvm+dagger2。

更多细节,可以看官网原文:

developer.android.com/topic/libra…

简书中文翻译:

www.jianshu.com/p/b1df61a4d…

完全demo:

github.com/LyndonChin/…

为了更好地理解@BindingAdapter,github地址里面提交了一个adapters目录,将系统提供的适配提交上去,以便查阅。

我们前两节讲了哪些内容呢? mvvm模型概念 dataBinding是什么 演示xml如何变为了代码 演示了数据自动通知BaseObservable

通过上面的学习,我们掌握了xml变成代码,并且数据(Model)和View通过dataBinding关联起来是如何操作的了。有人就说了,毕竟系统提供的适配器(@BindingAdapter标注的静态方法 )有限,我们能自己定义属性对应的方法吗? 答案是YES。因此我们就要自己去写自己的@BindingAdapter,来完成我们所需要的功能。如此一来,我们会发现这个dataBinding的突出优势来了。 so,我们看步骤: 1加个自定义属性

添加一个age年龄的属性,标记类型为整数

2在我们的xml使用

加入属性值,和User里面的age关联。(因为是我们自定义的属性,系统肯定不知道对应的函数方法是什么,因此@BindingAdapter来给指明方向)

3适配方法

随便在一个位置,写入如下代码:必须静态函数,原因很好理解。(不是静态含需要对应实例,用起来很怪。) 两个参数,第一个就是我们是在哪里是用的,因为我们是在一个TextView使用的,因此第一个参数是TextView类型。第二个就是我们定义的类型了,int,实现下操作即可。

4演示 在我们的User类里面,写上:

加入了一个值age,标记成可观测

实现一个设置接口啦。

调用地方:

我们看到,当赋值年龄之后,界面正确的显示出来了。效果如下:

5后记

我们看下这个@BindingAdapter最后在ActivityMainBinding承载着什么关系,直接看代码:

看到了吧。我们使用工具的时候,第一要素是什么呢?就是我们先去思考我们会遇见哪些问题,然后就可以去找对应的解决方案了。用我们的实际做法,去对应着这个dataBinding来实现,这样子我们就很快理解这个东西的实质了。

6代码位置

github.com/luxiaoming/…

android MVVM开发模式(四)

上节我们讲了自定义的@BindingAdapter,来扩展属性功能的时候,第一步添加了一个自定义属性这个其实是多余的。(我当时按照自定义view属性去做了,其实data-binding是不用这个的,它的实现原理是找到标记为@BindingAdapter对应属性之后,依据这个函数生成代码即可,这个属性在真正的xml里面,是会去掉的。) 这个是怎么发现的呢? 在继续思考@BindingAdapter的定义时候发现的。因为我们标记的时候,后面的参数可能是任意结构的,而本身属性里面标记的类型是有限的,从这里发现这个问题的。 小插曲 说完了。 我们上一节说了怎么玩@BindingAdapter,我们再来说下它是做什么的 通过标记一个静态方法为@BindingAdapter,标记附加值为对应属性。

静态方法参数:第一个为view的类型,随后参数就是我们关联的变量类型。

目的就是可以自定义任意形式的属性适配器。

我们之前还讲了BaseObservable类 和 @Bindable 使用类继承BaseObservable后,然后在属性的前面标记为@Bindable,这个属性则是可以通知的。通过使用 notifyPropertyChanged(BR.age);向界面通知。 参数就是这个属性对应的值。

回顾完成,我们看到了这个现在做的是数据更改,通知给view,没有一个view上面输入数据后,反馈给数据这边。因此我们这节解决这个问题。 我们一起看步骤: 1 setAge函数

这里我们多了一个条件判断,判断如果没有变化,停止设置text,原因是如果不设置,因为设置text会引起文本改变回调,回调回来又设置文本,又引起文本改变,继续回调,造成无限循环。

2 再加一个标记适配器

参数注意,第二个参数要求是这个InverseBindingListener,原因是我们作为双向通讯,这个作为桥梁。这里我们使用检测文本改变,然后调用 ageAttrChanged.onChange();即可。

3 牵线搭桥

关键的标注来了。@InverseBindingAdapter,两个参数,属性 和事件。事件后面的值和上面2里面的标注适配器值一样。

这里我们停一下,思考下,两个适配器

和一个关联

它的逻辑思路是: 适配器ageAttrChanged 来完成TextView的注册文本改变消息处理。里面使用onChange()调用。 关联的来处理onChange()的内部实现,返回值就是你的变量类型。 4 临门一脚

改变@ 为 @= ,变为双向方式 如此一来,达到view的数据变化,传递给数据这边。我们之前讲过如何将数据通知给view。这两个组合起来,则完成了双向通讯。 5 验证

这里先设置为28,然后在post里面做文本变更,通知到数据那边,然后数据那边设置一下,反馈给界面验证。

这里为什么用post呢?原因是binding内部处理数据是个异步的,所以当前这个消息队列里面,如果我们修改文本,因为文本改变回调还没注册呢,导致数据那边没同步了。(当然实际使用中这个情况很少的啦。)

6代码

github.com/luxiaoming/…

android MVVM开发模式(五) 上一讲我们说了@InverseBindingAdapter标记的事情。通过这个,我们可以实现view向数据方向的传递。从而实现真正的双向绑定。 已经讲了这么多,核心的知识点基本完成,要每个细节去说,估计十几节讲不完了,因此我们再来看下一个核心内容,结束本系列教程。如果使用中有任何疑问,欢迎沟通交流。 我们前面讲过,@BindingAdapter 实现的函数必须是静态的。那它不能是非静态的吗?答案是可以的。 这个需求的出现是因为 我们有时会想在两种情况下,一个属性出现两种表现逻辑代码,这个主要的需求便是 正常流程 和测试模式,测试下可以模拟一条线路,不必走我们正常流程下的数据,可以直接提供测试数据,来测试代码。 当然,如果我们使用一个属性,来改变界面颜色搭配。那么实现两个同一属性的方法,配置不同的颜色,通过设置使用哪个代码,可以达到换肤的效果啦。 我们看下怎么操作的。 移除掉User里面的@BindingAdapter @InverseBindingAdapter 的方法,原因是我们要给这个属性使用两组实现。

1 实现一个抽象类。

这里有个问题,本来按照我们的理解,@InverseBindingAdapter注解的函数方法,应该也是可以非静态的(我们想使用测试时候反馈和正常反馈有些差异,然而当前data-binding不允许这个为非静态~~~~。这个我看了生成代码,是完全可以做到为非静态的,所以不解为什么系统当前不支持。)

我们定义了两个抽象的属性适配,没有实现代码。

2 我们实现它

这里继承它,实现两个抽象方法。

3 实现DataBindingComponent接口

在我们做了上面的动作,具体指的是@BindingAdapter实现的方法是非静态的时候,那么我们肯定需要一个对应实例的吧。因此data-binding帮你将你需要写的方法生成了一个接口,让你去实现它就行了。(很智能化吧。)

我们实现它,返回一个适配器就可以了。在这里我们就可以清晰地看到,这个返回的我们可以定制的。如果我们多个继承了BaseAdapter类,比如OptionAdapter 和OptionAdapter2 ,我们这里可以再写一个组件,返回OptionAdapter2,在我们的代码里面依据情况使用不同的组件。

4 使用它

这里关键点,最后一个参数。将我们的组件实例传递给它。这样子生成的绑定里面,才能依据这个找到真正实现属性对应方法的实例,然后调用。

我们可以看到绑定的实现里面,做了这个动作。

mBindingComponent 是我们传递进来的,这里使用它的getBaseAdapter后再调用方法了。 所以我们通过传递不同的BindingComponent ,来实现同一属性多个实现方法了。

5 代码地址 github.com/luxiaoming/…