关于Loader的笔记

LoadManager

FragmentActivity#getSupportLoaderManager和Fragment#getLoaderManager都是调用：

FragmentActivity#getLoaderManager

FragmentActivity和LoaderManager的生命周期

FragmentActivity#onStartFragmentActivity#getLoaderManagerLoaderManagerImpl#doStart/finishRetain/doReportStartFragmentActivity#onStopFragmentActivity#onReallyStopLoaderManagerImpl#doStop(doRetain)LoaderInfo#stopLoader#stopLoadingFragmentActivity#onDestroyLoaderManagerImpl#doDestroy

Fragment和LoaderManager的生命周期

Fragment#performStartFragment#onStartFragmentActivity#getLoaderManagerLoaderManagerImpl#doStart(LoaderInfo#doStart)LoaderManagerImpl#doReportStart（LoaderInfo#doReportStart,在这里可能会调用LoaderCallback的onLoaderFinished,
使用mHaveData保证不会callOnLoadFinished在performStart中调用两次）
Fragment#performReallyStopLoaderManagerImpl#doStopFragment#performDestroyViewLoaderManagerImpl#doReportNextStartFragment#onDestroyLoaderManagerImpl#doDestroy

LoaderManagerImpl的执行流程

LoaderManagerImpl#initLoader/createAndInstallLoader/createLoaderLoaderCallbacjk#onCreateLoadernew LoaderInfoLoaderManagerImpl#installLoaderLoaderInfo#start()Loader#registerListenerLoader#startLoadingLoader#onStartLoading

(subclass必须覆盖onStartLoading，然后要调用forceLoad,否则不会继续往下走了，得到执行流程

 Fragment onAttach Fragment onCreate Fragment onCreateView Fragment onActivityCreated Fragment onCreateLoader Fragment loader onStartLoading Fragment onStart

可以看到从onStart之后LoaderManager没有执行了。正常情况下流程是：

 Fragment onAttach Fragment onCreate Fragment onCreateView Fragment onActivityCreated Fragment onCreateLoader Fragment loader onStartLoading Fragment onStart Fragment onResume Fragment loader loadInBackground Fragment loader deliverResult Fragment onLoadFinished

)

Loader#forceLoadAsyncTaskLoader#onForceLoadAsyncTaskLoader#cancelLoadAsyncTaskLoader#executePendingTaskLoadTask#doInBackroundAsyncTaskLoader#onLoadInBackgroundAsyncTaskLoader#loadInBackground(我们需要实现的)

LoaderTask#onPostExecuteAsyncTaskLoader#dispatchOnLoadComplete(在这一步，先会精心判断

1,mTask != task,则dispatchOnCancelled->onCanceled

2,isAbandoned,则onCanceled如果不是1、2的情形才往下走)AsyncTaskLoader#commitContentChangedAsyncTaskLoader#deliverResultLoaderInfo#onLoadCompleteLoaderInfo#callOnLoadFinished(如果没有覆盖或者调用了LoaderCallback的onLoadFinished)

If has pending task,destroy old(current)

LoaderCallback#onLoaderReset(在这里可以设置adapter的data为null)Loader#reset/onReset(在这里可以调用onStopLoading，而onStopLoading可以调用cancelLoad，后者调用onCanceled)

Google文档说我们不应该手动调用start/stop/abandon得到方法，而应该覆盖相应的onXxx版本的方法。

Loader的源码还是挺简单的，但是逻辑还是复杂。

commonsguy说Loader是是个失败的框架，建议不要用（也是，挺复杂的）

Why are Loaders bad in Android？

You will note that this is not what I said. I said that loaders are a failed abstraction. There's a difference.

A general recommendation, when trying to create a framework for significant reuse, is to design and create three discrete implementations of the framework. If your framework can support three different approaches, the design is probably flexible enough to handle future implementations.

The Loader framework, at the end of the day, is designed around one implementation: CursorLoader. Period. There are no other concrete implementations of Loader in the SDK. In particular, the Loader framework has a contract that requires that implementations of Loader be able to deliver updated results automatically. While this is a lovely contract from the standpoint of usersof the Loader framework, it makes things difficult for those who might create implementations of the Loader framework.

I attempted to create two separate implementations of the Loader framework, for SQLite and SharedPreferences (three if you count SQLCipher for Android separately). The SQLite one sucks, because the only way to do the automatic-reload stuff is for the Loader to know what needs to be reloaded, which is clunky. The SharedPreferences one used to work, but it was pointed out that nowadays onLoadFinished() will not be called if the object representing the results (the Cursor for a CursorLoader, SharedPreferences for SharedPreferencesLoader) is the same object as before. That breaks SharedPreferencesLoader, since the SharedPreferences object is updatedin situ when preferences are changed.

After writing my Loader implementations and using them for a bit, I concluded that they weren't worth it. I'd rather load stuff myself asynchronously using AsyncTask or IntentService and use a message bus (Otto, greenrobot's EventBus, etc.) for notifying interested parties about changes in data. While I could wrap that stuff inside of Loader, I am unconvinced that it would solve enough problems to be worth the effort.

Now, if you are using a ContentProvider and wish to use CursorLoader, that's fine. It may have its own issues, but at least it's supposed to work.

With respect to the CWAC-LoaderEx library, I am discontinuing it because:

• I only have so many hours in the day, and so as part of the great AAR-ification of the CWAC libraries, I am deciding which libraries are worth the effort to maintain

• I do not use CWAC-LoaderEx personally, outside of a couple of book examples

• CWAC-LoaderEx is dependent upon too much internal implementation of Loader for me to be comfortable that I will be able to keep it working over the long haul (see SharedPreferencesLoader)

CWAC-LoaderEx isn't going anywhere, but I just will not be putting more time into it. If somebody with a maintained/extended fork contacts me, I'll be happy to link to their fork from the project README.

I would also like to know about other better alternatives to Loaders

All a Loader does is asynchronously load content, re-load that content upon a detected change in the content, and retain said content across a configuration change. A retained model (or headless) fragment can do the same thing, in concert with an AsyncTask.

from:

http://stackoverflow.com/questions/20762514/why-are-loaders-bad-in-android/20762746#20762746

https://github.com/commonsguy/cwac-loaderex/issues/13

TabAcitivity+FragmentPagerAdapter+ViewPagr的生命周期

(TabAcitivity下一个Activity包含Fragment，Fragment包含ViewPagr，使用FragmentPagerAdapter)

1.Fragment 1:onAttach/onCreate/onCreateView/onActivityCreated/onStart/onResumeFragment 2:onAttach/onCreate/onCreateView/onActivityCreated/onStart/onResume2.程序切换到后台Fragment1:onPauseFragment2:onPauseFragment1:onStopFragment2:onStop3.切换回来Fragment1:onStartFragment2:onStartFragment1:onResumeFragment2:onResume4.切换到其他Tab(TabActivity)Fragment1:onPauseFragment2:onPause5.切换回来Fragment1:onResumeFragment2:onResume6.ViewPager的Fragment切换Fragment 3:onAttach/onCreate/onCreateView/onActivityCreated/onStart/onResumeFragment 1:onPause/onStop/onDestroyView6.ViewPager的Fragment切换回来Fragment 1:onCreateView/onActivityCreated/onStart/onResumeFragment 2:onPause/onStop/onDestroyView