Si j'attribue une propriété delegate de la classe B à la classe A d'Interface Builder, dois-je attribuer une classe IB à la classe B, puis dans la classe A dealloc, mettre le délégué à zéro via la sortie? (En supposant que la classe A est le propriétaire du fichier XIB ...)Dois-je déléguer les références effectuées via Interface Builder?
Réponse courte: oui. Indépendamment du fait que vous utilisiez Interface Builder ou non, il est recommandé que le délégué se retire lui-même en tant que délégué de l'objet délégué dès qu'il renonce à la propriété (c'est-à-dire libère) l'objet délégué. Cela peut être dans sa méthode dealloc au plus tard, mais cela peut aussi arriver plus tôt.
La raison: Généralement, le délégué est une sorte d'objet parent de l'objet délégué. Très souvent, le délégué et le propriétaire de l'objet délégué sont le même objet. Parce que l'objet parent conserve généralement l'objet enfant, afin d'éviter les références circulaires, l'objet délégué (c'est-à-dire, enfant) ne conserve normalement pas son délégué. Dans ces cas, il peut arriver que l'objet délégué soit désalloué alors que l'objet délégué est toujours actif (si un autre objet l'a également conservé). Si maintenant l'objet délégué essaye d'accéder à son délégué (qui n'existe plus), le programme pourrait tomber en panne. Donc juste avant que l'objet parent ne libère son objet enfant (généralement, mais pas toujours, dans sa méthode dealloc), il doit appeler childObject.delegate = nil;.
Vous ne devriez pas annull la propriété 'delegate' sauf si vous êtes réellement le délégué: ' si ([délégué otherObject] == auto) [otherObject setDelegate: nil]; ' –
+1 pour Jeremy. Merci pour la correction. –
1) Interface Builder a mis en place la connexion, donc ne devrait-il pas être responsable de sa désactivation? 2) L'objet parent peut même ne pas avoir de référence à l'objet délégué, car il a été créé dans Interface Builder sans aucune sortie explicite. Alors, comment désarmez-vous son délégué? – user102008