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

Je développe exclusivement pour iOS 5 en utilisant ARC. Les IBOutlets à UIViews (et les sous-classes) devraient strong- weakils être ou ?

Le suivant:

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

Se débarrasserait de tout cela:

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

Y a-t-il des problèmes à le faire? Les modèles utilisent tout strongcomme les propriétés générées automatiquement créées lors de la connexion directe à l'en-tête à partir de l'éditeur «Interface Builder», mais pourquoi? Le a UIViewControllerdéjà une strongréférence à son viewqui conserve ses sous-vues.

Le courant recommandé les meilleures pratiques d'Apple est pour IBOutlets d'être forte à moins faible est particulièrement nécessaire pour éviter retain cycle. Comme Johannes l'a mentionné ci-dessus, cela a été commenté dans la session "Implémentation de conceptions d'interface utilisateur dans Interface Builder" de la WWDC 2015 où un ingénieur Apple a déclaré:

Et la dernière option que je veux souligner est le type de stockage, qui peut être fort ou faible. En général, vous devez renforcer votre sortie, en particulier si vous connectez une sortie à une sous-vue ou à une contrainte qui ne sera pas toujours conservée par la hiérarchie des vues. La seule fois où vous avez vraiment besoin de rendre une sortie faible, c'est si vous avez une vue personnalisée qui fait référence à quelque chose de sauvegarder la hiérarchie des vues et en général ce n'est pas recommandé.

J'ai demandé à ce sujet sur Twitter à un ingénieur de l'équipe IB et il a confirmé que strong devrait être la valeur par défaut et que les documents du développeur sont en cours de mise à jour.

https://twitter.com/_danielhall/status/620716996326350848 https://twitter.com/_danielhall/status/620717252216623104

AVERTISSEMENT, RÉPONSE ANCIENNE : cette réponse n'est pas à jour selon WWDC 2015, pour la bonne réponse se référer à la réponse acceptée (Daniel Hall) ci-dessus. Cette réponse restera enregistrée.

Résumé de la bibliothèque des développeurs :

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

• Les sorties que vous créez, 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 des objets qui n'impliquent pas la propriété.

• Les sorties fortes sont fréquemment spécifiées par les classes de framework (par exemple, la sortie de vue UIViewController ou la sortie de fenêtre NSWindowController).

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

Bien que la documentation recommande d'utiliser des weakpropriétés pour les sous-vues, depuis iOS 6, il semble strongapproprié d'utiliser (le qualificatif de propriété par défaut) à la place. Cela est dû au changement dans le fait UIViewControllerque les vues ne sont plus déchargées.

• Avant iOS 6, si vous gardiez des liens solides vers les sous-vues de la vue du contrôleur, si la vue principale du contrôleur de vue était déchargée, celles-ci resteraient sur les sous-vues aussi longtemps que le contrôleur de vue est autour.
• Depuis iOS 6, les vues ne sont plus déchargées, mais chargées une fois, puis restent aussi longtemps que leur contrôleur est là. Des propriétés si solides n'auront aucune importance. Ils ne créeront pas non plus de cycles de référence forts, car ils pointent vers le bas le graphique de référence fort.

Cela dit, je suis déchiré entre l'utilisation

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

et

@property (nonatomic) IBOutlet UIButton *button;

dans iOS 6 et versions ultérieures:

• L'utilisation weakindique clairement que le contrôleur ne souhaite pas être propriétaire du bouton.

• Mais l'omission weakne fait pas de mal dans iOS 6 sans déchargement de vue et est plus courte. Certains peuvent signaler que c'est aussi plus rapide, mais je n'ai pas encore rencontré d'application trop lente à cause de l' weak IBOutletart.

• Ne pas utiliser weakpeut être perçu comme une erreur.

Conclusion: depuis iOS 6, nous ne pouvons plus nous tromper tant que nous n'utilisons pas le déchargement de vue. Il est temps de faire la fête. ;)

Je ne vois aucun problème avec cela. Avant l'ARC, j'ai toujours créé mes IBOutlets assign, car ils sont déjà conservés par leurs superviews. Si vous les faites weak, vous ne devriez pas avoir à les supprimer dans viewDidUnload, comme vous le faites remarquer.

Une mise en garde: vous pouvez prendre en charge iOS 4.x dans un projet ARC, mais si vous le faites, vous ne pouvez pas l'utiliser weak, vous devrez donc les créer assign, auquel cas vous voudrez toujours annuler la référence viewDidUnloadpour éviter un pointeur pendant. Voici un exemple de bogue de pointeur pendant que j'ai rencontré:

Un UIViewController a 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 rappel 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 constaté que si je rejetais cette vue au bon moment et que je ne mettais pas self.zip à zéro viewDidUnload, le rappel du délégué pourrait lever une mauvaise exception d'accès sur self.zip.text.

IBOutletdevrait être solide, pour des raisons de performances. Voir Storyboard Reference, Strong IBOutlet, Scene Dock dans iOS 9

Comme expliqué dans ce paragraphe, les sorties vers les sous-vues de la vue du contrôleur de vue peuvent être faibles, car ces sous-vues appartiennent déjà à l'objet de niveau supérieur du fichier nib. Cependant, lorsqu'une prise est définie comme un pointeur faible et que le pointeur est défini, ARC appelle la fonction d'exécution:

id objc_storeWeak(id *object, id value);

Cela ajoute le pointeur (objet) à une table en utilisant la valeur de l'objet comme clé. Ce tableau est appelé tableau faible. ARC utilise ce tableau pour stocker tous les pointeurs faibles de votre application. À présent, lorsque la valeur de l'objet est désallouée, ARC parcourt la table faible et définit la référence faible à zéro. L'ARC peut également appeler:

void objc_destroyWeak(id * object)

Ensuite, l'objet n'est pas enregistré et objc_destroyWeak appelle à nouveau:

objc_storeWeak(id *object, nil)

Cette comptabilité associée à une référence faible peut prendre 2 à 3 fois plus de temps que la publication d'une référence forte. Ainsi, une référence faible introduit une surcharge pour le runtime que vous pouvez éviter en définissant simplement les sorties comme fortes.

Depuis Xcode 7, il suggère strong

Si vous regardez la session 407 de la WWDC 2015 sur la mise en œuvre des conceptions d'interface utilisateur dans Interface Builder , cela suggère (transcription de http://asciiwwdc.com/2015/sessions/407 )

Et la dernière option que je veux souligner est le type de stockage, qui peut être fort ou faible.

En général, vous devez renforcer votre sortie, en particulier si vous connectez une sortie à une sous-vue ou à une contrainte qui ne sera pas toujours conservée par la hiérarchie des vues.

La seule fois où vous avez vraiment besoin de rendre une sortie faible, c'est si vous avez une vue personnalisée qui fait référence à quelque chose de sauvegarder la hiérarchie des vues et en général ce n'est pas recommandé.

Je vais donc choisir fort et je clique sur connecter ce qui va générer ma sortie.

Dans le développement iOS, le chargement 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 niveau supérieur sera conservée et lorsque vous désallouez le contrôleur, toutes ses sous-vues et sorties sont automatiquement libérées.

UiViewController utilise le codage des valeurs clés pour définir les sorties à l'aide de références fortes. Ainsi, lorsque vous désallouez votre UIViewController, la vue de dessus sera automatiquement désallouée, mais vous devez également désallouer toutes ses sorties dans la méthode dealloc.

Dans cet article du Big Nerd Ranch , ils couvrent 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 cela est recommandé par Apple dans ce cas).

Une chose que je souhaite souligner ici, et ce, malgré ce que les ingénieurs d'Apple ont déclaré dans leur propre vidéo WWDC 2015 ici:

https://developer.apple.com/videos/play/wwdc2015/407/

Apple ne cesse de changer d'avis sur le sujet, ce qui nous dit qu'il n'y a pas de bonne réponse unique à cette question. Pour montrer que même les ingénieurs d'Apple sont divisés sur ce sujet, jetez un coup d'œil à l'exemple de code le plus récent d'Apple, et vous verrez que certaines personnes utilisent faible, et d'autres non.

Cet exemple d'Apple Pay utilise faible: https://developer.apple.com/library/ios/samplecode/Emporium/Listings/Emporium_ProductTableViewController_swift.html#//apple_ref/doc/uid/TP40016175-Emporium_ProductTableViewController_swift

Tout comme cet exemple d'image dans l'image: https://developer.apple.com/library/ios/samplecode/AVFoundationPiPPlayer/Listings/AVFoundationPiPPlayer_PlayerViewController_swift.html#//apple_ref/doc/uid/TP40016166-AVFoundationPiPController

Tout comme l'exemple Lister: https://developer.apple.com/library/ios/samplecode/Lister/Listings/Lister_ListCell_swift.html#//apple_ref/doc/uid/TP40014701-Lister_ListCell_swift-DontLinkElementID_57

Tout comme l'exemple de l'emplacement principal: https://developer.apple.com/library/ios/samplecode/PotLoc/Listings/Potloc_PotlocViewController_swift.html#//apple_ref/doc/uid/TP40016176-Potloc_PotlocViewController_swift-

Tout comme l'exemple de prévisualisation du contrôleur de vue: https://developer.apple.com/library/ios/samplecode/ViewControllerPreviews/Listings/Projects_PreviewUsingDelegate_PreviewUsingDelegate_DetailViewController_swift.html#//apple_ref/doc_uidPort

Tout comme l'exemple HomeKit: https://developer.apple.com/library/ios/samplecode/HomeKitCatalog/Listings/HMCatalog_Homes_Action_Sets_ActionSetViewController_swift.html#//apple_ref/doc/uid/TP40015048-HMCatalogSelect

Tous ceux-ci sont entièrement mis à jour pour iOS 9 et utilisent tous des prises faibles. De cela, nous apprenons que A. Le problème n'est pas aussi simple que certains le prétendent. B. Apple a changé d'avis à plusieurs reprises, et C. Vous pouvez utiliser tout ce qui vous rend heureux :)

Un merci spécial à Paul Hudson (auteur de www.hackingwithsift.com) qui m'a donné la clarification et les références pour cette réponse.

J'espère que cela clarifie un peu mieux le sujet!

Prends soin de toi.

Depuis la WWDC 2015, il y a une session sur la mise en œuvre de conceptions d'interface utilisateur dans Interface Builder . Autour de la marque des 32 minutes, il dit que vous voulez toujours vous @IBOutlet fortifier .

Soyez conscient, IBOutletCollectiondevrait l'être @property (strong, nonatomic).

Il semble que quelque chose ait changé au fil des ans et maintenant Apple recommande d'utiliser le fort en général. Les preuves de leur session WWDC se trouvent dans la session 407 - Implémentation de conceptions d'interface utilisateur dans Interface Builder et commencent à 32h30. Ma note d'après ce qu'il dit est (presque, sinon exactement, le citant):

• les connexions de sortie en général doivent être solides, surtout si nous connectons une sous-vue ou une contrainte qui n'est pas toujours conservée par la hiérarchie des vues

• une connexion de sortie faible peut être nécessaire lors de la création de vues personnalisées ayant une référence à quelque chose de sauvegarde dans la hiérarchie des vues et en général, il n'est pas recommandé

Dans d'autres quartiers, il devrait toujours être fort tant que certaines de nos vues personnalisées ne créent pas de cycle de conservation avec une partie de la vue dans la hiérarchie des vues.

ÉDITER :

Certains peuvent poser la question. Le conserver avec une référence forte ne crée-t-il pas un cycle de conservation car le contrôleur de vue racine et la vue propriétaire la conservent? Ou pourquoi cela a-t-il changé? Je pense que la réponse est plus tôt dans cet exposé quand ils décrivent comment les plumes sont créées à partir du xib. Il existe une pointe distincte créée pour un VC et pour la vue. Je pense que cela pourrait être la raison pour laquelle ils modifient les recommandations. Ce serait quand même bien d'obtenir une explication plus approfondie d'Apple.

Je pense que les informations les plus importantes sont les suivantes: les éléments de xib sont automatiquement en sous-vues. Subviews est NSArray. NSArray possède ses éléments. etc ont des pointeurs forts sur eux. Donc, dans la plupart des cas, vous ne voulez pas créer un autre pointeur fort (IBOutlet)

Et avec ARC, vous n'avez rien à faire viewDidUnload