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

Question

Je crée un projet simple pour iPhone, 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 je dois programmer manuellement comment masquer le clavier. Cela peut être fait en utilisant des délégués. Ainsi, dans IB, je prends Object de la bibliothèque, lui attribuant le nom de la classe Control1Delegate, puis je connecte le point de vente délégué de mon champ de texte à ce 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 ça ne marche pas. Lors de l'exécution, il n'atteint jamais la méthode textFieldShouldReturn et ne plante pas sans msg ou avec EXEC_BAD_ACCESS. Ce qui est amusant, c’est que lorsque je déplace la méthode dans un fichier de contrôleur (celui que l’Assistant a généré) et que je me connecte depuis UITextField à ce contrôleur (File's Owner), tout fonctionne comme prévu. J'ai vu que la plupart des tutoriels de code Apple placent les méthodes déléguées dans des objets aléatoires plutôt que dans des classes séparées - j'aimerais savoir pourquoi. Puis-je avoir un délégué dans une classe séparée?

Qu'est-ce qui me manque ici? Un pointeur nul? Le cycle de vie d'un objet?

Answer 1

Votre objet Control1Delegate est 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. Cycle de vie .

Le propriétaire du fichier peut avoir une propriété comme celle-ci, afin de conserver l'objet:

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

N'oubliez pas de libérer l'objet une fois que vous n'en avez plus besoin.

Answer 2

Vous pouvez placer des méthodes de délégation dans n'importe quelle classe, y compris une méthode créée uniquement à cette fin. La raison pour laquelle Apple (et les autres programmeurs) ne crée généralement pas de classes spécifiquement pour les fonctions de délégation est que cela devient excessivement complexe et difficile de partager des données. Par exemple, dans l'un de mes projets, je pourrais créer une sous-classe de contrôleur de fenêtre qui gère les méthodes de délégation à 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 distinctes (plus probablement une classe de contrôleur pour les gérer) effectuant les mêmes fonctions - cela représente beaucoup de travail supplémentaire sans aucun avantage réel.

Pour ce qui est du blocage, il semble que vous commettiez une erreur de gestion de la mémoire 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 enfin compris comment les objets sont retenus dans le processus de création de Nib. Il ne suffit pas de créer un objet dans IB, s'il s'agit d'une nouvelle entité, il doit être connecté à un ivar réel dans File's Owner (avec un getter / setter correctement synthétisé).