iOSユーザーインターフェイス:Storyboards vs.NIBs vs.Custom Code

iOS開発者が同じ重要な質問のいくつかの変種を尋ねるのをよく聞きます:

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

この質問に対する答えは、明示的または暗黙的に、開発前に先行して対処されることが多い相互に排他的な選択があると仮定する傾向があります。

私は答えが代わりに一つ以上の反対の質問の形を取るべきだと意見しています。

“最高の”車は何ですか？

オフトピックの例で説明しましょう。 私は車を購入したいと言うと、私はあなたに一つの簡単な質問をします：”最良の選択は何ですか？”

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

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

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

iOS UIデザインに戻る

私たちの車のお問い合わせと同じように、”iOS UIを開発するための最良の方法は何ですか”という質問には文脈がありません。 そして驚くべきことに、答えはすべてのケースである必要はありません。

大まかに言えば、あなたが取ることができるユーザーインターフェイスの設計アプローチには、長所と短所、そのファンと嫌いを持つ三つのタイプがあ:

• iOS Storyboards:複数のアプリケーションビューとそれらの間の遷移をレイアウトするための視覚的なツール。
• NIBs(またはXIBs):各NIBファイルは単一のビュー要素に対応し、Interface Builderでレイアウトすることができ、視覚的なツールにもなります。 “NIB”という名前は、ファイル拡張子から派生していることに注意してください（以前。ペン先と今。xib、古い発音が持続しているが）。
• カスタムコード：つまり、GUIツールはありませんが、すべてのカスタム位置決め、アニメーションなどを処理します。 プログラム的に。

これらのオプションのどれも（あなたが聞くかもしれないものにもかかわらず）他のものよりも普遍的に優れていません。たとえば、

ストーリーボードは、iOS UI toolkitに追加された最新のものです。 私は彼らが未来だと言われました、彼らはNIBsとカスタムコードUiを置き換えるでしょう。 私はStoryboardsを便利なツールと見なしていますが、ペン先やカスタムコードを補完するものではありません。 ストーリーボードは、すべての状況ではありませんが、いくつかの適切な選択です。

さらに、（同じプロジェクトで）すべてを使用できるときに、単一のオプションに静的に固執し、特定の問題に最適なメカニズムを選択するのはなぜ

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

このiOS開発チュートリアルでは、これらの各メソッドを探索し、使用すべきユースケースと使用すべきでないユースケース、およびそれらをブレンドする方法を紹介します。

iOSストーリーボード

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

その名の通り、ストーリーボードは伝えるべき物語を持つボードです。 無関係な話を一つの大きなボリュームに混ぜるために使用すべきではありません。 ストーリーボードには、論理的に相互に関連するview controllerが含まれている必要があります。

たとえば、ストーリーボードを処理するときに使用するのが理にかなっています:

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

一方、単一のアプリ全体のストーリーボードを含む大規模なストーリーボードは避けるべきです（アプリが比較的単純でない限り）。 私たちは、任意の深く行く前に、理由を見てみましょう。

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

大規模なストーリーボードは、参照と保守が困難であることを除いて、チーム環境に複雑さの層を追加します。 また、ストーリーボードは内部的にテキストファイル（実際にはXMLファイル）として表現されますが、マージは通常は簡単ではありません。

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

のは、非常に簡単な例を見てみましょう: 2つの異なる開発者が（autolayoutを使用して）UILabelの位置を変更し、後者が変更をプッシュして次のような競合を生成するとします（競合するid属性に注意してく):

<layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides><layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides>

id自体は、その真の意義について何の兆候も提供していないので、あなたは何も作業することはありません。 唯一の意味のある解決策は、紛争の2つの側面の1つを選択し、もう1つを破棄することです。 副作用はありますか？ 誰が知ってる? お前じゃない

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

ストーリーボードを使用する場合

ストーリーボードは、view controller間の移行が主な簡素化であるため、複数の相互接続されたview controllerで使用するのが最適です。 ある程度、それらは、view controller間の視覚的および機能的なフローを持つペン先の構成と考えることができます。

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

最後に、ストーリーボードは複数のview controllerを含むシナリオに最適ですが、単一のテーブルビューコントローラで作業するときにストーリーボードを使用することも防:

• テーブルの細胞プロトタイプをその場で設計する機能は部分を一緒に保つのを助ける。
• 親テーブルビューコントローラ内で複数のセルテンプレートを設計できます。
• 静的テーブルビューを作成することは可能です（残念ながらストーリーボードでのみ利用可能な待望の追加）。

ペン先を使用して複数のセルテンプレートを設計することもできると主張することができます。 実際には、これは好みの問題です：一部の開発者はすべてを1つの場所に置くことを好みますが、他の開発者は気にしません。

iOSストーリーボードを使用しない場合

いくつかのケース:

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

このような場合、ビューをストーリーボードから外すか、view controllerに埋め込むことができます。 前者はストーリーボードの視覚的な流れを壊しますが、機能的または開発的に否定的な影響はありません。 後者はこの視覚的な流れを保持しますが、ビューはview controllerに統合されていないため、追加の開発努力が必要です。

一般的な長所と短所

ストーリーボードがiOS UI設計で有用なときの感覚があるので、このチュートリアルでNIBsに進む前に、一般的な長所と短所を見てみましょう。

Pro:Performance

直感的には、ストーリーボードがロードされると、そのすべてのview controllerがすぐにインスタンス化されると仮定できます。 幸いなことに、これは単なる抽象化であり、実際の実装には当てはまりません。 他のview controllerは、セグエが実行されるとき、またはコードから手動で動的にインスタンス化されます。

Pro:Prototypes

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

Con:再利用性

移動やコピーに関しては、iOSのストーリーボードの配置が不十分です。 ストーリーボードは、依存するすべてのview controllerと共に移動する必要があります。 つまり、単一のview controllerを個別に抽出して、単一の独立したエンティティとして他の場所で再利用することはできません。

Con:データフロー

アプリが移行するときに、多くの場合、view controller間でデータを渡す必要があります。 ただし、この場合、Interface Builderでこれが発生した痕跡がないため、Storyboardの視覚的な流れは壊れています。 ストーリーボードは、view controller間のフローを処理しますが、データのフローは処理しません。 そのため、宛先コントローラはコードで構成され、ビジュアルエクスペリエンスを上書きする必要があります。

このような場合、prepareForSegue:senderに依存する必要があり、if/else-ifスケルトンは次のようになります:

- (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = ; if ("segue_name_1"]) { MyViewController *vc = (MyViewController *) ; ; } else if ("segue_name_2"]) { ... } else if ...}

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

NIBs

NIBsは、iOSインターフェイス設計を実行する古い（er）方法です。

この場合、”古い”は”悪い”、”古い”、または”廃止予定”を意味しません。 実際、iOSストーリーボードはNibの普遍的な代替品ではなく、場合によってはUI実装を単純化するだけであることを理解することが重要です。

Nibを使用すると、任意のビューを設計でき、開発者は必要に応じてview controllerにアタッチできます。

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

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

iOS UIデザインにNIBsを使用する場合

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

• モーダルビュー
• シンプルなログインと登録ビュー
• 設定
• ポップアップウィンドウ
• 再利用可能なビューテンプレート
• 再利用可能な表セルテンプ2072>ペン先を使用しない場合

  あなたはペン先を使用しないようにする必要があります:

  • コンテンツに応じてレイアウトが大幅に変化する動的コンテンツを持つビュー。
  • Interface Builderでは本質的に簡単に設計できないと考えています。
  • ストーリーボードで単純化できる複雑な遷移を持つView controller。

  一般的な長所と短所

  より一般的には、ペン先を使用することの長所と短所を歩いてみましょう。

  Pro:再利用性

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

  単純なユースケースとして、ユーザー名とパスワードテキストフィールドを含むビューテンプレートを、仮想のTTLoginViewとTTSignupViewビューで実装することができます。 TTLoginViewはパスワードフィールドを非表示にする必要があり、両方とも対応する静的ラベル（’Enter your username’と’Enter your password’など）を指定する必要がありますが、ラベルは同じ基本機

  Pro&Con:Performance

  Nibは遅延ロードされるため、必要になるまでメモリを使用しません。 これは利点になる可能性がありますが、遅延読み込みプロセスには遅延があり、欠点のようなものにもなっています。

  iOSカスタムコード(プログラムUi)

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

  ペン先やストーリーボードではできないことは、常にコードで実装することができます。

  おそらくもっと重要なのは、ペン先やストーリーボードではできないことは、技術的に実現可能であることを、もちろん、コード提供で常に実装することがで それを見るもう一つの方法は、NIBsとStoryboardsがコードで実装されているため、その機能は自然にサブセットになるということです。 のは、長所と短所にまっすぐにジャンプしてみましょう。

  Pro:Under the Hood

  プログラムでiOS UIを作成する最大の利点:ユーザーインターフェイスをコーディングする方法を知っていれば、内部で何が起こるかを知っていますが、NIBsとStoryboardsでも同じことが必ずしも当てはまるわけではありません。

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

  これはiOSに限定されるものではなく、visual RADツール（例：Visual StudioやDelphiなど）に限定されます。 視覚的なHTML RAD環境は、典型的な境界線のケースを表しています：HTMLの知識が必要ではなく、すべてが視覚的に行うことができると主張して、コードを生成するために使用されます（しばしば不十分に書かれています）。 彼らは、生のHTMLとCSSを手動で処理することで、よりモジュール化された、より効率的なコードにつながることを知っています。

  だから、iOSのユーザーインターフェイスのコーディングを習得することで、これらの部分がどのように適合するかをより詳細に制御し、認識することができ、開発者としての上限を上げることができます。

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

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

  プロ: マージの競合

  NIBsとStoryboardsはマージの競合によって大幅に苦しんでいましたが、コードには同じ障害はありません。 すべてのコードは意味的な意味を持っているので、競合を解決することは通常よりも難しくありません。

  Con:Prototyping

  あなたが実際にそれを見るまで、レイアウトがどのように見えるかを把握するのは難しいです。 さらに、ビューやコントロールを視覚的に配置することはできないため、レイアウトスペックを有形のビューに変換するには、レンダリング方法をすぐにプレ

  コン: リファクタリング

  ずっと前に、または他の誰かによって書かれたコードをリファクタリングすることもはるかに複雑になります。

  Pro:Performance

  パフォーマンスの面では、ストーリーボードとペン先はロードと解析のオーバーヘッドの対象となり、最終的には間接的にコードに変換されます。 言うまでもなく、これはコード作成のUiでは起こりません。

  プロ: 再利用可能性

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

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

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

  • NIBファイルとStoryboardファイルを複製します。 その後、彼らは別々の生活を持ち、元のファイルとは関係がありません。
  • は見た目と動作をコードで上書きします。 コードによる重いオーバーライドは、視覚的なデザインを役に立たないようにし、頭痛の種に進化することもあります。、特定のコントロールがInterface Builderで一方通行で表示されますが、アプリの実行時には完全に異なるように見えます。

  コードを使用する場合

  あなたが持っているとき、それは多くの場合、iOSのユーザーインターフェイス設計のためのカスタムコードを使用するための良い呼び:

  • 動的レイアウト。
  • 角丸、影などのエフェクトを使用したビュー。
  • ペン先やストーリーボードを使用することが複雑または実行不可能な場合。

  コードを使用しない場合

  一般に、コード作成のUiは常に使用できます。 彼らはめったに悪い考えではないので、私はここに置くだろう。

  NIBsとStoryboardsはテーブルにいくつかの利点をもたらしますが、コードの使用を阻止するためにリストに入れる合理的な欠点はないと感じています（おそらく怠惰

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

  ストーリーボード、NIBs、およびコードは、iOSユーザーインターフェイスを構築するための三つの異なるツールです。 私たちはそれらを持って幸運です。 コードを使用すると、技術的に可能なすべてのことを行うことができますが、代替案には制限があります。 そこにいる他の開発者にとって、Xcode army knifeは、同じプロジェクトで一度に効果的に使用できる3つのツールを提供しています。

  どのように、あなたは尋ねますか？ しかし、あなたが好きです。 ここにいくつかの可能なアプローチがあります:

  • 関連するすべての画面を別々のグループにグループ化し、各グループを独自のストーリーボードで実装します。
  • テーブルビューコントローラ内のストーリーボードを使用して、再利用できないテーブルセルをその場で設計します。
  • 再利用を奨励し、繰り返しを避けるために、ペン先で再利用可能なテーブルセルを設計しますが、カスタムコードを使用してこれらのペン先をロードし
  • ペン先を使用して、カスタムビュー、コントロール、および中間オブジェクトを設計します。
  • 高度に動的なビューにはコードを使用し、より一般的には、ストーリーボードやニブを介して簡単に実装できないビューには、ビューの遷移をストーリーボードに収容します。

  閉じるには、それをすべて結びつける最後の例を見てみましょう。

  シンプルなユースケース

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

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

  さらに、ビューは次のように流れます:

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

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

  • 4つのview controller(リスト、詳細、メッセージのリスト、および新しいメッセージフォーム)を持つストーリーボード。
  • 再利用可能なプロファイルリストセルテンプレート用の別のNIBファイル。
  • プロファイル詳細ビュー用の三つの別々のNIBファイル、それを構成する別々のセクション（プロファイルの詳細、統計、最後の三つのメッセージ）ごとに一つ。 これらのNibはビューとしてインスタンス化され、view controllerに追加されます。
  • タグクラウドビューのカスタムコード。 このビューは、インターフェイスビルダーではストーリーボードやペン先を使用して設計できない典型的な例です。 代わりに、それは完全にコードを介して実装されています。 Storyboardのビジュアルフローを維持するために、空のview controllerをStoryboardに追加し、tag cloud viewをスタンドアロンビューとして実装し、view controllerにプログラムでビューを追加します。 明らかに、ビューはスタンドアロンビューとしてではなくビューコントローラ内に実装することもできますが、より良い再利用のために分離しておきます。

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

  そこで、UIデザインに対する三つの主要なアプローチを結びつけるコアビューを持つ合理的に洗練されたiOSアプリの基本的な構成を概説しました。 覚えておいてください：各ツールには長所と短所があるため、バイナリの決定はありません。

  ラップアップ

  このturtorialで調べたように、ストーリーボードはiOS UIデザインとビジュアルフローに顕著な簡素化を追加します。 それらはまた定型コードを除去する;しかしすべてこれは柔軟性で支払われる価格で来る。 一方、ペン先は、単一のビューに焦点を当てることによって、より多くの柔軟性を提供しますが、視覚的な流れはありません。 もちろん、最も柔軟な解決策はコードであり、これはむしろ非友好的で本質的に視覚的ではない傾向があります。

  この記事があなたに興味をそそられた場合、私は非常にレイWenderlichからの偉大な議論を見ることをお勧めします。

  最後に、私は一つのことを強調したい：すべてのコストで不適切なiOSのUIデザインツールを使用しないでください。 ビューがストーリーボードで設計できない場合、またはより簡単な方法でペン先またはコードで実装できる場合は、ストーリーボードを使用しないでください。 同様に、ビューがNibを使用して設計できない場合は、Nibを使用しないでください。 これらのルールは、シンプルながら、開発者としてのあなたの教育に長い道のりを行くでしょう。