I/O で発表された Android の Architecture Components. サポートライブラリの一味。ベストプラクティスを支援するためのライブラリらしい。

サブモジュールは四つ。Lifecycle, Live Data, ViewModel, Room ORM. ドキュメントなどを読んでみた今のところの自分の結論は: Lifecycle 以外いらない。

Lifecycle

今まで Android は Activity の lifecycle を外部から listen する良い方法がなく、開発者はみなそれぞれ Activity を継承してアドホックに(あるいはオレオレライブラリとして) lifecycle をフックしていた。ActivityLifecycleCallbacks というのがあるにはあるのだけれどこれはグローバルなフックなので大げさすぎた。初期の RxAndroid も、このせいで Activity の lifecycle のための Observable を提供する方法に合意がとれずに終わった。

Lifecycle モジュールはそのフックを提供する。そして Lifecycle をコールバックする Activity および Fragment の base class も用意している。API が安定したら support library の base class に直接同じ機能を入れる予定という。

このレイヤはしょうじき出来の良し悪しは割とどうでもよく、誰かが方法を決めて皆がそれに従うのが重要。なので support library がそれをやってくれるのは良いと思う。

Activity を継承しないと lifecycle がフックできないとかほんとにクソだなと誰もが思っていたのに今まで何もしてこなかったのはひどい話だと思うけど、Better late than never ではある。OSS の世界に複数の方法が乱立して辛くなる前だったのはよかった。

LiveData

RxJava 的なもののしょぼい再実装。既存の実装と比べて唯一の利点は Lifecycle aware なことだけれど、Lifecycle API が定義された今なら既存のライブラリたちを Lifecycle aware にするのは簡単なので、別に再実装しなくてよくね、と思う。

Support Library のような "official" なサードパーティライブラリしか使えない辛い立場の人にとっては better than nothing かもしれないけれど、どうせなら既存の出来の良いライブラリを endorse してほしかった。

ViewModel

使う必要なし、というかこれが best practice という点にまったく同意できないので積極的に避けていきたいかんじ。なお世間が MVVM の文脈で ViewModel と呼ぶものとは若干違うと思う。

Room Persistence Library

世の中もう ORM は足りてると思うのだがなぜまた作ったのだろうな・・・。

Lifecycle を別にすると既存のオープンソースのライブラリたちと比べて特に出来が良い様子もなく、そもそもコードが公開されておらず(support library の流儀を考えるとそのうち AOSP の一部として公開されるだろうけれど)、なんなのだろうな・・・。あなたたちに今更でてきてアーキテクチャどうこういわれる筋合いないですよ、と思う人が多いのではなかろうか。

コミュニティベースの Android 系カンファレンスではここ数年アーキテクチャや保守性に関する話題が延々と議論され、それなりに合意が生まれライブラリとかも揃ってきた。一方 Google I/O の Android 関連の talk はこれまで新機能や性能の話ばかりで開発者の生産性やコードの保守性に関する議論はなかった。Android は本体のコードもあんなだし参考実装を名乗る例年の I/O アプリも割とべったりした実装。少なくともアプリレベルのアーキテクチャやコードの品質についてはコミュニティからの credibility がないと思う。それを突然でてきてエラそうな顔されてもね・・・。

やっぱり Lifecycle だけ作ってあとはコミュニティを endorse したり support する方が良いのではないかなあ。