1

私がこれをするとき、私は気づきました：

[myParser setDelegate:self];

それは動作します：D（ヘッダーファイルにコードを追加しなかったとしても...ご存知のとおり、

<delegateStuff, delegateOtherStuff>

インターフェイス宣言で）

デリゲートを機能させるためにヘッダーファイルを変更するのはいつですか？setDelegateメソッドはそれを機能させるのに十分ですか？

助けてくれてありがとう;）

ゴーティエ

4

4 に答える 4

1

つまり、<NSXMLParserDelegate>インターフェイス宣言は必須ではなく、コンパイル時のエラーチェックのためにあります。setDelegate:デリゲートメッセージを受信する場合は、メソッドを呼び出す必要があります。

参照するの<delegateStuff>はプロトコル宣言です。Objective-CのプロトコルはJavaのインターフェイスのようなものです。クラスが応答するメッセージ（メソッド）のリストを定義します。ただし、Javaとは異なり、Objective-Cは動的に型指定されます。つまり、任意のメッセージを任意のオブジェクトに送信でき、実行時に応答するかどうかのみを確認できます。

これの結果は、のようなメソッドsetDelegate:が型のパラメータを要求する場合、idそれに任意のオブジェクトを与えることができるということです。NSXMLParserのコードは、メッセージを送信する前に、特定のメッセージに応答できるかどうかを確認できます。そうすれば、必要なデリゲートメソッドを実装できます。（Javaにはより厳密な型チェックがあるため、すべてのメソッドが必要かどうかに関係なく、すべてのメソッドをインターフェースに実装する必要があります。）

setDelegate:代わりに型に対して動作する場合id <NSXMLParserDelegate>は、NSXMLParserDelegateプロトコルを実装するオブジェクトが必要であると言っています。ただし、これはコンパイル時にのみチェックされ、エラーをキャッチするのに役立ちます。タイプキャストを使用する場合は、そこに任意のオブジェクトを送信でき、必要なメッセージに応答する限り、プログラムは正常に実行されます。（繰り返しになりますが、Javaでは、型キャストを使用してコンパイルできますが、オブジェクトが同じタイプであっても、オブジェクトが正しい型でない場合、型キャスト自体が例外をスローします。）

ちなみに、NSXMLParserをサブクラス化していますか？self（私はあなたがに渡すのでそう思いますsetDelegate:。それはそれが使われることを意図された方法ではありません！ Cocoaフレームワークは通常サブクラスよりデリゲートを好みます。あなたのデリゲートクラスはNSObject（またはあなたが望むなら何か他のもの）を拡張する別のクラスでなければなりません。

于 2010-02-20T17:14:56.157 に答える
1

必要に応じて、コンパイラは警告とともに通知します。

ヘッダーファイルにを追加すると、Xcodeは使用する可能性のあるすべてのデリゲートメソッドをオートコンプリートできることに気付きました。私はこの理由だけで毎回それをします。

于 2010-02-20T16:32:52.280 に答える
1

コンパイラは、iPhoneSDK4.0で欠落している場合に警告するようになりました

于 2010-05-31T04:08:31.567 に答える
0

「デリゲート」は、実行時に呼び出されるセレクターを実装している限り、常に機能します。一致するデリゲートプロトコルを宣言する必要はありませんが、デリゲートが単なる「id」以外に入力された場合（たとえば、id [SomeDelegateProtocol]デリゲート）、コンパイラの警告が表示される場合があります。

ただし...クラスが特定のプロトコルの仕様を満たしていることを宣言する場合は、（a）そのプロトコルが存在する必要があり、（b）クラスでプロトコルセレクターがチェックされます。現在iPhoneSDK4に含まれているNSXMLParserDelegateにより、古いアプリは警告をスローします。プロトコルを追加してから3.xに逆コンパイルしようとすると、プロトコルが4より前に存在しないため、コンパイルエラーが発生します（少なくとも、そのプロトコルを含むフレームワークが含まれている可能性は低いです）。現在のアプリを3から4に移行し始めているときに、これに遭遇しました。簡単に削除できない警告が嫌いです。

于 2010-06-18T06:26:54.483 に答える