Pemulihan Status di Aplikasi Seluler: apa itu, mekanisme dan prinsip kerja

Apa itu State Restoration?

State Restoration (pemulihan status) adalah mekanisme sistem yang memungkinkan menyimpan status antarmuka pengguna aplikasi saat ini dan memulihkannya setelah ditutup atau dijalankan ulang. Saat pengguna meminimalkan aplikasi atau sistem menutupnya untuk membebaskan sumber daya, State Restoration mencatat parameter utama UI dan menyimpannya di penyimpanan terenkripsi.

Tanpa State Restoration, pengguna kehilangan semua data yang belum disimpan saat beralih antar aplikasi. Misalnya, formulir kontak yang sudah diisi, kueri pencarian panjang atau daftar berita yang telah dilihat sebagian — semua itu hilang saat restart. State Restoration memecahkan masalah ini dengan secara otomatis merekam status ViewController atau Activity saat diminimalkan.

Mekanisme ini bekerja di tingkat sistem dan didukung oleh kedua platform seluler utama. iOS menyediakan State Restoration melalui NSUserActivity dan protokol UIStateRestoring, sedangkan Android melalui SavedStateHandle di komponen arsitektur Jetpack dan ViewModel. Implementasinya berbeda, tetapi konsepnya identik.

Bagaimana cara kerja mekanisme State Restoration?

Proses State Restoration dibagi menjadi dua fase: penyimpanan (save) dan pemulihan (restore). Pada fase penyimpanan, sistem memanggil metode siklus hidup yang sesuai di mana aplikasi harus men-serialisasi status UI saat ini menjadi representasi ringkas. Pada fase pemulihan, sistem mengirimkan data yang disimpan kembali, dan aplikasi melakukan deserialisasi untuk memulihkan UI.

Mekanisme penyimpanan status

Penyimpanan dimulai oleh sistem saat aplikasi beralih ke mode latar belakang atau saat menerima sinyal akan segera ditutup. Di iOS, metode encodeRestorableState dipanggil di UIViewController, di Android — onSaveInstanceState di Activity atau penyimpanan melalui SavedStateHandle. Data diserialisasi ke format yang mendukung tipe primitif: string, angka, array byte, dan objek Parcelable.

Volume data yang disimpan harus minimal — sistem memberlakukan batasan pada ukuran paket yang disimpan. Di Android, batasnya sekitar 50 KB per proses. Melebihi batas akan menyebabkan pengecualian TransactionTooLargeException. Oleh karena itu, arsitek merekomendasikan untuk menyimpan hanya pengidentifikasi dan kunci, dan memuat data lengkap dari penyimpanan permanen saat pemulihan.

Memulihkan UI dari status yang disimpan

Saat pemulihan, sistem mengirimkan paket data yang disimpan ke aplikasi saat startup. Di iOS, metode decodeRestorableState dipanggil, di Android — onRestoreInstanceState atau membaca dari SavedStateHandle. Aplikasi mengekstrak pengidentifikasi dan kunci dari paket dan memulihkan UI: posisi gulir, elemen yang dipilih, data yang dimasukkan.

Penting untuk diingat bahwa pemulihan dapat terjadi dalam proses baru. Jika aplikasi telah sepenuhnya dibongkar dari memori, proses dibuat ulang dan semua objek di memori tidak ada. Oleh karena itu, status harus dapat diserialisasi dan independen dari konteks runtime sesi sebelumnya. Ini sangat penting untuk formulir besar dengan banyak bidang input dan antarmuka multi-halaman yang panjang.

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 di iOS dan Android

Implementasi State Restoration berbeda secara signifikan antar platform. iOS menggunakan pendekatan deklaratif melalui storyboard dan protokol UIKit, sedangkan Android menggunakan pendekatan imperatif melalui metode siklus hidup Activity dan komponen arsitektur Jetpack. Pemilihan pendekatan tergantung pada platform target dan arsitektur aplikasi.

State Restoration di iOS (UIKit)

Di iOS, State Restoration dibangun di atas tiga komponen: UIApplication mengelola proses keseluruhan, UIViewController mengimplementasikan protokol UIStateRestoring, dan NSUserActivity menyimpan data untuk memulihkan navigasi. Untuk mengaktifkan, Anda perlu mengatur restorationIdentifier di UIViewController dan mengimplementasikan encodeRestorableState dan decodeRestorableState.

iOS secara otomatis menyimpan status pengontrol navigasi (UINavigationController) dan semua ViewController yang bersarang, jika mereka memiliki restorationIdentifier yang ditetapkan. Sistem mengelola tumpukan navigasi dan memulihkannya ke keadaan semula. Namun, data di dalam pengontrol (teks yang dimasukkan, posisi gulir) harus disimpan secara eksplisit oleh pengembang.

State Restoration di Android (SavedStateHandle)

Di Android, pendekatan modern untuk State Restoration didasarkan pada SavedStateHandle — komponen dari pustaka AndroidX Lifecycle. SavedStateHandle tersedia di dalam ViewModel dan secara otomatis menyimpan serta memulihkan data saat perubahan konfigurasi (rotasi layar) dan saat proses dijalankan ulang. Data disimpan di Bundle dan diserialisasi secara otomatis.

SavedStateHandle berperilaku seperti penyimpanan kunci-nilai dengan dukungan LiveData. Saat perubahan konfigurasi, data disimpan dan dipulihkan secara otomatis. Untuk mendukung proses restart, ViewModel harus dibuat melalui SavedStateViewModelFactory — ini memungkinkan ViewModel bertahan dari penutupan total aplikasi.

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

Implementasi State Restoration dalam kode

Implementasi praktis State Restoration memerlukan pertimbangan beberapa aspek: pemilihan penyimpanan yang tepat, penentuan volume data yang disimpan, dan pengujian berbagai skenario penutupan. Mari kita lihat implementasi langkah demi langkah untuk aplikasi Flutter menggunakan paket 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 ?? '';
  }
}

Saat implementasi, penting untuk mengingat batas penyimpanan. Tidak setiap bidang UI perlu dipulihkan. Posisi gulir di daftar panjang — ya. Status animasi sementara — tidak. Pengembang harus secara sadar memilih data mana yang penting untuk pengalaman pengguna dan mana yang dapat diatur ulang dengan aman tanpa kehilangan kenyamanan.

Pengujian State Restoration adalah tugas terpisah yang memerlukan simulasi penghentian proses. Di Android, ini dapat dilakukan melalui perintah adb shell am kill, di iOS — melalui simulasi penutupan di Xcode. Kerangka kerja pengujian UI seperti Espresso dan XCTest menyediakan metode khusus untuk memeriksa pemulihan status.

Praktik terbaik State Restoration

Aturan pertama — simpan pengidentifikasi, bukan data. Alih-alih menyimpan objek lengkap dengan ratusan bidang, simpan pengidentifikasi uniknya, dan saat pemulihan muat data terkini dari basis data atau API. Ini menghemat ruang di Bundle dan menjamin keakuratan data saat pemulihan.

Aturan kedua — uji semua skenario. Periksa pemulihan setelah rotasi layar, setelah diminimalkan dan kembali setelah satu jam, setelah aplikasi ditutup oleh sistem karena kehabisan memori. Setiap skenario dapat berperilaku berbeda tergantung pada status sistem operasi dan sumber daya yang tersedia.

Aturan ketiga — gunakan mekanisme sistem, bukan mekanisme sendiri. iOS dan Android menyediakan API bawaan untuk State Restoration yang dioptimalkan untuk platform tertentu. Implementasi sendiri melalui SharedPreferences atau UserDefaults dapat menyebabkan masalah sinkronisasi dan perilaku tidak terduga saat pemulihan.

Aturan keempat — tangani ketiadaan status. Pada startup pertama atau setelah penghapusan data, status mungkin tidak ada. UI harus berfungsi dengan benar dalam keadaan awal tanpa melempar pengecualian. Periksa semua data yang disimpan untuk null sebelum digunakan dan sediakan nilai default.

Aturan kelima — dokumentasikan kunci yang disimpan. Ketika ada puluhan layar dalam proyek dan masing-masing menyimpan beberapa bidang, tanpa manajemen kunci terpusat akan terjadi kekacauan. Buat satu kelas atau file dengan konstanta kunci untuk State Restoration di setiap modul. Ini menyederhanakan pemeliharaan dan mencegah penimpaan data secara tidak sengaja saat refactoring.