Yukiの枝折: LoaderManagerのAPIまとめ

LoaderManagerについて、ポイントとなるメソッドの概要をまとめました。

●Activity.getLoaderManager

複数のLoaderを管理するLoaderManagerのインスタンスを取得します。
LoaderManagerは各Activity/Fragment毎に１つ割り当てられ、何度getLoaderManager
をコールしても同じLoaderManagerインスタンスが返却されます。
Activity/Fragmentのインスタンスが異なれば返却されるLoaderManagerのインスタンス
は異なるので、LoaderのID重複を心配する必要はありません。
LoaderManagerはgetLoaderManagerメソッドの初回コール時に生成されます。
LoaderManagerのライフサイクルはActivity/Fragmentにより管理され、
そのライフサイクルはActivity/FragmentのonStart時に開始されます。
ただし、onStart時にLoaderManagerが初期化されていない(つまりgetLoaderManagerが
まだ呼ばれていない)時はLoaderManagerは正しく動作しません。
getLoaderManagerメソッドは遅くともActivity/Fragment.onStartより前にコールしていな
いと、LoaderManagerがLoaderを正しく管理してくれません。
# 画面回転時等のLoaderManager.onRetainで内部エラーが発生し、期待通りに動作しなく
# なります。

●LoaderManager.initLoader

指定したIDでLoaderを初期化・生成します。
ここで指定するIDはLoaderの識別子として使用され、Loaderが作成される時は
Loader.onCreateLoaderがコールバックされます。
initLoaderは指定のLoaderが初期化されることを保証します。
指定したIDに紐づくLoaderがすでに存在している場合、Loaderは初期化されません。
ただし、Loaderへのコールバックが指定されたインスタンスで上書きされます。
この時、引数のargsは無視されます。
initLoaderは関連するActivity/Fragmentの生成時(Activity.onCreate/Fragment.onCreateActivity)
に使用されるべきメソッドです。
LoaderManagerはconfiguration changeによって破棄・生成されず再利用されます。
LoaderManagerは既に存在するLoaderの再利用を可能としています。
そのため、Activityがconfiguration changeにより再生成されてonCreateでinitLoaderを
コールしても、対象のLoaderをLoaderManagerが既に保持しているのでLoaderを生成する
onCreateLoaderが再度呼ばれることはありません。
注意しなければならないのは、Loaderが再利用される場合は引数argsは無視されるということです。

●LoaderManager.restartLoader

引数のIDに関連付けられているLoaderを再生成します。
既存のLoaderは必要に応じてキャンセル/停止/破棄されます。
生成されるLoaderは引数argsを持つ新たなLoaderとして生成されます。
# # # # 下記詳細不明 (Loaderが実行中か、実行済みかでLoaderを制御している模様)
ただし、指定のIDに紐づくLoaderが複数作成されていて、まだそれが満了していない場合、
新たにLoaderを作成しても、既存のLoaderが満了するまでこれを起動できません。
restartLoaderで指定したIDに紐づく過去のLoaderは無効となり、それらのLoaderの
コールバックは以降通知されなくなります。

●LoaderManager.destroyLoader

以上です。