为什么“下拉刷新”没有成为移动应用的标准功能

大哥大姐哪位知道,为什么“下拉刷新”没有成为移动应用的标准功能
最新回答
﹎梦醒的夏天╰╯

2024-11-06 05:41:12

下拉刷新这种用户交互最早由twitter创始人洛伦•布里切特(Loren Brichter)发明,有理论认为,下拉刷新是一种适用于按照从新到旧的时间顺序排列feeds的应用,在这种应用场景中看完旧的内容时,用户会很自然地下拉查找更新的内容,因此下拉刷新就显得非常合理。大家可以参考这篇文章:有趣的下拉刷新,下面我贴出一个有趣的下拉刷新的案例。

2. 实现原理
上面这些例子,外观做得再好看,他的本质上都一样,那就是一个下拉刷新控件通常由以下几部分组成:
【1】Header
Header通常有下拉箭头,文字,进度条等元素,根据下拉的距离来改变它的状态,从而显示不同的样式
【2】Content
这部分是内容区域,网上有很多例子都是直接在ListView里面添加Header,但这就有局限性,因为好多情况下并不一定是用ListView来显示数据。我们把要显示内容的View放置在我们的一个容器中,如果你想实现一个用ListView显示数据的下拉刷新,你需要创建一个ListView旋转到我的容器中。我们处理这个容器的事件(down, move, up),如果向下拉,则把整个布局向下滑动,从而把header显示出来。
【3】Footer
Footer可以用来显示向上拉的箭头,自动加载更多的进度条等。

关于上图,需要说明几点:
1、这个布局扩展于LinearLayout,垂直排列
2、从上到下的顺序是:Header, Content, Footer
3、Content填充满父控件,通过设置top, bottom的padding来使Header和Footer不可见,也就是让它超出屏幕外
4、下拉时,调用scrollTo方法来将整个布局向下滑动,从而把Header显示出来,上拉正好与下拉相反。
5、派生类需要实现的是:将Content View填充到父容器中,比如,如果你要使用的话,那么你需要把ListView, ScrollView, WebView等添加到容器中。
6、上图中的红色区域就是屏的大小(严格来说,这里说屏幕大小并不准确,应该说成内容区域更加准确)

3. 具体实现
明白了实现原理与过程,我们尝试来具体实现,首先,为了以后更好地扩展,设计更加合理,我们把下拉刷新的功能抽象成一个接口:
1、IPullToRefresh<T extends View>

它具体的定义方法如下:
[java] view plain copy
public interface IPullToRefresh<T extends View> {
public void setPullRefreshEnabled(boolean pullRefreshEnabled);
public void setPullLoadEnabled(boolean pullLoadEnabled);
public void setScrollLoadEnabled(boolean scrollLoadEnabled);
public boolean isPullRefreshEnabled();
public boolean isPullLoadEnabled();
public boolean isScrollLoadEnabled();
public void setOnRefreshListener(OnRefreshListener<T> refreshListener);
public void onPullDownRefreshComplete();
public void onPullUpRefreshComplete();
public T getRefreshableView();
public LoadingLayout getHeaderLoadingLayout();
public LoadingLayout getFooterLoadingLayout();
public void setLastUpdatedLabel(CharSequence label);
}
这个接口是一个泛型的,它接受View的派生类,因为要放到我们的容器中的不就是一个View吗?

2、PullToRefreshBase<T extends View>
这个类实现了IPullToRefresh接口,它是从LinearLayout继承过来,作为下拉刷新的一个抽象基类,如果你想实现ListView的下拉刷新,只需要扩展这个类,实现一些必要的方法就可以了。这个类的职责主要有以下几点:
处理onInterceptTouchEvent()和onTouchEvent()中的事件:当内容的View(比如ListView)正如处于最顶部,此时再向下拉,我们必须截断事件,然后move事件就会把后续的事件传递到onTouchEvent()方法中,然后再在这个方法中,我们根据move的距离再进行scroll整个View。
负责创建Header、Footer和Content View:在构造方法中调用方法去创建这三个部分的View,派生类可以重写这些方法,以提供不同式样的Header和Footer,它会调用createHeaderLoadingLayout和createFooterLoadingLayout方法来创建Header和Footer创建Content View的方法是一个抽象方法,必须让派生类来实现,返回一个非null的View,然后容器再把这个View添加到自己里面。
设置各种状态:这里面有很多状态,如下拉、上拉、刷新、加载中、释放等,它会根据用户拉动的距离来更改状态,状态的改变,它也会把Header和Footer的状态改变,然后Header和Footer会根据状态去显示相应的界面式样。
3、PullToRefreshBase<T extends View>继承关系
这里我实现了三个下拉刷新的派生类,分别是ListView、ScrollView、WebView三个,它们的继承关系如下:

关于PullToRefreshBase类及其派和类,有几点需要说明:
对于ListView,ScrollView,WebView这三种情况,他们是否滑动到最顶部或是最底部的实现是不一样的,所以,在PullToRefreshBase类中需要调用两个抽象方法来判断当前的位置是否在顶部或底部,而其派生类必须要实现这两个方法。比如对于ListView,它滑动到最顶部的条件就是第一个child完全可见并且first postion是0。这两个抽象方法是:
[java] view plain copy
/**
* 判断刷新的View是否滑动到顶部
*
* @return true表示已经滑动到顶部,否则false
*/
protected abstract boolean isReadyForPullDown();

/**
* 判断刷新的View是否滑动到底
*
* @return true表示已经滑动到底部,否则false
*/
protected abstract boolean isReadyForPullUp();
创建可下拉刷新的View(也就是content view)的抽象方法是
[java] view plain copy
/**
* 创建可以刷新的View
*
* @param context context
* @param attrs 属性
* @return View
*/
protected abstract T createRefreshableView(Context context, AttributeSet attrs);
4、LoadingLayout
LoadingLayout是刷新Layout的一个抽象,它是一个抽象基类。Header和Footer都扩展于这个类。这类抽象类,提供了两个抽象方法:
getContentSize
这个方法返回当前这个刷新Layout的大小,通常返回的是布局的高度,为了以后可以扩展为水平拉动,所以方法名字没有取成getLayoutHeight()之类的,这个返回值,将会作为松手后是否可以刷新的临界值,如果下拉的偏移值大于这个值,就认为可以刷新,否则不刷新,这个方法必须由派生类来实现。
setState
这个方法用来设置当前刷新Layout的状态,PullToRefreshBase类会调用这个方法,当进入下拉,松手等动作时,都会调用这个方法,派生类里面只需要根据这些状态实现不同的界面显示,如下拉状态时,就显示出箭头,刷新状态时,就显示loading的图标。
可能的状态值有:RESET, PULL_TO_REFRESH, RELEASE_TO_REFRESH, REFRESHING, NO_MORE_DATA

我们可以随意地制定自己的Header和Footer,我们也可以实现如图一和图二中显示的各种下拉刷新案例中的Header和Footer,只要重写上述两个方法getContentSize()和setState()就行了。HeaderLoadingLayout,它默认是显示箭头式样的布局,而RotateLoadingLayout则是显示一个旋转图标的式样。

5、事件处理
我们必须重写PullToRefreshBase类的两个事件相关的方法onInterceptTouchEvent()和onTouchEvent()方法。由于ListView,ScrollView,WebView它们是放到PullToRefreshBase内部的,所在事件先是传递到PullToRefreshBase#onInterceptTouchEvent()方法中,所以我们应该在这个方法中去处理ACTION_MOVE事件,判断如果当前ListView,ScrollView,WebView是否在最顶部或最底部,如果是,则开始截断事件,一旦事件被截断,后续的事件就会传递到PullToRefreshBase#onInterceptTouchEvent()方法中,我们再在ACTION_MOVE事件中去移动整个布局,从而实现下拉或上拉动作。

6、滚动布局(scrollTo)
如图三的布局结构可知,默认情况下Header和Footer是放置在Content View的最上面和最下面,通过设置padding来让他跑到屏幕外面去了,如果我们将整个布局向下滚动(scrollTo)一定距离,那么Header就会被显示出来,基于这种情况,所以在我的实现中,最终我是调用scrollTo来实现下拉动作的。

总的说来,实现的重要的点就这些,具体的一些细节在实现在会碰到很多,可以参考代码。

4. 如何使用
使用下拉刷新的代码如下
[java] view plain copy
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

mPullListView = new PullToRefreshListView(this);
setContentView(mPullListView);

// 上拉加载不可用
mPullListView.setPullLoadEnabled(false);
// 滚动到底自动加载可用
mPullListView.setScrollLoadEnabled(true);

mCurIndex = mLoadDataCount;
mListItems = new LinkedList<String>();
mListItems.addAll(Arrays.asList(mStrings).subList(0, mCurIndex));
mAdapter = new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, mListItems);

// 得到实际的ListView
mListView = mPullListView.getRefreshableView();
// 绑定数据
mListView.setAdapter(mAdapter);
// 设置下拉刷新的listener
mPullListView.setOnRefreshListener(new OnRefreshListener<ListView>() {
@Override
public void onPullDownToRefresh(PullToRefreshBase<ListView> refreshView) {
mIsStart = true;
new GetDataTask().execute();
}

@Override
public void onPullUpToRefresh(PullToRefreshBase<ListView> refreshView) {
mIsStart = false;
new GetDataTask().execute();
}
});
setLastUpdateTime();

// 自动刷新
mPullListView.doPullRefreshing(true, 500);
}
这是初始化一个下拉刷新的布局,并且调用setContentView来设置到Activity中。
在下拉刷新完成后,我们可以调用onPullDownRefreshComplete()和onPullUpRefreshComplete()方法来停止刷新和加载

5. 运行效果
这里列出了demo的运行效果图。

6. 源码下载
实现这个下拉刷新的框架,并不是我的原创,我也是参考了很多开源的,把我认为比较好的东西借鉴过来,从而形成我的东西,我主要是参考了下面这个demo:
https://github.com/chrisbanes/Android-PullToRefresh
这个demo写得不错,不过他这个太复杂了,我们都知道,一旦复杂了,万一我们要添加一些需要,自然也要费劲一些,我其实就是把他的简化再简化,以满足我们自己的需要。
暴躁的喵

2024-11-06 10:08:05

但在 Instagram、苹果 Mail 等众多知名应用中,这一功能却不见踪影。著名设计师 Dustin Curtis 在最近与 Tweetbot 开发者的对话中得知,Twitter 目前正在提交的一项关于“用户界面机制”的专利申请也许是许多知名应用没有采用这一功能的原因。这一专利由 Tweetie 的开发者 Loren Brichter 发明并申请,在 Tweetie 被 Twitter 收购后转归 Twitter 所有。根据这一项还待最后批准的专利,“在接收到用户利用滚动形式输入的指令后,系统可以某种特定形式呈现可滚动的刷新触发信息。用户的滚动指令如果达到触发的条件,系统的刷新触发信息将完全呈现出来,同时屏幕的内容将进行刷新。”专利申请的其它部分显示,这一功能的覆盖范围并不局限于进行列表内容的更新,还包含了通过下拉操作实现的其他功能,例如前段时间热门的列表应用 Clear 的下拉创新新事项的功能。Twitter 和 Loren Brichter 曾经表示,即使这一申请通过,他们也不会强行执行。这一保证也许并不足以说服那些谨慎的应用完全放心的使用这一功能。(Via)下拉刷新为何没有成为标准?当然,专利问题也许并不是这一功能没有成为应用内刷新功能的标准的唯一原因,许多人曾就这一问题发起讨论。一种理论认为,这种刷新方式仅仅适合于那种按照从新到旧的时间排序的时间流应用,并不适合所有的应用类型。在Twitter、Facebook 这样以时间线形式呈现信息的社交网络应用中,用户最常见的行为方式是从下往上查看好友的状态更新。当内容列表滚动到顶部后,用户的直觉反应是继续往上滚动,查看更多的信息。在这种情景下,继续下拉是非常自然的反应。同时为了让用户确认是否真的想要进行更新,下拉更新在执行上,一般都采取了下拉一定长度后才进行更新操作的方式。但对于非列表形式的应用,用户在自然条件下不会有下拉的行为,在这种情况下,下拉这一操作将难以被用户发现。例如 Instagram 的热门图片标签,刷新操作的运行结果是将当前一屏的图片更换为另一批图片,而非在当前图片上方增添更多的图片,下拉刷新在这种情景下并不符合人们的心理预期,也与应用本身的功能不相符合。至于 Instagram 在好友时间线标签内也没有采用下拉刷新的方式,比较大的可能是为了保持应用内操作的一致性。纵观将下拉刷新功能利用的比较好的应用,它们大多都具有内容更新频繁的特点。也只有这种类型的应用,用户才会想要不断刷新获取更多的内容。而在电子邮件这样具有推送功能、同时更新并不是非常频繁的应用中,频繁的手动更新功能显得多余且没有必要,因此下拉更新并不适合在此类应用中使用。Instapaper、Dropbox 等应用可属于这一类型。Google Reader 这样的 RSS 阅读器则介于两种类型之间,因此我们见到如 Reeder 这样 RSS 阅读器采取了下拉同步的功能,而其他一些 RSS 阅读器就没有这个功能。Sparrow 虽然是电子邮件客户端,但其手机版目前没有推送功能,而且其很多地方借鉴了 Twitter 这样的社交网络的特点,因此加入下拉刷新的功能并不意外(桌面版 Sparrow 的下拉刷新功能是否必要还有待商榷)。另一角度来说,现今的很多 Twitter 应用开始加入 Stream 功能,新的信息会实时显示出来。在这种情况下,下拉刷新在功能上其实已经没有必要。但为了避免用户的信息过度消费,也许手动刷新还是更好的主意。另外,对于那些已经发现这一功能的人来说,下拉刷新也许非常自然。但对大多数用户来,这一功能是说比较难被发现的,并不是所有的应用都可以期待用户突然间“发现”这一重要功能的。没有一种设计是万能的Pinterest 的瀑布流固然吸引人,但并非所有网站都适合采用这一设计风格;Flipborad 的方格杂志设计固然便于新闻阅读,但这并不代表没有其他同样优秀的阅读版式;Clear 的手势操作固然酷劲十足,但许多应用简单的“+”添加按钮同样清晰而易用。任何一种优秀的设计,都有其应用的限制范围,不加取舍的借鉴非但不会使一款应用更好用,反而可能是东施效颦,弄巧成拙。
梦中梦

2024-11-06 03:11:25

但在 Instagram、苹果 Mail 等众多知名应用中,这一功能却不见踪影。著名设计师 Dustin Curtis 在最近与 Tweetbot 开发者的对话中得知,Twitter 目前正在提交的一项关于“用户界面机制”的专利申请也许是许多知名应用没有采用这一功能的原因。这一专利由 Tweetie 的开发者 Loren Brichter 发明并申请,在 Tweetie 被 Twitter 收购后转归 Twitter 所有。根据这一项还待最后批准的专利,“在接收到用户利用滚动形式输入的指令后,系统可以某种特定形式呈现可滚动的刷新触发信息。用户的滚动指令如果达到触发的条件,系统的刷新触发信息将完全呈现出来,同时屏幕的内容将进行刷新。”专利申请的其它部分显示,这一功能的覆盖范围并不局限于进行列表内容的更新,还包含了通过下拉操作实现的其他功能,例如前段时间热门的列表应用 Clear 的下拉创新新事项的功能。Twitter 和 Loren Brichter 曾经表示,即使这一申请通过,他们也不会强行执行。这一保证也许并不足以说服那些谨慎的应用完全放心的使用这一功能。(Via)下拉刷新为何没有成为标准?当然,专利问题也许并不是这一功能没有成为应用内刷新功能的标准的唯一原因,许多人曾就这一问题发起讨论。一种理论认为,这种刷新方式仅仅适合于那种按照从新到旧的时间排序的时间流应用,并不适合所有的应用类型。在Twitter、Facebook 这样以时间线形式呈现信息的社交网络应用中,用户最常见的行为方式是从下往上查看好友的状态更新。当内容列表滚动到顶部后,用户的直觉反应是继续往上滚动,查看更多的信息。在这种情景下,继续下拉是非常自然的反应。同时为了让用户确认是否真的想要进行更新,下拉更新在执行上,一般都采取了下拉一定长度后才进行更新操作的方式。但对于非列表形式的应用,用户在自然条件下不会有下拉的行为,在这种情况下,下拉这一操作将难以被用户发现。例如 Instagram 的热门图片标签,刷新操作的运行结果是将当前一屏的图片更换为另一批图片,而非在当前图片上方增添更多的图片,下拉刷新在这种情景下并不符合人们的心理预期,也与应用本身的功能不相符合。至于 Instagram 在好友时间线标签内也没有采用下拉刷新的方式,比较大的可能是为了保持应用内操作的一致性。纵观将下拉刷新功能利用的比较好的应用,它们大多都具有内容更新频繁的特点。也只有这种类型的应用,用户才会想要不断刷新获取更多的内容。而在电子邮件这样具有推送功能、同时更新并不是非常频繁的应用中,频繁的手动更新功能显得多余且没有必要,因此下拉更新并不适合在此类应用中使用。Instapaper、Dropbox 等应用可属于这一类型。Google Reader 这样的 RSS 阅读器则介于两种类型之间,因此我们见到如 Reeder 这样 RSS 阅读器采取了下拉同步的功能,而其他一些 RSS 阅读器就没有这个功能。Sparrow 虽然是电子邮件客户端,但其手机版目前没有推送功能,而且其很多地方借鉴了 Twitter 这样的社交网络的特点,因此加入下拉刷新的功能并不意外(桌面版 Sparrow 的下拉刷新功能是否必要还有待商榷)。另一角度来说,现今的很多 Twitter 应用开始加入 Stream 功能,新的信息会实时显示出来。在这种情况下,下拉刷新在功能上其实已经没有必要。但为了避免用户的信息过度消费,也许手动刷新还是更好的主意。另外,对于那些已经发现这一功能的人来说,下拉刷新也许非常自然。但对大多数用户来,这一功能是说比较难被发现的,并不是所有的应用都可以期待用户突然间“发现”这一重要功能的。没有一种设计是万能的Pinterest 的瀑布流固然吸引人,但并非所有网站都适合采用这一设计风格;Flipborad 的方格杂志设计固然便于新闻阅读,但这并不代表没有其他同样优秀的阅读版式;Clear 的手势操作固然酷劲十足,但许多应用简单的“+”添加按钮同样清晰而易用。任何一种优秀的设计,都有其应用的限制范围,不加取舍的借鉴非但不会使一款应用更好用,反而可能是东施效颦,弄巧成拙。
灿烂星空

2024-11-06 02:18:58

因为“下拉刷新”紧紧是一个程序动作,不能算作一个完整的应用。因此不能算作标准功能。
内谎言太羙。

2024-11-06 08:50:19

移动应用是对用户使用习惯的一个不断探索的过程,并不是一成不变的哦,有更好的更人性化的功能可以选择,当前功能当让就被迭代啦!