12

従来の .xib 戦略の代わりにストーリーボードを使用することは、私がまだ取り組んでいるものです。なぜなら、それが何をしているのか、そして私が実際にどのような制御を行っているのかを本当に理解せずに、隠れて多くのことを行うものを採用することにいくらかの躊躇があるからです。負け。

BNR iOS Programming Book では、ストーリーボードの使用に関するいくつかの「短所」が強調されています。以下にそれらをリストしましたが、私の質問は次のとおり です。これらのネガは iOS 6 でも有効ですか?

  1. ストーリーボードはチームで作業するのが難しい
  2. ストーリーボードがバージョン管理を台無しにする
  3. ストーリーボードはプログラミングの流れを混乱させる
  4. ストーリーボードは、使いやすさのために柔軟性と制御を犠牲にします
  5. ストーリーボードは常に新しいView Controllerインスタンスを作成します

私は、実際に構築し、できれば実際の iOS アプリケーションをデプロイし、「ストーリーボードと .xib」のこと自体に苦労している人々からの回答を探しています。

ありがとう

4

2 に答える 2

11

私は、iOS 6 がこれらの状況を修正するとは思わない。さらに言えば、xcode 4.5 はそれらを修正したり、修正しようとさえしません。リストされている問題は、意見や文体の好みを反映しているようで、おそらくいくつかの誤った情報です. これらは、コードで修正できるようなものではありません。

私はかなりのアプリにストーリーボードを使用していますが、これは本当に生産性の向上に役立ちます。同意しない場合は、試してみることをお勧めします。

問題リストに関するいくつかのコメント:

  1. 私はチームと SB に関する問題を認識していませんが、もし 2 が本当なら (そうではありません)、それはこの懸念を説明するでしょう. 2に基づく誤解だと思います。
  2. 違います。私は Git を熱心に使用しており、頻繁にコミットしています。問題ありません。コミット中、SB はソース コード形式 (XML) で表示されます。差分は完全に機能し、実際に SB がどのように実装されているかについての洞察を提供します。これにより、親しみやすさの問題ではない、不思議な「隠れた」行動の感覚が軽減されます。
  3. 同意しない。彼らは流れを乱すのではなく、異なる流れを提供します - それは彼らが力を得る場所です. 多くのプログラマーは、MVC 規律によって課される分離に価値を見出しています。SB は、UI 要素の配置とサポート コードの分離を導入します。これは自然な分割であり、大量の意味のないコードを排除します (これにより、タイプミスの可能性が排除され、残っている REAL コードが「整頓されます」)。
  4. 部分的に同意します - それらは間違いなく使いやすさを向上させます. しかし、私はまったく犠牲を見つけません。SB を使用している場合でも、必要に応じていつでも任意のオブジェクトをハンド コーディングに戻すことができます。柔軟性やコントロールを犠牲にすることはありません。
  5. これが何を意味するのか、なぜそれが問題になるのかはわかりません。もちろん、シーンごとに異なる VC を作成します。それは当然のことです。しかし、SB で VC クラスを再利用することは確かに可能です。この項目は、SB オブジェクトのクラスの設定方法に関する誤解である可能性があります。このステップを忘れがちで、初心者を困惑させることがあります。しかし、修正するのは簡単で、クラスを設定することはすぐに習慣になります。

私にとっての本当の懸念は次のとおりです。

  1. SB を使用すると、開発のために多くの画面領域が必要になります。小さなディスプレイで SB を使用すると、イライラすることがあります。
  2. 多くのシーンを含む非常に複雑な UI は、複数の SB に分割する必要があります。複数の SB は完全にサポートされていますが、失敗するのは簡単です。(これは、大きくなりすぎたメソッドをリファクタリングするようなものです。通常、何かが既に乱雑になった後で、コードを屈折させる必要があることに気付きます。)

レイアウト中の SB の利便性と、VC オブジェクトを乱雑にする多くの定型コードの排除は、大きな利点です。(私が削除するすべてのコード行は、私が台無しにできない行であり、残っている実際のコードを覆い隠すことができない行です。)

要するに、SBなしでの生活に戻ることは想像できません。はい、変更です。しかし、私は本当の深刻な欠点を見つけていません。SB を使用している場合でも、SB 以外のすべてのコーディング手法が機能することを覚えておくことが特に重要です。SB を試してみて、あなた自身の経験を報告してください。幸運を！

于 2012-09-29T13:25:06.250 に答える
7

私は一般的にjbbenniに同意します。私があなたの指摘で見た唯一の「有効な」批判は、「ストーリーボードは常に新しいインスタンスを作成する」ということでした。基本的に、これは、ボタンを接続してスタック上のビュー コントローラーをプッシュすることはできますが、追加のコードなしではボタンを接続してスタックをポップバックすることはできないことを意味していました。これは、Xcode 4.5 で「exit segues」を使用して解決されました。これにより、新しいインスタンスを作成するのではなく、前のコントローラーにポップ バックすることを示すことができます。

多くの人が訴えたストーリーボードのもう 1 つの制限は、ストーリーボード自体に子ビュー コントローラーを埋め込むことができないことでした。これは、Xcode 4.5 でも対処されています。

ストーリーボードは、iOS 開発にとって重要な前進です。「マージが難しくなる」などの苦情には根拠がありません。ストーリーボードは、他のコードよりもマージが難しくありません。「Obj-C ではない; 読めない」などと言い訳するのではなく、時間をかけて実際に diff を読む必要があります。

導入以来、私はストーリーボードをチーム設定でうまく使用してきました。知らない人に怖がらせないでください。彼らは素晴らしいです。

于 2012-09-29T14:46:52.840 に答える