Activityのソース巨大化を防止するには

Androidのアプリケーションを作っていると、Activityのソースが巨大化しやすい。その最大の理由はサンプルソースに有ると思う。

世の中にあふれているサンプルソースとして書かれているコードのほとんど全部が、Activityのクラス内にコードを書いてしまっているから。サンプルソースを見た人は、それをマネて書くから、機能を追加すればするほどActivityのコードが巨大化してしまう。

では、巨大化を防ぐにはどうすればいいか。

MVCアーキテクチャにしたがって、クラスの責務を設計することが重要だ。そもそも継承元のActivityが巨大なので、継承元のActivityが実装しているメソッドのオーバーライドを必要に応じて実装するだけでもそこそこ巨大化してしまう。だから、オーバーライド以外のメソッドは追加しないくらいのつもりでいいと思う。

Contextの種類で分類する

AndroidにはいくつかのContextが存在する。よく使われるのは、Application、Activity、Serviceの3つ。アプリケーション全体で共通して使われるメソッドは、Applicationを継承したクラスで実装すると、ActivityでもServiceでも使えて便利になる。

Applicationコンテキストの分離方法は、以前に書いたことがある。
≫アプリ全体でリソースを共有するには

Modelを分離する

MVCアーキテクチャで分類すると、ApplicationとServiceはModelにあたる。ActivityはViewにあたる。

ActivityがViewであることを考えた場合、Viewで表示しようとしているModelは、Activityのソースから分離すべきであるということは、容易に想像できる。

Controllerを分離する

MVCアーキテクチャにおいて、Controllerとは外部からの入力を受け取ったり、アプリケーション内部の変化を外部に伝達する役割を持つ。

外部からの入力といえば、キー入力や、画面上でのタッチやフリックなどの操作がそれにあたる。それと別に、ネットワークやBluetoothなどの通信の結果などもControllerに分類できる。

外部からの入力を適切に処理して、それがModelに何かの変化を与えるものであればModelに伝達し、単純にViewを変化させるだけでよければViewに伝達する。

Viewに対して直接伝達する場合は、注意する必要がある。Modelの存在を忘れて、Viewだけを更新する可能性がある。外部からの入力が本来はModelに伝達されるべきものなのにViewに伝達してしまうと、ModelとViewに矛盾が生じてしまう。Controllerは、情報をModelに伝達するだけにする。

Observerパターンを使って分離する。

ViewとModelの関係はObserverパターンを使用して、ModelをObservableにし、ViewをObserverにする。Modelが変化したことを、Viewがイベント通知で受け取るようにして、イベント通知を受けたViewがそのViewの責務に従って自身を描画するのが良い。

もともとActivityのメソッドで画面からの入力を受け取るメソッドが用意されているけど、その中に処理は書かずに、具体的な処理は HogeProcessor などのクラスを作って移譲する。

まとめ

・Contextの種類で分類する。
・ActivityからModelを分離する。
・ActivityからControllerを分離する。
・Observerパターンを使って分離する。