なるようになるかも

力は多くの場合、その人の思いを超えない。

Android Architecture Components 雑感。


Architecture Components - Introduction (Google I/O ‘17)

解説はこのビデオを見るのがとても分かりやすいです。

機械翻訳で日本語字幕が出せるので、英語が聞き取れなくてもだいじょうぶ。

いままでの Android の世界観

※人によってかなり違う気がします

f:id:quesera2:20170524223955p:plain

  • バックグラウンド処理は Service を使うことができました
    • Service をキックするのは Activity でもいいし、SyncAdapter とかを使う手もあったり
    • この辺使うのが面倒だったりで、AsyncTask の不治の病に陥ってたり、RxJava 使ったりの方が多いですよね…
  • ContentProvider を経由することでデータベース実装を抽象化
    • やってるの、正直あんまり見たことない…
    • 連絡帳プロバイダとかにちょっと凝ったクエリ(グルーピングとか)を投げようとすると、途端にテーブル構造を意識したハックみたいな記述になって全然抽象化されてない説がありますよね
    • Android 2.2 とかの時代に、android:exported (外部公開するかどうか)のデフォルト値が true だったせいで迂闊に使うと脆弱性があるみたいなイメージが付いたのが悪いんでしょうか…
  • データの取得・更新反映は CursorLoaderContentObserver を使えばおおよそ解決
    • これは割と普通に便利だと思うんですよ。Loader 単体でテストも書けるし

これからのざっくりとした感じ

f:id:quesera2:20170524230321p:plain

  • ライフサイクル問題の解決として、ViewModel が登場
    • 他にもなんかいろいろあるっぽいけどあんま追えてないです
    • Activity または Application のライフサイクルで生存するインスタンスみたいな感じ
    • ViewModel はあるものの、MVVM フレームワークにこれといった決定打がなく、また DialogFragment なんかをどうすればいいのか?という部分までは解決できていないという印象
  • データがローカルにあるのか、あるいは通信で取得するかはリポジトリで隠蔽
    • リポジトリLiveData を返す、LiveData は通信や DB アクセスを行った結果をリアクティブな感じで渡す
    • ちなみに現状で、Data Binding もしたい場合は、ObservableFieldLiveData の変換をどうにかしないとダメっぽい、辛い
    • ざっくり使ってみた感じだと、LiveData は正直使う必要性を感じない、普通に RxJava で良いと思う
  • 公式 ORM として、コードファーストな感じで DB を操作できる ROOM が(今更)登場

あくまでこれらは指針

念頭としてあるのは、開発者が行うべきことは、Activity のライフサイクルと格闘したり、FragmentManager の実装の深淵を追いかけたりすることでもなく、アプリケーション開発を通じてユーザーに価値を提供するということ。

その方法論として、「Andorid 標準のコンポーネントを使って、無理に Android のルールで拘りすぎる必要がない」ということが提示された、というのが一番大きいのかなぁと思いました。

Volley とか Loader の頃とかはまだ、Android のルールの上で利便性を高めることが意識されていたように思うのですが、ユーザーの間で発展していった設計思想なんかを、民主主義的に取り入れていくというメッセージ性を感じます。(Kotlin 公式言語化にも通じるところがあり)

Architecture Components 自体、強制されるものではなく、部分的に取り込んだり、より発展させることができる、非常に高い自由度があるサポートライブラリになっていて面白いです。