私はこれについて議論をしてきましたが、ある種のコンポーネントをビューではなく UIViewController にする正当な理由は何ですか? Navigation View Controllerなどを使用している場合を除いて、画面ごとに1つのView Controllerを想定しています
2 に答える
UIViewController
本格的なView Controllerが必要な場合は、クラスを作成します。UIView
親ビュー(View Controllerのビューなど)に追加されるある種の「ウィジェット」を作成するときに、を作成します。
ビューコントローラーは「画面」と考えてください。このView Controllerは画面全体を表します。メイン ビューには、多くのサブビューを追加できます。コントローラーは、データへのアクセス、ビューからのイベントの調整、ビューへのデータの提供を担当します。
ボタンはビューです。テーブルはビューです。画像はビューです。しかし、View Controller はこれらすべてのビューを結合し、すべてを接続します。
あなたの質問は、MVC パターンと、コントローラーとビューのパーツを分離する方法に非常に関連しています。1 つの画面に 1 つのビュー コントローラーを使用することは一般的に理にかなっています。以前は Apple のガイドラインで提案されていたことを覚えていますが、現在は変更されていますが、ほとんどの場合は引き続き機能します。
iOS ビュー ライブラリは非常に包括的であり、通常はカスタム ビューを作成する必要はなく、代わりにカスタム ビュー コントローラーを作成する必要があります。MVC パターンに従うアプリでは、viewcontroller はビューとデータ (モデル) の両方と対話する仲介者であるため、ビューをモデルに直接接続しないでください。これにより、その機能が大幅に制限されます。このように考えて、一般的な ios ビュー ライブラリを見てください。複雑なロジック (計算の実行、他のビューやオブジェクトとの対話) を含める必要がない場合、新しいクラスは uibutton、uiswitch、uitableview などの他のコントロールと共に存在する必要がありますが、ユーザーの操作をコントローラーに通知するだけで十分です。
カスタム ビューの典型的な使用法は、uiview の構成 (つまり、多くの Web ページのコンテンツ スライダー、imdb のムービー ページの 10 個の評価星) が必要で、別の表現が必要な場合 (つまり、円グラフや改善されたプログレス バーなどでいくつかのデータを表す) です。しかし、それ以外の場合は、ほとんどの場合、カスタム ビューコントローラーを使用します。