概述
通常来说,解决activity和fragment通信的问题。我们都是采用如下几种方式,
handler,广播,EvnetBus,接口等。那么有没有一种更好的方式来实现呢,最近项目一只在使用Rx,这里参照了一下Rx的设计来解决如上问题。先来说说常用的几种方式。
handler方式
这是一种最不好的初级方式,在fragment中调用activity中的handler发送信息,activity处理信息。缺点也十分明显,耦合性极强,并且获取不了activity的反馈,总之体验十分不好。
广播
这是一种另类的玩法,个人感觉大材小用了。广播适用于一对多且接收者不明确的情况下,
而且广播传播的信息需要实现序列化借口,总之是一种耗费性能的方式。
EvnetBus
EvnetBus作为一款事件总线存在,可以用于Action的传递,但是这种方式的缺点有:是用反射(对性能有影响),EvnetBus发送者和接受者分离严重,不好维护,且不可以获取activity反馈,也不是十分理想。
接口
之前处理这类问题一直也是适应这种方式,总体来讲还是很不错。但是也有缺点,当项目大了的时候,就需要定义很多的接口,这时候就容易混淆,不好维护。
新大陆
总结一下Rx的设计思路,Rx和设计模式中的观察者十分类似。activity和fragment通信,实质上就是所谓事件的传递和响应,只是这个事件是一个特殊的事件,就是可以执行的方法(js中function也可以是参数),那么如果activity需要监听fragment的事件,只需要观察其相应事件即可,fragment同理。
如果对观察者不熟悉的可以看一下:这就是观察者模式
Observable
1 | public interface ObservableInterface<T, P, R> { |
Observer
1 | public interface Function<Result, Param> { |
这里的Observer就是一个方法的抽象,包含 参数 和 返回值。在Activity和Fragment中传递的就是Fuction,在需要监听的地方注册事件,在适当的地方触发事件。下面看一下Observable的具体实现
ObservableManager
1 | public class ObservableManager<Param, Result> |
这里才用了一个HashMap来存储所有Observer集合,触发事件后就轮询集合循序之行,这就是观察者其中之一的缺点,一个Observer可能阻塞,影响其他执行。
使用
Activity中注册Function事件,Fragment中出发Function事件,执行的到结果,反之亦然。
1 | // 注册事件,Activity实现Function接口 |
1 | //触发事件,并获得返回值 |
1 | //事件执行,实现于Function接口 |
最终效果:
示例代码:ActivityFragment