iOSアプリの構成を教えてもらった

iOSエンジニアでもあるプロマネさんにWPFのMVVMを教えた代わりに、ちょっと聞いてみました。まずは忙しいところ興味本位の質問に答えていただいたことをお礼申しあげます。

以下の話は「ちょっと聞いてみた」のをまとめただけなので誤解や抜けがあるかもしれません。

似てるところ

見た目と論理の分離

ビューモデルに当たるところはUIControllerというクラス、ビューに当たるところはViewControllerというクラスがになっているようですね。WPFではライブラリを使わないとビューモデルにあたるクラスは自作しないといけませんが、iOSアプリの場合はコントローラー用のクラスが提供されているのですね。

データ変更の通知

データの変更通知はWPFではバインディング機構を使いますが、iOSアプリの場合はこれと雰囲気が似たものにKVO(Key Value Observing)というものがあります。何か登録しておくとで値に変更があったとき通知してくれる仕組みだそうです。
イベントドリブンに解決するときはUIApplicationDelegateというのを使うのだとか。インターフェースみたいですが、.NETだとRoutedEventかコマンドがそれにあたるところですね。これのほかにはアプリケーションに対してグローバルな通知を行う機構があるようですが、「これはなんでもできる最終手段」で、みだりに使うと開発者はもれなく死ぬらしいです。

ビューインスタンスの生死やパーツなど

ビューのインスタンスがすぐ死ぬ*1ところはWPFと大差ないようです。WPFの説明をしているときに「あー似てる」って言ってたのでたぶんそうです。
UserControlのように使いまわしたいパーツはUIViewというクラスを使って作るらしいとのこと。話を聞いている分には本当にプレゼンテーションしか作れないようで、コードビハインドに当たる部分はUIControllerに書くようです。うっかりしてるといつぞやの私のようにどんどん肥大化していくそうです。

そのほか

画面ひとつひとつにUIWindowというクラスのインスタンスができます。当たり前ですがこれはストアアプリに近い雰囲気のようですね。VisualStateのようなものがあるかは聞きませんでしたが、おそらくここにVisualStateManagerにあたるものはここで提供されているはずです。
エントリーポイントはUIApplicationというクラスにあるそうです。これはWPFだとApplicationクラスですね。

にてないところ

WPFのビューは専用のDSLであるXAMLを使って構築しますが、iOSアプリにはそんなものないようです。WYSIWYGエディターが充実しているんでしょうね…
またWPFで「ストーリーボード」といえばイベントやデータの変更をを検知して動作するアニメーションのことですが、iOSでは画面遷移のルートのことのようです。XCodeにはアドベンチャーゲームのシナリオ分岐をまとめたようなUIでストーリーボードを作れる画面があるようす。

示してもらった資料

iOS アプリの構造がどのようになっているか紐解いてみる - A Day In The Life
「iOS アプリ 構造」でググると最初のほうに出てくるページです。

突然ふっかけたにもかかわらずちゃんと説明してくれたプロマネさんがすごい。

*1:見えると生れてきて、見えなくなったら死にます