2

私はObjective-C、Cocoa、Xcode、InterfaceBuilderを初めて使用します。私は過去にCのバックグラウンドを持っており、RealBASICの経験もかなりあります。

私はMarkとLaMarcheのiPhone3Devの本を読んでいますが、退屈なものがあることに本当に驚いています。多分誰かが私のためにこれにいくつかの光を当てることができます。私の質問は、一見単純なアクションのプロセスに、なぜこのような複雑な数のステップが含まれるのかということです。後で好きになる複雑さにはメリットがありますか？それとも、避けられないのは単なる野蛮な事実ですか？

たとえば、RealBASICで、スライダーの値をテキストボックスに表示したい場合は、次を追加するだけです。

myTextBox.text = mySlider.value

スライダーのChangedイベントに移動します。これは1分足らずでプログラムできます。

Xcode / Interface Builderでは、テキストボックスとスライダーの両方の宣言を物理的に入力してから、それぞれのプロパティ/アウトレット宣言も入力し、ValueChangedのメソッド宣言と実装を作成してから、 （比較的）initWithFormatを使用したスライダーの整数値のNSStringへの複雑な型キャスト。次に、Interface Builderに戻って、入力したコントロールとメソッドのアウトレットにコントロールをリンクする必要があります。これを10分以内に実行する方法がわかりません。多分5。

それで、これの利点は何ですか？Interface Builderが、メソッド宣言と実装だけでなく、コントロール宣言と@propertyステートメントを自動的に作成しない、または少なくとも提案しないのはなぜですか？IBのスライダーをダブルクリックすると、イベントのリストが表示され、.hファイルと.mファイルにスケルトンメソッドが自動的に挿入されるのはなぜですか？そして、なぜIBは別のアプリケーションである必要があるのでしょうか。

私はこれのいくつかがXcodeのすべてに不慣れであるということを受け入れたいと思っていますが、これは開発環境と同じくらい効率的ですか？

これが完全なアグロで反対側の死んだ馬、炎の餌のトピックであるならば、私の謝罪。もしそうなら、「はい、そうです」と言って先に進んでください。

ありがとう、-Rob

4

2 に答える 2

3

MVCパラダイムに慣れるにつれて、IBの動作の背後にある多くの理由がより明確になります。

UIが変更されたときにモデルを更新するCocoaBindingsの使用を開始すると、生産性が大幅に向上するはずです。

于 2009-08-29T07:20:47.090 に答える
1

私も、Xcode と Interface Builder は不必要に複雑だと思っていましたが、両方に関する本 (具体的には、iPhone 開発の開始: iPhone SDK の探索) を読むまではそうでした。

Xcode と Interface Builder の使用に真剣に取り組んでいて、私が始めたときと同じように混乱している場合は、私が使用したような本を手に取ることを強くお勧めします。確かに、これは iPhone の開発に関するものでしたが、同じ出版社 (または著者) による、ストレートな Mac プログラミングに関する別の本があると思います。

作業を進めて、舞台裏で何が起こっているのかを理解すると、より理にかなったものになり始めます。いくつかの点で、.NET での WPF プログラミングには、Expression Blend や XAML などよりも IB を好みます。

本を試してみて、それが役立つかどうかを確認してください:-) 頑張ってください!

于 2009-08-28T20:56:56.140 に答える