文档章节

Android 多状态加载布局的开发 Tips

postdep
 postdep
发布于 2017/05/03 13:22
字数 2297
阅读 51
收藏 0

什么是多状态 Layout

对于大多数 App 而言,项目中都有多状态加载 View 这种需求,如下图所示。

demo

对应到开发中,我们通常会开发一个对应的自定义 layout 用于根据页面不同的状态来显示不同的提示 view。

在项目中,我们大多会在开发初期就把这套 layout 框架写好,然后其他人的自己的开发过程中直接使用即可。如下所示:

<name.gudong.MJMultipleStatusLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <ListView
        android:id="@+id/lv_activity_center"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />

</name.gudong.MJMultipleStatusLayout>

这篇文章不讨论如何去实现这样的自定义 loading layout,Github 上这样的 layout 太多了,这里主要思考、总结在实际开发中开发这样的自定义 Layout 时应该注意那些地方。

但是为了说明方便,这里还是采用的方案简单叙述一下。

为了后文描述方便,这里把这个多状态自定义 Layout 先称为 MultipleStatusLayout。

实现方案

在实现 MultipleStatusLayout 时,首先选择继承一个 ViewGroup 作为自己的父类,然后默认把内部的第一个子 View 作为 ContentView,其它各种情形下对应要显示的 layout view,根据不同的加载状态,在 MultipleStatusLayout 中通过动态 addView 去控制对应 layout 的加载显示,也可以通过 ViewStub 把不同情形的 layout 进行懒加载,然后对外提供不同的方法,方便外部调用、控制不同状态下的 layout 显示。

嗯,简单说来就是这样,原理很简单,实现起来也没什么技术难度,对于一般的开发人员只要一开始明白具体的产品逻辑和实现思路,相信花不了多少时间就可以完成这样的 MultipleStatusLayout。具体这种方式的实现可以参看一个开源项目 的实现。

下面着重列举一下开发 MultipleStatusLayout 过程中的注意点或者要点。

Tips

考虑到 MultipleStatusLayout 开发完成后,会在项目中的很多页面中应用,而且很多时候是作为页面顶级父容器而存在,所以开发过程中一定要注意其性能还有稳定性,否则一旦出现问题,整个项目中应用到该 MultipleStatusLayout 的页面都会随之出现问题。

以下就从性能角度、可维护性、稳定性等方面考虑出发,列举一些开发 tip 。

选择最合理的父容器

首先 FrameLayout、RelativeLayout、LinearLayout 都可以作为 MultipleStatusLayout 的父类,抛开现在的应用场景不谈,都知道 RelativeLayout 在 layout 时需要 measure 两次,所以对于一个未来要在很多页面中使用的 Layout ,把 RelativeLayout 作为父类这个方案首先 pass 掉。

但是因为 MultipleStatusLayout 中显示的 view 大都需要居中显示,所以使用 RelativeLayout 相对比较容易控制居中位置,这可能是很多人选择 RelativeLayout 作为父类的初衷。这里自己可以做一下权衡。

关于 LinearLayout 和 FrameLayout,如果按照上一节提到的实现方案,其实都可以采用,不过考虑到该类 Layout 的应用场景,建议选择 FrameLayout。

因为MultipleStatusLayout 未来在大多数情况下是作为页面父容器存在的,既然是父容器,内容可能会有各种变化,这时使用 LinearLayout 这种线性布局就会在布局时显得特别局限,比如一些页面可能需要在 MultipleStatusLayout 之上显示一个 FloatActionButton 或者其他的 view,这时使用 FrameLayout 就会好做很多也会灵活很多。

选择最优的加载 View 方式

如何控制这些多状态对应的 View ? 对于一般的情形,至少有两种 View 类型,一种是加载中的 loading 样式 view,一种是异常状态的 layout view,当然还可能有更多具体的情形。

不同的样式对应一个不同的布局,为了简便我们可以一次性的把所有状态对应的布局都写在一个 layout 布局里,然后可以通过控制隐藏、显示来根据不同的状态来展示不同 view,这是最直接的想法。

但是,只要多思考一步,就会发现这种方式非常不可取。因为很多时候,MultipleStatusLayout 作为一个父容器只关心自己的 ContentView,异常页面和加载页面甚至可能没有机会出现,但是现在这样做就表示,这个页面不论有没有异常或者加载逻辑,你的布局里都会存在对应的 layout 布局代码。这样在界面绘制时就会白白耗掉多余的时间。

而且这个 Layout 后续会在项目很多页面用到,所以这里的布局耗时问题放大后就显得很严重。

鉴于此,取而代之的更好的做法应该是动态去 addView,只有这个页面第一次调用 loading 或者 showError 这样的方法,我才去把对应布局加载进来,当然这里使用 ViewStub 也是一样的效果。

这里也就是说,只有调用了相应的方法,才去加载对应的 layout.

资源命名

其实这个问题是自己开发公用 Api 普遍面临的问题,由于开发 MultipleStatusLayout 可能会定义一些颜色资源或者背景资源,这里建议所有资源开头使用一个固定的开头,这样可以防止跟主版本中的资源重名。进而早成一些奇怪的 UI 问题或者编译问题。比如按钮的背景你可以定义为 msl_btn_normal 而不是 btn_normal,文字的颜色你可以定义为 msl_text_white 而不是 text_white。这样就可以有效避免一些资源冲突。

更多关于如何开发一个第三方库,可以查看天之界线开发第三方库最佳实践

提供友好的方法调用方式

既然是提供给大家使用,你就应该在方法命名上多花点心思,最好见名之意,这样大家调用时也会舒服很多。

另外对外提供 Api 时也应该保持克制。不要一下子提供出去太多的方法,不论有用没用,一下子都对外提供,这样会对后续的维护造成隐形的负担,因为提供的公用方法越多,表示你后续都要对这些方法进行维护。

最好的原则就是用到什么提供什么,不要提前设计。

另外,随着项目迭代,对外提供方法的参数可能会变得多起来,比如以前显示错误页面的方法是

void showErrorView(Stirng error) 

后来要增加自定义的 icon 或者点击事件响应,这时你就需要扩展方法参数,往往这种参数可能会变得很多不可收拾,这时建议使用 Build 构建模式设计,如下示例所示:

showErrorView(StatusViewConfig config) 

调用时就可以这样调用

showErrorView(new StatusViewConfig.StatusViewBuild(getContext())
                .icon(icon)
                .message(message)
                .subMessage(subMessage)
                .layoutMode(mLayoutMode)
                .withActionText(actionText, clickListener)
                .build())

良好的文档

当你开发完成后,最好趁热写一份简单明了的使用文档出来,这样大家就可以直接对照文档使用你写的库,不用去关心代码实现,直接调用 Api 就可以完成自己的业务需求,同时也省的自己去面对面跟别人讲怎么使用了。

前段时间在 V 站上看到一个问题,说你们公司使用什么样的文档管理工具?其中有一个回答言简意赅,很有意思,四个字 口口相传

其实对于任何一个项目都是,有时间写点文档,梳理自己思路的同时方便别人,何乐而不为。

其他

这种 Layout 在项目中会随着项目的更新迭代而不断的更新,所以一开始你就应该知道,后续还要不断迭代更新,所以代码设计实现时应该留意扩展性。

另外,相关的开源方案有很多,建议一开始可以参考一些好的方案,然后结合自己项目的实际需求,来开发维护属于自己项目的一套框架。因为多状态 loading 加载提示框架大都和产品设计强相关,不具备一般的通用性。

下面列举一些自己收集到的多状态加载开源方案,方便对比。

开源方案

StatefulLayout

progress-activity

StateLayout

MultipleStatusView

总结

同样功能的 Layout 可能在不同的业务场景下实现方式也会有很大的区别,所以不论哪种实现方式,无所谓好坏,只要适合就好。但是开发此类 Layout 要遵循的基本准则、以及要注意的点应该大都相同,希望此文可以给你一些启示帮助。

© 著作权归作者所有

共有 人打赏支持
postdep

postdep

粉丝 80
博文 255
码字总数 261672
作品 0
武汉
高级程序员
Flutter尝鲜:跨平台移动应用开发

开始之前 本人使用Flutter开发的一个图文App《每日图文》,可以同时运行在Android和iOS上,欢迎体验,喜欢的话还不吝Star一下。 叮叮叮~ 传送门 Flutter为何物? 随着移动App开发成本越来越...

开发的猫
06/06
0
0
Android Fragment 基本介绍

Fragment   Android是在Android 3.0 (API level 11)开始引入Fragment的。   可以把Fragment想成Activity中的模块,这个模块有自己的布局,有自己的生命周期,单独处理自己的输入,在Act...

postdep
2014/06/11
0
0
Android零基础入门第86节:探究Fragment生命周期

一个Activity可以同时组合多个Fragment,一个Fragment也可被多个Activity 复用。Fragment可以响应自己的输入事件,并拥有自己的生命周期,但它们的生命周期直接被其所属的Activity的生命周期...

鑫鱻
2017/10/30
0
0
Fragment 的使用(1)

基本:http://www.cnblogs.com/mengdd/archive/2013/01/08/2851368.html 深入:http://blog.csdn.net/pi9nc/article/details/12249619 Fragment  Android是在Android 3.0 (API level 11)开始......

chuiyuan
2014/07/23
0
0
Android零基础入门第85节:Fragment使用起来非常简单

Fragment创建完成后并不能单独使用,还需要将Fragment加载到Activity中,在Activity中添加Fragment的方式有两种:静态加载和动态加载,接下来分别进行学习。 一、静态加载 静态加载Fragment非...

鑫鱻
2017/10/27
0
0

没有更多内容

加载失败,请刷新页面

加载更多

实战讲解高并发和秒杀抢购系统设计

互联网特别是电商平台,阿里双11秒杀、还有12306春运抢票、以及平时各种节假日抢购活动等,都是典型的高并发场景。 这类场景最大的特征就是活动周期短,瞬间流量大(高并发),大量的人短期涌...

xtof
30分钟前
0
0
代码质量管理平台-sonarqube

在工作中,往往开发的时候会不怎么注重代码质量的人很多,存在着很多的漏洞和隐患等问题,sonarqube可以进行代码质量的审核,而且十分的残酷。。。。。接下来我们说下怎么安装 进入官网下载:...

落叶清风
33分钟前
6
0
在Ubuntu安装和配置Sphinx

Ubuntu系统默认是配置有sphinx的,先检查一下,别多此一举。。。。。 在开始本指南之前,您需要: 一个Ubuntu 16.04服务器。 sudo的一个非root用户,您可以通过以下设置本教程 。 安装在服务...

阿锋zxf
42分钟前
1
0
Qt编写输入法V2018超级终结版

对于qt嵌入式linux开发人员来说,输入法一直是个鸡肋问题,要么不支持实体键盘同步,要么不能汉字输入,要么不支持网页输入等,这几年通过陆续接触大量的各种输入法应用场景客户,得到真实需...

飞扬青云
53分钟前
2
0
TypeScript基础入门之高级类型的多态的 this类型

转发 TypeScript基础入门之高级类型的多态的 this类型 高级类型 多态的this类型 多态的this类型表示的是某个包含类或接口的子类型。 这被称做F-bounded多态性。 它能很容易的表现连贯接口间的...

durban
59分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部