iOSプログラミングでxibファイルの代わりにストーリーボードを使用する利点は何ですか？
主な違いストーリーボードとxibファイルの使用の違いは何ですか。
具体的には、ストーリーボードを使用することの利点または欠点は何ですか？
残念ながら、かなり多くの研究を行ったにもかかわらず、ストーリーボードで見つけることができたのは、ストーリーボードの具体的な情報ではなく、ストーリーボードの設定方法を示す簡単なチュートリアルだけです。
ストーリーボードは次のとおりです。
- すべてのシーンのコンテナ（View Controller、Nav Controller、TabBar Controllerなど）
- これらのシーン間の接続と遷移のマネージャー（これらはセグエと呼ばれます）
- 異なるコントローラーが互いにどのように通信するかを管理する良い方法
- ストーリーボードを使用すると、アプリケーションのフローを完全に確認できますが、個々のnibファイルからは決して流れません。
- それぞれが独自のnibファイルを持つ複数のコントローラーがある場合に発生するすべての「クラッター」のレデューサー。
私はしばらくの間、ストーリーボードを使用していますが、唯一の欠点は、iOS 4以下をターゲットにできないことです。ストーリーボードは、iOS 5以降を実行しているデバイスでのみ機能します。それ以外には、利点が多くあり、欠点は存在しないIMOです。
私が見た中で最高のチュートリアルは Ray Wenderlich's です
また、あなたがApple開発者プログラム、Storyboards（iTunesU）での昨年のWWDCセッションをチェックしてください、それは素晴らしいです。
もう1つの素晴らしいもの（iTunesUにもあります）は、最新のスタンフォードiOSアプリケーションプログラミングコースです。
ストーリーボードの長所だけでなく、短所もあります-入力を求めたからです：
- チーム内でSBを操作するのは簡単ではありません。1人の参加者しか一度にSBで作業できません（1つのファイルであるため）。
-以下は真実ではありません：-SBが提供していないことを行う必要がある場合、プログラムで作成されたビューとSBを混在させることは簡単ではありません（ただし、可能です）
経験則としては、プロジェクトが複雑になるほど、SBを使わない方が良いでしょう。
編集：-SBのもう1つの欠点：SBに関するXCodeの迷惑なバグをすべて回避します。例えば。いくつかの矛盾のため、DerivedDataフォルダーを頻繁にフラッシュする必要があります。ストーリーボードファイルまたはそれらへのリンクが破損する場合があります。次に、問題を検索する喜びがあるかもしれません。これを見てください アイデアを得るためのスレッド
EDIT 2（2013年3月）：一方、ストーリーボードとXcodeはより良く機能し、ドキュメントとベストプラクティスは広く普及しています。ストーリーボードでの作業は、まだいくつかの不具合があったとしても、大半のプロジェクトで推奨されると思います。
編集3（2013年9月）：SBを使用するチームで作業する新しいXcode 5形式では、 SBコードを簡単にマージできるようになりました
別の編集：まあ、時間があれば、座ってリラックスしてください このトピックについて議論しているこれらの人に聞いてください（Ray Wenderlich＆Co）
2016.1を編集します。長い間Storyboardの支持者でしたが、最後の数か月は非常に面倒だったので、できる限りStoryboardを放棄することにしました。その理由は、Appleは愚かなような機能を追加しますが、バグや欠陥は気にしません。多くの自動レイアウト制約を持つパフォーマンスは本当に悪いです（設計時）例：Xcodeでプロジェクトを開いた直後に、より複雑でないストーリーボードが「ダーティモード」になる傾向があります（git状態を参照）。すぐにプロトタイプを作成し、大量のコードなしで実行できるようになります。中間状態に入ると、プロジェクトにGUIコードが追加されます。今度は、コードとSBを行き来します。遅かれ早かれ、結果を複数のソースよりも予測しやすいため、ほとんどのGUIをコードで実行する傾向があります。
概要
Nibs/.xibファイルとStoryboardsはどちらも、XcodeでiOSおよびMacアプリケーションのユーザーインターフェイスを視覚的に作成するために使用されるInterface Builderファイルです（この質問にはiOSタグが付いていますが、Macプログラミングにも適用されるため、クラスにはiOS用語を使用します） 。
違い
ペン先は、単一のUIViewで使用することを目的としています。ファイルの所有者のクラスをUIViewControllerのサブクラスに設定し、ビューアウトレットを接続する（ドラッグして、右端のペインの[接続]インスペクターを使用して接続することにより、UIViewControllerサブクラスに接続することもできます。 Xcode）。
ストーリーボードは、1つ以上のUIViewControllerのユーザーインターフェイスを含むことを目的としています。ユーザーインターフェイス全体を1つのストーリーボードに構築するか、より小さなパーツに分割できます。
長所
ストーリーボードは、常に.xibファイル/ニブ（View Controller用）を優先して使用する必要があります。ストーリーボードにはより多くの機能があり、アップルによって積極的に開発されています。
ニブを支持するすべての議論は、ストーリーボードが多くのシーンを含んでいる間にそれらが個別に使用したという事実に依存しています。 UIViewControllerごとに1つのストーリーボードを使用できます。Nibsの場合と同じくらい簡単です（以下のコードサンプルを参照）。詳細な説明とコード例を読んでください。
詳細
Storboardsがニブより優れているのはなぜですか？
答えは基本的にApple Storyboardsの使用を奨励し、それらにより多くの開発努力を注ぐことです。
- ストーリーボードには、ニブにはないズーム機能があります。真剣に、あなたは小さなラップトップでより大きなスクリーンのために設計するとき、ひどくニブでズームすることができません。
- ペン先には次のような重要な機能がありません：
UITableViewのプロトタイプおよびダイナミックセル（ 詳細 ）- トップレイアウトガイド プロパティ（コメントを参照）
- おそらく他にもあります。このリストに追加するものがある場合は、編集またはコメントしてください
- ファイル所有者のクラスを設定することを台無しにする必要はありません。
ストーリーボードに対する基本的な議論は、すべてのView Controllerを1か所に置くと、マージの競合、遅いXcode、遅いビルド時間、そして維持するための一般的な苦痛になるということです。したがって、一般的なアドバイスは、UIViewControllerごとにペン先を使用することです。
しかし... UIViewControllerごとにストーリーボードを作成できます。一般的な方法（少なくとも私にとって）は、クラスメソッドですべてのUIViewController初期化を非表示にすることです（他のクラスはコントローラーのNib/Storyboardが配置されているファイルの名前を知る必要がないため）。このようなメソッドを作成するために使用する可能性のある関連コードスニペットを比較してみましょう。 1行のコードは、2つの間の完全な違いです。
Objective-C
ストーリーボード
+ (ViewController *)create
{
UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil];
return [storyboard instantiateInitialViewController];
}
ニブ
+ (ViewController *)create
{
return [super initWithNibName:@"ViewController" bundle:nil];
}
使用法
- (void)showMyViewController
{
ViewController *vc = [ViewController create];
[self presentViewController:vc animated:YES completion:nil];
}
Swift
ストーリーボード
static func create() -> ViewController {
let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle())
return storyboard.instantiateInitialViewController() as! ViewController
}
ニブ
static func create() -> ViewController {
return ViewController(nibName: "ViewController", bundle: nil)
}
使用法
func showMyViewController() {
let vc = ViewController.create()
self.presentViewController(vc, animated: true, completion: nil)
}
引数
Nibsのすべての通常の引数について説明します。先に述べたように、ストーリーボード上のニブの議論としてではなく、主に単一のファイルを支持しています
- チームとマージ
引数：多数のView Controllerを備えたストーリーボードがあると、複数の人が変更を加えているチームで作業している場合にマージの競合が発生します
応答：単一のストーリーボードは、単一のペン先ほどマージ競合を引き起こしません
- 複雑さ
引数：非常に複雑なアプリには、ストーリーボードに多くのシーンがあり、読み込みに永遠にかかる巨大なストーリーボードにつながり、そのサイズのためにほとんど理解できません。
応答：これは素晴らしい点ですが、ストーリーボードを簡単に小さなパーツに分割できます。 Storyboard References Storyboardをリンクするために使用できる優れた機能のように見えますが、Xcode 7/iOS 9以降でのみ使用できます。また、ストーリーボードよりも個々のペン先を選択する理由はまだありません。
- 再利用性
引数：UIViewControllerサブクラスごとにペン先を作成すると、コードを再利用できるため、ストーリーボードの各シーンにすべての制約とアウトレットを設定する必要がありません。
回答：繰り返しますが、個々のストーリーボードではなく個々のペン先を選択する理由ではありません。
数か月前のLiDG会議で ストーリーボードに関する素晴らしいプレゼンテーション が行われました。
個人的には、新しいアプリを使用する方法だと思います。特に非常に複雑なアプリの場合、いくつかのギャップがありますが、プロは主に短所を上回ります。
ストーリーボードのその他の利点：
- ストーリーボードは、Tableviewのサポートが向上しています。つまり、「動的」セルと「プロトタイプ」セルを使用できます。
- ストーリーボードを使用してView Controllerをインスタンス化する方が簡単です。次のようなことができます：[se lf.storyboard instantiateViewControllerWithIdentifer：]
- ストーリーボードはView Controllerコンテナをサポートしているため、子View Controllerをグラフィカルにレイアウトできます。
欠点は次のとおりです。
ストーリーボードに多くのView Controllerが含まれていると、XCodeでのレンダリングが遅くなります
ストーリーボードの1つのView Controllerで自動レイアウトを有効にすることはできません。
ストーリーボードを使用する場合、アプリには古いOSインストールとの下位互換性がないことに注意してください。
ストーリーボードは基本的に、開発者としての仕事を楽にするデバイスです。一連のnibファイルに準拠しているため、パフォーマンスはほぼ同等ですが、アプリケーションフロー全体の概要を簡単に確認できるのは開発者にとって素晴らしいことです。
私は、クライアントに最小バージョンとしてiOS 5を受け入れるよう説得することができれば、新しいプロジェクトでストーリーボードの使用に移行し始めています。これは純粋に私がこの方法で行うことを好むためであり、同じタスクを達成するのに時間がかかりません。
1秒で全体像が見えます。多くのNIBファイルがあるので、全体像は見えません。プログラムのメンテナンスが簡単になります。他のプログラムを理解するのが簡単です。
自動レイアウトに対する態度も、ストーリーボードを使用するかどうかに影響する場合があります。 xibを使用すると、自動レイアウトは.xib単位で有効または無効にでき、アプリケーション内での混合が可能になり、ストーリーボードは含まれるすべてのビューに選択を適用します。
ストーリーボードには、メリットよりも多くの問題があります。以下は、 iraycd からコピーした問題のリストです。
ストーリーボードはコンパイル時ではなく実行時に失敗します：セグエ名にタイプミスがあるか、ストーリーボードで間違って接続されていますか？実行時に爆発します。ストーリーボードにもう存在しないカスタムUIViewControllerサブクラスを使用しますか？実行時に爆発します。コードでそのようなことを行う場合、コンパイル時に早い段階でそれらをキャッチします。 Update ：私の新しいツールStoryboardLintは、ほとんどこの問題を解決します。
ストーリーボードはすぐに混乱します：プロジェクトが成長するにつれて、ストーリーボードのナビゲートがますます難しくなります。また、複数のView Controllerが他の複数のView Controllerに複数のセグエを持っている場合、ストーリーボードはすぐにボウルのスパゲッティのように見え始め、探しているView Controllerを見つけるために場所全体をズームインおよびズームアウトしてスクロールしますセグエがどこを指しているのかを見つけるために。 Update ：この問題は、 Pilkyによるこの記事 および this Robert Brownによる記事 。
ストーリーボードによりチームでの作業が難しくなります：通常、プロジェクトには1つの大きなストーリーボードファイルしかないため、複数の開発者がその1つのファイルに定期的に変更を加えるのは頭痛の種です。解決しました。競合が発生した場合、それを解決する方法を伝えるのは困難です。XcodeはストーリーボードXMLファイルを生成し、編集することはもちろん、人間が読む必要があることを念頭に置いて設計されていません。
ストーリーボードはコードレビューを困難またはほぼ不可能にします：チームでピアコードレビューを行うことは素晴らしいことです。ただし、ストーリーボードに変更を加えた場合、これらの変更を別の開発者で確認することはほとんど不可能です。プルアップできるのは、巨大なXMLファイルの差分だけです。実際に何が変更されたのか、それらの変更が正しいのか、それが何かを壊したのかを解読することは非常に困難です。
ストーリーボードはコードの再利用を妨げます：iOSプロジェクトでは、通常、アプリ全体で一貫したルックアンドフィールを提供するために使用するすべての色、フォント、マージン、インセットを含むクラスを作成します。アプリ全体でこれらの値のいずれかを調整する必要がある場合は、1行変更します。ストーリーボードでそのような値を設定した場合、それらを複製し、それらを変更する場合はすべての単一の出現を見つける必要があります。ストーリーボードには検索と置換がないため、見逃す可能性が高くなります。
ストーリーボードを使用すると、すべてを2回実行できます：iPadとiPhoneの両方で動作するユニバーサルアプリを構築していますか？ストーリーボードを使用する場合、通常、iPadバージョン用とiPhoneバージョン用に1つずつストーリーボードがあります。両方の同期を維持するには、2つの場所ですべてのUIまたはアプリワークフローの変更を行う必要があります。わーい。 Update ：iOS 8およびXcode 6では、iPhoneとiPadに単一のStoryboardを使用できます。
ストーリーボードには一定のコンテキストスイッチが必要：ストーリーボードよりもコードの方がはるかに速く動作し、ナビゲートしていることに気付きます。アプリでストーリーボードを使用するときは、常にコンテキストを切り替えます。「ああ、このTable Viewセルをタップして別のView Controllerをロードします。ストーリーボードを開いて、適切なView Controllerを見つけ、新しいセグエを作成する必要があります他のView Controller（私も見つけなければならない）に、セグエに名前を付け、その名前を覚えて（ストーリーボードで定数または変数を使用できない）、コードに切り替えて、名前を間違って入力しないことを願っています私のprepareForSegueメソッドのセグエ。この3行のコードをここに入力したいのです。」いいえ、面白くありません。コードとストーリーボード（およびキーボードとマウス）を切り替えると、古くなって速度が低下します。
ストーリーボードはリファクタリングが難しい：コードをリファクタリングするとき、ストーリーボードが期待するものと一致することを確認する必要があります。ストーリーボード内で物事を移動するとき、それがまだコードで機能するかどうかは実行時にのみわかります。 2つの世界の同期を維持する必要があるかのように感じます。それはもろく感じ、謙虚な意見では変化を思いとどまらせます。
ストーリーボードは検索不可：Xcodeでのプロジェクト全体の検索は、ストーリーボードを使用する場合、実際にはプロジェクト全体の検索ではありません。それらは検索に含まれません。そのため、コードからカスタムクラスを削除したり名前を変更したりする場合は、ストーリーボードを手動で確認するか、生のXMLを見て、コードの変更と同等であることを確認する必要があります。いいえ、私はそれが好きではありません。 Update ：ストーリーボードはXcode 6で検索可能です。
ストーリーボードの柔軟性は低い：コードでは、基本的には何でもできます！ストーリーボードを使用すると、コードでできることのサブセットに制限されます。特に、アニメーションやトランジションで高度なことをしたい場合は、「ストーリーボードと戦う」ことでそれを機能させることができます。
ストーリーボードでは、特別なView Controllerのタイプを変更できません：
UITableViewControllerをUICollectionViewControllerに変更しますか？またはプレーンUIViewControllerに？ストーリーボードでは不可能です。古いView Controllerを削除し、新しいView Controllerを作成して、すべてのセグエを再接続する必要があります。このようなコードの変更を行う方がはるかに簡単です。ストーリーボードはプロジェクトに2つの追加の負債を追加します：（1）ストーリーボードXMLを生成するストーリーボードエディターツール、および（2）XMLを解析し、そこからUIおよびコントローラーオブジェクトを作成するランタイムコンポーネント。両方の部分に、修正できないバグがある可能性があります。
ストーリーボードでは、
UIImageViewにサブビューを追加できません：理由は誰にわかりますか。ストーリーボードでは、個々のビューの自動レイアウトを有効にできません（-Controller）：ストーリーボードの自動レイアウトオプションをオン/オフにすることで、ストーリーボードのすべてのコントローラーに変更が適用されます。 （この点についてはSavaMazăreに感謝します！）
ストーリーボードは後方互換性を損なうリスクが高い：Xcodeはストーリーボードのファイル形式を変更することがあり、数年または今日作成したストーリーボードファイルを開くことができることを保証しません。今から数ヶ月。 （この点についてはthoughtadvancesに感謝します。 元のコメントを参照 ）
それはマクドナルドだ：スティーブ・ジョブズのマイクロソフトについての言葉で言うと： マクドナルドだ（ビデオ） ！
利点：
1）インターフェイスを設計することは非常に素晴らしい
2）StoryBoard Seguesを使用して、ナビゲーション/モーダル関係をクールな方法で識別できます。
3）アプリが複数のデバイスをサポートしている場合、異なるビューを整理するのに良い方法です。
4）プロトタイピングももう1つの利点です。
5）プロトタイプUITableViewCellは時間を節約でき、コードの量も減らします。
6）StoryBoardを使用して、アプリのすべての画面を1か所で見ることができます。
7）それらの間の関係を簡単に見ることができます
8）誰かのコードに取り組んでいる場合、アプリのフローをよりよく理解できます。
9）アプリを何度も実行することなく、ストーリーボードから網膜フォームファクターを適用することにより、iPhone 4およびiPhone 5のユーザーインターフェイスを設定できます。
10）クライアントは、開発を開始する前にアプリのプロトタイプを見ることができます。ここでは、ストーリーボードが役立ちます。
欠点：
1）iOS 5以降でのみ利用可能
2）StoryBoardSeguesは一種の厳格であり、prepareForSegueを何度も使用できます。
4）IBのように、他のディスプレイエンジンやツールキットにはあまり馴染みがありません。
4）1つのビューまたは一連のビューのデザインを共有するのが難しくなります。すべて送信するか、何も送信しないでください。
5）ストーリーボードには、iPadの場合に特別に大画面が必要です。
6）他のアプリからストーリーボードにビューをコピーする際の難しさ。
7）複数の開発者がgitリポジトリを使用して同じプロジェクトで作業する場合のストーリーボードの問題
いくつかのリソースからコピー
IOS 7より前は、ストーリーボードはきちんとしたものでしたが、必須ではありませんでした。彼らは解決した問題をいくつも導入しました。 iOS 7は、バランスをストーリーボードに傾けました。
iOS 8および9では、これはもう問題ではありません：ストーリーボードを使用してください！
ストーリーボードの主な欠点は、XCodeに完全に依存していることであり、XCodeのバグに時間を費やすことになります。しかし、XCodeはずっと良くなっており、ストーリーボードの利点は無視できないほど多くなっています。テーブルビューセルプロトタイプ、サイズクラス、自動レイアウトサポートなど。
いくつかのヒント：
- 各ストーリーボードは、一緒に属するView Controllerのコンテナと考えてください。アプリケーション全体の壮大なレイアウトと考えないでください。
- 複数のストーリーボードが必要な場合があります
- セグエは実際には最も些細な使用例にのみ有用です-それらはそのために素晴らしいです。しかし、実際のアプリでは、コード内から多くの移行が発生します。そしてそれは大丈夫です。
- ストーリーボードからView Controllerをプログラムでインスタンス化するためのカテゴリを作成します）。