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。这一点，是很多下拉刷新库没有考虑到的。
对于一个和我水平差不多的初级开发者，可能想重新实现一个自己的酷炫的头部，那么就需要根据上面的接口，实现自己的头部。这一点我和大多数下拉刷新库一样，提供了接口。那么按照你的大胆的想法实现头部就好。至于刷新控件的内部逻辑，交给我们来处理。
对于一个大神级开发者，对不起，我的库太垃圾了，你可以自己实现去写一个库，但是要考虑上加粗字体的那类人哦。

后语

这篇文章本来是想要代码层面分析我自己的控件的实现的。但是由于开发文档和我的开发进度的脱节，导致我再从代码层面分析，又要码近几千行的文字，时间上目前不太允许，可能以后会补上。
所以这篇文章的重点放在了，第三方下拉刷新库所需要考虑的点，加粗字体是我的个人体会和思考，如有片面和不妥的地方，欢迎讨论。