ListView和GridView简介
在Android App的开发中， ListView和GridView等控件是使用非常频繁的控件。 这两个控件的特点是使用数据适配器来显示数据， 并且在数据项较多的时候， 可以重用用于显示数据的条目（这里的条目指的是ListView或GridView中用于显示每一个数据项的子View）。本文的重点并不是讲解ListView和GridView的内部实现或使用方法，但是后文讲解的自定义Adapter是被ListView和GridView所调用的，所以在这里简单提及ListView和GridView。ListView，GridView和Adapter的关系如下图所示：
适配器的一般使用方式
由于GridView的使用方式和ListView很相似， 为了叙述的简洁， 下文只以ListView为例讲解。在开发中，ListView和Adapter的使用方式一般情况下是这样的：
1 继承SDK中的BaseAdapter， 实现和业务相关的自定义Adapter
2 创建一个Adapter的实例， 调用ListView的setAdapter方法， 将这个Adapter对象， 设置到ListView对象的内部。
在这里主要讲述实现自定义Adapter的过程。 在继承BaseAdapter后， 要实现BaseAdapter中定义的抽象方法getView。getView方法是由ListView对象调用的。 概括一下， 就是ListView对象在需要一个新的条目View的时候， 会调用这个getView方法，你必须实现这个方法，返回一个准备好的View。但是，ListView具有重用条目View的功能。
也就是不是每次需要一个条目View都从头创建。所以getView方法有一个参数convertView， 这个也是由ListView传到Adapter中的。 当ListView中存在能够重用的View时就将这个View传到getView方法中。 getView方法的实现者要判断convertView是否为空， 如果不为空， 就重用这个View。
自定义Adapter中的getView实现方式一般如下：（这里为了节省时间，直接使用项目中的代码， 读者只需关注getView 的实现形式， 不用关心业务相关的变量名称）
private static class ScheduleAdapter extends BaseAdapter{
private List<Schedule> meetings ;
private Context context;
private LayoutInflater inflator;
public ScheduleAdapter(Context context ) {
this.context = context;
inflator = LayoutInflater.from(context);
}
public ScheduleAdapter(Context context, List<Schedule> meetings) {
super();
this.context = context;
this.meetings = meetings;
inflator = LayoutInflater.from(context);
}
public List<Schedule> getMeetings() {
return meetings;
}
public void setMeetings(List<Schedule> meetings) {
this.meetings = meetings;
}
@Override
public int getCount() {
return meetings.size();
}
@Override
public Object getItem(int position) {
return meetings.get(position);
}
@Override
public long getItemId(int position) {
return position;
}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
View v = null;
if(convertView == null){
v = inflator.inflate(R.layout.schedule_item, null);
ViewHolder holder = new ViewHolder();
holder.name = (TextView) v.findViewById(R.id.schedule_name_id);
holder.time = (TextView) v.findViewById(R.id.schedule_time_id);
holder.icon = (ImageView) v.findViewById(R.id.schedule_icon_id);
v.setTag(holder);
}else{
v = convertView;
}
ViewHolder holder = (ViewHolder) v.getTag();
Schedule data = meetings.get(position);
holder.name.setText(data.getName());
holder.time.setText(data.getStartTime() + " " + data.getEndTime());
return v;
}
private static class ViewHolder{
public TextView name;
public TextView time;
public ImageView icon;
}
}
从上述代码可以看出， getView方法中处理的逻辑有两个：
1 判断是否可以重用View， 如果不能重用， 就创建新的条目View， 找到条目View中的各个子View， 被存放在一个ViewHolder独享中。如果可以重用View， 就重用这个view， 并且从和这个View相关的ViewHolder对象中找到已经缓存的子View。
2 将具体的数据和事件绑定到各个子View上。
实现自动重用View的Adapter
从上面的代码经常被使用到， 每次都要在getView方法中写这些重用View的逻辑， 并且还要每次都写一个业务相关的ViewHolder类，真的是非常非常恶心。那么有没有办法封装一下这些恶心的逻辑，而不用每次都从头写起呢？ 本文提供了一种实现方法。
首先给出完整的实现代码， 然后对代码中的关键点进行分析。
import java.util.ArrayList;
import android.content.Context;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.BaseAdapter;
/**
* 一个具有自动重用View功能的适配器实现
*
* @author zhangjg
* @date Feb 20, 2014 10:57:42 AM
*/
public abstract class AutoReuseViewAdapter extends BaseAdapter {
//Item布局资源
private int itemLayoutRes;
//Item中要操作的各个子View的Id
private int[] childViewIds;
//布局填充器
private LayoutInflater inflator;
public AutoReuseViewAdapter(Context context, int itemLayoutRes, int ... childViewIds) {
inflator = LayoutInflater.from(context);
this.itemLayoutRes = itemLayoutRes;
this.childViewIds = childViewIds;
}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
View v = null;
ViewHolder holder;
if(convertView != null){
v = convertView;
holder = (ViewHolder) v.getTag();
}else{
v = inflator.inflate(itemLayoutRes, null);
holder = new ViewHolder();
for(int childId : childViewIds ){
holder.cacheView(v.findViewById(childId));
}
v.setTag(holder);
}
boundDataAndEventToViews(position, v, holder.getCachedViews());
return v;
}
/**
* 抽象方法， 被子类覆盖， 将业务相关的数据和事件绑定到特定的子View上
*/
protected abstract void boundDataAndEventToViews(int position,
View itemView, ArrayList<View> childViews);
/**
* 内部类， 用于缓存条目View的子控件， 同样是面向抽象和业务无关的
*
* @author zhangjg
* @date Feb 20, 2014 9:12:33 AM
*/
private static class ViewHolder{
private ArrayList<View> cachedViews = new ArrayList<View>();
public void cacheView(View v){
cachedViews.add(v);
}
public ArrayList<View> getCachedViews(){
return cachedViews;
}
}
}
首先解释一下这个抽象类的成员变量。 itemLayoutRes是条目View的布局资源， childViewIds是一个int型的数组， 用于存放条目View中要处理的各个子View的id 。 这两个成员变量是通过构造方法注入的， 代码如下：
private int itemLayoutRes;
//Item中要操作的各个子View的Id
private int[] childViewIds;
//布局填充器
private LayoutInflater inflator;
public AutoReuseViewAdapter(Context context, int itemLayoutRes, int ... childViewIds) {
inflator = LayoutInflater.from(context);
this.itemLayoutRes = itemLayoutRes;
this.childViewIds = childViewIds;
}
在构造方法中， 还要根据context创建一个LayoutInflater对象， 用于从XML布局中加载条目View。
然后说一下getView方法的实现。 这个类中， 将getView中的逻辑分到两个方法中去处理。首先重用View的逻辑是业务无关的， 在getView 中实现， 将数据和事件绑定到各个子View上是业务相关的， 交给boundDataAndEventToViews方法处理， 这是个抽象方法， 必须由子类覆盖并实现， 因为业务相关的东西也只有具体子类才知道。
现在再从整体上审视一下这个Adapter的实现。 由于getView是由ListView调用的， 至于如何调用， 何时调用我们无法干预，但是不管怎么写代码， getView方法必须完成属于他的所有任务。 这里再重复一下getView 的职责：
1 判断是否可以重用View， 如果不能重用， 就创建新的条目View， 找到条目View中的各个子View， 被存放在一个ViewHolder独享中。如果可以重用View， 就重用这个view， 并且从和这个View相关的ViewHolder对象中找到已经缓存的子View。
2 将具体的数据和事件绑定到各个子View上。
在我们实现的这个AutoReuseViewAdapter中， getView方法同样完成了两个职责。 也就是说原有的处理流程还是由getView方法定义， 只是将部分逻辑（绑定数据和事件到子View）交给具体子类去实现， 这是标准的模板方法设计模式。
使用自动重用View功能的Adaper
在上面的步骤中， AutoReuseViewAdapter已经实现好了。 现在就看看如何根据这个AutoReuseViewAdapter实现自己业务相关的Adapter。基于AutoReuseViewAdapter实现自己的Adapter， 只需要做以下工作：
1 自定义自己的Adapter， 继承AutoReuseViewAdapter；
2 在子类的构造方法中调用父类AutoReuseViewAdapter的构造方法， 将条目布局的资源索引和条目View中各个子View 的Id传到父类构造器中；
3 覆盖并实现父类中的抽象方法， 在boundDataAndEventToViews方法中对子View进行数据和事件绑定。
在上面“适配器的一般使用方式“一节中， 给出了适配器的一般实现。 现在我们基于AutoReuseViewAdapter重新实现它， 看看是不是简单了很多。下面是重新实现的版本：
private static class ScheduleAdapter extends /*BaseAdapter*/AutoReuseViewAdapter{
private List<Schedule> meetings ;
public ScheduleAdapter(Context context ) {
super(context, R.layout.schedule_item,
R.id.schedule_name_id, R.id.schedule_time_id, R.id.schedule_icon_id);
}
public ScheduleAdapter(Context context, List<Schedule> meetings) {
this(context);
this.meetings = meetings;
}
public List<Schedule> getMeetings() {
return meetings;
}
public void setMeetings(List<Schedule> meetings) {
this.meetings = meetings;
}
@Override
public int getCount() {
return meetings.size();
}
@Override
public Object getItem(int position) {
return meetings.get(position);
}
@Override
public long getItemId(int position) {
return position;
}
@Override
protected void boundDataAndEventToViews(int position, View itemView,
ArrayList<View> childViews) {
Schedule data = meetings.get(position);
((TextView)childViews.get(0)).setText(data.getName());
((TextView)childViews.get(1)).setText(data.getStartTime() + " " + data.getEndTime());
//((ImageView)childViews.get(2)).setImageResource(resId);
}
}
看， 是不是变得简单多了。 我们现在只需要关心业务相关的逻辑了， 不用再关心业务无关的逻辑（重用View的逻辑）。所以， 如果在项目中有一些业务无关的代码总是重复的写， 那么有很大可能有优化的余地， 这时我们就要发扬程序员的”懒惰“的优良传统，将重复的逻辑抽取出来。
最后有两点需要强调：
1 因为父类中的getView方法定义了完整的逻辑流程， 所以子类绝对不要覆盖getView方法， 只要实现boundDataAndEventToViews方法就够了。
2 boundDataAndEventToViews方法中， 需要绑定数据和事件的子View是由一个集合ArrayList<View> childViews， 通过父类传递到子类中的， 子View在集合中的顺序， 和构造方法中子View的Id传入的顺序相同。
以上面的代码为例，在构造方法中子View的id传入的顺序如下： R.id.schedule_name_id, R.id.schedule_time_id, R.id.schedule_icon_id 。 第一个是显示名字的TextView， 第二个是显示时间的TextView， 第三个是显示图标的ImageView。所以在boundDataAndEventToViews中childViews集合中子View的顺序也是这样的。这种顺序相关性必须由子类定义和维护，
如果顺序不对， 可能会抛出类型转化异常。