はじめに
Android Architecture Componentsについて、n番煎じながらそれぞれの要素について咀嚼した内容のメモ。
なお、諸事情によりFatなActivityやFragmentのオンパレードだったり、諸事情により対応OSのアップデートが頻繁にできなかったりする案件でも徐々に取り込こんでダイエットできそう！っていう比較的低次元なところで感動して記事を起こしたので、Reactiveなライブラリごりごり使いこなしてMVVMとかMVPとかクリーンアーキテクチャとかばっちりなイケイケアプリのエンジニアさんにはとても物足りない内容だと思いますのでご了承くださいませ。
以下、たいへん参考にさせていただきましたm(_ _)m
[Android Architecture Components] Lifecycle, LiveData and ViewModel 詳解
【Android Architecture Components】Guide to App Architecture 和訳
Android Architecture Components
Googleさんが、品質が安定したAndroidアプリを作るベストプラクティスとおすすめするアーキテクチャ。
そんな品質の良いアプリを構築するためのサポートライブラリを提供してくれたり、ドキュメントにはサポートライブラリを使いつつ具体的なアプリでのデータの取り扱い方例とかも記載してくれている。
Android Architecture Components 公式ドキュメント
Diagram
公式ドキュメントから引用。
Android Architecture Components用にサポートライブラリが準備されているうち、ライブラリ単位でまとめる。
それぞれの要素、入れたいものを単独で導入可能。入れ方はこちら
Lifecycles
「画面のここの部分はonCreateのときにこうして、onPauseのときはこういうふうにして...」っていう組み立て方が気軽にできるようにしてくれるサポートライブラリ。
ActivityやFragmentのライフサイクルメソッドにが発動するタイミングで必要な処理を詰め込む必要がなくなり、いろいろ分離しやすくなる。
実装イメージは以下(公式ドキュメントより引用)
public class MyObserver implements LifecycleObserver {
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
public void connectListener() {
...
}
@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
public void disconnectListener() {
...
}
}
myLifecycleOwner.getLifecycle().addObserver(new MyObserver());
独自のライフサイクルも定義できるらしいのだけど、ざっくりみた感じどのクラスでどうやるのかピンとこなかったので深堀はしておらず。
独自のライフサイクルを定義すると便利なケースってどんなタイミングだろう？
LiveData
通信結果の表示とか、画面上の操作に応じて別の箇所の表示を変えるとか、表示内容が確定次第すぐに画面に表示したい内容をLiveData型に入れておくと簡単に即反映してくれる。
拡張していろんな状態監視できるよ！とかできることはいろいろあるのだけど、DataBindingでLiveData型を直接指定できて、組み合わせて使うだけでもととても強力。
以下、参考にさせていただきました！
ViewModel
Activity生成後、完全に破棄されるまでデータを保持可能にしてくれる。保持期間は以下の公式ドキュメントより引用した図を参照。
一番早急に適用しやすいところでいくと、onSavedInstanceStateで消えたら困るデータを都度Bundleに保持〜って処理を最初からViewModelクラスに詰めることで撲滅できる。
そして、LiveDataと組み合わせることでActivityやFragmentからスマートに表示分岐処理とか通信処理とかを切り離せる。
Room
Googleさんが、例えばオフラインでも快適にアプリが使える場面が提供できるようにデータの永続キャッシュをする場合はSQLiteを直接使う代わりに今後はこれを使いなさいって言ってるサポートライブラリ。
アノテーションにクエリ文書いたりして、SQLiteよりすっきりと同じ処理が実現できる。
以下、参考にさせていただきました！
- 公式ドキュメント
-
Squeezing Performance from SQLite: Insertions (with Room)
- 古めの記事だけど、RoomとSQLite直接使用時の速度検証してみたという内容。
- この当時はRoomのほうが件数少ないと速いらしい。Googleさんが今後Room使ってって言ってる以上、パフォーマンスの改善が見込めるのはRoomの方だとは思うのでSQLite使ってるアプリは移行進めたいなと思う
- 古めの記事だけど、RoomとSQLite直接使用時の速度検証してみたという内容。
Paging(2018年04月現在β版)
主にリスト画面で、最新との差分だけの更新を画面に反映したりする実装を手軽にできるようになるサポートライブラリ。こちらはまだβ版なので注意。
今後リスト形式の画面を新たに作る場合、LiveDataと組み合わせつつのこれを使ったほうが断然良さそう。既存アプリの同類画面でこのライブラリ利用への差し替えはちょっと高いかなって気がしてるけど、ViewHolder取り扱う辺りとか基本は変わらなそうなので正式版出た頃にがっつり調べて使わせてもらうかも。
以下、参考にさせていただきました！
さいごに
Androidの開発業務を1年以上ご無沙汰していたあいだ、「iOSは追わないと古い書き方すると動かないとかよくあるけどAndroidならキャッチアップサボってもなんとかなるよね！」って情報追うのを疎かにした結果、つい1,2週間前Android Architecture Componentsの存在を知って今頃記事を起こした次第・・・サボっててすんませんでした。
現在、影響範囲Kotlin化のついでに比較的さくっと放り込めて将来的なバグ減少というダイレクトな恩恵が見込めるViewModelとLiveDataについては入れてみてる最中なので、別途Before/Afterみたいな記事を起こすかもしれない。