Restaurarea stării în aplicațiile mobile: ce este, mecanismul și principiul de funcționare

Ce este State Restoration?

State Restoration (restaurarea stării) este un mecanism de sistem care permite salvarea stării curente a interfeței de utilizator a aplicației și restaurarea acesteia după închidere sau repornire. Când utilizatorul minimizează aplicația sau sistemul o închide pentru a elibera resurse, State Restoration înregistrează parametrii cheie ai UI și îi salvează într-un depozit criptat.

Fără State Restoration, utilizatorul pierde toate datele nesalvate la comutarea între aplicații. De exemplu, un formular de contact completat, o căutare lungă sau o listă de știri vizualizată parțial — totul dispare la repornire. State Restoration rezolvă această problemă, înregistrând automat starea ViewController sau Activity în momentul minimizării.

Mecanismul funcționează la nivel de sistem și este suportat de ambele platforme mobile principale. iOS oferă State Restoration prin NSUserActivity și protocolul UIStateRestoring, iar Android — prin SavedStateHandle în componentele arhitecturale Jetpack și ViewModel. Implementarea diferă, dar conceptul este identic.

Cum funcționează mecanismul State Restoration?

Procesul State Restoration se împarte în două faze: salvare (save) și restaurare (restore). În faza de salvare, sistemul apelează metodele corespunzătoare ale ciclului de viață, în care aplicația trebuie să serializeze starea curentă a UI într-o reprezentare compactă. În faza de restaurare, sistemul transmite datele salvate înapoi, iar aplicația le deserializizează pentru a restaura UI.

Mecanismul de salvare a stării

Salvarea este inițiată de sistem la trecerea aplicației în fundal sau la primirea unui semnal de închidere iminentă. În iOS este apelată metoda encodeRestorableState în UIViewController, în Android — onSaveInstanceState în Activity sau salvarea prin SavedStateHandle. Datele sunt serializate într-un format care suportă tipuri primitive: șiruri de caractere, numere, tablouri de octeți și obiecte Parcelable.

Volumul datelor salvate trebuie să fie minim — sistemul impune limite asupra dimensiunii pachetului salvat. În Android limita este de aproximativ 50 KB per proces. Depășirea limitei duce la excepția TransactionTooLargeException. De aceea, arhitecții recomandă salvarea doar a identificatorilor și cheilor, iar datele complete să fie încărcate din stocarea persistentă la restaurare.

Restaurarea UI din starea salvată

La restaurare, sistemul transmite pachetul de date salvat aplicației în momentul pornirii. În iOS este apelată metoda decodeRestorableState, în Android — onRestoreInstanceState sau citirea din SavedStateHandle. Aplicația extrage identificatorii și cheile din pachet și restaurează UI: poziția de derulare, elementele selectate, datele introduse.

Este important de reținut că restaurarea poate avea loc într-un proces nou. Dacă aplicația a fost descărcată complet din memorie, procesul este creat din nou și toate obiectele din memorie lipsesc. Prin urmare, starea trebuie să fie serializabilă și independentă de contextul de execuție al sesiunii anterioare. Acest lucru este deosebit de critic pentru formularele mari cu câmpuri multiple de intrare și interfețe lungi cu mai multe pagini.

class MainActivity : AppCompatActivity() {
    private var searchQuery: String = ""

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("search_query", searchQuery)
    }

    override fun onRestoreInstanceState(savedState: Bundle) {
        super.onRestoreInstanceState(savedState)
        searchQuery = savedState.getString("search_query", "")!!
        restoreSearchUI(searchQuery)
    }
}

State Restoration pe iOS și Android

Implementarea State Restoration diferă semnificativ între platforme. iOS utilizează o abordare declarativă prin storyboard și protocoale UIKit, iar Android — una imperativă prin metodele ciclului de viață Activity și componentele arhitecturale Jetpack. Alegerea abordării depinde de platforma țintă și arhitectura aplicației.

State Restoration în iOS (UIKit)

În iOS, State Restoration se bazează pe trei componente: UIApplication gestionează procesul general, UIViewController implementează protocolul UIStateRestoring, iar NSUserActivity stochează datele pentru restaurarea navigării. Pentru activare, trebuie să setați restorationIdentifier la UIViewController și să implementați encodeRestorableState și decodeRestorableState.

iOS salvează automat starea controlerului de navigare (UINavigationController) și a tuturor ViewController-urilor imbricate, dacă acestea au setat restorationIdentifier. Sistemul gestionează stiva de navigare și o restaurează în starea inițială. Cu toate acestea, datele din interiorul controlerelor (text introdus, poziția de derulare) trebuie salvate explicit de către dezvoltator.

State Restoration în Android (SavedStateHandle)

În Android, abordarea modernă a State Restoration se bazează pe SavedStateHandle — o componentă din biblioteca AndroidX Lifecycle. SavedStateHandle este disponibil în interiorul ViewModel și salvează și restaurează automat datele la schimbarea configurației (rotirea ecranului) și la repornirea procesului. Datele sunt stocate în Bundle și serializate automat.

SavedStateHandle se comportă ca un depozit cheie-valoare cu suport LiveData. La schimbarea configurației, datele sunt salvate și restaurate automat. Pentru a suporta repornirea procesului, ViewModel trebuie creat prin SavedStateViewModelFactory — acest lucru permite ViewModel să supraviețuiască închiderii complete a aplicației.

class SearchViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    companion object {
        private val KEY_QUERY = string("search_query")
    }

    fun getSearchQuery(): String? = savedStateHandle[KEY_QUERY]

    fun saveSearchQuery(query: String) {
        savedStateHandle[KEY_QUERY] = query
    }
}

Implementarea State Restoration în cod

Implementarea practică a State Restoration necesită luarea în considerare a mai multor aspecte: alegerea depozitului potrivit, determinarea volumului datelor salvate și testarea diferitelor scenarii de închidere. Să examinăm implementarea pas cu pas pentru o aplicație Flutter utilizând pachetul state_restoration.

class RestorableSearchField extends RestorableProperty<String> {
  String _value = '';

  @override
  String get value => _value;

  @override
  void set value(String newValue) {
    if (_value != newValue) {
      _value = newValue;
      notifyListeners();
    }
  }

  @override
  String? toPrimitives() => _value;

  @override
  void fromPrimitives(String? data) {
    _value = data ?? '';
  }
}

La implementare, este important să vă amintiți de limitele de salvare. Nu orice câmp UI trebuie restaurat. Poziția de derulare într-o listă lungă — da. Starea temporară a animațiilor — nu. Dezvoltatorul trebuie să aleagă conștient ce date sunt critice pentru experiența utilizatorului și care pot fi resetate în siguranță fără pierderea confortului.

Testarea State Restoration este o sarcină separată, care necesită simularea închiderii procesului. Pe Android, acest lucru se poate face prin comanda adb shell am kill, pe iOS — prin simularea închiderii în Xcode. Framework-urile de testare UI, precum Espresso și XCTest, oferă metode speciale pentru verificarea restaurării stării.

Cele mai bune practici State Restoration

Prima regulă — salvați identificatori, nu date. În loc să salvați un obiect complet cu sute de câmpuri, salvați identificatorul său unic, iar la restaurare încărcați datele actuale din baza de date sau API. Acest lucru economisește spațiu în Bundle și garantează actualitatea datelor la momentul restaurării.

A doua regulă — testați toate scenariile. Verificați restaurarea după rotirea ecranului, după minimizare și revenire după o oră, după închiderea aplicației de către sistem din cauza lipsei de memorie. Fiecare scenariu se poate comporta diferit în funcție de starea sistemului de operare și resursele disponibile.

A treia regulă — utilizați mecanismele de sistem, nu pe cele proprii. iOS și Android oferă API-uri încorporate pentru State Restoration, optimizate pentru platforma respectivă. Implementarea proprie prin SharedPreferences sau UserDefaults poate duce la probleme de sincronizare și comportament neașteptat la restaurare.

A patra regulă — gestionați absența stării. La prima pornire sau după ștergerea datelor, starea poate lipsi. UI trebuie să funcționeze corect în starea inițială fără a genera excepții. Verificați toate datele salvate pentru null înainte de utilizare și prevedeți valori implicite.

A cincea regulă — documentați cheile salvate. Când în proiect există zeci de ecrane și fiecare salvează câteva câmpuri, fără o gestionare centralizată a cheilor apare haosul. Creați o clasă sau un fișier unic cu constantele cheilor pentru State Restoration în fiecare modul. Acest lucru simplifică întreținerea și previne suprascrierile accidentale de date la refactorizare.