[Android]お寿司屋で例えるAndroid Architecture Component 第一貫:どんなもんか知る


Android Architecture Componentって?

どうもReoです。
Android Architecture Componentとは、丈夫でテストがしやすく、保守性の高いアプリを作るためのライブラリ群です。
公式の呼び方ではないのですが、それらを用いた設計手法として、MVVMがAndroidだと有名です。

あ!ここ違くね!ってところがあったらコメントとか筆者の(Twitter)で教えてもらいたいです~!

取り敢えず、公式リファレンスを見てみましょう。

上記の図が、Android Architecture Componentによって作られてアプリの設計図です。
一応、こちらがAndroidの推奨設計とされていますが、当然完全なわけではありません。
状況に応じて適切な設計手法があるものです。

我々が、普段よく使うのはActivityやFragmentですよね。
自分自身もよくやりがちなのが、兎に角一つのActivityやFragmentに全コードを書いちゃうことです。
こうすると、簡単なアプリの場合はいいのですが、凝ったアプリを作った際に、大変なことになります。
例えば、筆者はランニングアプリを数か月前にリリースしたのですが、その際一つのファイルで1000行越えることがありました。
関数で共通化できていなかった部分もありますが、その時の自分は、わーい!1000行越えた~!イケてるアプリ作っちゃってる~!、と優越感に浸ってました。
また、それに関してどやるツイートもしちゃってました。(反省)

しかし、修正しようとした時に、該当コードがどこにあるのか?どうやって実装したんだっけ?、そもそもなんでこの書き方したの??等々自分ですら追えないことがありました。

自分でも追えないコードなんて、他人から見たら解読不可能です。
ここから、筆者はアプリの保守性を意識するようになり、設計について学ばねば!と思うに至りました。

話しを戻します。
上記の図を見ると、色々な役割やリファレンス内には小難しい説明があって良く分からんぁと思っているかなと。
でも、それほど複雑な作りではありません。

要は、分業をしているのです。
リファレンス内では、関心の分離と表現していますね!!

アーキテクチャを現実世界で例えてみる

例えば、みんな大好きお寿司屋さん!

お寿司屋には、板前さんがいてお寿司を握ってくれます。
そして、そのお魚さんはどこから来るのか、、
そう、漁師さんがとってきてくれますよね。
じゃぁ、そのお魚さんは港に水揚げされて、仲卸業者がライバル業者より高い値段で勝ち取る!
そして、それを自分たちのお魚屋さんにもっていき、お寿司屋さんに売るわけです。
他にも、冷凍車で配送する人など、色々な人が関わっています。

では、この漁に出る所からお寿司を握ってお客さんに提供するまでを板前さん一人でやるとしたらどうですかね?

とてつもない労力になりますよね!

筆者は、一つのFragmentに機能モリモリにして、1000行のコードでどやってましたが、その板前さんの例えをソフトウェアの世界でやっちゃってるようなものです。
一つのActivity/Fragmentが、板前や配送業や卸売業や漁師などの様々な役割を担ってしまうと、キャパオーバーになります。
ソフトウェア的には、メモリ不足・・・
要は、ソフトウェアの世界でも分業は必要なのです。
その為に、MVVM等のアーキテクチャをアプリに導入するわけです。

さてさて、お寿司屋の例えを無理やりこちらのMVVMの図に当てはめると、

View(Activity/Fragment)はお客さん

ViewModelが板前さん

Repositoryが、漁師

Modelが、海

こんな感じですかね。(仲卸業者どこいった!笑)
自分自身、自力でMVVM実装したことないので、人によっては、いやこうじゃね???って部分があるかと思いますが、無理やり比喩表現したので悪しからず。

そして、大事なのが矢印の方向性にしか依存関係がないということです。

お客さんは、板前さんにお寿司を注文する(つまり依存している)
板前さんは漁師さんに魚を取ってきてもらう。(〃)
漁師さんは、海がないと魚が取れない。(〃)

また、データの流れは矢印の逆です。
データを魚だとすると、海から魚が流通してくるということですね。

第二貫までに筆者自身、理解を深めておきます。
このイメージをもってMVVM設計を作っていきましょう。

第二貫に続く・・・