单页面请求多接口的处理逻辑

说明:

随着公司发展, APP端页面越来越多, 页面元素信息和交互逻辑越来越丰富, 免不了有时一个复杂的页面需要请求多个接口. 我们来简单总结一下以往的处理方式.

如果一个页面打开的时候需要请求几个接口, 分几种情况:

1. 几个接口之间的数据在逻辑层和UI层没有任何依赖关系, 如下:

    接口A->处理逻辑A->更新UI元素A
    接口B->处理逻辑B->更新UI元素B
    ...

这里每一个接口的返回处理又分几种情况:

1.1. 接口返回的数据不太重要(非强业务逻辑). 例如一个用户/社团的关注状态.

这种情况下: 

    接口调用成功, 就调整对应的UI元素. 例如上面的关注按钮的已关注状态/未关注状态;

    接口调用失败, 按照既定原则来调整对应的UI元素到一个默认状态. 例如上面的关注按钮, 和产品后端讨论后, 决定显示为未关注状态;

1.2. 接口返回数据很重要, 缺失这些数据无法正常完成既定逻辑. 例如漫画评论页顶部的当前漫画信息.

这种情况下:

    接口调用成功, 就调整对应的UI元素. 例如漫画评论页顶部的当前漫画信息;

    接口调用失败, 因提供一种交互方式让用户可以自行重新触发这个接口请求. 例如显示一个reload按钮;

2. 几个接口之间在逻辑层存在前后关系, 后面的接口需要前面的接口返回数据作为参数请求, 如下:

    接口A->处理逻辑A->更新UI元素A(maybe), 同时调用接口B->处理逻辑B->更新UI元素B

唉, 其实这种情况我觉得不应该存在, 毕竟API端有责任整理好完整的数据再给前端. 不过当然也有跨服跨SDK的特例.

做法只能直接按照逻辑顺序一个一个调用, 注意要处理每一个请求失败的情况

3. 几个接口之间有逻辑层关系, 但是可以并行调用:

    接口A-> 处理逻辑A-> 更新UI元素 <-处理逻辑B <-接口B

通过线程同步手段(如Dispatch_group)来同步各个接口的回调, 然后一起刷新UI.

标签:none