Perché impostiamo il delegato su nil su dealloc se l'oggetto verrà distrutto comunque?

Question

-(void) scrollViewDidScroll:(UIScrollView *)scrollView 
{ 
    PO(NSStringFromCGPoint(self.tableView.contentOffset)); 
    PO(NSStringFromUIEdgeInsets(self.tableView.contentInset)); 

    while(false); 
} 

-(void)dealloc 
{ 
    PO(NSStringFromClass([self class])); 
    PO(@"Deallocated"); 
    self.tableView.delegate=nil; 
} 

Qui ho bisogno di impostare self.tableView.delegate = nil per evitare errori.

Sono consapevole, dalla mia domanda precedente, che self.tableView.delegate non diventerà automaticamente nill quando il delegato viene distrutto. Questo perché il tipo di delegato assegna il riferimento anziché il riferimento debole.

Tuttavia, che dire di self.tableView?

L'unica cosa con un forte riferimento a self.tableView è la superview che appartiene a self e self itsef.

Quindi quando self viene distrutto, anche self.tableView dovrebbe essere distrutto e ciò significa che anche self.tableView.delegate sarà eliminato.

Quindi, perché è necessario impostare self.tableView.delegate=nil;

Answer 1

Se si mantiene l'unico riferimento a self.tableView, non è necessario impostare il delegato su zero.

L'unica situazione in cui devi impostare il delegato su zero, se un'altra classe ha la tua classe come delegato, perché se la tua classe viene distrutta, quell'altra classe cercherà la tua classe per implementare alcuni metodi, e il tuo la chiamata non sarà lì.

Answer 2

In realtà questo non è richiesto. Lo stiamo facendo per evitare di formare il ciclo di conservazione. Non dovremmo creare un delegato con un forte riferimento. Se si crea accidentalmente un delegato con un riferimento forte, non verranno rilasciati sia padre che figlio. In tal caso, lo stesso dealloc non verrà chiamato. Quindi non è necessario.

Answer 3

In molti casi è necessario impostare il delegato su zero. Nel tuo caso tableView può essere referenziato da qualche classe esterna e non verrà distrutto dopo il tuo metodo dealloc di classe. E continuerà a chiamare il suo metodo delegato che porta al crash. Esistono diverse classi che funzionano in un altro thread (NSURLConnection per esempio). Anche se lo rilasci, può continuare a chiamare i metodi delegati poiché viene mantenuto in un altro thread.

Answer 4

consente di dire che abbiamo un SpriteKitscene dove si ha una gesture recognizer e si imposta il relativo delegate.

Quindi si dealloc questo scene e il suo recognizer dal suo controller.

Porterebbe a arresto se il metodo delegate è stato chiamato in scene durante questo processo.