首页 > 代码库 > LoaderManager使用详解(三)---实现Loaders

LoaderManager使用详解(三)---实现Loaders

这篇文字将介绍Loader<D>类,并且介绍自定义Loader的实现。这是本系列的第三篇文章。
 
一:Loaders之前世界
二:了解LoaderManager
三:实现Loaders
四:实例:AppListLoader
 
重中之重,如果你还没有读过前面两篇文章,我建议你在深入之前先读一读那两篇文章。先简短的总结一下这篇博客覆盖了什么内容。Loader之前的世界(第一篇)描述了Android3.0之前的数据载入方法和在UI主线程中执行的冗长的查询操作。这些UI非友好的API导致了应用响应变差。总总情况就是了解LoaderManager(第二篇)的写作动机。这篇文章介绍了LoaderManager类,并且讲到了它在异步载入数据中所扮演的角色。LoaderManager在Activity和Fragment的声明周期中管理Loaders,并且在配置变化时保持已载入的数据(译者注:避免了Activity重启导致数据重载入)。

Loader基础 

Loades负责在一个单独线程中执行查询,监控数据源改变,当探测到改变时将查询到的结果集发送到注册的监听器上(通常是LoaderManager)。下面这些特性使Loaders成为AndroidSDK中强大的工具:
 
1. 它封装了实际的数据载入。Activity/Fragment不再需要知道如何载入数据。实际上,Activity/Fragment将该任务委托给了Loader,它在后台执行查询要求并且将结果返回给Activity/Fragment。
 
2. 客户端不需要知道查询如何执行。Activity/Fragment不需要担心查询如何在独立的线程中执行,Loder会自动执行这些查询操作。这种方式不仅减少了代码复杂度同事也消除了线程相关bug的潜在可能。
 
3. 它是为安全的事件驱动方式。Loader检测底层数据,当检测到改变时,自动执行新的载入获取最新数据。这使得使用Loader变得容易,客户端可以相信Loader将会自己自动更新它的数据。Activity/Fragment所需要做的就是初始化Loader,并且对任何反馈回来的数据进行响应。除此之外,所有其他的事情都由Loader来解决。
 
Loaders是一个比较高级的话题,可能需要更多时间来使用它。在下一节中,我们会从分析它的四个定义的特性来开始。

Loader由什么组成?

总共有四个特性最终决定了一个Loader的行为:
 
1. 执行异步载入的任务。为了确保在一个独立线程中执行载入操作,Loader的子类必须继承AsyncTaskLoader<D>而不是Loader<D>类。AsyncTaskLoader<D>是一个抽象Loader,它提供了一个AsyncTask来做它的执行操作。当定义子类时,通过实现抽象方法loadInBackground方法来实现异步task。该方法将在一个工作线程中执行数据加载操作。
 
2. 在一个注册监听器中接收载入完成返回的结果(见附注1)。对于每个Loader来说,LoaderManager注册一个OnLoadCompleteListener<D>,该对象将通过调用onLoadFinished(Loader<D> loader, D result)方法使Loader将结果传送给客户端。Loader通过调用Loader#deliverResult(D result),将结果传递给已注册的监听器们。
 
3. 三种不同状态(见附注2)。任何Loader将处于三种状态之中,已启动、已停止、重启:
a. 处于已启动状态的Loader会执行载入操作,并在任何时间将结果传递到监听器中。已启动的Loader将会监听数据改变,当检测到改变时执行新的载入。一旦启动,Loader将一直处在已启动状态,一直到转换到已停止和重启。这是唯一一种onLoadFinished永远不会调用的状态。
b. 处于已停止状态的Loader将会继续监听数据改变,但是不会将结果返回给客户端。在已停止状态,Loader可能被启动或者重启。
c. 当Loader处于重启状态时,将不会执行新的载入操作,也不会发送新的结果集,也不会检测数据变化。当一个Loader进入重启状态,它必须解除对应的数据引用,方便垃圾回收(同样地,客户端必须确定,在Loader无效之后,移除了所有该数据的引用)。通常,重启Loader不会两次调用;然而,在某些情况下他们可能会启动,所以如果必要的话,它们必须能够适时重启。
 
4. 有一个观察者接受数据源改变的通知。Loader必须实现这些Observer其中之一(比如ContentObserver,BroadcastReceiver等),来检测底层数据源的改变。当检测到数据改变,观察者必须调用Loader#onContentChanged()。在该方法中执行两种不同操作:a. 如果Loader已经处于启动状态,就会执行一个新的载入操作; b. 设置一个flag标识数据源有改变,这样当Loader再次启动时,就知道应该重新载入数据了。
 
到目前为止,你应该基本知道了Loader如何工作了。如果没有的话,我建议你先放一放,稍后再重新读一遍(读一下这篇文档,)。也就是说,让我们从实际代码入手,写写看。

实现Loader

就如我之前陈述的那样,在实现自定义Loader的时候有很多需要注意。子类必须实现loadInBackground()方法,必须覆写onStartLoading(), onStoppLoading(),onReset(),onCanceled()和deliverResult(D results)来实现一个完整功能的Loader。覆写这些方法非常重要,LoaderManager将会在Activity/Fragment不同声明周期调用不同的方法。例如,当一个Activity第一次启动,它将会让LoaderManager在Activity#onStart()中启动它所拥有的每个Loaders。如果一个Loader没有启动,LoaderManager将会调用startLoading()方法,该方法将Loader进入已启动状态并且立即调用Loader的onStartLoading()方法。也就是说,LoaderManager在后台所做的大量工作都是基于Loader正确实现的基础上,所以不要小看实现这些方法的重要性。
 
下面的代码就是Loader典型实现的样板。SampleLoader查询结果为一个包含SampleItem对象的列表,并且将查询结果列表List<SampleItem>返回给客户端:
public class SampleLoader extends AsyncTaskLoader<List<SampleItem>> {  // We hold a reference to the Loader’s data here.  private List<SampleItem> mData;  public SampleLoader(Context ctx) {    // Loaders may be used across multiple Activitys (assuming they aren‘t    // bound to the LoaderManager), so NEVER hold a reference to the context    // directly. Doing so will cause you to leak an entire Activity‘s context.    // The superclass constructor will store a reference to the Application    // Context instead, and can be retrieved with a call to getContext().    super(ctx);  }  /****************************************************/  /** (1) A task that performs the asynchronous load **/  /****************************************************/  @Override  public List<SampleItem> loadInBackground() {    // This method is called on a background thread and should generate a    // new set of data to be delivered back to the client.    List<SampleItem> data = http://www.mamicode.com/new ArrayList<SampleItem>();    // TODO: Perform the query here and add the results to ‘data‘.    return data;  }  /********************************************************/  /** (2) Deliver the results to the registered listener **/  /********************************************************/  @Override  public void deliverResult(List<SampleItem> data) {    if (isReset()) {      // The Loader has been reset; ignore the result and invalidate the data.      releaseResources(data);      return;    }    // Hold a reference to the old data so it doesn‘t get garbage collected.    // We must protect it until the new data has been delivered.    List<SampleItem> oldData =http://www.mamicode.com/ mData;    mData = data;    if (isStarted()) {      // If the Loader is in a started state, deliver the results to the      // client. The superclass method does this for us.      super.deliverResult(data);    }    // Invalidate the old data as we don‘t need it any more.    if (oldData != null && oldData != data) {      releaseResources(oldData);    }  }  /*********************************************************/  /** (3) Implement the Loader’s state-dependent behavior **/  /*********************************************************/  @Override  protected void onStartLoading() {    if (mData != null) {      // Deliver any previously loaded data immediately.      deliverResult(mData);    }    // Begin monitoring the underlying data source.    if (mObserver == null) {      mObserver = new SampleObserver();      // TODO: register the observer    }    if (takeContentChanged() || mData =http://www.mamicode.com/= null) {      // When the observer detects a change, it should call onContentChanged()      // on the Loader, which will cause the next call to takeContentChanged()      // to return true. If this is ever the case (or if the current data is      // null), we force a new load.      forceLoad();    }  }  @Override  protected void onStopLoading() {    // The Loader is in a stopped state, so we should attempt to cancel the     // current load (if there is one).    cancelLoad();    // Note that we leave the observer as is. Loaders in a stopped state    // should still monitor the data source for changes so that the Loader    // will know to force a new load if it is ever started again.  }  @Override  protected void onReset() {    // Ensure the loader has been stopped.    onStopLoading();    // At this point we can release the resources associated with ‘mData‘.    if (mData != null) {      releaseResources(mData);      mData = null;    }    // The Loader is being reset, so we should stop monitoring for changes.    if (mObserver != null) {      // TODO: unregister the observer      mObserver = null;    }  }  @Override  public void onCanceled(List<SampleItem> data) {    // Attempt to cancel the current asynchronous load.    super.onCanceled(data);    // The load has been canceled, so we should release the resources    // associated with ‘data‘.    releaseResources(data);  }  private void releaseResources(List<SampleItem> data) {    // For a simple List, there is nothing to do. For something like a Cursor, we     // would close it in this method. All resources associated with the Loader    // should be released here.  }  /*********************************************************************/  /** (4) Observer which receives notifications when the data changes **/  /*********************************************************************/   // NOTE: Implementing an observer is outside the scope of this post (this example  // uses a made-up "SampleObserver" to illustrate when/where the observer should   // be initialized).     // The observer could be anything so long as it is able to detect content changes  // and report them to the loader with a call to onContentChanged(). For example,  // if you were writing a Loader which loads a list of all installed applications  // on the device, the observer could be a BroadcastReceiver that listens for the  // ACTION_PACKAGE_ADDED intent, and calls onContentChanged() on the particular   // Loader whenever the receiver detects that a new application has been installed.  // Please don’t hesitate to leave a comment if you still find this confusing! :)  private SampleObserver mObserver;}

总结 

我希望本文对你有用,并且通过它可以很好的理解Loaders和LoaderManager如何协同工作来执行异步任务,自动更新查询结果。记住,Loader是你的朋友。。。如果你使用它们,你的app将从相应性能、所需代码量中收益。我希望通过把它们的细节列举出来,可以减小它的学习曲线。

附注

1. 你不需要担心为你的Loader注册监听器,除非你不准备跟LoaderManager协同使用。LoaderManager担任的就是“listener”的角色,并将Loader返回的任何结果传给LoaderCallbacks#LoadFinished方法。
2. Loader也有可能处于“abandoned”状态(译者注:丢弃状态?)。这个是一个可选的中间状态,处于停止状态和重置状态之间。为了更简明的理解,再这里不讨论丢弃状态。也就是说,以我的经验来看,通常并无必要实现onAbandon()方法。

LoaderManager使用详解(三)---实现Loaders