2019/09/18

Androidアプリ開発:データとビューの整理の考え方とObserverパターン

データを扱い始めると、データとビューをどうつなげるかを整理しないと、あっという間に混乱が襲ってくる。たとえActivityが一小さなアプリであっても、表示されるデータが変化する場合、想像以上にアプリの構造は複雑になっていく。ネットワーク経由でデータを取得する場合は、なおさらだ。

加えて、処理はイベントドリブンな形で実現しなければならない。何も考えずに書いていると、巨大なActivityができあがる。これば絶対おかしいと思い調べてみると、Fat activityというよくある罠。

Fat Activityは、アプリのクラス構造の設計を適切にすることで解決できる。昔からの定石があり、この先人の知恵は絶対に参考にすべきだ。MVC(Model-Vew-Controller), MVP(Model-View-Presenter), MVVM(Model-View-View Model)などのキーワードで検索すると、ありがたい情報がたくさん見つかるはずだ。

ポイントは、UIのイベント・画面更新、データの維持、これらのつなぐロジックをそれぞれ別のクラスとして実装し、かつ、これらのクラス間の依存関係を極力減らすような実装にすることだ。 依存関係を減らすカギが、Observerというデザインパターンである。

MVCやMVPなどの考え方をクラス設計に取り入れるだけで、Activityの混沌は大きく解消されると思う。Activityが一つのような小さなアプリでも、絶対にこれらの考え方を取り入れないと、メンテできないアプリになると思う。

複数のオブジェクトでアプリを構成するようになると、オブジェクトの状態変更をどう知らせるかが、次の悩みポイントになる。単純にクラス間でメソッドを呼び出す形で通知することもできるが、これをやると、状態変更を知りたいクラスが複数あると破綻する。そんなことあるのか?と思うかもしれないが、リストビュー、グラフビューなど、Viewが複数ある方が普通だ。同時にアクティブにはなっていないかもしれないが、表示の形態を切り替えられるのは普通だ。

ここで登場するのが、Observerと呼ばれるデザインパターンだ。あるオブジェクトが、誰かわからない外部のオブジェクトに状態の変化を伝えたい場合、変化が発生したときに呼び出すメソッドを含むインタフェースを定義する。変化を知りたいオブジェクト(Observer)は、このインタフェースを実装し、自身を変化の発生元のオブジェクトに登録する。このObserverのオブジェクトは、変化の発生元のクラスが使っているインタフェースさえ実装していればよく、どんなクラスでも構わない。これによって、状態変化元とそれを観測する側のクラスの依存関係をなくしている。インタフェースは特別なものでなくてよくて、Runnableインタフェイスなどで十分出会う。

ソース側は、Observerオブジェクトの登録・削除を受け付けるメソッドを用意し、状態変化時に登録されたオブジェクトが実装するインタフェースメソッドを呼び出せば良い。このとき、ソース側はObserverのクラスは知らなくて良い、というところが重大なポイント。これによって、ソース側はObserverとは独立して開発ができることになる。

一方のObserver側は、オブジェクトの登録、通知インタフェースに変更がない限り、ソース側の実装から切り離される。つまり、こちらも独立して開発、メンテができるようになる。

実装が隠蔽され、他のクラスとの依存関係がへり、テストもしやすくなり。効果は、小さなアプリでも絶大。たぶん、当たり前のことなんだけど、一度実際に罠にハマって悩んでここにたどり着くと、その効果がよくわかります。

0 件のコメント :

コメントを投稿