délégué en tant que classe externe en Objective-C

Question

Je crée un projet simple pour iPhone, en utilisant Xcode et Interface Builder. Bien que je comprenne ce qu'est un délégué, j'ai un problème avec son utilisation.

J'ai un UITextField dans mon interface. Il affiche le clavier lorsque l'utilisateur appuie dessus, mais j'ai besoin de programmer manuellement comment cacher le clavier. Cela peut être fait en utilisant des délégués. Donc, dans IB, je prends Object à partir de la bibliothèque, en donnant son nom de classe comme Control1Delegate, puis en connectant la sortie de délégué de mon champ de texte pour être Control1Delegate. J'ai aussi des fichiers .m et .h pour cette classe Control1Delegate:

Control1Delegate.h

@interface Control1Delegate : NSObject <UITextFieldDelegate> { 
} 

- (BOOL) textFieldShouldReturn:(UITextField *)textField; 

@end 

Control1Delegate.m

#import "Control1Delegate.h" 

@implementation Control1Delegate 

- (BOOL) textFieldShouldReturn:(UITextField *)textField { 
    [textField resignFirstResponder]; 
    return YES; 
} 

@end 

Mais cela ne fonctionne pas. Lors de l'exécution, il n'atteint jamais la méthode textFieldShouldReturn ou se bloque sans msg ou avec EXEC_BAD_ACCESS. La chose amusante est que quand je déplace la méthode dans le fichier du contrôleur (l'assistant a généré) et que je me connecte de UITextField à ce contrôleur (le propriétaire du fichier), tout fonctionne comme prévu. J'ai vu que la plupart des didacticiels de code de pomme mettent des méthodes déléguées dans des objets aléatoires plutôt que des classes séparées - je voudrais savoir pourquoi. Je ne peux pas avoir de délégué dans une classe séparée?

Qu'est-ce qui me manque ici? Un pointeur nul? Livecycle d'objet?

Answer 1

Votre objet est Control1Delegate se détruit peu de temps après sa création. Tous les objets Nib de niveau supérieur doivent être conservés si vous souhaitez les conserver en vie. Reportez-vous au Resource Programming Guide: The Nib Object Life Cycle.

propriétaire pourrait avoir une propriété du fichier comme celui-ci, afin de conserver l'objet:

@property (nonatomic, retain) IBOutlet Control1Delegate *control1delegate; 

Souvenez-vous de libérer l'objet après qu'il ne soit plus nécessaire.

Answer 2

Vous pouvez mettre des méthodes de délégués dans toutes les catégories, y compris un construit juste à cette fin. La raison pour laquelle Apple (et d'autres programmeurs) ne créent généralement pas de classes spécifiquement pour les fonctions de délégué est qu'il devient trop complexe et difficile de partager des données. Par exemple, dans un de mes projets, je pourrais créer une sous-classe Window Controller qui gère les méthodes déléguées à partir de la fenêtre, la vue tabulaire à l'intérieur de la fenêtre et la barre d'outils de la fenêtre. Tout ce dont vous avez besoin pour manipuler et maintenir l'état de cette fenêtre est dans une classe de contrôleur. Maintenant, imaginez trois classes séparées (plus probablement une classe de contrôleur pour les gérer) faisant les mêmes fonctions - c'est beaucoup de travail supplémentaire sans réel bénéfice.

Quant à savoir pourquoi il est écraser, il semble que vous faites une erreur avec la gestion de la mémoire quelque part ailleurs dans votre application. Vous pouvez utiliser le débogueur pour savoir exactement d'où il vient.

Answer 3

Merci à vous deux. Non seulement je sais maintenant comment résoudre mon problème, mais j'ai aussi compris comment les objets sont conservés dans le processus de création de Nib. Il ne suffit pas de créer un objet dans IB, si c'est une nouvelle entité, il faut le connecter à un vrai ivar dans le propriétaire du fichier (avec un getter/setter correctement synthétisé).