viewWillDisappear în iOS — esența metodei și cum să o folosești corect

Ce este viewWillDisappear

viewWillDisappear este o metodă a UIViewController pe care UIKit o apelează imediat înainte ca View-ul controlerului să înceapă să dispară de pe ecran. În acest moment, ecranul este încă vizibil pentru utilizator, dar tranziția a fost deja inițiată: NavigationController a început animația push/pop, fereastra modală a început să se închidă sau TabBar a început să comute pe o altă filă. Dezvoltatorul suprascrie această metodă pentru a executa operații care necesită ca ecranul să fie încă disponibil, dar se pregătește deja pentru ascundere.

Spre deosebire de viewDidDisappear, care se declanșează după ce ecranul este ascuns, viewWillDisappear oferă ultima șansă de a salva datele și de a elibera resursele în timp ce utilizatorul încă vede interfața. Acest lucru este esențial pentru UX — salvarea unei ciorne sau oprirea unui timer trebuie să aibă loc înainte ca utilizatorul să treacă la un alt ecran.

Metoda primește parametrul animated, care indică dacă dispariția are loc cu animație. Valoarea true înseamnă că UIKit execută tranziția cu animație, false — ecranul dispare instantaneu, de exemplu la dismiss fără animație sau la ștergerea programatică din ierarhie.

Când este apelat viewWillDisappear

viewWillDisappear este apelat în toate scenariile în care ecranul curent încetează să fie activ. Să analizăm cazurile principale specifice dezvoltării iOS.

La push-ul unui nou ecran

Când UINavigationController execută push-ul unui nou controler, la controlerul curent este apelat viewWillDisappear la începutul animației de tranziție. În acest moment, ecranul curent este încă vizibil sub noul controler care alunecă peste el. Acesta este scenariul standard în care viewWillDisappear se declanșează cu animated = true.

La pop-ul ecranului curent

Când utilizatorul apasă butonul înapoi sau execută un swipe interactiv înapoi, la controlerul curent este apelat viewWillDisappear. La gestul interactiv, această apelare poate fi anulată dacă utilizatorul s-a răzgândit și a readus ecranul la locul său. Aceasta este o caracteristică importantă care trebuie luată în considerare la proiectarea salvării stării.

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

La dismiss-ul controlerului

La închiderea ferestrei modale, viewWillDisappear este apelat pe controlerul care se închide la începutul animației de dismiss. În acest moment, se pot transmite rezultatele înapoi prin delegat sau closure, deoarece controlerul care a prezentat fereastra modală nu a primit încă controlul.

La comutarea filelor TabBar

UITabBarController apelează viewWillDisappear pe controlerul filei părăsite imediat după ce utilizatorul atinge o altă filă. Dacă pe fila curentă există procese active — redare media, încărcare fișier, timer — aici ele sunt întrerupte sau oprite.

Sarcini practice în viewWillDisappear

viewWillDisappear rezolvă sarcini concrete de gestionare a resurselor și stării. Să analizăm scenariile cheie cu exemple de cod.

Salvarea datelor utilizatorului

Cea mai importantă sarcină a viewWillDisappear — salvarea datelor pe care utilizatorul le-a introdus sau modificat pe ecranul curent. Ciorne de mesaje, câmpuri de formular editate, setări selectate — toate acestea trebuie salvate înainte ca ecranul să dispară. Folosiți Core Data, UserDefaults sau stocare în fișiere pentru persistență.

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

Dezabonarea de la notificări

NotificationCenter, KVO și publisherii Combine la care v-ați abonat în viewWillAppear sau viewDidLoad trebuie anulați în viewWillDisappear. Dacă nu faceți acest lucru, notificările vor ajunge la ecranul ascuns, provocând actualizări UI pe care utilizatorul nu le vede sau, mai rău — căderi din cauza referințelor la obiecte deja eliberate.

Oprirea animațiilor și timerelor

Animațiile UIView pornite în viewDidAppear și timerele care funcționează prin Timer sau DispatchSource trebuie oprite în viewWillDisappear. Animațiile care continuă pe un ecran ascuns consumă GPU și bateria fără niciun beneficiu pentru utilizator. Opriți-le explicit, apelând invalidate la timere și removeAllAnimations la straturi.

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

Transmiterea datelor înapoi

Dacă controlerul a fost deschis pentru a obține un rezultat — selectarea unui element, introducerea textului, confirmarea unei acțiuni — viewWillDisappear este ultimul moment în care controlerul original mai există în stivă și poate primi date. Apelați delegatul sau closure-ul înainte ca deinit să fie apelat.

Strategia de salvare a stării

Salvarea fiabilă a stării ecranului este una dintre cele mai dificile sarcini în dezvoltarea iOS. viewWillDisappear este un element important, dar nu singurul al strategiei. Să analizăm o abordare complexă.

Nivelul 1 — salvare în viewWillDisappear. Salvarea rapidă a datelor ușoare care trebuie să fie disponibile imediat după revenire. Potrivit pentru starea UI: poziția de derulare, segmentul selectat, textul din câmpurile de intrare. Problemă: la gestul interactiv pop anulat, salvarea are loc deși utilizatorul a rămas pe ecran — datele sunt suprascrise inutil.

Nivelul 2 — salvare în viewDidDisappear. Dublează salvarea de la primul nivel, dar se declanșează numai după ce ecranul este garantat ascuns. Aceasta este o asigurare împotriva gesturilor anulate. Totuși, dacă în viewWillDisappear v-ați dezabonat deja de la notificări, viewDidDisappear poate să nu aibă acces la unele date.

Nivelul 3 — salvare prin notificări ale aplicației. UIApplication.willResignActiveNotification și UIApplication.didEnterBackgroundNotification interceptează minimizarea aplicației. Dacă utilizatorul a minimizat aplicația, viewWillDisappear poate să nu fi fost apelat — dar salvarea prin aceste notificări garantează integritatea datelor la încheierea sesiunii.

Recomandare: folosiți combinația tuturor celor trei niveluri pentru datele critice ale utilizatorului. Pentru starea necritică — primul nivel este suficient. Este important să nu suprascrieți aceleași date în mod repetat — folosiți un flag dirty care indică dacă datele s-au modificat de la ultima salvare.

O atenție deosebită trebuie acordată strategiei pentru ecranele CRUD, unde utilizatorul introduce date. Pe astfel de ecrane nu se recomandă salvarea fiecărei apăsări de tastă în viewWillDisappear — este redundant. Folosiți auto-save cu întârziere (debounce) prin Timer, iar viewWillDisappear aplicați doar pentru salvarea forțată finală, dacă există modificări nesalvate. O astfel de abordare face echilibrul între performanță și siguranța datelor.

Pentru aplicațiile cu Core Data, o măsură suplimentară este apelarea saveContext în viewWillDisappear numai atunci când există modificări reale în managed object context. Verificarea context.hasChanges înainte de salvare previne scrierile inutile în persistent store și prelungește durata de viață a bateriei dispozitivului. Combinați această verificare cu salvarea globală în applicationDidEnterBackground.

Greșeli tipice în viewWillDisappear

Utilizarea incorectă a viewWillDisappear poate duce la pierderea datelor, scurgeri de memorie și comportament instabil al aplicației. Să analizăm greșelile frecvente ale dezvoltatorilor iOS.

Prima greșeală — salvarea datelor doar în viewWillDisappear. După cum s-a discutat mai sus, la gestul interactiv pop metoda este apelată chiar dacă ecranul nu dispare. Dacă salvarea are efecte secundare — trimiterea datelor la server, modificarea stării — aceasta poate duce la declanșări false. Adăugați verificarea isBeingDismissed sau isMovingFromParent.

A doua greșeală — lipsa dezabonării de la NotificationCenter. Aceasta este una dintre cele mai frecvente scurgeri de memorie în iOS. Dacă v-ați abonat în viewWillAppear la UIResponder.keyboardWillShowNotification, dar nu v-ați dezabonat în viewWillDisappear, closure-ul continuă să fie apelat. La deinit-ul controlerului, closure-ul va face referire la un obiect eliberat — căderea aplicației este garantată.

A treia greșeală — executarea operațiilor sincrone grele. Salvarea unui volum mare de date, scrierea în Core Data sau sistemul de fișiere în viewWillDisappear blochează main thread-ul. Dacă operația durează mai mult decât animația de tranziție, UIKit întrerupe firul de execuție și interfața îngheață. Transferați salvările grele în cozi de fundal.

A patra greșeală — a uita să apelați super. Neapelarea super.viewWillDisappear poate perturba funcționarea UINavigationController și UITabBarController, care folosesc această metodă pentru stările lor interne. Apelați întotdeauna super primul sau ultimul, conform documentației Apple.

Această problemă se agravează pe iOS cu multitasking activ și comutări între aplicații. A cincea greșeală — utilizarea DispatchQueue.main.async după salvare în viewWillDisappear. Dacă trimiteți asincron un bloc în coada principală după apelarea super.viewWillDisappear, nu există garanția că controlerul mai există la momentul executării blocului. Folosiți întotdeauna referințe slabe [weak self] în interiorul closure-urilor pentru a preveni referirea la memoria eliberată și a preveni căderea aplicației.