前面所讲述的使用,对一般需求来说已经足够了,但是可能还有人发现了一些问题,之前说可以代替Intent传递数据,我们知道的是Intent可以在activity的时候携带数据,十分方便,那么EventBus可不可以在跳转的时候传递数据呢?
我们这里建两个测试用的Activity,分别是TestActivity和TestSecondActivity,同时新建一个事件类,综合前面所讲的内容写一个两个activity之间使用EventBus的示例。
TestActivity代码如下:
|
|
由于TestActivity只用来产生事件,不需要接收事件,所以不需要注册EventBus,只在产生事件的点击事件方法里调用了post方法。
被注释掉的代码请先忽视,这是后面另一个测试的代码内容,这里只看点击事件中未被注释的两行。
下面是TestSecondActivity的代码:
|
|
可以看到,为了在TestSecondActivity接收到事件,我们在onCreate里注册了EventBus,并且在onDestory方法中取消了注册,同时编写了带有注解的getMsgFromFirstActivity方法,方法运行在UI线程,接收TestEvent事件并打印log。
两个activity的布局文件都十分简单,只有一个或者两个控件,这里不再列出。
TestEvent类作为事件类,也就是一个简单的实体类:
|
|
运行后结果为:
可以看到,只有发送事件的log,第二个activity并没有接收的事件,这是为什么呢?
回头看我们的流程,很容易就会发现,我们的事件发送是在第二个activity调用onCreate方法之前发生的,也就是说第一个发送方发送事件的时候接收方还没有注册,而接收方注册完成的时候事件已经发送过去了。所谓我生君未生,君生我已老,世界上最悲惨的事莫过于此了┑( ̄Д  ̄)┍。
我们当然不能让悲剧发生,所以黏性事件就这么产生了,怎么发送黏性事件呢?很简单的修改,将post换为postSticky即可。
|
|
然后由于黏性事件与黏性广播类似,黏性事件是将事件暂存在EventBus的缓存中,所以在接收方最后除了要取消注册外,还需要清除黏性事件。
|
|
同时为了接收黏性事件,我们也用到了@Subscribe注解中的sticky属性,需要将接收事件的方法注解中添加sticky=true:
|
|
将之前的代码进行上面的三处修改后运行,运行结果:
可以看到,第二个activity在跳转后完美收到了第一个activity发送的事件。
还有一个需要注意的地方,黏性事件的原理是将发送的事件暂时存放在EventBus的一处内存中,一旦有对应的接收方注册,就会从这个内存中获取到这个事件并进行响应的处理。
那么如果我们在第二个activity注册前发送多个同类型的黏性事件,第二个activity会怎么接收这些事件呢?
下面把之前注释掉的代码解除注释:
|
|
第二个类不变,下面运行,点击前两次后log显示了两个test11send,表示有两个黏性事件发送了出去,点击第三次后发送第三个黏性事件并启动接收事件的activity,运行结果如下:
可以看到,只有最后一个黏性事件被接收到,也就是说,如果有多个同类型的黏性事件发送到同一个接收方,则接收方注册后只会接收到最后一个事件。