9

iOS4をサポートする必要があったため、すべてxibファイルで開発してきました。

最終的に iOS5 と iOS6 のみをサポートするようになったので、ストーリーボードを試してみることにしました。すべて問題なく簡単ですが、次のような多くのコードを実行していることに気付きました。

-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {

    if ([segue.identifier isEqualToString:@"AddPlayer"]) { //Ugly

        UINavigationController * navigationController = segue.destinationViewController;
        PlayerDetailViewController * playerDetailsViewController = [navigationController viewControllers][0]; //Super Ugly
        playerDetailsViewController.delegate = self;
    }
}

皆さんのことはわかりませんが、このコードは非常に見苦しく、エラーが発生しやすいことがわかりました。

ストーリーボードを操作するためのより良い方法はありますか? xib ファイルに戻る必要がありますか?

4

3 に答える 3

6

私が働いている場所で作成した最後のアプリでは、ストーリーボードをかなり頻繁に使用していました。ええ、定型コードがしばらくするとかなり面倒になることに同意しますが、私が知る限り、prepareForSegueセグエを使用するときにパラメーターを渡す方法は使用することだけです。 ストーリーボード自体からカスタム ビュー コントローラーにプロパティ/デリゲートを割り当てることはできません。

  • iOS 5 および 6 のみを対象とする場合、XIB を使用することに戻りますか? 場合によります。

小規模から中規模のアプリ (ビューが多すぎず、それらの間のクロス ナビゲーションが少ない) を構築する必要がある場合は、間違いなくストーリーボードを使用します。しかし、たくさんのビューがあり、それらの間を行き来するナビゲーションがたくさんある場合、ストーリーボードをきれいに整頓しておくのは本当に複雑になり、実際には最善ではないものを使用することを余儀なくされているように感じます.

一方で、ストーリーボードを使用すると、ゼロから始めるときにアプリの流れや全体的な外観を簡単に感じることができ、それを使用して実際に本物のように見えるモックアップを作成することもできます.

したがって、本質的には、プロジェクトを開始するときに何が必要かということになります。

編集：

考慮すべきもう 1 つの点: チームで作業するために SVN/Git またはその他の VCS を使用している場合、ストーリーボード ファイルの競合は完全なビッチです。

于 2012-10-31T20:38:38.860 に答える
5

私はそれが醜いコードであることに同意し、私のビジョンをスムーズにするためにマクロを作成しました:

#define WhenSegueIdentifierDo(segueIdentifier, block) if([segue.identifier isEqualToString:segueIdentifier]) block();

そして私のprepareForSegueで：

WhenSegueIdentifierDo(kModalVC1ToVC2, ^
{
    //code
});

WhenSegueIdentifierDo(kModalVC1ToVC3, ^
{
    //code
});

また、ハードコーディングされた文字列の代わりに定数を使用して (ただし、ストーリーボードでは使用できません)、より美しく保ちます。k +トランジションの種類+元のビュー コントローラー名+ to +目的のビュー コントローラー名という規則も使用します。

使用することもできます

navigationController.topViewController

それ以外の

[navigationController viewControllers][0];

ちょうど私の2セント...

于 2013-08-01T19:53:01.157 に答える
2

それはまさに獣の性質です。Cocoa 規則を使用する Objective-C は、冗長なコードではありますが、(うまくいけば) 自己文書化されたコードを生成します。あなたの例を見ると、あなたの意図を判断するのに問題はありません。

見栄えを良くしたい場合は、これらすべてをマクロにカプセル化して、1 行に凝縮することができます。見栄えは良いかもしれませんが、獣を維持する上で不必要な複雑さが増すことは間違いありません。エンド ユーザーは、新しい機能の追加が妨げられない限り、コードがどれほどきれいであっても気にしません。

絵コンテについての議論については…それらは確かに異なりますが、6か月間使用してきたので、個々のファイルを探すのに時間を費やすのではなく、すべてのペン先を1か所にまとめてあることに感謝しています. 視覚的なレイアウトで物事を見つけてから、キャメルケースのファイル名を解析する方がはるかに簡単です。それは私だけです。

私のアドバイスは、彼らに時間を与えてください。数か月後にそれらがワークフローを妨げていることに気付いた場合は、必ず個々のペン先に戻ってください。彼らはどこにも行きません。少なくともしばらくの間。

ちょうど私の2セント。幸運を！

于 2012-10-31T20:33:27.657 に答える