Continuity is The Father of Success

Androidアプリとかゲームとか。毎日続けてるものについて。

Android Architecture Components Pagingを推したくて

Kotlin愛好会で談義してきた。

love-kotlin.connpass.com

speakerdeck.com

Kotlin愛好会にはサーバーサイドエンジニアの方も多く参加される & Paging自体があまり導入例を聞かないので、Paging紹介:Kotlinな話=7:3ぐらいにしてみました。

Pagingライブラリ

developer.android.com

Pagingライブラリは、大量のデータを読み込んでリスト表示したいときに利用するライブラリです。 「大量のデータ」は多くの場合API経由で読み込むサーバー上に保存されているデータになりますが、端末内のストレージに保存したデータでも構いません。

本業ではタイムラインの読み込みから導入して、今ではいろいろな追加読み込み処理を任せるようになっています。 大変便利。

tech.studyplus.co.jp

Pagingを導入すると何が嬉しいのか

RecyclerViewへ渡すデータ量の調整ができることはもちろん嬉しいのですが、Pagingを導入することによる最大のメリットは「RecyclerViewのスクロールリスナーを用意しなくて良くなる」ことだと思っています。 Pagingライブラリを利用するということは、ほぼ PagedListPagedListAdapter を利用したコードを書くことです。

developer.android.com

developer.android.com

PagedListAdapterPagedList を受け取り、PagedList の更新通知を RecyclerView へ渡す仕組みを持っています。 そして PagedListAdapterRecyclerView のスクロールにより追加読み込みが必要になったとき、追加読み込み処理を PagedList へ伝える仕組みも持っています。 このことにより ViewModelRepositoryRecyclerView.OnScrollListener を組み合わせるコードを、個々の開発者が書く必要がなくなります。 素早くスクロールしたケース、データの終点までスクロールしたときに追加読み込みをどうループさせないか、などの細かな実装を避けられるため、思っている以上に開発コストが下がるのが感じられるのでは、といったところです。

Paging導入の障害(?)

architecture-components-samplesの実装例を見ながら、そこそこ試行錯誤しながら書く必要があるのが大変かなーと思います。

github.com

PagingWithNetworkSample を時間をかけて読み込むことをお勧めします。 (DIがされていないサンプルになるため、LocatorとViewModelの接続がわかりにくいのですが、Dagger2などが導入済みプロジェクトであればもっと簡単に記述できます)

これといった必要条件もないのですが、参照できる実装例が少ないのが導入を妨げているのかなーと思っています。 または GroupieEpoxy をすでに導入しているプロジェクトにおいて、Pagingを追加する実例が少ないのもあるのかなと思います。 こちらについては、DroidKaigiにプロポーザルを出して落選してしまったので、ブログかRejectConあたりで整理できればな、と思っています。

おわりに

取り止めなく書いてしまいましたが、今の率直な気持ちとしては「どんどんPagingを利用する人が増えて、機能開発やバグ修正(あるのか?)がされるようになれば!」という感じです。 Pagingは2.1.0リリースの後、長期間の(かつ大規模な)Kotlinを利用した開発に入っているので、もっともっと「利用したい!」という声が上がるようになればいいなー……!

なんてことを考えていたら、たるさんに誘われて技術書博2に寄稿することになりました。

内容はPagingライブラリv3.0.0(開発中)で取り組まれているKotlin化と、Kotlin化したことによりより便利になった箇所の解説になります。 しっかりと探したわけではありませんが、Pagingについてandroidx-maste-devをそこそこ読んで解説しようとしているのは、他にないのではーと思っています。

興味が惹かれるようでしたら、是非お手に取ってみてください。