Interface Builder を使用してビューを設計する場合、パフォーマンス、開発上の欠点または利点はありますか?
6 に答える
多くの場合、Interface Builder を使用する必要があります。プログラム インターフェイスでこれを行う理由はいくつかあります。
- これは、コードを使用するだけでは簡単に達成できない単純さと視覚的な利点があるため、ユーザー インターフェイスを作成する方法としてより受け入れられています。
- これは、iPhone アプリケーション全体で一貫性と使いやすさを維持するために、Apple が開発者に推奨するマーカーなどを使用して、アプリケーションがiPhone ヒューマン インターフェイス ガイドラインに準拠するのに役立ちます。
それにもかかわらず、Interface Builder を使用するよりもプログラム インターフェイスの方が有利な場合がある主な理由は、n
UIImageView
Interface Builder で複製できない変数に基づいて、複数回作成する必要があるインターフェイス要素 (たとえば、s の作成) のためです。プログラム インターフェイスは、この柔軟性を可能にし、通常、この場合より効率的です。
NIB/XIB もメモリを消費することに注意してください。すべてのインターフェイスがメインの NIB ファイルに配置されている場合、アプリケーションによるメモリ使用量が増加するだけでなく (とにかくすぐに必要とされないリソースのために)、増加します。ロード時間。ただし、この問題の通常の回避策は、プログラム インターフェイスを使用するのではなく、インターフェイス要素のさまざまなグループをさまざまな NIB ファイルに配置し、すぐに必要なインターフェイスをメインの NIB ファイルに配置して、アプリケーションの起動時に読み込まれるようにすることです。 、および必要に応じてロードされる他の NIB ファイル内のインターフェイス要素の他のグループ。
つまり、Interface Builder で簡単に処理できない可変量の要素を作成する必要がある場合を除いて、Interface Builder を使用するのが一般的な方法です。
欠点の 1 つは、コンセントやアクションの配線を見落としやすく、トラブルシューティングが面倒なことです。2 つの良い点は、UI 要素の配置、整列、および固定がはるかに簡単であり、電話が回転すると要素が再描画されることです (これは、プログラム要素を使用して自分で処理する必要があるアニメーション プロセスです)。
私自身のことを言えば、iPhone 向けの開発方法を学ぼうとしていたとき、Interface Builder はひどく鈍感であることがわかりました。あなたが使用するはずのワークフローは、まだあまり意味がありません。インターフェイス ビルダーは、ハンド コーディングよりも細かいインターフェイス レイアウトのほうが高速です。
UIViewControllers でプログラムによって GUI を生成することの欠点は、MVC パターンでビューとコントローラーの違いがぼやけてしまうことです。GUI の生成を loadView メソッドに留めることができれば、情報を生成するコードと情報を表示するコードの間に適切な境界を維持することができます。
要するに、私は UIViewController サブクラスで loadView をオーバーライドして GUI を生成することを好みます。
なぜ誰も翻訳について言及しなかったのですか。私たちは 11 のロケールでプロジェクトを持っています - これは nib*(#locales) の数を与えます - それは受け入れられません (10 UI のプロジェクトで 100 以上の nib)。
ツールを使用してNIBのコード生成を見ないでください。しかし、アップルのメモを見てください。
注: nib ファイルを使用せずに Objective-C アプリケーションを作成することはできますが、作成することは非常にまれであり、推奨されません。アプリケーションによっては、nib ファイルの使用を回避するには、大量のフレームワークの動作をオーバーライドして、nib ファイルを使用した場合と同じ結果を得る必要があります。