Che cosa esattamente willMoveToParentViewController: e didMoveToParentViewController: do?

So che a partire con iOS5 e dei nuovi metodi di contenimento UIViewController, si suppone di chiamare questi metodi insieme addChildViewController:, removeFromParentViewController: e il metodo di transizione. Conosco anche l'ordine corretto di chiamarli nei tre scenari. Quello che non so è esattamente cosa fanno questi metodi?Che cosa esattamente willMoveToParentViewController: e didMoveToParentViewController: do?

Se questi erano solo punti di sostituzione per sottoclassi di UIViewController, suppongo che non saremmo obbligati a chiamare super in caso di override. Cosa può/andrà storto se non chiamo willMoveToParentViewController: nil prima di rimuovere un controller di visualizzazione o didMoveToParentViewController: self?

fonte

2012-10-16 konrad

In aggiunta a quanto detto, che fanno chiamare alcuni metodi delegato:

addChildViewController chiamate [child willMoveToParentViewController:self]

e removeFromParentViewController: chiamate [child didMoveToParentViewController:nil]

Inoltre, modificano la proprietà childViewControllers, che contiene una matrice dei controller di visualizzazione figlio.

fonte

2012-10-16 08:20:25 Guillaume

Sì, lo so, 'aggiungi' e 'rimuovi' chiama un metodo automaticamente (willMove ... e didMove ... rispettivamente) e richiede di chiamare l'altro manualmente. Penso di non avere problemi con la comprensione di cosa "aggiungi" e "rimuovi": sembra piuttosto complicato. Mi sento un po 'confuso su ciò che in realtà fanno la' volontà 'e' fatto '. – konrad

'will' e' didè' non hanno un'implementazione particolare, li chiami sul controller figlio, e se non lo fai, non vengono semplicemente chiamati ... il che potrebbe essere un problema se il bambino il controller li ha implementati e si è basato su di essi. Nella mia risposta li ho erroneamente definiti "metodi delegati", ma questo è quasi quello che sono, funzionano come metodi delegati opzionali e il bambino potrebbe usarli per eseguire alcune operazioni di configurazione o pulizia. Qualunque sottoclasse di UIViewController potrebbe sovrascriverli, e se si implementa un controller contenitore, si suppone che si debba rispettare questo comportamento e chiamarli. – Guillaume

Per essere chiari, 'willMoveToParentViewController di UIViewController:' e 'didMoveToParentViewController:' non fanno nulla. Tuttavia, qualsiasi sottoclasse consente loro di essere sovrascritti, quindi se non li chiami, non interromperesti un UIViewController, ma interromperesti le sottoclassi che si basano su di esso (ad esempio: una sottoclasse vuole rilasciare un oggetto quando viene rimosso da un controller di visualizzazione padre, se non si chiama il metodo, quindi non rilascerà mai l'oggetto). – Guillaume

Ci sono molte risposte a questo:

Sono lì e si sono tenuti a chiamarli se del caso a sostenere sempre il modello. In questo modo, se cambi le superclasse da UIViewController al tuo controller di visualizzazione, non dovrai preoccuparti di dove hai seguito l'intero schema.
Sono luoghi migliori in cui aggrapparsi che dire a tutti di ignorare addChildViewController:. Come dici tu, l'errata gestione di willMoveToParentViewController: suona come se fosse meno pericoloso della manomissione errata addChildViewController:, soprattutto se ti dimentichi di chiamare super.
UIViewController probabilmente dipende dal mantenimento del modello. Forse riterrà lo stato incoerente se sa di aver ricevuto addChildViewController: ma non ottiene mai gli altri due messaggi. Se questo accade a causa di UIViewController fare la contabilità per attirarti a sostenere il modello completo o se davvero fai confusione nel suo stato interno è un gioco di indovinelli divertente, ma anche qualcosa che potrebbe cambiare in qualsiasi versione di iOS. Le cose potrebbero rompersi male. Ecco perché il modello è lì, perché Apple ti possa dire che finché lo farai, manterremo le cose funzionanti, non importa quale.

Mettere in discussione un modello è buona, ma ci sono molti potenziali negativi che vengono con il tentativo di tagliare il conformità di un modello per l'osso. A meno che il modello non sia coinvolto in modo ridicolo, di solito è più semplice conformarsi ad esso.

fonte

2012-10-16 08:11:31 Jesper

Non intendo mettere in dubbio l'utilizzo di questi metodi. Se i documenti Apple dicono "devi" chiamarli, c'è sicuramente una ragione dietro di essi. Spero solo che qualcuno con un po 'più di esperienza e conoscenza del meccanismo di nidificazione di UIViewControllers lo spiegherà in modo un po' più dettagliato rispetto ai documenti ufficiali che dicono solo che "informa" il controllore della visione del bambino sulla modifica. La mia teoria è che consente un po 'di preparazione e pulizia se si desidera che la transizione sia animata, ma è solo un'ipotesi. – konrad

Oh, questo è ciò che verrà utilizzato se si sottoclasse un 'UIViewController'. Il mio punto era che anche se non avesse fatto nulla, sapendo che non avrebbe reso la chiamata "super" qualcosa che dovresti evitare. Forse è meglio riassunto da "lo rende molto meno complicato perché non dovrai sovrascrivere' addChildViewController: '" (punto 2). – Jesper

Che cosa esattamente willMoveToParentViewController: e didMoveToParentViewController: do?

risposta

Problemi correlati