quand utiliser respondsToSelector en objective-c

- (void)someMethod
{
    if ( [delegate respondsToSelector:@selector(operationShouldProceed)] )
    {
        if ( [delegate operationShouldProceed] )
        {
            //do something appropriate
        }
    }
}

La la documentation dit:

La précaution est nécessaire uniquement pour les méthodes optionnelles dans un protocole formel ou méthodes informelles de ce protocole

Ça veut dire quoi? Si j'utilise un protocole officiel je peux utiliser [delegate myMethod]?

InformationsquelleAutor Taho | 2010-09-12

ios objective-c

82

Vous utilisez de manière assez juste quand vous pensez que vous avez besoin de: pour vérifier si un objet implémente la méthode que vous êtes sur le point d'appel. Généralement cela est fait quand vous avez une option de méthodes ou de façon plus informelle du protocole.

Je n'ai jamais utilisé respondsToSelector quand je suis en train d'écrire du code qui doit communiquer avec un délégué de l'objet.
```
if ([self.delegate respondsToSelector:@selector(engineDidStartRunning:)]) {
        [self.delegate engineDidStartRunning:self];
    }
```
Parfois, vous pouvez l'utiliser respondsToSelector sur une méthode qui retourne et id ou générique NSObject où vous n'êtes pas sûr de ce que la classe de l'objet retourné est.
- merci. Je comprends maintenant. J'ai remarqué que vous utilisez.déléguer, ce qui est une propriété. Je viens d'utiliser une variable d'instance: id délégué. quelle est la différence? Im apprendre objective-c. merci encore
- self.delegate est exactement le même que l'appel à la [self delegate]. Dans mon code il n'y a pas de différence entre [self.delegate someMethod] et [_delegate someMethod], mais j'ai tendance à utiliser la syntaxe à point, car il garde tout droit dans mon esprit, les variables sont locales à la méthode que je suis, et qui sont variables d'instance.
- Si vous êtes juste de commencer, il sera utile de votre temps pour lire Apple guide de l'Obj-C. developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/...
- encore une question: dois-je créer délégué = nil dans le dealloc et viewDidUnload méthode?(du délégué de la classe ou de la classe qui implémente le délégué ou aucun des deux?)
- Pas de. Délégué propriétés doivent presque toujours être assigné au lieu de la conserver. Dans la grande majorité des exemples, vous n'avez pas le délégué de l'objet, de sorte que vous ne devriez pas le garder ou de le libérer. stackoverflow.com/questions/918698/...
- C'est fondamentalement syntatic sucre, mais quand j'ai une très régulier ensemble de délégué méthodes que j'utilise, un pré-processeur de macro peut vraiment rendre le code plus lisible. Par exemple: #define NOTIFY_OPTIONAL(sel, id) si ([id respondsToSelector:@selector(sel)]) {[id sel soi];} Ensuite dans mon code: NOTIFY_OPTIONAL(playStarted:, _focusPlayer);
- Je suis à l'aide d'un délégué de la même manière: si ([self.délégué respondsToSelector:@selector(engineDidStartRunning:)]) { [self.délégué engineDidStartRunning:self]; } Mais il a encore parfois du me donne une erreur de Mauvaises Excès.
InformationsquelleAutor kubi
45

Juste à ajouter à ce que @kubi a dit, l'autre fois que je l'utilise, c'est quand une méthode a été ajouté à une pré-existants de la classe dans une version plus récente des cadres, mais j'ai encore besoin d'être rétro-compatible. Par exemple:
```
if ([myObject respondsToSelector:@selector(doAwesomeNewThing)]) {
  [myObject doAwesomeNewThing];
} else {
  [self doOldWorkaroundHackWithObject:myObject];
}
```
InformationsquelleAutor Dave DeLong
13

Comme kubi mentionné respondsToSelector est généralement utilisé lorsque vous avez un exemple d'une méthode qui est conforme à un protocole.
```
//Extend from the NSObject protocol so it is safe to call `respondsToSelector` 
@protocol MyProtocol <NSObject> 

//@required by default
- (void) requiredMethod;

@optional

- (void)optionalMethod;

@end
```
Donné et de l'instance de ce protocole, nous pouvons appeler de toute méthode.
```
id <MyProtocol> myObject = ... 
[myObject requiredMethod];
```
Cependant, les méthodes optionnelles peuvent ou ne peuvent pas être mis en œuvre, de sorte que vous besoin de vérifier au moment de l'exécution.
```
if ([myObject respondsToSelector:@selector(optionalMethod)]) 
{
     [myObject optionalMethod];
}
```
Faire cela permettra d'éviter une collision avec un méconnu sélecteur.

Aussi, la raison pour laquelle vous devez déclarer les protocoles comme une extension de NSObjects, c'est à dire
```
@protocol MyProtocol <NSObject> 
```
Est parce que le NSObject protocole déclare le respondsToSelector: sélecteur. Sinon XCode pense que c'est dangereux pour l'appeler.
- J'ai juste oublié d'ajouter <NSObject> résolu mon problème merci
InformationsquelleAutor Robert
2

Vieille question, mais j'ai appris à être très cautios avec l'aide des trucs comme addTarget:@selector(fu:) parce que le nom de la méthode n'est pas contrôlée, ni inclus dans refactoring par XCODE. Cela m'a causé des problèmes déjà. Alors maintenant, j'ai fait un habbit de toujours intégrer des trucs comme addTarget ou addObserver dans un respondsToSelector-Vérifier comme suit:
```
if([self respondsToSelector:@selector(buttonClicked:)]){
    [self.button addTarget:self action:@selector(buttonClicked:) forControlEvents:UIControlEventTouchUpInside];
}else{
    DebugLog(@"Warning - a class or delegate did not respond to selector in class %@", self);
} 
```
Je sais que c'est pas super élégant, mais je préfère ajouter un peu de code réutilisable, que d'avoir un crash inattendu de mes applications dans l'App Store.
- Je pense que "methodName:" est maintenant vérifiée dans des énoncés comme @selector(methodName:) dans xCode maintenant, n'est-ce pas?
- XCode ne vérifier que le sélecteur existe quelque part dans votre cible. Ainsi, par exemple, si vous avez écrit @selector(date) au lieu de @selector(data) XCode ne vous avertira pas parce que le date sélecteur existe sur NSDateComponents.
InformationsquelleAutor Wirsing

Vous devez vous connecter pour publier un commentaire.