viewWillAppear in iOS: l'essenza del metodo e come utilizzarlo

Cos'è viewWillAppear

viewWillAppear è un metodo UIViewController che UIKit chiama immediatamente prima di aggiungere la View alla gerarchia delle finestre. In questo momento, la View ha già le sue dimensioni finali dopo i passaggi di Auto Layout, ma non è ancora visibile all'utente — l'animazione di transizione non è ancora iniziata o è in corso. Lo sviluppatore sovrascrive questo metodo per eseguire operazioni che devono avvenire prima di ogni visualizzazione dello schermo.

A differenza di viewDidLoad, che viene attivato una sola volta, viewWillAppear viene chiamato ogni volta che lo schermo sta per apparire: all'apertura iniziale, al ritorno da un controller figlio, dopo la chiusura di una finestra modale e al cambio di schede del TabBar. Questo lo rende un metodo chiave per mantenere aggiornato lo stato dell'interfaccia.

Il metodo accetta un parametro animated di tipo Bool, che è true se l'apparizione dello schermo è accompagnata da animazione. Questo parametro è comodo da passare ai metodi NavigationBar e TabBar, che hanno anch'essi un parametro simile per un comportamento coerente.

Quando viene chiamato viewWillAppear

Il momento della chiamata di viewWillAppear dipende dal tipo di navigazione, ma la regola generale rimane invariata: il metodo viene attivato prima che la View diventi visibile. Consideriamo gli scenari principali.

Alla prima apertura dello schermo

Dopo viewDidLoad, UIKit inizia la preparazione alla visualizzazione: la View viene aggiunta alla gerarchia, i passaggi di layout vengono attivati, e immediatamente prima dell'inizio dell'animazione di transizione, viene chiamato viewWillAppear. In questo momento, lo schermo non è ancora visibile, ma tutte le subview hanno dimensioni corrette e il loro contenuto può essere aggiornato in modo sicuro.

Al ritorno dal NavigationController

Quando l'utente tocca il pulsante indietro o chiama programmaticamente popViewController, UIKit torna allo schermo precedente e chiama il suo viewWillAppear. Questo è lo scenario principale per utilizzare viewWillAppear — aggiornare una lista dopo l'aggiunta di un elemento o sincronizzare le impostazioni.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    updateBadgeCount()
}

Alla chiusura di una finestra modale

Dopo aver chiuso un controller presentato modalmente, UIKit chiama viewWillAppear sul controller che lo ha presentato. Questo scenario richiede particolare attenzione se si utilizzano delegati o closure per restituire dati — viewWillAppear garantisce che lo schermo si aggiorni dopo aver ricevuto il risultato.

Al cambio di schede del TabBar

TabBarController chiama viewWillAppear sul controller della scheda selezionata ogni volta che avviene un cambio. Se la scheda visualizza dati dinamici — tassi di cambio, notifiche, stato utente — viewWillAppear è il luogo ideale per aggiornarli.

Compiti pratici in viewWillAppear

viewWillAppear risolve diversi compiti specifici che sono impossibili o subottimali da eseguire in altri metodi. Vediamo i principali.

Aggiornare i dati della tabella

L'uso più comune di viewWillAppear è ricaricare una UITableView o UICollectionView ogni volta che lo schermo appare. Se i dati potrebbero essere cambiati sullo schermo precedente (elemento aggiunto, stato modificato), chiamare reloadData in viewWillAppear garantisce che l'utente veda informazioni aggiornate.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    viewModel.synchronize()
    tableView.reloadData()
}

Configurare NavigationBar e TabBar

In viewWillAppear è comodo configurare l'aspetto della NavigationBar: nasconderla o mostrarla, cambiarne il colore, impostare un titolo grande. Se schermi diversi hanno stili di NavigationBar differenti, viewWillAppear è il posto giusto per queste modifiche, poiché viewDidLoad viene chiamato solo una volta.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    navigationController?.setNavigationBarHidden(
        false, animated: animated
    )
    navigationController?.navigationBar.prefersLargeTitles = true
    tabBarController?.tabBar.isHidden = false
}

Sottoscrivere notifiche temporanee

Le notifiche che hanno senso solo quando lo schermo è visibile — notifiche di tastiera, notifiche di modifica del contenuto — vengono sottoscritte in viewWillAppear e annullate in viewDidDisappear. Ciò evita gestori non necessari quando lo schermo non è attivo e protegge da perdite di memoria.

Ripristinare lo stato dell'interfaccia

Se lo schermo può essere nascosto dall'app o minimizzato, viewWillAppear è un luogo comodo per ripristinare lo stato dell'interfaccia: cambiare segmenti, ripristinare la posizione di scorrimento, reimpostare modifiche temporanee. L'utente ottiene lo schermo in uno stato prevedibile ogni volta che appare.

Aggiornare badge e contatori

Sugli schermi che visualizzano contatori di messaggi non letti, valutazioni o notifiche, viewWillAppear è il posto giusto per aggiornarli. Se l'utente potrebbe aver cambiato la quantità su un altro schermo, qui vengono chiamati il ricalcolo e l'aggiornamento di UITabBarItem.badgeValue o degli indicatori personalizzati. Ciò garantisce che l'utente veda sempre numeri aggiornati indipendentemente da quanto tempo è stato su altri schermi.

Particolare attenzione va dedicata al lavoro con collectionView: se i dati sullo schermo sono presentati come una griglia con celle contenenti contatori o stati, il loro aggiornamento in viewWillAppear dovrebbe essere selettivo. Invece di un reloadData completo, usa reloadItemsAtIndexPaths per le celle visibili, per evitare sfarfallii e perdita della posizione di scorrimento.

Differenze tra viewWillAppear e viewDidLoad

Comprendere la differenza tra viewWillAppear e viewDidLoad è il fondamento di una corretta architettura UIViewController. Questi metodi hanno frequenza di chiamata, contesto e scopo diversi.

viewDidLoad viene chiamato una volta ed è adatto per configurazioni che non cambiano nel tempo: registrare celle, impostare delegati, inizializzare costanti. viewWillAppear viene chiamato ad ogni apparizione ed è adatto per operazioni che devono essere ripetute: aggiornare dati, configurare elementi visibili, sincronizzare lo stato.

La regola d'oro: se un'operazione deve essere eseguita una sola volta — mettila in viewDidLoad. Se deve essere eseguita ogni volta che torni allo schermo — mettila in viewWillAppear.

Errori comuni in viewWillAppear

L'uso scorretto di viewWillAppear può portare a problemi di prestazioni, aggiornamenti eccessivi e stato incoerente dell'interfaccia. Vediamo gli errori più comuni.

Il primo errore — duplicare la logica di viewDidLoad. Se registri le celle della tabella sia in viewDidLoad che in viewWillAppear, la registrazione verrà eseguita più volte, sebbene una configurazione una tantum sia sufficiente. Sposta tutte le configurazioni una tantum in viewDidLoad.

Il secondo errore — reloadData incondizionato ad ogni apparizione. Se i dati non sono cambiati, ricaricare la tabella causa query non necessarie al data source e ridisegno delle celle, riducendo le prestazioni. Verifica se lo stato è effettivamente cambiato prima di chiamare reloadData.

Il terzo errore — lavorare con richieste di rete senza considerare che lo schermo potrebbe essere nuovamente nascosto prima del completamento della richiesta. Se avvii una richiesta URLSession in viewWillAppear e l'utente naviga immediatamente verso un altro schermo, il risultato potrebbe essere applicato a una View già nascosta. Usa attività cancellabili o verifica isViewLoaded e window prima di aggiornare.

Il quarto errore — dimenticare di chiamare super. Non chiamare super.viewWillAppear può compromettere il comportamento dei controller padre (UINavigationController, UITabBarController) e portare a una gestione errata di gesti e transizioni. super deve essere sempre chiamato.

Il quinto errore — modificare i constraint senza chiamare layoutIfNeeded. Se modifichi i constraint programmaticamente in viewWillAppear, UIKit non li applica immediatamente — le modifiche si accumulano fino al successivo passaggio di layout. Per un'applicazione immediata delle modifiche dopo aver modificato i constraint, chiama view.layoutIfNeeded(). Questo è particolarmente importante quando si regola l'altezza di elementi dipendenti dal contenuto.

Il sesto errore — tentare di eseguire animazioni in viewWillAppear. Come menzionato sopra, UIKit sta ancora elaborando l'animazione di transizione e la tua animazione potrebbe competere con quella di sistema. Se hai bisogno che un elemento appaia con un effetto, usa l'animazione in entrata in viewDidAppear, e in viewWillAppear configura solo lo stato iniziale: trasparenza 0, transform a scala 0,8 e così via.

Il settimo errore — ignorare il parametro animated. Alcuni sviluppatori non controllano il valore di animated in viewWillAppear ed eseguono operazioni che dovrebbero dipendere dalla presenza dell'animazione. Ad esempio, nascondere la NavigationBar quando animated = false può essere fatto senza animazione, e quando animated = true — con animazione, in modo che la transizione sembri fluida. Passa sempre il parametro animated ai metodi UIKit appropriati.

L'ottavo errore — modificare l'interfaccia quando lo schermo non è visibile. Se avvii una richiesta di rete in viewWillAppear e il suo blocco di completion aggiorna l'interfaccia quando lo schermo potrebbe già essere scomparso, l'utente vedrà sfarfallio o stato incoerente. Verifica sempre isViewLoaded e window prima di aggiornare l'interfaccia nelle closure. Questa semplice azione previene crash e ridisegni non necessari dell'interfaccia.