タスクを紹介するとともに、タスクが動作する一般的な仕組みの一部を学びました。前回の投稿をご覧になっていない場合は、以降を読む前にご覧いただくことをお勧めします。今回の投稿では、結果を取得するためにタスクに追加できるさまざまなリスナーの動作の違いについて見ていきます。使う次のようなタスクにリスナーを追加しました。この形式を使うと、リスナーはメインスレッドで起動します。ビューの更新など、メインスレッドでしかできないことを行うことができます。タスクによって制御がメインスレッドに戻されるのはたいへんありがたいことです。点だけ注意事項があります。アクティビティでこのようにしてリスナーを登録した場合、そのアクティビティが破棄されるときにリスナーを削除しないと、アクティビティがリークする可能性があります。アクティビティのリークを防止するもちろん、アクティビティのリークを発生させたい人はいません。そのためにまず、アクティビティのリークとはどのようなものか考えてみましょう。オブジェクトの参照を保持しているオブジェクトがある場合に発生します。そのアクティビティのインスタンスをもう利用しないことが確実にわかります。コレクタはそのアクティビティ、付随するすべてのビュー、その他の不要になったオブジェクトを回収します。コレクタはそのアクティビティやそれに付随するすべてのビューを回収しません。タスクを使うと、慎重に回避しない限り、アクティビティのリークが問題になる場合があります。オブジェクトは、自身を含むアクティビティへの暗黙的な強い参照を保持します。リスナー内部のコードがアクティビティやそのメンバーを変更できるのはそのためですが、このあたりの細かい制御はコンパイラが暗黙的に行ってくれます。呼び出された後もリスナーを参照している場合に発生します。実際は、タスクにどのくらい時間がかかるかについては何の保証もありません。そのため、リスナーは無限に保持できるようになっています。前に完了していないとアクティビティがリークする可能性があります。(たとえば、ネットワーク通信が滞っている場合など)たくさんのタスクがアクティビティへの逆参照を保持している場合、アプリのメモリが足りなくなってクラッシュすることもあります。詳しくは、こちらの動画もご覧ください。使うと、適切なタイミングでリスナーを削除するよう十分注意しない限り、アクティビティがリークする可能性があります。アクティビティのリークを考慮する場合(もちろん考慮が必要です)、この点を認識しておく必要があります。使うと、リスナーの削除を自動的に行ってくれるので便利です。呼び出す部分を少し変更してみましょう。つの引数があることを除けば、先ほどのものとまったく同じです。最初の引数は「this」です。そのため、このコードがアクティビティの中にある場合、「this」はアクティビティのインスタンスを指します。伝えることができます。タスクから削除されるようになります。アクティビティがアクティブである間に作成したすべてのタスクを自分で削除する必要がなくなるため、これはとても便利な方法です。適切かどうかを確認する必要はありますが、多くの場合は問題ないでしょう。次のアクティビティ(画面の向きが変わって現在のアクティビティが新しいアクティビティに置き換わった場合など)でタスクのトラッキングを継続する場合、次のアクティビティで必要になる情報を保持する方法を検討する必要があります。この点については、アクティビティの状態を保存するをご覧ください。メインスレッド以外で処理するタスクが完了した際の処理をメインスレッド上で行いたくないケースもあるでしょう。リスナーでブロック処理を行いたい場合や、それぞれのタスクの結果を(シーケンシャルではなく)並列に処理したい場合などです。その場合、メインスレッドでの処理ではなく、代わりに自分で制御する別のスレッドで結果を処理したいと思うでしょう。次のような形式です(リスナーは省略しています)。呼び出して新しい設定値を取得しています。呼び出し、最初の引数としてエグゼキュータを渡します。エグゼキュータは、リスナーを起動するスレッドを決定します。制御下にあるスレッドとは、単一スレッドの場合もありますが、作業を行うべく待ち構えているスレッドプールである場合もあります。アプリで直接エグゼキュータを使うことはあまり多くはなく、この手法はアプリのスレッドの動作を管理する高度な技法と見られることもあります。ここで覚えておくべきことは、状況によっては、リスナーの結果を受信するのはメインスレッドでなくてもよいということです。エグゼキュータを使用する場合は、スレッドがリークしないように共有シングルトンとして管理するか、エグゼキュータのライフサイクルを管理するようにします。することによって、タスクがオブジェクトを直接生成しないことを宣言できます。型データがないことを示すデータ型です。このタスクを単なるタスクの完了を示すインジケーターとして使用しています。使用して頂く必要があります。失敗時と完了時のリスナーにも同じ形式があります。特別なことは何もありません。成功と失敗の両方を受信できるリスナーなので、コールバックの内部でステータスを確認する必要があります。メタデータのコールバックは、成功と失敗でリスナーを分けずに、次のように書き換えることもできます。つのリスナーで成功と失敗の両方の処理を行うことができます。呼び出すと、成功か失敗かがわかります。両方を登録するのと同じ機能になります。どちらの方式を使うかは、主に好みの問題です。種類のリスナーで受信できます。つの方法でコールバックを受信することができます。いくつかの選択肢がありますが、どれが一番状況に適しているかを選ぶのは皆さんです。タスクの結果を処理する方法はこれだけではありません。複雑な処理を行うために、タスク結果のパイプラインを作成することもできます。次回は、その方法を詳しく説明します。マスターへの旅を続けましょう。チャネルも用意しています。フォローもよろしくお願いします。ForumGooglePrivacyTerms。