Fragment is dead?
The Cornerに Androidの Fragmentを DISる記事 が出たんで、なんか自分の周りで Fragmentの価値が暴落している模様。 自分もかの記事には基本賛成なんだけど、いままで G社の意図にしたがって頑張って Fragmentを勉強してきたのがサンクコストになるのが悔しくて、いろいろと考えている最中。
その途中のまとめとしてこの記事を書いてみます。なにしろ、自分自身がそういうアンビバレンツな状態にあるのでうまくまとまるか心配だけど、アウトプットしないと進みそうにないので。
Advocating Against Android Fragments のすごく端折ったまとめ
- いままで頑張ったけど、Fragmentはやっぱりいらない子だ。
- ライフサイクル(笑) が複雑すぎ。
- FragmentManagerImplがわけわからなくてデバッグが難しい。
- logicと viewが混じってて unit testも難しい。
- FragmentTransactionが非同期実行なので、それまで状態が不安定。
- 復活する時、引数なしコンストラクタが必要なので inner classにできない。
- まあ、それでも Fragmentはいろいろ教えてくれた。
- Responsive UIを Fragmentなしでつくってみる!
- 細かくは説明しないけど、 Containerって interfaceつくって頑張る!
- ビジネスロジックの部分は Presenterっていうのを作って分離して、unit testも簡単だ。
- バックスタック管理は Flow を使え。
- Daggerと Mortarは Fragmentとは直交したものだから、やっぱり有効。
- まとめ: Fragmentを使おうと頑張ったけど、心変わりしました:
- ほとんどの難解なクラッシュは Fragmentのライフライクル関連のせいだ。
- Viewとバックスタック、画面遷移があればレスポンシブUIはできる。
自分の想像
今までの自分の理解では、Fragmentは、Viewだけじゃなくて Presenter をモジュール化するものだった。
Androidにおける Activityは、強力でいろいろ見えすぎて、ついいろんなロジックを詰め込みすぎてしまうのはよく言われるところだ。一方、Viewは、すでにある widgetツリーでモジュール化できている。そこで、Activityの一部である Presenter ――― Viewよりもビジネスロジックよりだけど、それほど抽象化もされておらず UIに依存したレイヤ ――― に当たる部分もモジュール化できればより部品の再利用性が高まる、端的に言えばレスポンシブUIができると Honeycombの開発にあたって思ったんだろう。
それだけなら話は簡単なんだけど、G社はそんなに単純に Fragmentを作らなかった。
理由の一つはなんとなく自分にも想像できて、Androidの onResumeとかのややこしいライフサイクルに対応したかったんじゃないか。Presenterの状態は、基本 Modelから生成できるものなので、onStopでそれを開放して onResumeで再生成する、なんてセコいワザを Androidチームは考えていたのではないか。Bitmapとかのでかいデータならそれは有効だろう。
なんで FragmentManagerとかがこんなにややこしくなってしまったかは、ちょっとまだ整理できてないのでおいておく。いずれにしても、G社の人は Fragmentを単なる Presenterの分割法としては捉えず、ほかのいろんなこともさせようとして泥沼にはまっていったんじゃないかしらん。
Fragmentを捨てていいのか?
どうなんでしょう。
自分としてはまだ決心はついていない。いま書いてるコードがもう Fragmentをそこそこ使って安定して動いているので、頑張って移行する気力はないが、今後はなるべく避けるぐらいだろうか。
Presenterについて、かの Squareが言及してくれたのは自分の理解が多少あってたようで嬉しいけど、Squareは自分理論の一つには答えてくれてない: onResumeとかをハンドリングしたいときはどうするんだ?
ここらへん、モダンな環境になれた Squareは気にしないけど、省メモリ至上主義の組み込み屋体質の Androidチームがこだわってたところなんだろうなあ、とか夢想してにやにやしてたりする。実際、自分も onStop()で何かしたいという欲求はないので、必然性が出てきたら考えればいいんだろうなあ。
