Principalement à éviter les fuites mémoires. Et en particulier à éviter les cycles de références fortes.
Exemple : un contrôleur de vue possède une vue qui contient un contrôle, disons un champ de texte. Et ce même contrôleur de vue est le délégué de ce champ de texte. S'il n'y avait que des propriétés strong, on obtiendrait un cycle de références fortes viewController -> view -> textField -> viewController.
Si ce contrôleur de vue est déréférencé par son propriétaire (par exemple un contrôleur de navigation, et aussi par exemple dans le cas d'une alerte mémoire), le cycle de références empêcheraient alors la mémoire de se libérer correctement.
Le fait de définir systématiquement les delegate (et généralement les outlets aussi) comme weak permet d'éviter les cycles de références fortes.
C'est bon Alf1996 je me suis présenté sur la page prévue à cet effet /wink.png' class='bbc_emoticon' alt=';)' />
Donc jpimbert, une propriété weak c'est dans le cas ou un objet A a une référence vers un objet B et cet objet B a une référence vers l'objet A. Si on ne met pas de propriétés weak, et que A et B n'ont plus de lien vers l'extérieur alors il ne seront pas détruis car il sont fortement liés l'un à l'autre ? Alors que normalement comme ils n'ont plus de lien avec le reste du système ils devraient être supprimés ?
Donc jpimbert, une propriété weak c'est dans le cas ou un objet A a une référence vers un objet B et cet objet B a une référence vers l'objet A. Si on ne met pas de propriétés weak, et que A et B n'ont plus de lien vers l'extérieur alors il ne seront pas détruis car il sont fortement liés l'un à l'autre ? Alors que normalement comme ils n'ont plus de lien avec le reste du système ils devraient être supprimés ?
C'est exactement ça. Lorsqu'on adopte ARC, un objet est libéré dès qu'il n'est plus référencé fortement. S'il y a un cycle de références fortes cette situation n'arrive jamais et les objets du cycle ne sont jamais libérés.
Des fois quand on développe on est obligé d'utiliser l'espèce de gros truc mou qu'on a (enfin pas tous semble-t-il) entre les deux oreilles, à l'intérieur de la boà®te crânienne. À mon grand désespoir d'ailleurs car le mien commence à fatiguer ...
Réponses
Premier post : à quoi elle sert cette section ?
Exemple : un contrôleur de vue possède une vue qui contient un contrôle, disons un champ de texte. Et ce même contrôleur de vue est le délégué de ce champ de texte. S'il n'y avait que des propriétés strong, on obtiendrait un cycle de références fortes viewController -> view -> textField -> viewController.
Si ce contrôleur de vue est déréférencé par son propriétaire (par exemple un contrôleur de navigation, et aussi par exemple dans le cas d'une alerte mémoire), le cycle de références empêcheraient alors la mémoire de se libérer correctement.
Le fait de définir systématiquement les delegate (et généralement les outlets aussi) comme weak permet d'éviter les cycles de références fortes.
C'est bon Alf1996 je me suis présenté sur la page prévue à cet effet
Donc jpimbert, une propriété weak c'est dans le cas ou un objet A a une référence vers un objet B et cet objet B a une référence vers l'objet A. Si on ne met pas de propriétés weak, et que A et B n'ont plus de lien vers l'extérieur alors il ne seront pas détruis car il sont fortement liés l'un à l'autre ? Alors que normalement comme ils n'ont plus de lien avec le reste du système ils devraient être supprimés ?
C'est exactement ça. Lorsqu'on adopte ARC, un objet est libéré dès qu'il n'est plus référencé fortement. S'il y a un cycle de références fortes cette situation n'arrive jamais et les objets du cycle ne sont jamais libérés.
Des fois quand on développe on est obligé d'utiliser l'espèce de gros truc mou qu'on a (enfin pas tous semble-t-il) entre les deux oreilles, à l'intérieur de la boà®te crânienne. À mon grand désespoir d'ailleurs car le mien commence à fatiguer ...