通讯录-选择器架构

周勋
222 阅读2分钟

一 .选择器模块整体结构

whiteboard_exported_image.png

上图从代码架构方面描述了其他业务模块调用通讯录-选择器模块的交互流程

  • 选择器Interface接口定义了：

      1）进入选择器的不同入口类型：EnterContactActionType

      2）进入选择器路由：ContactPickerInterFace.HomeRouter

      3）选择结果拦截器：PickerContactProcessor

      4）选择了的人/群：PickedUserModel，PickedGroupModel，这两个类都继承自PickedBaseModel

  • 其他模块调用选择器功能，通过选择器定义的Interface接口进入，示例如下：
const inPara:InPickerContactBasePara = {
   finishedPicker: (pickedModels: PickedBaseModel[]) => {

   },
   entranceType:EnterContactActionType.IM_MESSAGE_TYPE,
}
MNavRouteHelper.push(ContactPickerInterFace.HomeRouter, inPara)

其中的pickerProcessor是需要业务方自己生成的一个派生自PickerContactProcessor基类的实例对象，选择器通过finishedPicker方法返回业务方已选择的人/群数组。业务方根据自己业务逻辑进行后面的业务代码开发

二 .选择器模块内部结构

whiteboard_exported_image-2.png

  • 从上图结构可以看出进入选择器模块后，本次选择过程中的的各个Pages，Components共用同一个PickerContactViewModel的实例对象。PickerContactViewModel实例对象在选择器首页（PickerContactPage）生成，后面进入下级页面只需要将该PickerContactViewModel通过路由参数传递下去即可。
  • PickerContactContext根据业务方进入选择器时传进来的EnterContactActionType类型生成，其主要会生成一下选择器的静态配置参数，比如是否可多选canMutiSelect，最大选择人数maxSelectCount，是否允许分享给自己canChooseOwn等等。
  • PickerContactViewModel，持有一个PickerContactContext实例，并维护一个已选人/群的数组。各个Pages，Components中选择/取消选择都是通过其持有的公共PickerContactViewModel对象操作其内部维护的已选人/群数组。这样子各个Components查询自己对应的人/群选择状态也就很方便了。

三 .设计目标

  • 职责单一： 选择器只负责选择人/群，只是将选择了的人/群数组交给业务方的自己定义的xxxPickerContactProcessor处理。业务方拿到选择的人/群数组后，按照自己的业务需求继续开发自己的业务流程。
  • 单向依赖： 其他业务模块通过通讯录-选择器声明的Interface接口依赖选择器功能，选择器不依赖其他业务方定义的任何数据模型。
  • 解 耦合 ： 通过通讯录-选择器Interface接口声明选择器提供的能力，并将该Interface接口打包至公共模块协议接口供其他模块引入，调用。

四 .结尾

由于代码块展示有限，具体的业务逻辑还是需要去阅读通讯录-选择器相关代码

avatar
文章
阅读
粉丝