Android MVVM 設計 1
Android 担当の松下です。
Android アプリを作った時に Activity に全て詰め込んでしまった事はありませんか？
実は僕が Android アプリに join した時はそういう設計でした…。（リリースを急いでいたらしいので仕方ないですね 😓）
リリースが完了し少し落ち着いた頃に、大規模なリファクタリングを行うことが決まって、その時に 「MVVM」 にしようという話が出てきました。
そういった経緯で弊社アプリは MVVM の設計になりました。
今回は 「MVVM」 の恩恵を、経験に基づいて書いていこうと思います。
MVVM になると何が嬉しいのか？
まずは、前述の「全部 Activity に書く」場合の辛いところを列挙します。
コードが見辛くなる
Android は Activity にリスナーを実装するので処理があっちこっちに行きがちです。*1
それに加えてその他のコードを増やすともう何がなんだかわからなくなってしまいますね…。
画面回転で死ぬ
Android の Activity は 画面回転で再生成されるのは有名な話ですよね。 その対策に いろいろ やったり icepick などの便利なライブラリをつかったりしていると思います。
ただ、そういうことをしてももう一度 onCreate が呼ばれてしまうのは事実。ここにシリアライズできない、例えば通信クライアントの初期化処理などを置いておくのはちょっと無駄な気がします。
ようするに
責任過多ってことです。
次に MVVM だとどうなるかを書いてみましょう。
コードが分割される
MVVM だとコードが以下のように分割出来ます。
View
見た目、アニメーション、画面遷移など、 UI 関連。 Activity, Fragment, xml が該当します。
Model
主にデータの入れ物。これは Activity に全部突っ込むスタイルでも、なんとなくあるのではないかと思います。
ViewModel
画面が持っている変数*2や、ボタンを押したときの処理など。
これで Activity が全部責務を追う必要がなくなりました。
画面のライフサイクルとは関係なく動ける
Activity のライフサイクルとは別に ViewModel が変数を持っているので画面が回転しようが何しようが関係ありません。その代わり、メモリリークには気をつける必要があります…。
次回予告
なんとなく MVVM いいっぽいな、ということが伝わったでしょうか？次回は実際にどうやって実装するのか？ということを書いていこうと思います。
ねこじゃらしについて
ねこじゃらしでは Android に限らず Ruby (Ruby on Rails) や JavaScript での開発経験がある Web エンジニア、UI/UX デザイナを募集しております。
ご興味をお持ちいただけましたら、以下のリンクからお問い合わせください。
