この本を見ながら進めてる↓
前回⇒「【Swift奮闘記ep29】iOSアプリ開発入門（SDKとフレームワーク、iOSアプリの動作の仕組み）」
UIとは（簡単に言えば）ユーザー操作に対する動作の仕組みの事（と考えてよいと思う）。
前後半にわけてiOSアプリのUIの仕組みについて詳しく見ていこう。
iOSアプリの画面表示
iOSデバイスのディスプレイにiOSアプリの画面を表示させる処理は、UIKitフレームワーク（忘れた人は参照⇒「【Swift奮闘記ep29】iOSアプリ開発入門（SDKとフレームワーク、iOSアプリの動作の仕組み）」）の中の以下のクラスが主に行っている。
- UIScreen: iOSデバイスの物理的なディスプレイを表すクラス
- UIWindow: UIScreenに対して描画する機能を提供するクラス
- UIView: コンテンツを実際に描画するクラス
UIScreenに画面サイズや明るさや彩度の情報（データ）が保管されている。そのUIScreenに何を映し出すかまとめた場所がUIWindowである。
UIWindowに配置する要素はUIView（のサブクラス）で、実際に画面に表示されているのはUIViewクラスを継承したもの（ボタンやラベル等色んなパーツ）である。
UIViewやUIViewのサブクラスのことをビュー呼ぶ。
イメージはこんな感じだと思う。
さらにUIViewは入れ子にすることができる。（入れ子ってのは入れ物みたいなもんでパソコンで言うフォルダみたいなもん。）その入れ子のことをコンテナと呼ぶ。
つまり
こんな風にUIViewは入れ子になっているのがわかる。
ビューコントローラを使った画面構成と画面遷移
上で紹介した３つのクラス以外にも画面構成するUIViewControllerというクラスがある。
これは例えば「一覧画面」や「詳細画面」や「設定画面」といった具合にいくつかの画面を管理したり構成したりするための機能である。
ビューコントローラは原則１つのビューをもっている。つまりそのビューは入れ子になっていて幾つかのビューが入っている。
さらにUIViewControllerとUIWindowを連携させることによってビューコントローラが持っているビューがUIWindowに配置される。
それからUIScreenへ描写→画面表示、という流れである。
ひとつのUIWindowに対して連携させるUIViewControllerは１つ。
その代わり違うビューコントローラに取り換えることができる。その際に「一覧画面」→「詳細画面」へと変わるという仕組みだ。
これを画面遷移（トランジション）という。
またビューコントローラに関する一連の流れを管理する機能も持つ。
「画面を読み込み」→「画面を表示」→「画面から消える」→「破棄される」
この流れをライフサイクルの管理という。
画面の状況の変化を検知できるため、その変化によって任意の処理をすることができる。
ユーザーの操作イベント
「タッチ」「スライド」「シェイク」などスマホに対してユーザーが行う行為をイベントという。
そのイベントを受け取る（検知する）クラスが存在する。
それがUIResponderというクラス。
この中に「タッチされた」等のイベントを受け取るメソッドが書いてある。
さらにUIView、UIWindow、UIViewController、UIApplicationクラスはUIResponderクラスを継承しているため、ユーザー操作を受け取ることが可能。
ユーザー操作が行われてから処理されるまでの大きな流れは以下。
① iOSアプリの心臓部のUIApplicationインスタンスがまずユーザー操作を受け取る。
② 次にUIWindowインスタンスへイベントの発生を伝える。
③ するとUIWindowに設置されているビューに伝えられる。おそらく「このイベントに対する処理はあなたがやりなさい！」みたいな感じで。（追記：ビューに伝えられるのは「こんなイベントが起こりましたよ」っていくことだけ。）
④ で処理が実行される。（追記：イベントに対してビューが返答するって事。）
というのが大まかな流れ。
UIViewのサブクラスを使っているのであれば、そのクラスの中にどんな処理かを定義することができる。
このようにiOSではユーザー操作を検知した時にどういう処理を行うかを定義していくことで、ユーザーがアプリを操作することが可能になっているのだ。
コントロールとアクション
「イベント」が何か行われた時にそれを受け取るのがUIViewで、具体的に言うとUIButton、UISwitch、UITextFieldといったものがある。
これらを事を「コントロール」という。
例えばUIButtonは「タップ」というイベントを受け取って、何らかの処理をするのだが、「タップ」っていうのは「画面を触ってから離すまでの事」である。その一連の動作を「アクション」という。
コントロールは「イベント」を受け取ったらSelectorというインスタンス（セレクタともいう）を使って「ターゲット」を呼び出す。
その「ターゲット」に何らかの処理がかかれていて実行される、という流れだ。
通常「ターゲット」はUIViewControllerであることがほとんどだ。
なにやら循環しているようにも思えるが、とりあえずUIViewControllerは最強という事はわかった。
アクションから指示までを図示してみた。
わかりやすい図だ。（俺的には）
疑問が１つ残るが、それはいつか分かる事だろう。
イベントに応じて何らかの処理を行う事が出来るクラスが用意されています。たとえばボタンを表すUIButton、ON/OFFのスイッチを表すUISwitch、入力欄を表すUITextFieldなどと言ったクラスです。
とあるが、たとえばタップされたらそのイベントをUIButtonに伝えるってことでいいのかな？「タップされたよ、タップ担当はUIButton君だ。はい、働いて。セレクタ君を使ってターゲットを呼んで来い！」
っていう事でいいのだろうか。
⇒多分いい。ちょっと前の説明部分に以下のように書いてあるから。
UIApplicationインスタンスからイベント発生を伝えられたUIWindowインスタンスは、そのイベントがどのビューに対するものなのか判断し、対象のビューに対して伝えます。こうして、ビューはあるイベントが発生したら何を行うか反応できるようになります。
UIWindowが仕事を振り分けてくれてるって事だね。でコントロール（ここでいうビュー）に伝わってやっとビューが働きだす、と。
もうちょっと仕組みについて語るよ～…
続き⇒「【Swift奮闘記ep31】iOSアプリのUIの仕組み～後半～（Storyboad、AutoLayout、PlaygroundとiOSアプリ開発の違い）」
コメント