Android Activity数据回传的一种另类实现

@(八千里路云和月)

[TOC]

业务场景描述

ActA启动了ActB, ActB会对数据进行处理, ActB里面的数据可能会在ActC里面进行进一步的处理, 要求: C和B都要能够给处理结果传递给ActA.

可能的实现方案

1. startActivityForResult
   对于级联的startActivityForResult, 我们需要设置FLAG_ACTIVITY_FORWARD_RESULT, 具体可以参考这篇博客](https://goo.gl/seVq9k)
   这个是最先想到的方案,尝试了一下, 发现并不能解决问题, 原因也在Android doc 里面有说

   if the activity you are launching uses the singleTask launch mode, it will not run in your task and thus you will immediately receive a cancel result

2. 使用BroadcastReceiver来进行通讯.
   这个方案能够解决问题, 大家很开心.
   由于一开始模块没有使用多进程,我们实现上使用了LocalBroadcast, 之后我们使用了多进程的方案, 然后这个LocalBroadcast废了, 还好更新的BoradcastReceiver工作量也不大.

   使用该方案要注意BoradcastReceiver生命周期的管理: 使用onCreate/onDestory来进行管理(总感觉怪怪的...).

3. 使用其他进程间通讯的方案

   1. Socket/LocalSocket
      ActA启动一个ServerSocket, ActB/ActC对数据修改时, 将信息写入到Socket里面, 这样ActA就能实时的获取数据的变更了.
      这个是典型的用牛刀, 不实用,但也是一个解决问题的思路.
   2. Service数据同步
      提供一个后台服务(BackgroundService/BS), 数据修改时, 告诉BS, ActA到BS里面进行查询结果.
      这个实现起来也太重,仅做参考.

第一种方案改进(Evolution):

对于singleTask E1

EventBus提供了Sticky Event能够规避这个问题.

Sticky Events
可以先发布后订阅的事件, 具体可以参考官方的说明Sticky Events

由于EventBus不支持多进程,因此, 该方案要继续进化.

多进程支持 E2

由于E1 不支持多进程, 因此 用E1+3.2(数据同步)就能够解决问题了.
前提

应用里面已经有了跨进程数据存储的方案(DB)

因此我们只要实现数据的Cache/Retrieve就可以了.具体的实现如下

1. 定义数据存储的接口

//IRepository.java 定义数据的存取
Observable<List<StoreEventPO>> getCurrentUIEvents(String actionType);
Observable<StoreEventPO> saveUIEvent(final StoreEventPO event);
Observable<StoreEventPO> removeUIEvent(StoreEventPO event);

//StoreEventPO.java 定义要存取的事件的数据结构.

2. ActB/ActC 更新数据时, Cache行为事件

//Client: 事件的生产者 调用
saveUIAction{
    ...
    IRepository#saveUIEvent(StoreEventPO)
    ...
}

3. ActA Retrieve 行为事件.

//Client: 事件的消费者 
    @Override
    protected void onResume() {
        ...
        checkUIEvents();  
    }
    public void checkUIEvents() {
        IRepository#getCurrentUIEvents(EVENT_TYPE_XXX).logic...
    }

方案一演进到E2就能够解决业务场景的问题了, 该方案避免使用FLAG_ACTIVITY_FORWARD_RESULT这个复杂(对结果进行forward)的字段

总结

遇到问题, 使用直接暴力的方式去解决, 发现在特殊的场景下(singleTask)撂挑子,然后思考怎样解决该特殊的场景, 发现EventBus的Sticky Events(本质是Cached Events)能够解决当下问题, 又引入了新问题(cross process), 结合项目的具体实现(数据存储能够 cross process)最终演进到能够解决问题的方案.