从上图可知,DataAgent的大致工作流程为:
DataAgent将真正的数据请求发送给各数据源,数据源可能为缓存、SQLite或文件,但通常是从服务端获取数据,因
此DataAgent会将数据请求发到网络框架层,然后等待数据返回。
由于数据源不同,返回数据也可能不同,这里简化为两种:原始JSON或Model。
DataAgent拿到数据后,则开始数据处理流程。以从网络请求的JSON数据为例,先对返回的JSON进行数据校验,检
查数据的有效性与正确性,如果数据校验通过,接下来根据需求来决定要不要写入缓存,然后再进行数据加工(如精度
处理、数据拼接、数据裁剪等),最后进行数据解析得到视图层需要的Model。如果数据校验没有通过,则尝试从缓存
中读取,从缓存中读取后也需要校验(检查数据的时效性、有效性、正确性),校验通过后同样进行数据处理、解析等流
程。如果缓存中读取得到的就是Model,那么则可以省略数据处理和解析的流程。得到最终的Model后,DataAgent将
其包装发送给MessageScheduler。另外DataAgent还要具有一定的容错功能,因为任何数据源都无法保证能够返回合
法的数据,如果不对数据错误进行容错处理,那么就可能无法解析为对应的Model,从而导致视图层无数据甚至异常。
如果接口及缓存都无法返回正确的数据,DataAgent需要做特殊处理,以保证视图层能给用户以反馈。
业务视图逻辑
虽然不同的业务页面有不同的视图逻辑,这里以一个应用中最常见的页面为例来说明,假设该页面有一个列表。大家
都知道ListView(此处为泛指,可能大家都在用RecyclerView了)的工作方式,它需要ViewHolder来填充视图,需要
Adapter来填充数据,如果每个需要ListView的界面都维护各自的一套ViewHolder及Adapter,那么页面逻辑又将变得
臃肿。
我们在实践中是这样做的:
封装一个Adapter公共处理类,提供多种构造函数,其中有一个type参数,用来标明需要使用哪个ViewHolder。
封装一个ViewHolder抽象类,定义数据设置的逻辑,并交由具体的ViewHolder实现。
构建一个叫做ViewHolderFactory的类,顾名思义该类主要作用是用来构建ViewHolder,它主要提供两个方法
createViewHolder()与createConvertView(),其中createConvertView()是个中间方法,用于生成ViewHolder。
在Adapter的getView方法中,根据上述type参数,获取具体的ViewHolder实现,调用设置数据的逻辑。
经过上述封装之后,视图层只需要向Adapter公共处理类传入一个type参数即可得到对应的Adapter;等数据返回到视图
层后,再将数据传给Adapter公共处理类,其他什么都不用管,就可以展示列表数据了。原本需要很多代码实现的逻辑
从视图层抽离之后,视图层只需要几行代码就能够完成一个列表展示了。
Hybrid框架