Android Architecture Components 雑感。
Architecture Components - Introduction (Google I/O ‘17)
解説はこのビデオを見るのがとても分かりやすいです。
機械翻訳で日本語字幕が出せるので、英語が聞き取れなくてもだいじょうぶ。
いままでの Android の世界観
※人によってかなり違う気がします
- バックグラウンド処理は
Service
を使うことができましたService
をキックするのはActivity
でもいいし、SyncAdapter
とかを使う手もあったり- この辺使うのが面倒だったりで、
AsyncTask
の不治の病に陥ってたり、RxJava 使ったりの方が多いですよね…
ContentProvider
を経由することでデータベース実装を抽象化- データの取得・更新反映は
CursorLoader
とContentObserver
を使えばおおよそ解決- これは割と普通に便利だと思うんですよ。
Loader
単体でテストも書けるし
- これは割と普通に便利だと思うんですよ。
これからのざっくりとした感じ
- ライフサイクル問題の解決として、
ViewModel
が登場 - データがローカルにあるのか、あるいは通信で取得するかはリポジトリで隠蔽
- リポジトリは
LiveData
を返す、LiveData
は通信や DB アクセスを行った結果をリアクティブな感じで渡す - ちなみに現状で、Data Binding もしたい場合は、
ObservableField
とLiveData
の変換をどうにかしないとダメっぽい、辛い - ざっくり使ってみた感じだと、
LiveData
は正直使う必要性を感じない、普通に RxJava で良いと思う
- リポジトリは
- 公式 ORM として、コードファーストな感じで DB を操作できる ROOM が(今更)登場
あくまでこれらは指針
念頭としてあるのは、開発者が行うべきことは、Activity
のライフサイクルと格闘したり、FragmentManager
の実装の深淵を追いかけたりすることでもなく、アプリケーション開発を通じてユーザーに価値を提供するということ。
その方法論として、「Andorid 標準のコンポーネントを使って、無理に Android のルールで拘りすぎる必要がない」ということが提示された、というのが一番大きいのかなぁと思いました。
Volley
とか Loader
の頃とかはまだ、Android のルールの上で利便性を高めることが意識されていたように思うのですが、ユーザーの間で発展していった設計思想なんかを、民主主義的に取り入れていくというメッセージ性を感じます。(Kotlin 公式言語化にも通じるところがあり)
Architecture Components 自体、強制されるものではなく、部分的に取り込んだり、より発展させることができる、非常に高い自由度があるサポートライブラリになっていて面白いです。