ios - UIPopoverControllerがUIViewControllerサブクラスではないのはなぜですか？

Question

AppleがUIPopoverControllerをプレーンなNSObjectサブクラスとして実装することを選択した特定の理由を考えられますか？私にとって、UIViewControllerサブクラスは、適切なUIViewController包含を実装するためにはるかに理にかなっています。

しかし、おそらく私が考えていなかった理由があります。なぜAppleの優秀なエンジニアが彼らの選択をしたのでしょうか。

Answer 1

UIAlertViewと同様に、新しいUIWindowに表示されるため、windowLevelプロパティにより、すべてのコンテンツに表示されることが保証されるためだと思います。

新しいUIWindowにあるかどうかに関係なく、View Controllerの包含に関する限り、UIPopoverControllerに存在するViewControllerで複雑な親子ViewControllerコンテナ階層を使用しても問題はありません。一部のポップオーバーについて、 Pillboxieに少なくとも3つのレベルのネストを備えたビューコントローラーがありますが、問題はありません。

更新：サンプルプロジェクトのビュー階層の最初の3つのレベルのクラスをログに記録して階層を確認しました。ポップオーバーが表示されている場合は、次のようになります（ルートビューコントローラーには2つのUIButtonがあります）。

ウィンドウ：

_SUBVIEWクラス：UIView

___サブサブビュークラス：UIRoundedRectButton

_ _SUBSUBSUBVIEW CLASS：UIButtonLabel

___サブサブビュークラス：UIRoundedRectButton

_ _SUBSUBSUBVIEW CLASS：UIButtonLabel

_SUBVIEWクラス：UIDimmingView

___サブサブビュークラス：_UIPopoverView

_ _SUBSUBSUBVIEWクラス：_UIPopoverStandardChromeView

_ _SUBSUBSUBVIEWクラス：UIView

Appleのドキュメントには、UIWindow内のルートビューコントローラのビューには、他のビューコントローラによって管理される兄弟ビューがあってはならないと記載されています。これらの兄弟ビューコントローラは回転イベントを受け取らないためです（ここの2番目の箇条書きを参照）。

したがって、AppleがUIPopoverControllerをUIViewControllerサブクラスにした場合、それをrootViewControllerの階層の子/サブビューとして追加する必要があります。しかし、ルートビューコントローラー（とにかくあなたのコード）がUIPopoverControllerのビューの階層に干渉するビューを提示することを決定した場合はどうなりますか？Appleは、それをまとめるのではなく、UIPopoverControllerのプレゼンテーションを完全に管理することを決定したようですが、UIWindowのno-sibling-view-controllersポリシーに例外を認める必要はありませんでした。

Answer 2

UIPopoverControllerオブジェクトはユーザーと対話しないため、これがビューレイヤーの一部ではなくUIViewController、ユーザーと通信でき、オブジェクトUIPopoverController内で同様のジョブを実行しない理由です。

コントローラの一般的な定義をざっと見てみましょう。

コントローラは、関連するビューにコマンドを送信して、モデルのビューの表示を変更できます（たとえば、ドキュメントをスクロールすることによって）。モデルにコマンドを送信して、モデルの状態を更新できます（ドキュメントの編集など）。

それがビューレイヤーの一部ではない理由を説明しています。お役に立てば幸いです。