Androidの設計について

この記事は NewsPicks Advent Calendar 2019 の20日目の記事です。

はじめに

本記事は、NewsPicksのAndroidアプリにおける設計のお話をします

2018年〜2019年8月までは、2018アドベントカレンダーのこちらの記事にある通りMVPで実装していました。

なぜMVPを捨てて別の設計を採用したのかについてお伝えしていきます

きっかけ

そもそもMVPを捨てる決断に至った要因としてAndroid技術者が現在の人数の倍になった時、思惑通りスケールさせるには現状のMVPだけでは足りなそうというものでした。
なにがどう足らなそうかというと、ワクワク感が少ない(特に新しい技術でもないため)、ファイル数とコーディング量がMVPだとどうしても増える、というあたりが焦点となり、2019年8月に、折角なのでAndroidチームで集まってどうすれば思惑通りスケールするかの設計についてMTGをしました。

スケーリング可能な設計

では思惑通りのスケールとはなんぞやということで以下のように定義しました

新しく入った人(Android経験者)が標準コンポーネントレベルであれば迷うことなくNewsPicks用にコーディングできること

結論としてはMVPからCoroutineとViewModelScopeでレイヤードアーキテクチャな設計になりました。
構成としては通信及び非同期処理まわりを簡潔に書けるためKtor + Coroutine、ViewModelは安心安定のOS標準のViewModelを採用しました。

導入

いきなり新しい設計を今動いているアプリに入れるよりも、まずは小さいアプリをチーム内で作ってそれを元に設計を磨こうとなり、リファレンスアプリ(Android版NewsPicks用のお手本実装)プロジェクトがスタートし現在も継続中です。

そして、リファレンスアプリプロジェクトにより、新しい設計による画面も既にいくつかNewsPicks本体にくみこまれていってはいますが、全てのコードを入れ替えるまでには至っていません。

メリット

MVPのコードからどうかわったかというと、まずファイル数と書くコード量が減りました。
そしてMVPでよくあるファイルを行ったり来たりが減ることによる可読性向上が結構大きかったです

デメリット

色々実装を見ているが、細かい所でいくつか書き方がふわっとしてしまっている(あまりガチガチに型にはめるのもよくはないですが)
新しい技術も取り入れたため学習コストがかかりましたが、人によってはむしろモチベーションになったので一概にデメリットとも言いづらいかもです。

まとめ

約半年かけて少しずつ紹介した設計に楽しみながら寄せていけています。
リファレンスアプリに関してはそのままレビュー観点にもなるように議論できたのが大きかったです。
また、リファレンスアプリに関してはブラッシュアップしていき、ある程度の規模になったら外部へ公開予定です。

21日目は、@betchiさんです。