Pagpapanumbalik ng Estado sa mga Mobile App: ano ito, mekanismo at prinsipyo ng paggana

Ano ang State Restoration?

State Restoration (pagpapanumbalik ng estado) ay isang mekanismo ng system na nagpapahintulot na i-save ang kasalukuyang estado ng user interface ng application at ibalik ito pagkatapos isara o i-restart. Kapag ni-minimize ng user ang application o isinara ito ng system para magbakante ng resources, nire-record ng State Restoration ang mga pangunahing parameter ng UI at ini-save ang mga ito sa naka-encrypt na imbakan.

Kung walang State Restoration, nawawala ng user ang lahat ng hindi na-save na data kapag lumilipat sa pagitan ng mga application. Halimbawa, isang napunan na contact form, mahabang search query o bahagyang tiningnang listahan ng balita — lahat ito ay nawawala sa pag-restart. Nire-resolve ng State Restoration ang problemang ito sa pamamagitan ng awtomatikong pagre-record ng estado ng ViewController o Activity sa sandali ng pag-minimize.

Ang mekanismo ay gumagana sa antas ng system at sinusuportahan ng parehong pangunahing mobile platform. iOS ay nagbibigay ng State Restoration sa pamamagitan ng NSUserActivity at UIStateRestoring protocol, at Android — sa pamamagitan ng SavedStateHandle sa mga architectural component ng Jetpack at ViewModel. Ang implementasyon ay nag-iiba, ngunit ang konsepto ay magkapareho.

Paano gumagana ang mekanismo ng State Restoration?

Ang proseso ng State Restoration ay nahahati sa dalawang yugto: pag-save (save) at pagpapanumbalik (restore). Sa yugto ng pag-save, tinatawagan ng system ang mga kaukulang pamamaraan ng lifecycle kung saan dapat i-serialize ng application ang kasalukuyang estado ng UI sa isang compact na representasyon. Sa yugto ng pagpapanumbalik, ibinabalik ng system ang na-save na data, at dini-deserialize ito ng application para maibalik ang UI.

Mekanismo ng pag-save ng estado

Ang pag-save ay sinisimulan ng system kapag lumipat ang application sa background mode o kapag nakatanggap ng senyales ng nalalapit na pagsasara. Sa iOS, ang pamamaraang encodeRestorableState ay tinatawagan sa UIViewController, sa Android — onSaveInstanceState sa Activity o pag-save sa pamamagitan ng SavedStateHandle. Ang data ay isa-serialize sa format na sumusuporta sa mga primitive na uri: mga string, numero, byte array at Parcelable na mga bagay.

Ang dami ng na-save na data ay dapat minimal — ang system ay nagpapataw ng mga limitasyon sa laki ng na-save na pakete. Sa Android, ang limitasyon ay humigit-kumulang 50 KB bawat proseso. Ang paglampas sa limitasyon ay nagdudulot ng exception na TransactionTooLargeException. Kaya naman inirerekomenda ng mga arkitekto na i-save lamang ang mga identifier at key, at i-load ang kumpletong data mula sa permanenteng imbakan sa pagpapanumbalik.

Pagpapanumbalik ng UI mula sa na-save na estado

Sa pagpapanumbalik, inihahatid ng system ang na-save na data packet sa application sa sandali ng pagsisimula. Sa iOS, ang pamamaraang decodeRestorableState ay tinatawagan, sa Android — onRestoreInstanceState o pagbasa mula sa SavedStateHandle. Kinukuha ng application ang mga identifier at key mula sa packet at ibinabalik ang UI: posisyon ng scroll, mga napiling elemento, na-input na data.

Mahalagang isaalang-alang na ang pagpapanumbalik ay maaaring mangyari sa isang bagong proseso. Kung ang application ay ganap na na-unload mula sa memorya, ang proseso ay nilikha muli at lahat ng mga bagay sa memorya ay wala. Samakatuwid, ang estado ay dapat na serializable at independiyente sa runtime context ng nakaraang session. Ito ay lalong kritikal para sa malalaking form na may maraming input field at mahahabang multi-page na interface.

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 sa iOS at Android

Ang implementasyon ng State Restoration ay malaki ang pagkakaiba sa pagitan ng mga platform. iOS ay gumagamit ng deklaratibong approach sa pamamagitan ng storyboard at UIKit protocols, habang ang Android ay gumagamit ng imperatibong approach sa pamamagitan ng lifecycle method ng Activity at mga architectural component ng Jetpack. Ang pagpili ng approach ay depende sa target na platform at arkitektura ng application.

State Restoration sa iOS (UIKit)

Sa iOS, ang State Restoration ay binuo sa tatlong component: UIApplication ang namamahala sa pangkalahatang proseso, UIViewController ang nag-iimplementa ng UIStateRestoring protocol, at NSUserActivity ang nag-iimbak ng data para sa pagpapanumbalik ng nabigasyon. Para i-activate, kailangan mong itakda ang restorationIdentifier sa UIViewController at i-implement ang encodeRestorableState at decodeRestorableState.

Awtomatikong ini-save ng iOS ang estado ng navigation controller (UINavigationController) at lahat ng nested na ViewController, kung mayroon silang nakatakdang restorationIdentifier. Pinamamahalaan ng system ang navigation stack at ibinabalik ito sa orihinal na estado. Gayunpaman, ang data sa loob ng mga controller (na-input na text, posisyon ng scroll) ay dapat na malinaw na i-save ng developer.

State Restoration sa Android (SavedStateHandle)

Sa Android, ang modernong approach sa State Restoration ay nakabatay sa SavedStateHandle — isang component mula sa AndroidX Lifecycle library. Ang SavedStateHandle ay available sa loob ng ViewModel at awtomatikong nagse-save at nagre-restore ng data sa pagbabago ng configuration (pag-ikot ng screen) at sa pag-restart ng proseso. Ang data ay iniimbak sa Bundle at awtomatikong ise-serialize.

Ang SavedStateHandle ay kumikilos bilang isang key-value storage na may suporta sa LiveData. Sa pagbabago ng configuration, ang data ay awtomatikong nase-save at nare-restore. Para suportahan ang pag-restart ng proseso, ang ViewModel ay dapat na likhain sa pamamagitan ng SavedStateViewModelFactory — ito ay nagpapahintulot sa ViewModel na makaligtas sa kumpletong pagsasara ng application.

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
    }
}

Implementasyon ng State Restoration sa code

Ang praktikal na implementasyon ng State Restoration ay nangangailangan ng pagsasaalang-alang ng ilang aspeto: pagpili ng tamang imbakan, pagtukoy ng dami ng data na i-save, at pagsubok ng iba't ibang senaryo ng pagsasara. Tingnan natin ang step-by-step na implementasyon para sa isang Flutter application gamit ang state_restoration package.

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 ?? '';
  }
}

Sa implementasyon, mahalagang tandaan ang mga hangganan ng pag-save. Hindi bawat UI field ay kailangang ibalik. Posisyon ng scroll sa mahabang listahan — oo. Pansamantalang estado ng animation — hindi. Ang developer ay dapat na may kamalayang pumili kung aling data ang kritikal para sa karanasan ng user at alin ang maaaring ligtas na i-reset nang walang pagkawala ng kaginhawahan.

Ang pagsubok ng State Restoration ay isang hiwalay na gawain na nangangailangan ng simulasyon ng pagsasara ng proseso. Sa Android, ito ay maaaring gawin sa pamamagitan ng command na adb shell am kill, sa iOS — sa pamamagitan ng simulation ng pagsasara sa Xcode. Ang mga UI testing framework tulad ng Espresso at XCTest ay nagbibigay ng mga espesyal na pamamaraan para suriin ang pagpapanumbalik ng estado.

Pinakamahusay na kasanayan sa State Restoration

Unang panuntunan — i-save ang mga identifier, hindi ang data. Sa halip na i-save ang isang kumpletong bagay na may daan-daang field, i-save ang natatanging identifier nito, at sa pagpapanumbalik i-load ang kasalukuyang data mula sa database o API. Ito ay nakakatipid ng espasyo sa Bundle at ginagarantiyahan ang pagiging napapanahon ng data sa sandali ng pagpapanumbalik.

Pangalawang panuntunan — subukan ang lahat ng senaryo. Suriin ang pagpapanumbalik pagkatapos ng pag-ikot ng screen, pagkatapos i-minimize at bumalik pagkatapos ng isang oras, pagkatapos isara ng system ang application dahil sa kakulangan ng memorya. Ang bawat senaryo ay maaaring kumilos nang iba depende sa estado ng operating system at mga available na resources.

Pangatlong panuntunan — gamitin ang mga mekanismo ng system, hindi ang sarili mong mekanismo. Ang iOS at Android ay nagbibigay ng mga built-in na API para sa State Restoration na na-optimize para sa partikular na platform. Ang sariling implementasyon sa pamamagitan ng SharedPreferences o UserDefaults ay maaaring humantong sa mga problema sa synchronization at hindi inaasahang pag-uugali sa pagpapanumbalik.

Pang-apat na panuntunan — hawakan ang kawalan ng estado. Sa unang pagsisimula o pagkatapos ng pag-clear ng data, ang estado ay maaaring wala. Ang UI ay dapat gumana nang tama sa paunang estado nang hindi nagtatapon ng mga exception. Suriin ang lahat ng na-save na data para sa null bago gamitin at magbigay ng mga default na halaga.

Pang-limang panuntunan — idokumento ang mga naka-save na key. Kapag mayroong dose-dosenang mga screen sa proyekto at bawat isa ay nagse-save ng ilang field, kung walang sentralisadong pamamahala ng key ay magkakaroon ng kaguluhan. Gumawa ng isang klase o file na may mga constant ng key para sa State Restoration sa bawat module. Pinapasimple nito ang pagpapanatili at pumipigil sa aksidenteng pag-overwrite ng data sa refactoring.