实现统一用户体验的BaseActivity

对一个规模较大的App开发团队来说,保持统一的代码规范是个好的事情,同时,保持统一的用户体验规范也是个好的事情。

当用户进入一个页面时,一般会有以下交互场景:
场景1, 初始化loading,页面从server拉取配置信息;
场景2, 初始化成功,页面展现业务UI布局,比如输入框,按钮等;
场景3, 初始化失败,页面从server拉取配置信息出现异常;
场景4, 初始化失败,因为设备的网络连接异常;
5, ……

对于某一个负责某一业务模块的开发人员来说,他可能会有糟糕的用户体验实现:
实现场景1, 当初始化页面的时候,直接展示业务UI布局,然后弹出一个loading对话框,用户可以看到地下残缺不全的UI元素;
实现场景2, 初始化成功之后,dismiss掉第1条的loading对话框,业务UI布局被数据填充;
实现场景3, 因为数据错误初始化失败, dismiss掉第1条的loading对话框,业务UI布局没有数据可填充,残缺不全,甚至状态不对(比如某个按钮需要让server的开关决定是不是点亮状态),然后toast一句错误给用户,之后用户只好退出页面再从入口再次点进来以进行初始化重试;
实现场景4, 因为网络异常初始化失败,同第3条,UI元素没数据填充,状态不对,用户被一句toast打发了,没有重试入口,只能退出页面再来;

对于另一个负责某一业务模块的开发人员来说,他可能会有良好的用户体验实现:
实现场景1, 当初始化页面的时候,页面暂时不展示业务UI布局,而是展示一个加载中的页面;
实现场景2, 当初始化成功之后,切换到业务UI布局,并用数据填充UI;
实现场景3, 因为数据错误初始化失败之后,从加载的状态切换到一个“没有数据”或者“数据错误“之类的页面,并且用户点击页面,可再次重试初始化接口;
实现场景4, 因为网络异常初始化失败之后,从加载的状态切换到一个”网络未连接“之类的页面,并且用户点击页面,会再次重试初始化接口;甚至,监听网络状态,当网络连接后,自动重试;

好,对比之后,我们把第二个开发人员的体验实现当做规范,并要求所有开发人员在业务页面实现过程中都遵守这个规范。
那么问题来了:
1, 业务开发人员工作量增加,上面讲的4个场景都要一一实现;
2, 冗余代码多,上面说的场景,除了第2条,1, 3,4都是一样的代码实现;
3, 场景1, 3, 4的实现没有收敛,以后无法统一修改;

然后,一个抽象的实现来了,BaseActivity, 把场景1, 3, 4都包了,只留下2给业务开发人员去实现。
更多,一般每个页面都有导航栏,导航栏是个通用实现,上面的场景都是针对导航栏下面的区域进行的,跟导航栏没关系,所以这个BaseActivity也把导航栏的实现给承包了,子类透明无感。
子类布局的root view对于BaseActivity来说,只是其布局中的一部分。

BaseActivity要做这些事情:
1, 布局,包含导航栏,以及导航栏下面的4个要切换的布局,包括loading布局、业务UI的父布局、数据错误布局、网络异常布局;
2, 重写所有setContentView方法,子类调用这个方法的时候,把其传过来的view添加到第一条里的业务UI的父布局上;
3, 假定网络请求返回的数据对象是BaseResult,BaseActivity提供protected的一个方法,该方法接收一个BaseResult参数,然后根据其内容自动切换到对应的场景布局下;
4, 提供网络异常和数据错误的点击事件回调给子类,以便子类发起重试;

原文地址:https://www.cnblogs.com/mosthink/p/5289131.html