IBOutlets dovrebbe essere forte o debole sotto ARC?

Sto sviluppando esclusivamente per iOS 5 utilizzando ARC. Qualora IBOutletS per UIViews (e sottoclassi) sia strongo weak?

Il seguente:

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

Mi sbarazzerei di tutto questo:

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

Ci sono problemi a farlo? I modelli stanno usando strongcome sono le proprietà generate automaticamente create quando ci si collega direttamente all'intestazione dall'editor 'Interface Builder', ma perché? L' UIViewControllerha già un strongriferimento ai suoi viewche conserva la sua subviews.

La corrente negativa migliore pratica da Apple è per IBOutlets siano forti meno debole è specificamente necessaria per evitare un ciclo conservare. Come Johannes ha menzionato sopra, questo è stato commentato nella sessione "Implementazione di progetti di interfaccia utente in Interface Builder" dal WWDC 2015 in cui un ingegnere Apple ha dichiarato:

E l'ultima opzione che voglio sottolineare è il tipo di archiviazione, che può essere forte o debole. In generale, dovresti rafforzare il tuo punto vendita, specialmente se stai collegando un punto vendita a una sottoview o a un vincolo che non sarà sempre mantenuto dalla gerarchia della vista. L'unica volta in cui è davvero necessario indebolire un punto vendita è se si dispone di una vista personalizzata che fa riferimento a qualcosa di backup della gerarchia della vista e in generale non è consigliabile.

Ho chiesto a questo proposito su Twitter a un ingegnere del team IB e ha confermato che il valore predefinito dovrebbe essere forte e che i documenti per gli sviluppatori vengono aggiornati.

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

ATTENZIONE, RISPOSTA AGGIORNATA : questa risposta non è aggiornata secondo WWDC 2015, per la risposta corretta fare riferimento alla risposta accettata (Daniel Hall) sopra. Questa risposta rimarrà per la cronaca.

Riassunto dalla libreria degli sviluppatori :

Da un punto di vista pratico, in iOS e OS X le prese dovrebbero essere definite come proprietà dichiarate. I punti vendita dovrebbero essere generalmente deboli, ad eccezione di quelli dal proprietario del file agli oggetti di livello superiore in un file pennino (o, in iOS, una scena di storyboard) che dovrebbe essere forte. I punti vendita creati saranno pertanto generalmente deboli per impostazione predefinita, poiché:

• I punti vendita creati, ad esempio, per le viste secondarie della vista di un controller di visualizzazione o della finestra di un controller di finestra, sono riferimenti arbitrari tra oggetti che non implicano la proprietà.

• I punti di forza sono spesso specificati da classi di framework (ad esempio, punto di vista di UIViewController o punto di finestra di NSWindowController).

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

Mentre la documentazione consiglia di utilizzare le weakproprietà per le visualizzazioni secondarie, dal momento che iOS 6 sembra invece usare bene strong(il qualificatore di proprietà predefinito). Ciò è causato dalla modifica delle UIViewControllerviste che non viene più scaricata.

• Prima di iOS 6, se si mantenevano forti collegamenti con le visualizzazioni secondarie della vista del controller in giro, se la vista principale del controller della vista veniva scaricata, quelle rimarrebbero aggrappate alle visualizzazioni secondarie fintanto che il controller della vista è in circolazione.
• Da iOS 6, le viste non vengono più scaricate, ma caricate una volta e quindi restano in posizione finché il controller è presente. Quindi le proprietà forti non contano. Inoltre, non creano cicli di riferimento forti, poiché indicano il grafico di riferimento forte.

Detto questo, sono combattuto tra l'utilizzo

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

e

@property (nonatomic) IBOutlet UIButton *button;

in iOS 6 e versioni successive:

• L'uso weakindica chiaramente che il controller non desidera la proprietà del pulsante.

• Ma omettere weaknon fa male in iOS 6 senza scaricare la visualizzazione ed è più breve. Alcuni potrebbero sottolineare che è anche più veloce, ma devo ancora incontrare un'app che è troppo lenta a causa di weak IBOutlets.

• Il mancato utilizzo weakpuò essere percepito come un errore.

In conclusione: da iOS 6 non possiamo più sbagliare finché non utilizziamo lo scaricamento della vista. Tempo di fare festa. ;)

Non vedo alcun problema con quello. Pre-ARC, ho sempre realizzato i miei IBOutlet assign, poiché sono già conservati dalle loro superview. Se li fai weak, non dovresti annullarli in viewDidUnload, come fai notare.

Un avvertimento: puoi supportare iOS 4.x in un progetto ARC, ma se lo fai, non puoi usarlo weak, quindi dovresti crearli assign, nel qual caso vorrai comunque annullare il riferimento viewDidUnloadper evitare un puntatore penzolante. Ecco un esempio di un bug puntatore penzolante che ho riscontrato:

Un UIViewController ha un UITextField per il codice postale. Utilizza CLLocationManager per invertire il codice geografico della posizione dell'utente e impostare il codice postale. Ecco il callback delegato:

-(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];
}

Ho scoperto che se avessi rifiutato questa visione al momento giusto e non avessi annullato self.zip viewDidUnload, il callback del delegato avrebbe potuto generare un'eccezione di accesso errato su self.zip.text.

IBOutletdovrebbe essere forte, per motivi di prestazioni. Vedi Storyboard Reference, Strong IBOutlet, Scene Dock in iOS 9

Come spiegato in questo paragrafo, gli sbocchi per le visualizzazioni secondarie della vista del controller di visualizzazione possono essere deboli, poiché tali visualizzazioni secondarie sono già di proprietà dell'oggetto di livello superiore del file pennino. Tuttavia, quando un Outlet è definito come un puntatore debole e il puntatore è impostato, ARC chiama la funzione di runtime:

id objc_storeWeak(id *object, id value);

Ciò aggiunge il puntatore (oggetto) a una tabella usando il valore dell'oggetto come chiave. Questa tabella viene definita tabella debole. ARC utilizza questa tabella per archiviare tutti i puntatori deboli dell'applicazione. Ora, quando il valore dell'oggetto è deallocato, ARC ripeterà la tabella debole e imposterà il riferimento debole su zero. In alternativa, ARC può chiamare:

void objc_destroyWeak(id * object)

Quindi, l'oggetto non è registrato e objc_destroyWeak chiama di nuovo:

objc_storeWeak(id *object, nil)

Questa tenuta della contabilità associata a un riferimento debole può richiedere 2-3 volte più a lungo rispetto al rilascio di un riferimento forte. Quindi, un riferimento debole introduce un sovraccarico per il runtime che è possibile evitare semplicemente definendo punti vendita come forti.

A partire da Xcode 7, suggerisce strong

Se guardi la sessione 407 del WWDC 2015 Implementare i disegni dell'interfaccia utente in Interface Builder , suggerisce (trascrizione da http://asciiwwdc.com/2015/sessions/407 )

E l'ultima opzione che voglio sottolineare è il tipo di archiviazione, che può essere forte o debole.

In generale, dovresti rafforzare il tuo outlet, specialmente se stai collegando un outlet a una vista secondaria o a un vincolo che non sarà sempre mantenuto dalla gerarchia della vista.

L'unica volta in cui è davvero necessario indebolire un punto vendita è se si dispone di una vista personalizzata che fa riferimento a qualcosa di backup della gerarchia della vista e in generale non è consigliabile.

Quindi sceglierò forte e farò clic su Connetti che genererà il mio punto vendita.

Nello sviluppo iOS il caricamento NIB è leggermente diverso dallo sviluppo Mac.

Nello sviluppo di Mac, un IBOutlet è di solito un riferimento debole: se si dispone di una sottoclasse di NSViewController, viene conservata solo la vista di livello superiore e quando si distribuisce il controller, tutte le sue visualizzazioni secondarie e punti vendita vengono liberati automaticamente.

UiViewController utilizza Key Value Coding per impostare i punti vendita utilizzando riferimenti forti. Pertanto, quando si distribuisce UIViewController, la vista superiore viene automaticamente deallocata, ma è necessario anche deallocare tutti i suoi punti vendita nel metodo dealloc.

In questo post del Big Nerd Ranch , trattano questo argomento e spiegano anche perché usare un forte riferimento in IBOutlet non è una buona scelta (anche se è raccomandato da Apple in questo caso).

Una cosa che vorrei sottolineare qui, e cioè, nonostante ciò che gli ingegneri Apple hanno dichiarato nel loro video del WWDC 2015 qui:

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

Apple continua a cambiare idea sull'argomento, il che ci dice che non esiste una sola risposta corretta a questa domanda. Per dimostrare che anche gli ingegneri Apple sono divisi su questo argomento, dai un'occhiata al codice di esempio più recente di Apple e vedrai alcune persone usare deboli, altre no.

In questo esempio di Apple Pay si usa debole: https://developer.apple.com/library/ios/samplecode/Emporium/Listings/Emporium_ProductTableViewController_swift.html#//apple_ref/doc/uid/TP40016175-Emporium_ProductTableViewController

Come fa questo esempio picture-in-picture: https://developer.apple.com/library/ios/samplecode/AVFoundationPiPPlayer/Listings/AVFoundationPiPPlayer_PlayerViewController_swift.html#//apple_ref/doc/uid/TP4001616PP_Viewer

Come nell'esempio Lister: https://developer.apple.com/library/ios/samplecode/Lister/Listings/Lister_ListCell_swift.html#//apple_ref/doc/uid/TP40014701-Lister_ListCell_swift-DontLinkElementID_57

Come nell'esempio Core Location: https://developer.apple.com/library/ios/samplecode/PotLoc/Listings/Potloc_PotlocViewController_swift.html#//apple_ref/doc/uid/TP40016176-Potloc_PotlocViewController_sinkiftDont

Come fa l'anteprima del controller di visualizzazione: https://developer.apple.com/library/ios/samplecode/ViewControllerPreviews/Listings/Projects_PreviewUsingDelegate_PreviewUsingDelegate_DetailViewController_swift.html_//elpre_view_pre_view

Come nel caso dell'esempio HomeKit: https://developer.apple.com/library/ios/samplecode/HomeKitCatalog/Listings/HMCatalog_Homes_Action_Sets_ActionSetViewController_swift.html#//apple_ref/DS_48_TP001

Tutti questi sono completamente aggiornati per iOS 9 e tutti usano punti deboli. Da ciò apprendiamo che A. Il problema non è così semplice come alcune persone pensano che sia. B. Apple ha cambiato idea più volte e C. Puoi usare tutto ciò che ti rende felice :)

Un ringraziamento speciale a Paul Hudson (autore di www.hackingwithsift.com) che mi ha dato il chiarimento e i riferimenti per questa risposta.

Spero che questo chiarisca un po 'meglio l'argomento!

Stai attento.

Dal WWDC 2015 c'è una sessione sull'implementazione di progetti di interfaccia utente in Interface Builder . Intorno al segno dei 32 minuti dice che vuoi sempre rendere @IBOutlet forte il tuo .

Essere consapevoli, IBOutletCollectiondovrebbe essere @property (strong, nonatomic).

Sembra che qualcosa sia cambiato nel corso degli anni e ora Apple consiglia di utilizzare forte in generale. Le prove sulla loro sessione del WWDC si trovano nella sessione 407 - Implementazione dei disegni dell'interfaccia utente in Interface Builder e inizia alle 32:30. La mia nota da ciò che dice è (quasi, se non esattamente, citandolo):

• le connessioni outlet in generale dovrebbero essere forti soprattutto se connettiamo una sottoview o un vincolo che non viene sempre mantenuto dalla gerarchia della vista

• potrebbe essere necessaria una connessione con presa debole quando si creano viste personalizzate che hanno qualche riferimento a qualcosa di backup nella gerarchia delle viste e in generale non è raccomandato

In altri reparti dovrebbe essere sempre forte ora, purché alcune delle nostre visualizzazioni personalizzate non creino un ciclo di conservazione con parte della vista in alto nella gerarchia delle viste

MODIFICARE :

Alcuni potrebbero porre la domanda. Mantenerlo con un riferimento forte non crea un ciclo di mantenimento come controller della vista principale e la vista proprietaria mantiene il riferimento ad esso? O perché quel cambiamento è successo? Penso che la risposta sia precedente in questo discorso quando descrivono come i pennini vengono creati dallo xib. È stato creato un pennino separato per un VC e per la vista. Penso che questo potrebbe essere il motivo per cui cambiano le raccomandazioni. Sarebbe comunque bello avere una spiegazione più approfondita da parte di Apple.

Penso che le informazioni più importanti siano: gli elementi in xib sono automaticamente nelle sottoview della vista. Sottoviste è NSArray. NSArray possiede i suoi elementi. ecc. hanno puntatori forti su di essi. Quindi nella maggior parte dei casi non si desidera creare un altro puntatore forte (IBOutlet)

E con ARC non devi fare nulla viewDidUnload