APIのinterfaceは何かで包んでからRepositoryとかに渡すのがいい、という話。APIにアクセスするライブラリを使うときにも有効ではないかと思う。そのようにするモチベーションを次の通り述べる。私はRestClientみたいな名前のクラスに包んでいる。APIへのアクセスはいろんな画面で起きるので、エラーレスポンスのハンドリングも素直にやると画面ごとに実装しなければならなくなる。レスポンスが返ってこないときはいつも決まったメッセージを出すとか、そういった共通の処理はなにかの形でまとめたい。そのような用途のために、エラーレスポンスが返ってきたときの共通処理や、エラーレスポンスをイベントに変換してどこかに流すPublisherやChannel的なものを用意してRestClientに注入する。APIでは2ページ目以降を取得するときにトークンが必要になることがある。このトークンは1ページ目のレスポンスの中にリストデータと一緒に含まれている。2ページ目を取得するときまでは何らかの形で覚えておかなければならない。そのような時、メモリ上に保持しておけばいいというような場合はRestClientで保持していればよい。RestClientの利用者はトークンを意識することなく次のページを取得できる。次のページを取得する方法を隠蔽しているので、REST側がランダムアクセス的なインタフェースに変わったとしても(あるいはランダムアクセス的なインタフェースからトークン方式に変わったとしても)RestClientの利用者は処理を変える必要がない。トークンをシリアライズしたいというときには一工夫する必要があるかもしれない。ライブラリとアプリとの境界を規定するシンプルに見ればライブラリとアプリとの間にレイヤーを挟む格好になるので、腐敗防止層的な役割もやってくれる(Retrofitが腐敗してしまうのは考えたくないけど)。API側が開発中で完成していない場合や、まだバギーな時も代わりの値を返すようなものを差し込みやすいかもしれない。Repositoryのテストもいくらか楽になるかもしれない。ver.24.2.1で確認した。...2015-07-06AndroidAnnotationsをプロジェクトで使うためのGradleメモこのページにかいてあること。読者になるリンクはてなブログブログをはじめる(無料)お知らせ検索はてなブログをはじめよう!akihito104さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。