36 votes

IBOutlet et viewDidUnload sous ARC

Il y a une question similaire à celle-ci sur SO ici, cependant je veux juste clarifier quelque chose qui n'était pas entièrement expliqué là-bas.

Je comprends que tous les délégués et les outlets - en fait toute référence à un objet "parent", pour être un bon citoyen et penser au graphe d'objets pendant une minute - devraient être des références faibles à zéro. En raison de la nature des pointeurs faibles à zéro qui passent automatiquement à nil lorsque le compteur de références de l'objet référencé atteint zéro, est-ce que cela signifie que définir les IBOutlets sur nil dans viewDidUnload est désormais inutile ?

Donc, si je déclare mon outlet de la manière suivante :

@property (nonatomic, weak) IBOutlet UILabel *myLabel;

Est-ce que le code suivant a un effet ?

- (void)viewDidUnload
{
    self.myLabel = nil;

    [super viewDidUnload];
}

15voto

Daryl Teo Points 3670

Je fais juste un peu de recherche...

D'après ce que je comprends, weak est similaire à assign, dans le sens où ce sont tous les deux des références faibles.

Cependant, assign ne crée pas une référence à zéro. c'est-à-dire que si l'objet en question est détruit et que vous accédez à cette propriété, vous OBTIENDREZ une exception BAD_ACCESS_EXCEPTION.

Les propriétés faibles sont automatiquement mis à zéro (= nil) lorsque l'objet qu'elles référencent est détruit.

Dans les deux cas, il n'est pas nécessaire de définir la propriété à nil, car cela ne contribue pas au nombre de références de l'objet en question. C'est nécessaire lorsque l'on utilise des propriétés de rétention.

Apparemment, l'ARC introduit également une nouvelle propriété "strong", qui est la même que "retain"?

Recherche effectuée ici

11voto

Stuart Points 8578

J'ai fait quelques tests et il semble que le code dans la méthode viewDidUnload est inutile. Pour le soutenir, la documentation pour viewDidUnload dit en fait :

À ce moment-là, la propriété de vue est nil.

Indiquant que la référence faible doit avoir été automatiquement définie sur nil.

5voto

Emile Cormier Points 13654

J'ai des preuves empiriques pour soutenir que les IBOutlets sont en effet déjà automatiquement définis à nil. Voici ce que j'ai fait :

  1. J'ai configuré des ivars explicites pour mes propriétés IBOutlet (@synthesize myLabel = myLabel_) afin de pouvoir plus tard inspecter leurs valeurs dans le débogueur.
  2. J'ai activé un point d'arrêt sur la première ligne de viewDidUnload.
  3. J'ai arrangé pour que viewDidUnload soit appelé en simulant un avertissement de mémoire.
  4. J'ai inspecté les valeurs des ivars explicites que j'ai associés à mes propriétés IBOutlet.

Les ivars explicites avaient tous nil comme valeur quand j'ai atteint le point d'arrêt.

3voto

scottbates22 Points 283

D'après ce que je comprends de la façon dont les outlets sont gérés dans ARC, si vous utilisez une référence faible, vous n'avez pas besoin d'ajouter quoi que ce soit à viewDidUnload car elle sera déjà nulle. Le faire est donc redondant.

Cependant, si vous avez des outlets forts, qu'Apple recommande d'utiliser si vous pointez vers un élément de niveau supérieur dans le nib, alors vous devriez certainement continuer à ajouter la ligne appropriée dans viewDidUnload pour annuler ces derniers.

0voto

MonsieurDart Points 3133

À partir de iOS 5 et OS X 10.7, weak produira un pointeur automatiquement annulé. Cela signifie que lorsque l'objet pointé est libéré, le pointeur est automatiquement défini sur nil (pour plus de détails, voir Références faibles annulées in ARC).

Ainsi, sous iOS 5+ et OS X 10.7+, il n'est pas utile de définir manuellement les propriétés weak IBOutlet sur nil dans la méthode viewDidUnload : lorsque la vue principale est déchargée, tous ses sous-vues seront libérées, donc les propriétés liées seront définies sur nil.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X