よく聞く iOS開発者 同じ重要な質問のいくつかの変形を尋ねます：

iOSでUIを開発するための最良の方法は何ですか：ストーリーボード、NIB、またはコードを使用しますか？

この質問への回答は、明示的または暗黙的に、開発前に相互に排他的な選択が行われることを想定する傾向があります。これは、多くの場合、事前に対処されます。

私は、答えは代わりに1つ以上の形を取るべきだと思います カウンター 質問。

「最高の」車は何ですか？

トピック外の例で説明しましょう。車を購入したいとして、簡単な質問を1つします。「最良の選択は何ですか？」

モデルを提案することで本当に答えることができますか、 ブランド ？あなたがフェラーリを提案しない限り、ありそうもない。代わりに、次のような他のいくつかの質問で答えるでしょう。

• あなたの予算はいくらですか？
• 何席必要ですか？
• 燃費は気になりますか？
• スポーツカーについてどう思いますか？

のようなものがないことは明らかです 良い または 悪い 適切な状況に配置されていない限り、車です。特定のニーズに基づいて、良い車と悪い車があります。

iOSUIデザインに戻る

私たちの車の問い合わせと同じように、 「iOSUIを開発するための最良の方法は何ですか」 質問には文脈が欠けています。そして驚くべきことに、答えは万能の場合である必要はありません。

大まかに言えば、あなたが取ることができるユーザーインターフェースデザインアプローチには3つのタイプがあり、それぞれに長所と短所、ファンと嫌いがあります。

• iOSストーリーボード ：複数のアプリケーションビューとそれらの間の遷移をレイアウトするためのビジュアルツール。
• NIB（またはXIB） ：各NIBファイルは単一のビュー要素に対応し、Interface Builderでレイアウトできるため、ビジュアルツールにもなります。 「NIB」という名前はファイル拡張子に由来していることに注意してください（以前は.nibでしたが、現在は.xibですが、古い発音は残っています）。
• カスタムコード ：つまり、いいえ GUI ツールではなく、すべてのカスタムポジショニング、アニメーションなどをプログラムで処理します。

これらのオプションはどれも普遍的ではありません より良い 他のどれよりも（あなたが聞くかもしれないものにもかかわらず）。

デザインリズム定義の原則

ストーリーボード たとえば、iOSUIツールキットに追加された最新の製品です。それらは未来であり、NIBとカスタムコードUIに取って代わると言われています。ストーリーボードは便利なツールだと思いますが、それほどではありません。 置換 持っている 補体 NIBおよびカスタムコード用。ストーリーボードは、すべてではありませんが、一部の状況では正しい選択です。

さらに、（同じプロジェクトで）すべてを使用できるのに、目前の特定の問題に最適なメカニズムを選択して、静的に1つのオプションに固執する必要があるのはなぜですか？

これは、私の意見では、より高いレベルで一般化できる質問であり、その回答は、ソフトウェア開発の原則のリストで上位にランク付けされています。 すべてのソフトウェア開発の問題に対して普遍的な最良の選択である普遍的な言語、フレームワーク、またはテクノロジーはありません。 iOSUIデザインについても同じことが言えます。

このiOS開発チュートリアルでは、これらの各方法を検討し、それらが必要なユースケースとすべきユースケースを紹介します。 ない それらが一緒にブレンドされることができる方法と同様に、採用されます。

iOSストーリーボード

古典的な初心者の間違いは、プロジェクト全体で1つの大規模なiOSストーリーボードを作成することです。私もストーリーボードを使い始めたときにこの間違いを犯しました（おそらくそれは魅力的なルートだからです）。

古典的な初心者の間違いは、プロジェクト全体で1つの巨大なストーリーボードを作成することです。ストーリーボードは、ストーリーを伝えるボードです。無関係なストーリーを1つの大きなボリュームに混合するために使用するべきではありません。

その名前が示すように、ストーリーボードは 伝えるべきストーリーのあるボード 。無関係なストーリーを1つの大きなボリュームに混ぜるために使用するべきではありません。ストーリーボードには、論理的に相互に関連するビューコントローラが含まれている必要があります。これは、 すべて ビューコントローラー。

たとえば、以下を処理するときにストーリーボードを使用することは理にかなっています。

s-corpとc-corpの違い

• 認証と登録のための一連のビュー。
• マルチステップの注文入力フロー。
• ウィザードのような（つまり、チュートリアル）フロー。
• ビューのマスター/詳細セット（プロファイルリスト、プロファイル詳細など）。

一方、単一のアプリ全体のストーリーボードを含む大きなストーリーボードは避ける必要があります（アプリが比較的単純でない限り）。深く掘り下げる前に、その理由を見てみましょう。

大きなiOSストーリーボードの愚かさ

大規模なストーリーボードは、参照と保守が難しいことを除けば、チーム環境に複雑さの層を追加します。複数の開発者が同じストーリーボードファイルで同時に作業する場合、 ソース管理の競合は避けられません 。ストーリーボードは内部的にテキストファイル（実際にはXMLファイル）として表されますが、マージは通常簡単ではありません。

開発者がソースコードを見るとき、彼らはそれを意味的な意味に帰します。したがって、手動でマージする場合、競合の両側を読んで理解し、それに応じて行動することができます。代わりに、ストーリーボードはXcodeによって管理されるXMLファイルであり、コードの各行の意味は必ずしも理解しやすいとは限りません。

非常に簡単な例を見てみましょう。2人の異なる開発者がUILabelの位置を変更するとします。 （自動レイアウトを使用）、後者は彼の変更をプッシュし、次のような競合を生成します（競合するid属性に注意してください）：

id

allocそれ自体は、その真の意味については何も示していないので、何も扱う必要はありません。唯一の意味のある解決策は、対立の2つの側面の一方を選択し、もう一方を破棄することです。副作用はありますか？知るか？あなたではありません。

これらのiOSインターフェイス設計の問題を緩和するには、同じプロジェクトで複数のストーリーボードを使用することをお勧めします。

ストーリーボードを使用するタイミング

ストーリーボードは、相互接続された複数のView Controllerで使用するのが最適です。これは、ViewController間の移行が大幅に簡素化されるためです。ある程度、それらは、ビューコントローラ間の視覚的および機能的なフローを備えたNIBの構成と考えることができます。

ストーリーボードは、相互接続された複数のView Controllerで使用するのが最適です。これは、ViewController間の移行が大幅に簡素化されるためです。

ナビゲーションフローを容易にすることに加えて、別の明確な利点は、ビューコントローラをポップ、プッシュ、表示、および閉じるために必要な定型コードを排除することです。さらに、View Controllerは自動的に割り当てられるため、手動でinitする必要はありません。およびprepareForSegue:sender。

最後に、ストーリーボードは複数のView Controllerが関係するシナリオに最適ですが、ストーリーボードを使用して作業する場合も防御できます。 シングル 3つの理由によるテーブルビューコントローラー：

• テーブルセルのプロトタイプをインプレースで設計する機能は、ピースをまとめるのに役立ちます。
• 親テーブルビューコントローラ内で複数のセルテンプレートを設計できます。
• 静的なテーブルビューを作成することは可能です（残念ながら、ストーリーボードでのみ利用可能な待望の追加）。

NIBを使用して複数のセルテンプレートを設計することもできると主張する人もいるかもしれません。実際、これは好みの問題です。開発者の中には、すべてを1か所にまとめることを好む人もいれば、気にしない人もいます。

いつ ない iOSストーリーボードを使用するには

いくつかのケース：

• ビューは複雑または動的なレイアウトであり、コードで最適に実装されます。
• ビューはすでにNIBまたはコードで実装されています。

そのような場合は、ストーリーボードからビューを除外するか、ビューコントローラーに埋め込むことができます。前者はストーリーボードの視覚的な流れを壊しますが、機能や開発に悪影響を与えることはありません。後者はこの視覚的な流れを保持しますが、ビューはビューコントローラに統合されていないため、追加の開発作業が必要です。ビューはコンポーネントとして埋め込まれているだけなので、ビューコントローラはビ​​ューを実装するのではなく対話する必要があります。

一般的な長所と短所

これで、ストーリーボードがiOSでいつ役立つかがわかりました。 UIデザイン 、そしてこのチュートリアルでNIBに進む前に、NIBの一般的な長所と短所を見ていきましょう。

プロ：パフォーマンス

直感的には、ストーリーボードが読み込まれると、そのすべてのビューコントローラーがすぐにインスタンス化されると想定できます。幸いなことに、これは単なる抽象化であり、 ない 実際の実装に当てはまります。代わりに、最初のView Controller（存在する場合）のみが作成されます。他のViewControllerは、セグエが実行されるとき、またはコードから手動でインスタンス化されます。

プロ：プロトタイプ

ストーリーボードは、ユーザーインターフェイスのプロトタイピングとモックアップを簡素化します そして フロー。実際、ビューとナビゲーションを備えた完全に機能するプロトタイプアプリケーションは、ストーリーボードと数行のコードを使用して簡単に実装できます。

あり：再利用性

移動やコピーに関しては、iOSストーリーボードの位置が適切ではありません。ストーリーボードは、依存するすべてのビューコントローラーと一緒に移動する必要があります。つまり、単一のビューコントローラを個別に抽出して、単一の独立したエンティティとして他の場所で再利用することはできません。機能するのはストーリーボードの残りの部分に依存します。

あり：データフロー

多くの場合、アプリの移行時にViewController間でデータを渡す必要があります。ただし、この場合、Interface Builderで発生した痕跡がないため、ストーリーボードの視覚的な流れは壊れています。ストーリーボードは、View Controller間のフローの処理を処理しますが、データのフローは処理しません。そのため、宛先コントローラーは、視覚的なエクスペリエンスをオーバーライドするコードで構成する必要があります。

ストーリーボードは、View Controller間のフローの処理を処理しますが、データのフローは処理しません。

このような場合、次のようなif / else-ifスケルトンを使用して- (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = [segue identifier]; if ([identifier [email protected] 'segue_name_1']) { MyViewController *vc = (MyViewController *) [segue destinationViewController]; [vc setData:myData]; } else if ([identifier [email protected] 'segue_name_2']) { ... } else if ... } に依存する必要があります。

TTLoginView

このアプローチはエラーが発生しやすく、不必要に冗長であることがわかりました。

NIB

NIBは、iOSインターフェイスデザインを実行するための古い（より）方法です。

この場合、「古い」は「悪い」、「時代遅れ」、「非推奨」を意味するものではありません。実際、iOSストーリーボードはNIBの普遍的な代替品ではないことを理解することが重要です。でUIの実装を簡素化するだけです いくつか ケース。

NIBを使用すると、任意のビューを設計でき、開発者は必要に応じてビューコントローラーに接続できます。

オブジェクト指向設計をUIに適用する場合、ViewControllerのビューをに分割することは理にかなっています 個別のモジュール 、それぞれが独自のNIBファイル（または同じファイルにグループ化された複数のモジュール）を持つビューとして実装されます。このアプローチの明らかな利点は、各コンポーネントの開発、テスト、およびデバッグが容易なことです。

NIBは、ストーリーボードで見たマージの競合の問題を共有しますが、NIBファイルは小規模で動作するため、程度は低くなります。

iOSUIデザインにNIBを使用する場合

すべてのユースケースのサブセットは次のようになります。

初心者向けのangularjsサンプルデモ

• モーダルビュー
• シンプルなログインおよび登録ビュー
• 設定
• ポップアップウィンドウ
• 再利用可能なビューテンプレート
• 再利用可能なテーブルセルテンプレート

その間…

いつ ない NIBを使用するには

次の目的でNIBを使用することは避けてください。

• 動的コンテンツを含むビュー。コンテンツに応じてレイアウトが大幅に変更されます。
• 本質的にInterfaceBuilderで簡単に設計できないビュー。
• ストーリーボーディングで簡略化できる複雑なトランジションを持つビューコントローラー。

一般的な長所と短所

より一般的には、NIBを使用することの長所と短所を見ていきましょう。

製品に課せられる一般的な制約は何ですか

プロ：再利用性

NIBは、同じレイアウトが複数のクラスで共有されている場合に便利です。

単純な使用例として、ユーザー名とパスワードのテキストフィールドを含むビューテンプレートを仮想のTTSignupViewで実装できます。およびTTLoginViewビュー。どちらも同じNIBから発生する可能性があります。

パスワードフィールドを非表示にする必要があり、両方で対応する静的ラベル（「ユーザー名を入力」と「パスワードを入力」など）を指定する必要がありますが、ラベルの基本機能は同じで、レイアウトも同様です。

長所と短所：パフォーマンス

NIBは 怠惰にロード 、したがって、必要になるまでメモリを使用しません。これは利点になる可能性がありますが、遅延読み込みプロセスには待ち時間があり、欠点もあります。

iOSカスタムコード（プログラムUI）

どれか iOSインターフェースデザイン これはストーリーボードで実行でき、NIBは生のコードで実装することもできます（もちろん、開発者がそのような豊富なツールセットの贅沢を持っていなかった時代がありました）。

NIBやストーリーボードでは実行できないことは、常にコードで実装できます。

おそらくもっと重要なことは、NIBやストーリーボードでは実行できないことは、技術的に実現可能であれば、常にコードで実装できることです。別の見方をすれば、NIBとストーリーボードはコードで実装されているため、それらの機能は当然サブセットになります。長所と短所に直接飛び込みましょう。

プロ：フードの下で

プログラムでiOSUIを作成する最大の利点： ユーザーインターフェイスのコーディング方法を知っている場合は、内部で何が起こるかを知っています 、一方、同じことがNIBとストーリーボードに必ずしも当てはまるわけではありません。

比較するには：電卓は便利なツールです。しかし、手動で計算を実行する方法を知っていることは悪いことではありません。

これはiOSに限定されるものではなく、あらゆるビジュアルRADツール（たとえば、Visual StudioやDelphiなど）に限定されます。ビジュアルHTMLRAD環境は、典型的な境界のケースを表しています。これらは、HTMLの知識は不要であり、すべてを視覚的に実行できると主張して、（多くの場合、記述が不十分な）コードを生成するために使用されます。しかし、Web開発者は、手を汚さずにWebページを実装することはできません。生のHTMLとCSSを手動で処理すると、よりモジュール化された、より効率的なコードにつながることを知っています。

そのため、iOSユーザーインターフェイスのコーディングをマスターすることで、これらの要素がどのように組み合わされるかをより細かく制御し、認識を深めることができます。これにより、開発者としての上限が引き上げられます。

プロ：コードが唯一のオプションである場合

カスタムiOSコードがUIデザインの唯一のオプションである場合もあります。ビュー要素が移動し、フローまたはレイアウトがコンテンツに基づいて大幅に調整される動的レイアウトが典型的な例です。

プロ：競合のマージ

NIBとストーリーボードはマージの競合に大きく悩まされていましたが、コードに同じ欠点はありません。すべてのコードには意味的な意味があるため、競合の解決は通常よりも難しくありません。

と：プロトタイピング

実際の動作を確認するまで、レイアウトがどのように見えるかを理解するのは困難です。さらに、ビューとコントロールを視覚的に配置できないため、レイアウト仕様を具体的なビューに変換するのに、物事がどのようにレンダリングされるかを即座にプレビューできるNIBやストーリーボードと比較してはるかに時間がかかる可能性があります。

あり：リファクタリング

ずっと前に、または他の誰かによって書かれたコードのリファクタリングもはるかに複雑になります。要素がカスタムメソッドと魔法数で配置およびアニメーション化されると、デバッグセッションが困難になる可能性があります。

プロ：パフォーマンス

パフォーマンスの観点から、ストーリーボードとNIBは、ロードと解析のオーバーヘッドの影響を受けます。そして最終的に、それらは間接的にコードに変換されます。言うまでもなく、これはコードで作成されたUIでは発生しません。

プロ：再利用性

プログラムで実装されたビューは、再利用可能な方法で設計できます。いくつかのユースケースを見てみましょう。

• 2つ以上のビューは共通の動作を共有しますが、わずかに異なります。基本クラスと2つのサブクラスが問題をエレガントに解決します。
• 単一のコードベースを作成することを目的として、プロジェクトをフォークする必要がありますが、それぞれが特定のカスタマイズを備えた2つ（またはそれ以上）の異なるアプリケーションを生成します。

同じUI設計プロセスは、NIBとストーリーボードでははるかに複雑になります。テンプレートファイルでは継承が許可されておらず、考えられる解決策は次のとおりです。

• NIBファイルとストーリーボードファイルを複製します。その後、彼らは別々の生活をし、元のファイルとは関係がありません。
• 外観と動作をコードでオーバーライドします。これは単純な場合には機能する可能性がありますが、他の場合には重大な問題を引き起こす可能性があります。コードを大幅にオーバーライドすると、ビジュアルデザインが役に立たなくなり、常に頭痛の種になる可能性があります。たとえば、特定のコントロールがInterface Builderで一方向に表示されても、アプリの実行中はまったく異なって見える場合などです。

コードを使用する場合

次のような場合は、iOSユーザーインターフェースの設計にカスタムコードを使用することをお勧めします。

• 動的レイアウト。
• 角の丸み、影などの効果のあるビュー。
• NIBとストーリーボードの使用が複雑または実行不可能な場合。

いつ ない コードを使用するには

一般に、コードで作成されたUIは 常に 利用される。悪い考えになることはめったにないので、ここに置きます。

NIBとストーリーボードはテーブルにいくつかの利点をもたらしますが、コードの使用を思いとどまらせるためにリストに入れることには合理的な欠点はないと思います（おそらく怠惰を除いて）。

1つのプロジェクト、複数のツール

ストーリーボード、NIB、およびコードは、iOSユーザーインターフェイスを構築するための3つの異なるツールです。それらを持っていることは幸運です。プログラマティックUIの狂信者は、おそらく他の2つのオプションを考慮に入れていません。コードを使用すると、技術的に可能なすべてのことを実行できますが、代替手段には制限があります。そこにいる残りの開発者のために、Xcodeアーミーナイフは同じプロジェクトで同時に効果的に使用できる3つのツールを提供します。

emberjsチュートリアルステップバイステップ

どのように、あなたは尋ねますか？あなたの好きなように。考えられるアプローチは次のとおりです。

• 関連するすべての画面を個別のグループにグループ化し、各グループに独自のストーリーボードを実装します。
• テーブルビューコントローラ内のストーリーボードを使用して、再利用できないテーブルセルをインプレースで設計します。
• 再利用を促進し、繰り返しを避けるために、NIBで再利用可能なテーブルセルを設計しますが、カスタムコードを介してこれらのNIBをロードします。
• NIBを使用して、カスタムビュー、コントロール、および中間オブジェクトを設計します。
• 非常に動的なビュー、より一般的にはストーリーボードとNIBを介して簡単に実装できないビューにコードを使用し、ストーリーボードにビューの遷移を格納します。

最後に、すべてを結び付ける最後の例を見てみましょう。

簡単なユースケース

いくつかの異なるビューを持つ基本的なメッセージングアプリを開発したいとします。

• フォローしている友達のリスト（将来のリスト全体でUIの一貫性を保つための再利用可能なセルテンプレートを使用）。
• 個別のセクション（プロファイル情報、統計、およびツールバーを含む）で構成されるプロファイル詳細ビュー。
• 友人との間で送受信されるメッセージのリスト。
• 新しいメッセージフォーム。
• ユーザーメッセージで使用されているさまざまなタグを表示するタグクラウドビュー。各タグのサイズは、使用された回数に比例します。

さらに、ビューが次のように流れるようにします。

• フォローしている友達のリストのアイテムをクリックすると、関連する友達のプロフィールの詳細が表示されます。
• プロファイルの詳細には、プロファイル名、アドレス、統計、最新のメッセージの短いリスト、およびツールバーが表示されます。

このiOSアプリを実装するには、次の3つのUIツールすべてが便利です。

• 4つのViewController（リスト、詳細、メッセージのリスト、および新しいメッセージフォーム）を備えたストーリーボード。
• 再利用可能なプロファイルリストセルテンプレート用の個別のNIBファイル。
• プロファイル詳細ビュー用の3つの個別のNIBファイル（プロファイル詳細、統計、最後の3つのメッセージ）を構成する個別のセクションごとに1つ、保守性を向上させます。これらのNIBはビューとしてインスタンス化され、ビューコントローラに追加されます。
• タグクラウドビューのカスタムコード。このビューは、StoryBoardsでもNIBでも、InterfaceBuilderで設計できない典型的な例です。代わりに、コードによって完全に実装されます。ストーリーボードの視覚的な流れを維持するために、ストーリーボードに空のビューコントローラを追加し、タグクラウドビューをスタンドアロンビューとして実装し、プログラムでビューをビューコントローラに追加することを選択します。明らかに、ビューはスタンドアロンビューとしてではなく、View Controller内に実装することもできますが、再利用しやすいように分離したままにしています。

本当に基本的なモックアップは次のようになります。

それで、合理的にの基本的な構造を概説しました 洗練されたiOSアプリ そのコアビューは、私たちの3つの主要なアプローチを結び付けています UIデザイン 。各ツールには長所と短所があるため、二者択一の決定はありません。

まとめ

このタートリアルで調べたように、ストーリーボードは目立った単純化を追加します ios UIデザインとビジュアルフロー。また、定型コードを排除します。しかし、これはすべて、柔軟性のある代償を伴います。一方、NIBは、単一のビューに焦点を当てることで柔軟性を高めますが、視覚的な流れはありません。もちろん、最も柔軟な解決策はコードです。これは、やや不親切で本質的に非視覚的である傾向があります。

この記事に興味をそそられた場合は、視聴することを強くお勧めします 大論争 Ray Wenderlichから、55分間、NIB、ストーリーボード、およびコードで作成されたUISのディスカッションに費やされました。

最後に、1つのことを強調したいと思います。 不適切なiOSUIデザインツールの使用は絶対に避けてください 。ビューがストーリーボードで設計できない場合、またはビューをNIBまたはコードでより簡単な方法で実装できる場合は、 しないでください ストーリーボードを使用します。同様に、ビューがNIBを使用して設計できない場合は、NIBを使用しないでください。これらのルールは単純ですが、開発者としての教育に大いに役立ちます。