lightbulb_outline Help shape the future of the Google Play Console, Android Studio, and Firebase. Start survey

ローダ

Android 3.0 で導入されたローダによって、アクティビティやフラグメントでのデータの非同期ロードが簡単になりました。 ローダには、次の 3 つの特徴があります。

  • すべての ActivityFragment で使用できる。
  • 非同期のデータロードを提供する。
  • データのソースを監視し、コンテンツが変更されたときに新しい結果を配信する。
  • 設定の変更後に再作成されると、自動的に最後のローダのカーソルに再接続するため、 再度データを問い合わせる必要がない。

Loader API の概要

アプリケーションでローダを使用するのに必要になりそうなクラスやインターフェースは複数あります。 次の表で、それらの概要をまとめました。

クラス/インターフェース 説明
LoaderManager1 つ以上の Loader インスタンスを管理するための、ActivityFragment に関連した抽象クラスです。 これにより、アプリケーションは ActivityFragment のライフサイクルと連動して長時間の操作を管理できるようになります。最も一般的なのは、CursorLoader で使用する方法ですが、アプリケーションでは他のタイプのデータのロード用に、独自のローダを自由に作成することもできます。

1 つのアクティビティやフラグメントごとに、LoaderManager は 1 つだけ存在しますが、LoaderManager は複数のローダを持つことができます。
LoaderManager.LoaderCallbacksクライアントが LoaderManager とやり取りするためのコールバック インターフェースです。 たとえば、onCreateLoader() コールバック メソッドを使用して新しいローダを作成します。
Loader非同期のデータロードを実行する抽象クラスです。 これは、ローダの基本クラスです。 通常は CursorLoader を使用しますが、独自のサブクラスを実装することもできます。ローダがアクティブな間は、データのソースを監視し、コンテンツが変更されたときに新しい結果を配信します。
AsyncTaskLoader処理を行うための AsyncTask を提供する抽象的なローダです。
CursorLoader ContentResolver に問い合わせて Cursor を返す AsyncTaskLoader のサブクラスです。 これは、カーソルのクエリ用に標準的な方法で Loader プロトコルを実装するクラスで、アプリの UI をブロックせずにバックグラウンドでカーソルのクエリを実行するように、AsyncTaskLoader を基に構築されています。 ContentProvider からデータを非同期的にロードする際は、フラグメントの API やアクティビティの API 経由でマネージド クエリを実行するのではなく、このローダを使用するのが最適です。

上の表のクラスとインターフェースは、アプリケーションでローダを実装する際に使用する必須コンポーネントです。 作成するローダごとにこれらすべてが必要になるわけではありませんが、ローダを初期化したり、CursorLoader などの Loader クラスを実装したりするには、LoaderManager への参照が常に必要になります。 次のセクションでは、アプリケーションでのこれらのクラスとインターフェースの使用方法を説明します。

アプリケーションでローダを使用する

このセクションでは、Android アプリケーションのローダの使用方法について説明します。通常、ローダを使用するアプリケーションには次の内容が含まれます。

ローダを開始する

LoaderManager は 1 つ以上の Loader インスタンスを ActivityFragment 内で管理します。1 つのアクティビティやフラグメントごとに、LoaderManager は 1 つだけ存在しますが、

通常は、アクティビティの onCreate() メソッドか、フラグメントの onActivityCreated() メソッド内で Loader を初期化します。 その方法は次のとおりです。

// Prepare the loader.  Either re-connect with an existing one,
// or start a new one.
getLoaderManager().initLoader(0, null, this);

initLoader() メソッドが次のパラメータを受け取ります。

  • ローダを識別する一意の ID。この例では、ID は 0 です。
  • ローダの構築時に提供する任意の引数(この例では null)。
  • LoaderManager がローダのイベントを報告する際に呼び出す LoaderManager.LoaderCallbacks の実装。 この例では、ローカルクラスが LoaderManager.LoaderCallbacks インターフェースを実装するため、自身の this に参照を渡します。

initLoader() の呼び出しによって、ローダが初期化され、アクティブになります。 結果には次の 2 つの可能性があります。

  • ID で指定されたローダが既に存在する場合は、最後に作成されたローダが再利用されます。
  • ID で指定したローダが存在しない場合、initLoader()LoaderManager.LoaderCallbacks メソッドの onCreateLoader() をトリガーします。ここで、インスタンスを作成して新しいローダを返すコードを実装します。詳細については、onCreateLoader のセクションをご覧ください。

いずれの場合でも、その LoaderManager.LoaderCallbacks の実装はローダに関連付けられ、ローダの状態が変化したときに呼び出されます。 この呼び出しの時点で、呼び出し側が開始された状態にあり、リクエストされたローダが既に存在し、データを生成済みの場合は、システムはただちに onLoadFinished() を呼び出す(initLoader() の間に)ため、それに備えておく必要があります。 このコールバックの詳細については、 onLoadFinished をご覧ください。

initLoader() メソッドは作成された Loader を返しますが、そこへの参照はキャプチャしないことに注意してください。 LoaderManager は自動的にローダの生存状態を管理します。 LoaderManager は必要に応じて開始と停止を行いし、ローダとそれに関連付けられたコンテンツの状態を管理します。 このことからもわかるように、ローダと直接やり取りすることはほとんどありません(ローダの動作を微調整するローダ メソッドの使用例については、LoaderThrottle のサンプルをご覧ください)。特定のイベントが発生したときにローディングの処理に干渉することを目的に、LoaderManager.LoaderCallbacks を使用することがよくあります。 このトピックの詳細については、LoadManager コールバックを使用するをご覧ください。

ローダを再開する

上記のように initLoader() を使用する場合、指定した ID があれば既存のローダを使用し、なければ新たに作成します。 ただし、古いデータを破棄して最初からやり直したいこともあります。

古いデータを破棄するには、restartLoader() を使用します。たとえば、この SearchView.OnQueryTextListener を実装すると、ユーザーのクエリが変化したときにローダが再開されます。 新しい検索フィルタを使用して新しいクエリを実行できるように、ローダは再開される必要があります。

public boolean onQueryTextChanged(String newText) {
    // Called when the action bar search text has changed.  Update
    // the search filter, and restart the loader to do a new query
    // with this filter.
    mCurFilter = !TextUtils.isEmpty(newText) ? newText : null;
    getLoaderManager().restartLoader(0, null, this);
    return true;
}

LoaderManager コールバックを使用する

LoaderManager.LoaderCallbacks はクライアントが LoaderManager とやり取りできるようにするコールバック インターフェースです。

特に、CursorLoader のローダでは、停止後もデータを保持しておくことが望まれます。 これにより、アプリケーションがアクティビティやフラグメントの onStop() メソッドや onStart() メソッド全体でデータを維持することができるので、ユーザーがアプリケーションに戻ったときにデータの再ロードを待つ必要がありません。 新しいローダを作成するタイミングを知りたいときや、ローダのデータの使用を停止するタイミングをアプリケーションに伝えるときは、LoaderManager.LoaderCallbacks メソッドを使用します。

LoaderManager.LoaderCallbacks には次のメソッドが含まれています。

  • onLoadFinished()— 前に作成されたローダがロードを完了した時に呼び出されます。
  • onLoaderReset() — 前に作成されたローダがリセットされ、データが利用不可になったときに呼び出されます。

これらのメソッドについては、次のセクションで詳しく説明します。

onCreateLoader

ローダにアクセスしようとしたとき(たとえば、initLoader() 経由など)、ID で指定したローダが存在するかどうかを確認します。 存在しない場合は、LoaderManager.LoaderCallbacksonCreateLoader() メソッドをトリガーします。ここで、新しいローダを作成します。 通常は、CursorLoader になりますが、独自の Loader サブクラスを実装することもできます。

この例では、onCreateLoader() コールバック メソッドが CursorLoader を作成します。 CursorLoader は、そのコンストラクタ メソッドを使用して構築する必要があり、ContentProvider へのクエリを実行するのに必要なすべての情報が必要になります。 具体的に必要な情報は次のとおりです。

  • uri — 取得するコンテンツの URI。
  • projection — 返す列のリスト。null を渡すとすべての列が返されるため、効率的ではありません。
  • selection — SQL WHERE 句の書式で返す行を宣言するフィルタ(WHERE 自体は除く)。 null を渡すと指定した URI のすべての行が返されます。
  • selectionArgs — selection に ? を含めると、selection に表示される順序で selectionArgs の値に置き換えられます。 この値は、Strings 配列でバインドされます。
  • sortOrder — SQL ORDER BY 句(ORDER 自体は除く)の形式で行を順序付けします。null を渡すとデフォルトのソート順序が使用されるため、順序が付けられない場合があります。

次に例を示します。

 // If non-null, this is the current filter the user has provided.
String mCurFilter;
...
public Loader<Cursor> onCreateLoader(int id, Bundle args) {
    // This is called when a new Loader needs to be created.  This
    // sample only has one Loader, so we don't care about the ID.
    // First, pick the base URI to use depending on whether we are
    // currently filtering.
    Uri baseUri;
    if (mCurFilter != null) {
        baseUri = Uri.withAppendedPath(Contacts.CONTENT_FILTER_URI,
                  Uri.encode(mCurFilter));
    } else {
        baseUri = Contacts.CONTENT_URI;
    }

    // Now create and return a CursorLoader that will take care of
    // creating a Cursor for the data being displayed.
    String select = "((" + Contacts.DISPLAY_NAME + " NOTNULL) AND ("
            + Contacts.HAS_PHONE_NUMBER + "=1) AND ("
            + Contacts.DISPLAY_NAME + " != '' ))";
    return new CursorLoader(getActivity(), baseUri,
            CONTACTS_SUMMARY_PROJECTION, select, null,
            Contacts.DISPLAY_NAME + " COLLATE LOCALIZED ASC");
}

onLoadFinished

このメソッドは、前に作成したローダがロードを完了したときに呼び出されます。このメソッドは、このローダが提供した最後のデータが解放される前に呼び出されることが保証されています。 この時点で、すべての古いデータを削除する必要がありますが(まもなく解放されるため)、データの所有者はローダでありローダが処理するため、自身でデータを解放しないようにしてください。

アプリケーションがもうデータを使用していないことを検知すると、ローダがデータを解放します。 たとえば、データが CursorLoader からのカーソルの場合は、自身で close() を呼び出さないようにしてください。カーソルが CursorAdapter に置かれている場合は、古い Cursor がクローズされないように swapCursor() メソッドを使用する必要があります。 次に例を示します。

// This is the Adapter being used to display the list's data.
SimpleCursorAdapter mAdapter; ... public void onLoadFinished(Loader<Cursor> loader, Cursor data) { // Swap the new cursor in.  (The framework will take care of closing the // old cursor once we return.) mAdapter.swapCursor(data); }

onLoaderReset

このメソッドは、前に作成されたローダがリセットされ、データが利用できなくなったときに呼び出されます。 このコールバックにより、データが解放されるタイミングがわかり、そのデータへの参照を削除できます。  

この実装では、null の値を使用して swapCursor() を呼び出します。

// This is the Adapter being used to display the list's data.
SimpleCursorAdapter mAdapter;
...

public void onLoaderReset(Loader<Cursor> loader) {
    // This is called when the last Cursor provided to onLoadFinished()
    // above is about to be closed.  We need to make sure we are no
    // longer using it.
    mAdapter.swapCursor(null);
}

以下は、連絡先のコンテンツ プロバイダに対するクエリの結果が含まれた ListView を表示する Fragment の完全な実装の例です。 CursorLoader を使用してプロバイダへのクエリを管理しています。

この例にあるように、アプリケーションがユーザーの連絡先にアクセスするには、マニフェストに READ_CONTACTS の許可を含める必要があります。

public static class CursorLoaderListFragment extends ListFragment
        implements OnQueryTextListener, LoaderManager.LoaderCallbacks<Cursor> {

    // This is the Adapter being used to display the list's data.
    SimpleCursorAdapter mAdapter;

    // If non-null, this is the current filter the user has provided.
    String mCurFilter;

    @Override public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);

        // Give some text to display if there is no data.  In a real
        // application this would come from a resource.
        setEmptyText("No phone numbers");

        // We have a menu item to show in action bar.
        setHasOptionsMenu(true);

        // Create an empty adapter we will use to display the loaded data.
        mAdapter = new SimpleCursorAdapter(getActivity(),
                android.R.layout.simple_list_item_2, null,
                new String[] { Contacts.DISPLAY_NAME, Contacts.CONTACT_STATUS },
                new int[] { android.R.id.text1, android.R.id.text2 }, 0);
        setListAdapter(mAdapter);

        // Prepare the loader.  Either re-connect with an existing one,
        // or start a new one.
        getLoaderManager().initLoader(0, null, this);
    }

    @Override public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
        // Place an action bar item for searching.
        MenuItem item = menu.add("Search");
        item.setIcon(android.R.drawable.ic_menu_search);
        item.setShowAsAction(MenuItem.SHOW_AS_ACTION_IF_ROOM);
        SearchView sv = new SearchView(getActivity());
        sv.setOnQueryTextListener(this);
        item.setActionView(sv);
    }

    public boolean onQueryTextChange(String newText) {
        // Called when the action bar search text has changed.  Update
        // the search filter, and restart the loader to do a new query
        // with this filter.
        mCurFilter = !TextUtils.isEmpty(newText) ? newText : null;
        getLoaderManager().restartLoader(0, null, this);
        return true;
    }

    @Override public boolean onQueryTextSubmit(String query) {
        // Don't care about this.
        return true;
    }

    @Override public void onListItemClick(ListView l, View v, int position, long id) {
        // Insert desired behavior here.
        Log.i("FragmentComplexList", "Item clicked: " + id);
    }

    // These are the Contacts rows that we will retrieve.
    static final String[] CONTACTS_SUMMARY_PROJECTION = new String[] {
        Contacts._ID,
        Contacts.DISPLAY_NAME,
        Contacts.CONTACT_STATUS,
        Contacts.CONTACT_PRESENCE,
        Contacts.PHOTO_ID,
        Contacts.LOOKUP_KEY,
    };
    public Loader<Cursor> onCreateLoader(int id, Bundle args) {
        // This is called when a new Loader needs to be created.  This
        // sample only has one Loader, so we don't care about the ID.
        // First, pick the base URI to use depending on whether we are
        // currently filtering.
        Uri baseUri;
        if (mCurFilter != null) {
            baseUri = Uri.withAppendedPath(Contacts.CONTENT_FILTER_URI,
                    Uri.encode(mCurFilter));
        } else {
            baseUri = Contacts.CONTENT_URI;
        }

        // Now create and return a CursorLoader that will take care of
        // creating a Cursor for the data being displayed.
        String select = "((" + Contacts.DISPLAY_NAME + " NOTNULL) AND ("
                + Contacts.HAS_PHONE_NUMBER + "=1) AND ("
                + Contacts.DISPLAY_NAME + " != '' ))";
        return new CursorLoader(getActivity(), baseUri,
                CONTACTS_SUMMARY_PROJECTION, select, null,
                Contacts.DISPLAY_NAME + " COLLATE LOCALIZED ASC");
    }

    public void onLoadFinished(Loader<Cursor> loader, Cursor data) {
        // Swap the new cursor in.  (The framework will take care of closing the
        // old cursor once we return.)
        mAdapter.swapCursor(data);
    }

    public void onLoaderReset(Loader<Cursor> loader) {
        // This is called when the last Cursor provided to onLoadFinished()
        // above is about to be closed.  We need to make sure we are no
        // longer using it.
        mAdapter.swapCursor(null);
    }
}

その他の例

ApiDemos には、ローダの使用方法を示す他のサンプルがいくつか用意されています。

  • LoaderCursor — 上記のスニペットの完全バージョン。
  • LoaderThrottle — スロットリングを使用して、データの変更時にコンテンツ プロバイダのクエリ数を軽減する方法の例です。

SDK サンプルのダウンロードとインストールの詳細については、サンプルの取得をご覧ください。