PTR源码心得（一）

Pull To ReFresh

PullToRefresh(PTR)是非常常用的一个控件，虽然因为理念的问题，已经算是落后，并且已经停止维护，但是总得来说是十分实用的控件，并且其中很多的设计理念都还算非常缜密。
最近因为项目需要，需要对ptr进行一些改进，所以第一次系统的读了一下ptr的代码，也是第一篇的csdn的博客。

1.设计概述

ptr支持的空间包括gridview/ scrollview/ expandablelistview/ recyclerView/ Scrollview/ WebView多个

从设计的角度，ptr的作者希望将整个ptr作为一个组件而非一个容器进行设计，所以希望ptr不但能够完成下拉刷新的功能，也需要对其中的组件进行属性控制，从设计模式的角度出发，设计的耦合度会比较高，不利于扩展和修改，所以这也是系统落后的一个原因。

ptr核心的类包括PullToRefreshBase(PTRBase)、 PullToRefreshAdapterViewBase(PTRAdapter)、 LoadingLayout，支持的组件全部继承自PTRAdapter，PTRAdapter继承自PTRBase，模拟了一个adapter的行为。而PullToRefreshBase则实现了所有下拉刷新和上拉加载的功能基础，LoadingLayout实现了刷新的Header和Footer，在PTRBase中进行实现初始化。

2.PTR的Orientation、Mode&State

在PTR中，设置了2种方向5种模式和6种状态，以设定PTR的行为。

PTR的方向，当然包括水平和垂直，不同的方向会加载不同的LoadingLayout，实现不同的布局属性等。

当然从设计模式来说，不算是一个好的设计结构，理想的状态，当然是不管是水平还是垂直，都可以采用同一个自适应的header，否则的话，如果进行扩展，工作量就会加倍

通过设定PTR的Mode可以选择五种状态为disable(不能下拉)、PULL_FROM_START(下拉以刷新)、PULL_FROM_END(上拉加载更多)、BOTH(都可以)、MANUAL_REFRESH_ONLY(只允许手动刷新)。

看过UltraPullToRefresh的设计思路之后，确实觉得这种设计方法不好，因为下拉刷新和上拉加载更多所承载的功能并不相同。从设计模式的单一功能的原则来说，这样并不合理，但是在当时来说，应该也是源自某个项目。并且disable这个状态也设定的有一些多余。

几种状态为RESET(回归原状态)、PULL_TO_REFRESH(下拉但是没有达到刷新位置)、RELEASE_TO_REFRESH(已经达到了刷新位置，可以进行刷新)、REFRESHING(刷新中)、MANUAL_REFRESHING (手动刷新)、 OVERSCROLLING （这个不知道怎么翻译）。

个人感觉状态的设定比较琐碎，在阅读代码中，觉得这个过程可以化简为，刷新前、刷新、刷新后，甚至可以更加简化为刷新与未刷新，当然UPTR采用的是前者，阅读代码时的感觉，这些状态也是作者在设计PTR的过程中不断添加以应对深度耦合带来的修改不便的情况，导致了代码的行数的无畏增加，因为很多状态并没有什么有用的实现。

3.ILoadingLayout与IPullToRefresh

这两个接口中生命LoadingLayou和PTRBase的属性设定方法，包括文字颜色和刷新的Drawable等。

如果是仅仅是对属性进行设定，可以写成LoadingLayout的set的方法，并且设定一些默认的属性，因为字体颜色、刷新时进行动画的drawable这些属性，都不是必须同时设定并且必须的，而且既然刷新时的提示语都可以采用设定好的String，那这些应该也可以吧。设定成一个借口，没有太大的必要了。

4.PTR与UPTR

在对PTR的源码阅读之前，由于项目需求了解了UltraPullToRefresh的设计思路和一部分代码，从设计的角度来说，由于UPTR的作者秋百万前辈也借鉴了很多PTR种的思路(后面会说)，所以UPTR的设计更加的先进。并且UPTR仅仅实现了下拉刷新的功能，所以整个项目更加的干净灵活。
我自己的看法中，写出了PTR的一些问题，也不敢有所指点，毕竟我也是一个新手，但是觉得设计一个组件，可能考虑到设计模式的一些准则，可能会使代码的可读性更好一点，扩展性更强一点吧。