4

私は iOS 開発のことを学んでおり、チュートリアルや本で見つけたのは、通常、コントローラー層がビューのコントロール (テキストフィールド、ラベルなど) に直接アクセスできることです。そのような例を考えてみましょう:

View に というラベルlblResultと というテキストフィールドがあるとしtxtDataToAnalyzeます。コントローラー インターフェイスよりも、次のようなものがあります。

@property (nonatomic, retain) IBOutlet UILabel* lblResult;
@property (nonatomic, retain) IBOutlet UITextField* txtDataToAnalyze;

および@synthesize実装ファイル内のいくつかのステートメント。

私はJavaSwing開発の経験があり、GUIビルダーなしで手動で書いているとほとんどの人が考えています.MVCで通常行うことは、ゲッター/セッターを介してビューのコントロールにアクセスすることです. 例:void setResult(String resString);またはString getDataToAnalyze();. このように、コントローラーはビューに表示される情報のみを認識し、どのように表示されるかは認識しません。より柔軟だと思います（後でビューレイヤーを変更する方が簡単です）。

iOSにはいくつかの特定のルールがあり、XIB / NIBファイルなどが導入されていることを知っているので、iPhone / iPadの開発の場合、私の疑問はまったく役に立たないかもしれません. しかし、私は iOS 用のより本格的なアプリケーションを作成する予定です (実際には、Java Swing から「書き直します」)。

私の考え方を変えて、その新しい (私にとって) アプローチ (xib ファイル、ドラッグ & ドロップを使用して GUI を作成し、データをビューに表示する方法に関する情報をコントローラーに提供する) に慣れるべきだと思いますか?? iOS を始めたとき、同じような疑問を持ったことはありませんか?

4

2 に答える 2

4

簡潔な答え：

はい、Interface Builder (IB) を使用して NIB とストーリーボードを作成することに慣れるのに少し時間を費やすべきだと思います。IB は、対話する必要があるコントロールのIBOutletと参照を作成します。IBAction熟練すれば、容易に保守できるコードを生成する生産性に感心するでしょう。IB をすぐに却下しないでください。

コントローラーがIBOutletおよびIBAction参照と直接対話できるようにするという点では、これは単純なユーザー インターフェイスの一般的な方法です。実際の例がいくつかある場合は、画面のスナップショットを含む新しい質問を投稿してください。より実用的なガイダンスを提供できます。

長い答え:

  1. あなたの質問の一部は、ビューのコントロールと詳細なやり取りをしているビュー コントローラーを見ることへの不安によって引き起こされているようです。問題は、コントローラーをビューの実装の詳細の一部から分離したい場合は、先に進んでビューをサブクラス化し、そこにビュー固有のものを配置することです。IB は、ビュー コントローラーのサブクラスとビューのサブクラスの両方とやり取りできます。そのため、IB を問題なく使用しながら、View Controller をこれらの実装の詳細から切り離すことができます。

    個人的には、ビューが主観的な複雑さのしきい値に達した場合にのみ、このサブクラス化をUIView行います (たとえば、私にとって、そのしきい値は、CADisplayLink複雑なジェスチャ認識などを使用するなど、複雑なアニメーションを実行していることに気付いたときです)。また、独自の論理エンティティーであるサブビュー (UITableViewCellまたは などUICollectionViewCell) もサブクラス化します。しかし、モデルを操作してコントロールのプロパティを設定したり、テキスト フィールドを操作したりする単純なビューの場合は、それをビュー コントローラーに配置しても問題ないと思います。そうは言っても、モデルとビューの統合とは関係のないビュー固有のコードがコントローラーにたくさんある場合は、 のサブクラス化を開始UIViewし、ビューのみのコードをそれにシフトします。

  2. あなたの質問に暗示されているのは、NIB/ストーリーボードを使用するのではなく、プログラムでビューを構築するという概念です。私の意見では、Interface Builder (IB) を使用して UI を構築すると、開発と保守がはるかに簡単になります。ビューをプログラムで構築するテスト プロジェクトを行うことには教育的価値があるかもしれません。そのため、何が起こっているのかを本当に理解できますが、その後、ストーリーボードにすぐに引き寄せられることに気付くと思います。また、標準の IB コントロールの機能を超えること (例: 複雑なカスタム コンテナー ビューなど) を開始すると、独自の非 IB コードを作成する機会がたくさんあります。ビューをプログラムで開発することを好む人は確かにいますが、IB で生成された UI の開発速度とメンテナンスの容易さに勝るものはないと思います。

于 2013-03-16T18:19:51.180 に答える
1

私は一般的に、コントローラーはビューについて知りませんが、ビューはコントローラーについて知っています。

ギャング・オブ・フォー・ブックは次のように述べています。

「MVC を使用すると、視覚的な表現を変更することなく、ビューがユーザー入力に応答する方法を変更することもできます。たとえば、キーボードへの応答方法を変更したり、コマンド キーの代わりにポップアップ メニューを使用したりすることができます。 MVC encapsulates the response mechanism in a Controller object. コントローラーのクラス階層があるため、既存のコントローラーのバリエーションとして新しいコントローラーを簡単に作成できます。

ビューは Controller サブクラスのインスタンスを使用して、特定の応答戦略を実装します。別の戦略を実装するには、インスタンスを別の種類のコントローラーに置き換えるだけです。実行時にビューのコントローラーを変更して、ビューがユーザー入力に応答する方法を変更することもできます。たとえば、入力イベントを無視するコントローラーを指定するだけで、ビューを無効にして入力を受け付けないようにすることができます。

View-Controller 関係は、Strategy (315) デザイン パターンの例です。ストラテジーは、アルゴリズムを表すオブジェクトです。アルゴリズムを静的または動的に置き換えたい場合、アルゴリズムのバリエーションが多い場合、またはアルゴリズムにカプセル化したい複雑なデータ構造がある場合に役立ちます。」

于 2013-03-16T17:19:40.153 に答える