2010-06-22 5 views
4

La gestion de la mémoire avec les délégués, je comprends que je ne retiens pas les délégués, je ne sais pas quoi faire avec le délégué si la vue est déchargée (via viewDidUnload) et recréée plus tard (via viewDidLoad)?Gestion de la mémoire avec les délégués?

@property(assign) SomeClass *someDelegate; 

.

- (void)viewDidLoad { 
    [super viewDidLoad]; 
    someDelegate = [[SomeClass alloc] init]; 
    [someDelegate setDelegate:self]; 
} 

-(void)viewDidUnload { 
    [super viewDidUnload]; 
    [self setSomeDelegate:nil]; 
} 

-(void)dealloc { 
[super dealloc]; 
} 

PS: je pourrais être sur la mauvaise voie, je suis juste essayer d'obtenir ma tête autour de cette ...

acclamations Gary

+0

Modifié pour refléter les corrections/commentaires du Deans. – fuzzygoat

Répondre

2

Si vous utilisez pour affecter votre propriété, vous ne pas appeler retain sur l'objet. Cela signifie que vous ne devez absolument PAS appeler release ou autorelease dessus!

Votre ligne dans votre dealloc

[someDelegate release]; 

provoque un accident à un moment donné dans l'avenir - il faut l'enlever. Vous n'avez pas besoin de vous préoccuper des propriétés assignées dans la méthode dealloc.

Votre ligne

[self setSomeDelegate:nil]; 

ne fuira pas.


Cependant, vous semblez avoir [[someDelegate alloc] init] dans votre méthode viewDidLoad. C'est inhabituel. il est normal que le délégué soit un objet externe, pas un objet fabriqué par vous-même. Dans votre cas, ce n'est pas vraiment un délégué, c'est juste un objet qui fait quelque chose pour vous - vous devez le renommer et changer la propriété en un retain (et n'oubliez pas de le libérer dans dealloc).

Actuellement, si votre propriété est définie sur (assigner) et que quelqu'un d'autre la définit, vous perdrez votre délégué initial. Si vous utilisez uniquement le délégué dans cette classe, peut-être que ce ne devrait pas être une propriété du tout? Si vous voulez juste être capable de le lire à partir de l'extérieur de votre classe, vous pourriez être en mesure d'utiliser (en lecture seule) au lieu de assign (et changer [self setSomeDelegate:nil] à someDelegate=nil;)

Votre ligne viewDidUnload qui définit le délégué à zéro supprime la question vous soulevez dans votre deuxième commentaire - vous supprimez le délégué donc au moment où vous arrivez à viewDidLoad à nouveau, votre délégué est déjà nul :)

+0

Si je comprends bien, merci Dean. Je devenais confus sur la façon dont le @property (assign) a fonctionné. – fuzzygoat

+0

Donc, étant donné que j'ai un init [[someDelegate alloc]] dans viewDidLoad, que se passe-t-il si la vue est déchargée et appelle à nouveau viewDidLoad? Chaque fois que j'appelle viewDidLoad je vais obtenir un nouveau someDelegate et fuir l'ancien. – fuzzygoat

+0

Voir la modification que je viens de faire :) – deanWombourne

1

This éclairera peut-être de comprendre pourquoi

la raison que vous évitez de retenir les délégués est que vous n EED à éviter un cycle retenir:

A crée BA se définit en tant que délégué de B ... A est libéré par son propriétaire

Si B avait retenu A, A ne serait pas libéré, comme B possède A, ainsi A dealloc ne serait jamais appelé, causant A et B à la fuite.

Vous ne devriez pas vous inquiéter du fait que A s'en va parce qu'il possède B et obtient ainsi en désavantage.

+0

Merci Anders, c'est très utile aussi ... – fuzzygoat