プラグインを使用してカスタム ビューを Interface Builder に統合することを推奨するのはいつですか? Apple のInterface Builder Plug-In Programming Guideにざっと目を通してみると、次のことがわかりました。
- カスタム オブジェクトは 1 つのアプリケーションだけで使用されますか?
- カスタム オブジェクトは、アプリケーションだけにある状態情報に依存していますか?
- カスタム ビューをスタンドアロンのライブラリまたはフレームワークにカプセル化することは問題になりますか?
上記の質問のいずれかに「はい」と答えた場合、オブジェクトはプラグインの候補として適していない可能性があります。
それは私の質問のいくつかに答えますが、それが良い考えである場合についてのあなたの考えをまだ知りたいです. どのような利点があり、時間の投資はどれくらいですか?
アプリケーションが使用するビュークラスとコントローラークラスを、アプリケーションラッパーに埋め込まれた別のフレームワークにプッシュすることは完全に合理的です。このフレームワーク用に、InterfaceBuilderプラグインも作成します。
-awakeFromNib他の理由の中でも、アプリケーションで一般的に使用されるクラスは、散在する実装ではなく、InterfaceBuilderでの使用時に構成できます。これは、InterfaceBuilderで設定できるバインディングをオブジェクトに公開させる唯一の方法でもあります。
少しコーディングしますが、複数の場所で使用され、実際に使用する前に追加のセットアップが必要なビュークラスとコントローラークラスの場合、全体としてかなりの時間を節約できる可能性があります。また、独自のコントローラーとビュークラスを使用して開発した経験は、Cocoaを使用して開発したようなものになります。
Appleのガイドラインはそれをうまくまとめていると思います。
複数のアプリケーションで使用され、完全に汎用的なコントロールを作成している場合は、カスタムオブジェクトを作成することをお勧めします。外観を視覚化し、InterfaceBuilderから直接プロパティを設定できるようになります。
コントロールが1つのアプリケーションに制限されている場合、またはデータと緊密に結合されている場合は、それをカスタムオブジェクトに移動しても、実際にはそれほど多くは購入できません。
カスタムビューを作成することは難しくありません。そこには、わかりやすいガイドがたくさんあります。