Android自己动手实现下拉刷新控件(3)—-动手实现
整个系列文章的脉络是:
github地址:https://github.com/BigPig-LittleTail/RefreshLayout
ps: 自己看文章和github开源库的时候最烦的就是没有readme和图的文章,不料自己也是其中一员,后续可能会补上动图。这是后续加上的效果图,readme还没有写。有加载进度条的头部的图片怎么也上传不上去。先拿这个没有进度条的凑合着吧。
写在这篇文章的前面
在我完成开发文档之后的日子里,我又对自己实现的下拉刷新控件做了维护和更新。
写这三篇博客的本意是将自己在开发下拉刷新过程中遇到的问题,怎么解决问题,以及自己的一些思考记录下来。所以本想将自己的开发文档copy过来,但发现将自己的开发文档已经落后于自己的开发。在这里就不copy了,写点新鲜的。
这篇文章主要说说自己实现一个下拉刷新控件,所思考和所实现的。
为什么要实现一个自己的下拉刷新控件
github上很多下拉刷新库都很炫酷,为什么要自己实现一个下拉刷新控件?
这个问题我在第一篇文章里就提到过。我最初的答案一定是:练手。所以以练手为目的的下拉刷新,实现简单,但可扩展性差。
人总是要有追求一点,我又去比较了github上高星的下拉刷新库,他们的大多做法是,集成一些炫酷的下拉刷新头,完善自己的RefreshLayout的逻辑,适应各种头部。
但是当炫酷的头部并不是使用者所需要的需求时,他们大多是怎么做的呢?提供一个Header头部的接口,让使用者重新实现一个头部。
这就引发了我更深一步的思考,到底一个下拉刷新库应该是怎么样的呢?
于是问题就变成了,为什么要实现自己的下拉刷新库,我的库和别人的有什么优势呢?
我对“一个下拉刷新库应该是怎样的”的思考
一个成熟的第三方库所需要做的事情有以下几点:
- 很少的bug(想做到没有bug是不可能的)
- 向前兼容
- 可扩展性强
- 对各类使用者友好
对于第一点和第二点:
作为一个开发者,所需要保证的是,在各个版本迭代的过程中,不仅保证向前兼容,也要保证内部逻辑能处理复杂的环境。这是库的核心,也是最需要保障的事情。所以,我在开发过程中,不断测试进行bugfix,尽量保证有最少量的bug。
对于第三点:
作为一个使用者,无论你的第三方库做到了多么极致,集成了多少头部,它总有没有办法满足自己需求的一天,那么一个使用者能不能在你的库的基础上,实现自己的下拉刷新就很关键。所以,我和很多第三方库的做法一样。提供了整个头部所需要实现的接口。按照接口,实现一个自己的头部。
public interface RefreshHeaderInterface {
View sendHeaderView(ViewGroup parent);
float sendHeaderHeightDp();
float sendHeightDpWhenRefreshing();
void reset();
void pull(float pullPercent);
void pullFull();
void refreshing();
void showRefreshResult(boolean refreshResult);
}
对于第四点:
这是我的下拉刷新库与一些库不同的地方。对各类使用者友好,意味着,面对不同水平的使用者,我们都要做到友好。
- 对于完全不会写下拉刷新的人,我提供了内置的刷新头,供这类人使用,这跟很多库集成大量酷炫的头部的做法一样,目的是,一个不会写下拉刷新的使用者上手成本很低。(当然我的库目前没有他们那么炫酷)
- 对于一个会写android动画的人,或者会使用canvas绘制的人,我提供了builder模式和加载进度ProgressView的抽象类,他们只需要重写少量的代码,就能改变头部效果或者实现自己的加载进度ProgressView。这一点,是很多下拉刷新库没有考虑到的。
- 对于一个和我水平差不多的初级开发者,可能想重新实现一个自己的酷炫的头部,那么就需要根据上面的接口,实现自己的头部。这一点我和大多数下拉刷新库一样,提供了接口。那么按照你的大胆的想法实现头部就好。至于刷新控件的内部逻辑,交给我们来处理。
- 对于一个大神级开发者,对不起,我的库太垃圾了,你可以自己实现去写一个库,但是要考虑上加粗字体的那类人哦。
后语
这篇文章本来是想要代码层面分析我自己的控件的实现的。但是由于开发文档和我的开发进度的脱节,导致我再从代码层面分析,又要码近几千行的文字,时间上目前不太允许,可能以后会补上。
所以这篇文章的重点放在了,第三方下拉刷新库所需要考虑的点,加粗字体是我的个人体会和思考,如有片面和不妥的地方,欢迎讨论。