Say Numbers その1: アプリの構成

最初のブログとして、またXamarinとMvvmCrossの入門を書いた方がいいと思いました。 N+1 Days of MvvmCrossがきっかけで、そのまま使えるアプリを作るチュートリアルシリーズを書くことにしました。 アプイのタイトルはSay Numbersで、外国語として英語を学んでいる方々に数字を口にさせます。日本に住んでいるので、特に日本人を相手にしています。日本語の数字単位が「万」で、英語の単位は「千」(例えば1万=10千)なので特に難しいでしょう。完成したプロジェクトはこちらにあります。

今日はアプリの構成について書き、次回からはしたからアプリの段階を詳しく説明していきます。

このアプリはMVVM(モデル、ビュー、ビューモデル)という原則に従います。柔軟なモデルで、アプリの表示(ビュー)とロジック(モデル)を仲介(ビューモデル)を得てカップリングを解きます。ゲームを開発しているチームで考えれば簡単かもしれません。モデルはプログラマー、ビューはアーティストでビューモデルはその二人がお互い直接話し合えないために ニーズを伝えていくテクニカルアーティストみたいな構成です。

MVVM Diagram
これがMVVMの構成です。

このモデルのパワーを使えば、ますますプラットフォーム共通ソースを書くことができます。なお、Xamarin Formsを加えて共通にできないソースが非常に少なくなります。各段階をもうちょっと詳しく見てみましょう。

モデル


ここはアプリのコアビズネスロジクになります。あるロジックを実行する「サービス」というクラスが含みます。この段階で定義してもいいし、もし必要だったら依存性の注入という制度を使ってプラットフォーム固有段階でも定義できます。要するに、インターフェースのみで対応して、ランタイムでそのインターフェースを実装します。

ビューモデル


この段階は上の段階(ビュー)と下の段階(モデル)のコミュニケーションを担当します。ユーザーがアプリと対応したらビューはシグナルを送り、ビューモデルは適切にモデルを更新します。更新が同期に行われたか非同期に行われたかに関わらず、終わったらモデルは再びビューモデルにシグナルを送ってビューモデルがビューに伝えます。

ビュー


この段階はユーザーインターフェースを表示します。これしかやりません。ここで行うロジックはできるだけ少なくしなければなりません。ビューがプラットフォーム固有の時にさらに大切でしたが、表示とロジックのカップリングを防ぐためにまだ大切です。

次はパート2で、モデルを詳しく説明しますので、ぜひお読みください!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s