AsyncTaskLoader を使うのを止めた

Android 版アプリ開発で非同期処理に AsyncTaskLoader を使っていましたが、どうにもしっくりこない。

Fragment で利用する Loader が 1 つになるような局面では、Fragment に LoaderCallbacks を 実装するパターンで可読性が下がるわけではなく、Fragment/Activity のライフライクルとも連動して便利なのかなと思います。

しかし、開発中のアプリでは、1 つの Fragment から幾つものサーバ通信処理（非同期処理）を呼び出すので、Fragment に LoaderCallbacks を実装して onLoadFinished で分岐するにしても、非同期処理別に LoaderCallbacks を実装しても、どちらにせよ可読性が大きく低下します。

また、非同期に実行したい処理は、極自然に実装したクラスのメソッドであるため、それら各メソッド毎に AsyncTaskLoader のサブクラスを実装する必要もあり、これも可読性を下げます。仮に、単一の AsyncTaskLoader のサブクラスで共通化できるように API を整理したとしても、onCreateLoader でのインスタンス化処理の可読性が下がるでしょう。これは、CursorLoader の使い方が示す通りです。

ってことで、何か良い枠組みが無いかと検索したところ、直ぐに以下が見つかりました。

JDeferred

非同期に実行する処理を直後に、done/fail/always でコールバックを書けるのが良いですね。ある非同期処理に関連する全ての処理の把握が容易です。
非同期処理では、その開始でプログレスバーやプログレス ダイアログを動かし、成功と失敗の両方でそれらを止めるなどの UI 制御が必要となりますが、そのような後処理を always で共通化できるのも便利です。

しかし、JDeferred は導入せず、考え方だけを取り入れてフレームワークを自作して利用しています（Deferred/Promise には従っていません）。
開発中のアプリでのみ利用する物として考えれば、必要な部分だけを洗い出し、より簡潔に可読性の高いフレームワークを作ることは容易です。
必要としない型パラメータを排除し、非同期に実行する処理は Runnable/Callable の実装としたりなどで簡素化した感じですね。

・・・つーか、ラムダ式を使いたい。匿名クラスによるコールバック実装では、可読性の向上に限界があります。