viewWillDisappear in iOS — l’essenza del metodo e come usarlo correttamente

Cos’è viewWillDisappear

viewWillDisappear è un metodo di UIViewController che UIKit chiama immediatamente prima che la View del controller inizi a scomparire dallo schermo. In questo momento lo schermo è ancora visibile all’utente, ma la transizione è già stata avviata: NavigationController ha iniziato l’animazione push/pop, la vista modale ha iniziato a chiudersi, o TabBar ha iniziato a cambiare scheda. Lo sviluppatore sovrascrive questo metodo per eseguire operazioni che richiedono che lo schermo sia ancora accessibile ma si stia preparando a nascondersi.

A differenza di viewDidDisappear, che si attiva dopo che lo schermo è nascosto, viewWillDisappear fornisce l’ultima opportunità per salvare dati e liberare risorse mentre l’utente può ancora vedere l’interfaccia. Questo è criticamente importante per l’UX — salvare una bozza o fermare un timer deve avvenire prima che l’utente passi a un altro schermo.

Il metodo accetta un parametro animated, che indica se la scomparsa è animata. true significa che UIKit sta eseguendo una transizione animata, false significa che lo schermo scompare istantaneamente, ad esempio durante un dismiss senza animazione o una rimozione programmatica dalla gerarchia.

Quando viene chiamato viewWillDisappear

viewWillDisappear viene chiamato in tutti gli scenari in cui lo schermo corrente cessa di essere attivo. Esaminiamo i principali casi specifici dello sviluppo iOS.

Durante il push di un nuovo schermo

Quando UINavigationController esegue il push di un nuovo controller, viewWillDisappear viene chiamato sul controller corrente all’inizio dell’animazione di transizione. In questo momento lo schermo corrente è ancora visibile sotto il nuovo controller che scorre sopra di esso. Questo è lo scenario standard in cui viewWillDisappear si attiva con animated = true.

Durante il pop dello schermo corrente

Quando l’utente preme il pulsante indietro o esegue uno swipe interattivo all’indietro, viewWillDisappear viene chiamato sul controller corrente. Con un gesto interativo questa chiamata può essere annullata se l’utente cambia idea e riporta lo schermo al suo posto. Questa è una caratteristica importante da considerare quando si progetta il salvataggio dello stato.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    saveDraftData()
    NotificationCenter.default.removeObserver(self)
}

Durante il dismiss di un controller

Durante la chiusura di una vista modale, viewWillDisappear viene chiamato sul controller in chiusura all’inizio dell’animazione di dismiss. A questo punto puoi restituire i risultati tramite un delegato o closure, poiché il controller che ha presentato la modale non ha ancora ripreso il controllo.

Durante il cambiamento di schede TabBar

UITabBarController chiama viewWillDisappear sul controller della scheda abbandonata subito dopo che l’utente ha toccato un’altra scheda. Se la scheda corrente ha processi attivi — riproduzione multimediale, download di file, timer — devono essere messi in pausa o fermati qui.

Compiti pratici in viewWillDisappear

viewWillDisappear risolve compiti specifici di gestione delle risorse e dello stato. Esaminiamo gli scenari chiave con esempi di codice.

Salvare i dati utente

Il compito più importante di viewWillDisappear è salvare i dati che l’utente ha inserito o modificato sullo schermo corrente. Bozze di messaggi, campi modulo modificati, impostazioni selezionate — tutto questo deve essere salvato prima che lo schermo scompaia. Utilizza Core Data, UserDefaults o archiviazione di file per la persistenza.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    guard hasUnsavedChanges else { return }
    draftStorage.save(currentDraft)
}

Annullare l’iscrizione alle notifiche

Gli abbonamenti a NotificationCenter, KVO e ai publisher Combine che hai effettuato in viewWillAppear o viewDidLoad devono essere cancellati in viewWillDisappear. Altrimenti, le notifiche arriveranno sullo schermo nascosto, causando aggiornamenti dell’interfaccia che l’utente non vede, o — peggio — crash dovuti all’accesso a oggetti già deallocati.

Fermare animazioni e timer

Le animazioni UIView avviate in viewDidAppear e i timer in esecuzione tramite Timer o DispatchSource devono essere fermati in viewWillDisappear. Le animazioni che continuano su uno schermo nascosto sprecono GPU e batteria senza alcun beneficio per l’utente. Fermali esplicitamente chiamando invalidate sui timer e removeAllAnimations sui layer.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    countdownTimer?.invalidate()
    countdownTimer = nil
    loadingIndicator.layer.removeAllAnimations()
}

Restituire dati

Se un controller è stato aperto per ottenere un risultato — selezione di un elemento, inserimento di testo, conferma di un’azione — viewWillDisappear è l’ultimo momento in cui il controller originale esiste ancora nello stack e può ricevere dati. Chiama il delegato o la closure prima che venga invocato deinit.

Strategia di salvataggio dello stato

Il salvataggio affidabile dello stato è uno dei compiti più difficili nello sviluppo iOS. viewWillDisappear è un elemento importante ma non l’unico della strategia. Consideriamo un approccio completo.

Livello 1 — salvataggio in viewWillDisappear. Salvataggio rapido di dati leggeri che dovrebbero essere disponibili immediatamente al ritorno. Adatto per lo stato dell’interfaccia: posizione di scorrimento, segmento selezionato, testo nei campi di input. Problema: su un gesto di pop interattivo annullato, il salvataggio avviene anche se l’utente è rimasto sullo schermo — i dati vengono sovrascritti inutilmente.

Livello 2 — salvataggio in viewDidDisappear. Duplica il salvataggio del primo livello ma si attiva solo dopo che lo schermo è garantitamente nascosto. Questa è una protezione contro i gesti annullati. Tuttavia, se ti sei già disiscritto dalle notifiche in viewWillDisappear, viewDidDisappear potrebbe non avere accesso ad alcuni dati.

Livello 3 — salvataggio tramite notifiche dell’applicazione. UIApplication.willResignActiveNotification e UIApplication.didEnterBackgroundNotification intercettano la minimizzazione dell’app. Se l’utente ha minimizzato l’app, viewWillDisappear potrebbe non essere stato chiamato — ma il salvataggio tramite queste notifiche garantisce l’integrità dei dati al termine della sessione.

Raccomandazione: utilizza una combinazione di tutti e tre i livelli per i dati utente critici. Per lo stato non critico, il primo livello è sufficiente. È importante non salvare gli stessi dati più volte — usa un flag dirty che indica che i dati sono cambiati dall’ultimo salvataggio.

Particolare attenzione va dedicata alla strategia per gli schermi CRUD dove l’utente inserisce dati. Su tali schermi non è raccomandato salvare ogni battitura in viewWillDisappear — è eccessivo. Utilizza il salvataggio automatico con ritardo (debounce) tramite Timer, e usa viewWillDisappear solo per il salvataggio forzato finale se ci sono modifiche non salvate. Questo approccio bilancia le prestazioni e l’integrità dei dati.

Per le app che utilizzano Core Data, una misura aggiuntiva è chiamare saveContext in viewWillDisappear solo quando ci sono modifiche reali nel contesto degli oggetti gestiti. Controllare context.hasChanges prima del salvataggio evita scritture non necessarie nell’archivio persistente e prolunga la durata della batteria del dispositivo. Combina questo controllo con il salvataggio globale in applicationDidEnterBackground.

Errori comuni in viewWillDisappear

L’uso scorretto di viewWillDisappear può portare a perdita di dati, perdite di memoria e comportamento instabile dell’app. Esaminiamo gli errori frequenti degli sviluppatori iOS.

Primo errore — salvare i dati solo in viewWillDisappear. Come discusso sopra, con un gesto di pop interattivo il metodo viene chiamato anche se lo schermo non è scomparso. Se il salvataggio ha effetti collaterali — invio di dati al server, cambiamento di stato — questo può portare a falsi attivazioni. Aggiungi un controllo di isBeingDismissed o isMovingFromParent.

Secondo errore — non annullare l’iscrizione a NotificationCenter. Questa è una delle perdite di memoria più comuni in iOS. Se ti sei iscritto in viewWillAppear a UIResponder.keyboardWillShowNotification ma non ti sei disiscritto in viewWillDisappear, la closure continuerà a essere chiamata. Al deinit del controller, la closure farà riferimento a un oggetto deallocato — crash dell’app garantito.

Terzo errore — esecuzione di operazioni sincrone pesanti. Salvare grandi quantità di dati, scrivere in Core Data o nel filesystem in viewWillDisappear blocca il thread principale. Se l’operazione dura più dell’animazione di transizione, UIKit mette in pausa il thread e l’interfaccia si blocca. Sposta i salvataggi pesanti in code in background.

Quarto errore — dimenticare di chiamare super. Non chiamare super.viewWillDisappear può rompere UINavigationController e UITabBarController, che utilizzano questo metodo per i loro stati interni. Chiama sempre super per primo o per ultimo, seguendo la documentazione Apple.

Questo problema è aggravato su iOS con il multitasking attivo e il cambio di app. Quinto errore — utilizzare DispatchQueue.main.async dopo il salvataggio in viewWillDisappear. Se invii in modo asincrono un blocco alla coda principale dopo aver chiamato super.viewWillDisappear, non c’è garanzia che il controller esista ancora al momento dell’esecuzione del blocco. Utilizza sempre riferimenti deboli [weak self] all’interno delle closure per evitare l’accesso a memoria deallocata e prevenire crash dell’app.