Les IBOutlets doivent-ils être forts ou faibles sous l'ARC ?

Question

Je développe exclusivement pour iOS 5 en utilisant ARC. Est-ce que IBOutlet s à UIView (et les sous-classes) soient strong o weak ?

Les suivantes :

@property (nonatomic, weak) IBOutlet UIButton *button;

Je me débarrasserais de tout ça :

- (void)viewDidUnload
{
    // ...
    self.button = nil;
    // ...
}

Cela pose-t-il des problèmes ? Les modèles utilisent strong tout comme les propriétés générées automatiquement lorsqu'on se connecte directement à l'en-tête à partir de l'éditeur "Interface Builder", mais pourquoi ? Le site UIViewController a déjà un strong référence à son view qui conserve ses sous-vues.

Answer 1

AVERTISSEMENT, RÉPONSE PÉRIMÉE Cette réponse n'est pas à jour par rapport à la WWDC 2015, pour la réponse correcte, veuillez vous référer à la page de la WWDC 2015. réponse acceptée (Daniel Hall) ci-dessus. Cette réponse restera dans les archives.

---

Résumé de l'étude bibliothèque de développeurs :

D'un point de vue pratique, dans iOS et OS X, les points de vente doivent être définis comme des propriétés déclarées. Les sorties doivent généralement être faibles, à l'exception de celles du propriétaire du fichier vers les objets de niveau supérieur d'un fichier nib (ou, dans iOS, d'une scène de storyboard) qui doivent être fortes. Les outlets que vous créez seront donc généralement faibles par défaut, car :

• Les sorties que vous créez vers, par exemple, des sous-vues de la vue d'un contrôleur de vue ou de la fenêtre d'un contrôleur de fenêtre, sont des références arbitraires entre objets qui n'impliquent pas de propriété.

• Les points de sortie forts sont souvent spécifiés par des classes de cadre (par exemple, le point de sortie de la vue de UIViewController, ou le point de sortie de la fenêtre de NSWindowController).

  @property (weak) IBOutlet MyView *viewContainerSubview;
  @property (strong) IBOutlet MyOtherClass *topLevelObject;

Answer 2

Bien que la documentation recommande d'utiliser weak sur les propriétés pour les sous-vues, depuis iOS 6, il semble être possible d'utiliser strong (le qualificatif de propriété par défaut) à la place. C'est dû au changement dans UIViewController que les vues ne sont plus déchargées.

• Avant iOS 6, si vous conserviez des liens forts vers des sous-vues de la vue du contrôleur, si la vue principale du contrôleur était déchargée, ces liens s'accrochaient aux sous-vues tant que le contrôleur était présent.
• Depuis iOS 6, les vues ne sont plus déchargées, mais chargées une fois et restent en place tant que leur contrôleur est présent. Les propriétés fortes n'ont donc plus d'importance. Elles ne créeront pas non plus de cycles de référence forte, puisqu'elles pointent vers le bas du graphe de référence forte.

Cela dit, je suis partagé entre l'utilisation

@property (nonatomic, weak) IBOutlet UIButton *button;

y

@property (nonatomic) IBOutlet UIButton *button;

dans iOS 6 et suivants :

• Utilisation de weak indique clairement que le contrôleur ne veut pas la propriété du bouton.

• Mais en omettant weak ne fait pas de mal dans iOS 6 sans déchargement de la vue, et est plus courte. Certains pourraient faire remarquer que c'est aussi plus rapide, mais je n'ai encore jamais rencontré une application qui soit trop lente à cause de weak IBOutlet s.

• Ne pas utiliser weak peut être perçue comme une erreur.

En résumé : Depuis iOS 6, nous ne pouvons plus nous tromper tant que nous n'utilisons pas le déchargement des vues. Il est temps de faire la fête ;)

Answer 3

Je ne vois pas de problème à cela. Avant l'ARC, j'ai toujours fait en sorte que mes IBOutlets assign car ils sont déjà retenus par leurs supervisions. Si vous les faites weak vous ne devriez pas avoir à les réduire à néant dans viewDidUnload, comme vous le faites remarquer.

Un bémol : vous pouvez prendre en charge iOS 4.x dans un projet ARC, mais si vous le faites, vous ne pouvez pas utiliser weak donc tu dois les faire assign dans ce cas, vous voudrez toujours rendre nulle la référence dans viewDidUnload pour éviter un pointeur qui pendouille. Voici un exemple d'un bug de type "dangling pointer" que j'ai rencontré :

Un UIViewController possède un UITextField pour le code postal. Il utilise CLLocationManager pour inverser le géocodage de l'emplacement de l'utilisateur et définir le code postal. Voici le callback du délégué :

-(void)locationManager:(CLLocationManager *)manager
   didUpdateToLocation:(CLLocation *)newLocation
          fromLocation:(CLLocation *)oldLocation {
    Class geocoderClass = NSClassFromString(@"CLGeocoder");
    if (geocoderClass && IsEmpty(self.zip.text)) {
        id geocoder = [[geocoderClass alloc] init];
        [geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
            if (self.zip && IsEmpty(self.zip.text)) {
                self.zip.text = [[placemarks objectAtIndex:0] postalCode];
            }
        }];    
    }
    [self.locationManager stopUpdatingLocation];
}

J'ai découvert que si je rejetais cette vue au bon moment et que je ne mettais pas à zéro self.zip dans le fichier viewDidUnload le callback du délégué pourrait lancer une exception de mauvais accès sur self.zip.text.

Answer 4

Dans le développement iOS, le chargement des NIB est un peu différent du développement Mac.

Dans le développement Mac, une IBOutlet est généralement une référence faible : si vous avez une sous-classe de NSViewController, seule la vue de premier niveau sera conservée et lorsque vous désallouez le contrôleur, toutes ses sous-vues et sorties sont libérées automatiquement.

UiViewController utilise le Key Value Coding pour définir les points de vente en utilisant des références fortes. Ainsi, lorsque vous désallouez votre UIViewController, la vue supérieure est automatiquement désallouée, mais vous devez également désallouer toutes ses sorties dans la méthode dealloc.

Dans ce billet du Big Nerd Ranch Les auteurs traitent de ce sujet et expliquent également pourquoi l'utilisation d'une référence forte dans IBOutlet n'est pas un bon choix (même si elle est recommandée par Apple dans ce cas).

Answer 5

Faites attention, IBOutletCollection devrait être @property (strong, nonatomic) .