Menyimpan status UI

Mempertahankan dan memulihkan status UI aktivitas secara tepat waktu pada aktivitas yang dimulai oleh sistem atau penghancuran aplikasi adalah bagian penting dari pengalaman pengguna. Dalam kasus ini pengguna mengharapkan status UI tetap sama, tetapi sistem menghancurkan aktivitas dan status apa pun yang tersimpan di dalamnya.

Untuk menutup kesenjangan antara ekspektasi pengguna dan perilaku sistem, gunakan kombinasi objek ViewModel, metode onSaveInstanceState(), dan/atau penyimpanan lokal untuk mempertahankan status UI pada transisi instance aktivitas dan aplikasi. Menentukan cara menggabungkan opsi ini bergantung pada kompleksitas data UI Anda, kasus penggunaan untuk aplikasi Anda, dan pertimbangan kecepatan pengambilan dibandingkan dengan penggunaan memori.

Terlepas dari pendekatan yang diambil, Anda harus memastikan bahwa aplikasi memenuhi ekspektasi pengguna sehubungan dengan status UI mereka, dan memberikan UI yang mulus dan cepat (menghindari keterlambatan waktu dalam memuat data ke dalam UI, terutama setelah perubahan konfigurasi yang sering terjadi, seperti rotasi). Biasanya, Anda harus menggunakan ViewModel dan onSaveInstanceState().

Halaman ini membahas ekspektasi pengguna tentang status UI, opsi yang tersedia untuk mempertahankan status, keseimbangan, dan keterbatasan masing-masing.

Ekspektasi pengguna dan perilaku sistem

Bergantung pada tindakan yang dilakukan oleh pengguna, mereka mengharapkan status aktivitas dihapus atau status dipertahankan. Pada beberapa kasus, sistem otomatis melakukan tindakan yang diharapkan oleh pengguna. Pada kasus lainnya, sistem melakukan kebalikan dari tindakan yang diharapkan oleh pengguna.

Penutupan status UI yang diinisialisasi pengguna

Pengguna mengharapkan bahwa saat mereka memulai aktivitas, status UI sementara dari aktivitas tersebut akan tetap sama hingga pengguna sepenuhnya menutup aktivitas. Pengguna dapat sepenuhnya menutup aktivitas dengan:

• menekan tombol kembali
• menggeser aktivitas di luar layar Ringkasan (Terbaru)
• menuju ke atas dari aktivitas
• menutup aplikasi dari layar Setelan
• menyelesaikan semacam aktivitas "penyelesaian" (yang didukung oleh Activity.finish())

Asumsi pengguna dalam kasus penutupan yang menyeluruh ini adalah bahwa pengguna menutup aktivitas secara permanen, dan jika aktivitas dibuka kembali, pengguna berharap aktivitas dimulai dari status bersih. Perilaku sistem yang mendasari skenario penutupan ini sesuai dengan ekspektasi pengguna - instance aktivitas akan dihancurkan dan dihapus dari memori, beserta status apa saja yang tersimpan di dalamnya dan catatan status instance tersimpan apa saja yang terkait dengan aktivitas.

Ada beberapa pengecualian aturan ini terkait penutupan menyeluruh -- misalnya pengguna mungkin berharap browser membawa pengguna ke halaman web yang mereka lihat sebelum keluar dari browser menggunakan tombol kembali.

Penutupan status UI yang dimulai oleh sistem

Pengguna berharap status UI aktivitas tetap sama selama perubahan konfigurasi, seperti rotasi atau beralih ke mode multi-aplikasi. Akan tetapi, secara default sistem menghancurkan aktivitas saat perubahan konfigurasi tersebut terjadi, dengan menghapus status UI apa saja yang tersimpan di instance aktivitas. Untuk mempelajari konfigurasi perangkat lebih lanjut, lihat halaman Referensi konfigurasi. Perlu diperhatikan, Anda dapat (meski tidak direkomendasikan) mengganti perilaku default untuk perubahan konfigurasi. Lihat Menangani Sendiri Perubahan Konfigurasi untuk detail selengkapnya.

Pengguna juga berharap status UI aktivitas tetap sama jika pengguna untuk sementara beralih ke aplikasi lain, lalu kembali ke aplikasi Anda nanti. Misalnya, pengguna melakukan penelusuran pada aktivitas penelusuran Anda, lalu menekan tombol layar utama atau menjawab panggilan telepon - saat pengguna kembali ke aktivitas penelusuran, pengguna berharap menemukan kata kunci penelusuran dan hasilnya tetap ada di sana, persis seperti sebelumnya.

Dalam skenario ini, aplikasi ditempatkan di latar belakang, sistem melakukan yang terbaik untuk mempertahankan proses aplikasi dalam memori. Akan tetapi, sistem dapat menghancurkan proses aplikasi saat pengguna berinteraksi dengan aplikasi lain. Dalam kasus tersebut, instance aktivitas dihancurkan, beserta status apa saja yang tersimpan di dalamnya. Saat pengguna meluncurkan ulang aplikasi, aktivitas secara tidak terduga berada dalam status bersih. Untuk mempelajari penghentian proses lebih lanjut, lihat Proses dan Siklus Proses Aplikasi.

Opsi untuk mempertahankan status UI

Jika ekspektasi pengguna tentang status UI tidak sesuai dengan perilaku sistem default, Anda harus menyimpan dan memulihkan status UI pengguna untuk memastikan bahwa penghancuran yang dimulai oleh sistem bersifat transparan kepada pengguna.

Tiap opsi untuk mempertahankan status UI bervariasi di sepanjang dimensi berikut yang memengaruhi pengalaman pengguna:

Menggunakan ViewModel untuk menangani perubahan konfigurasi

ViewModel ideal untuk menyimpan dan mengelola data terkait UI saat pengguna aktif menggunakan aplikasi. Ini memungkinkan akses cepat ke data UI dan membantu Anda menghindari pengambilan kembali data dari jaringan atau disk selama rotasi, perubahan ukuran jendela, dan perubahan konfigurasi lainnya yang umum terjadi. Untuk mempelajari cara mengimplementasikan ViewModel, lihat panduan ViewModel.

ViewModel menyimpan data dalam memori, yang artinya lebih murah diambil daripada data dari disk atau jaringan. ViewModel terkait dengan aktivitas (atau beberapa pemilik siklus proses lainnya) - dan tetap berada dalam memori selama perubahan konfigurasi dan sistem secara otomatis mengaitkan ViewModel dengan instance aktivitas baru yang dihasilkan dari perubahan konfigurasi.

ViewModel otomatis dihancurkan oleh sistem saat pengguna logout dari aktivitas atau fragmen Anda atau jika Anda memanggil finish(), yang berarti status akan dihapus seperti yang diharapkan pengguna dalam skenario ini.

Tidak seperti status instance yang tersimpan, ViewModel dihancurkan selama penghentian proses yang dimulai oleh sistem. Itu sebabnya Anda harus menggunakan objek ViewModel yang dikombinasikan dengan onSaveInstanceState() (atau persistensi disk lainnya), yang menyembunyikan ID dalam savedInstanceState untuk membantu melihat model memuat ulang data setelah penghentian sistem.

Jika Anda telah menyiapkan solusi dalam memori untuk menyimpan status UI selama perubahan konfigurasi, Anda mungkin tidak perlu menggunakan ViewModel.

Menggunakan onSaveInstanceState() sebagai cadangan untuk menangani penghentian proses yang dimulai oleh sistem

Callback onSaveInstanceState() menyimpan data yang diperlukan untuk memuat ulang status pengontrol UI, seperti aktivitas atau fragmen, jika sistem menghancurkan dan membuat ulang pengontrol tersebut. Untuk mempelajari cara mengimplementasikan status instance yang tersimpan, lihat Menyimpan dan memulihkan status aktivitas di panduan Siklus Proses Aktivitas.

Paket status instance yang tersimpan tetap bertahan saat terjadi perubahan konfigurasi dan penghentian proses, tetapi dibatasi oleh penyimpanan dan kecepatan karena onSavedInstanceState() melakukan serialisasi data ke disk. Serialisasi dapat menghabiskan banyak memori jika objek yang diserialisasi rumit. Karena proses ini terjadi pada thread utama selama perubahan konfigurasi, serialisasi yang berjalan lama dapat menyebabkan penurunan frame dan tampilan visual yang patah-patah.

Jangan gunakan penyimpanan onSavedInstanceState() untuk menyimpan data dalam jumlah besar, seperti bitmap, atau struktur data kompleks yang memerlukan serialisasi atau deserialisasi yang panjang. Simpan hanya jenis primitif dan objek yang kecil dan sederhana seperti String. Dengan demikian, gunakan onSaveInstanceState() untuk menyimpan jumlah data minimum yang diperlukan, seperti ID, untuk membuat ulang data yang diperlukan agar dapat memulihkan UI kembali ke keadaan sebelumnya jika mekanisme persistensi lainnya gagal. Sebagian besar aplikasi harus menerapkan onSaveInstanceState() untuk menangani proses penghentian yang dimulai oleh sistem.

Bergantung pada kasus penggunaan aplikasi, Anda mungkin tidak perlu menggunakan onSaveInstanceState() sama sekali. Misalnya, browser mungkin membawa pengguna kembali ke halaman web yang mereka lihat sebelum keluar dari browser. Jika aktivitas Anda menunjukkan perilaku seperti ini, Anda dapat mengabaikannya menggunakan onSaveInstanceState() dan mempertahankan semuanya secara lokal.

Selain itu, saat Anda membuka aktivitas dari suatu intent, paket berisi tambahan dikirimkan ke aktivitas saat konfigurasi berubah dan saat sistem memulihkan aktivitas. Jika sepotong data status UI, seperti kueri penelusuran, diteruskan sebagai tambahan intent saat aktivitas diluncurkan, Anda dapat menggunakan paket tambahan, bukan paket onSaveInstanceState(). Untuk mempelajari tambahan intent lebih lanjut, lihat Intent dan Filter Intent.

Dalam salah satu skenario ini, Anda tetap harus menggunakan ViewModel untuk menghindari pemborosan siklus pemuatan ulang data dari database selama perubahan konfigurasi.

Jika ingin mempertahankan data UI yang sederhana dan ringan, Anda cukup menggunakan onSaveInstanceState() untuk mempertahankan data status.

Mengaitkan ke status tersimpan menggunakan SavedStateRegistry

Mulai dari Fragment 1.1.0 atau dependensi transitifnya Activity 1.0.0, pengontrol UI, seperti Activity atau Fragment, mengimplementasikan SavedStateRegistryOwner dan memberikan SavedStateRegistry yang terikat dengan pengontrol tersebut. SavedStateRegistry memungkinkan komponen untuk terkait ke status tersimpan pengontrol UI untuk memakainya atau berkontribusi untuknya. Misalnya, modul Status Tersimpan untuk ViewModel menggunakan SavedStateRegistry untuk membuat SavedStateHandle dan memberikannya ke objek ViewModel Anda. Anda dapat mengambil SavedStateRegistry dari dalam pengontrol UI dengan memanggil getSavedStateRegistry().

Komponen yang berkontribusi pada status tersimpan harus mengimplementasikan SavedStateRegistry.SavedStateProvider, yang menentukan satu metode yang disebut saveState(). Metode saveState() memungkinkan komponen Anda menampilkan Bundle yang berisi status apa pun yang harus disimpan dari komponen tersebut. SavedStateRegistry memanggil metode ini selama fase status penyimpanan siklus proses pengontrol UI.

class SearchManager : SavedStateRegistry.SavedStateProvider {
    companion object {
        private const val QUERY = "query"
    }

    private val query: String? = null

    ...

    override fun saveState(): Bundle {
        return bundleOf(QUERY to query)
    }
}

class SearchManager implements SavedStateRegistry.SavedStateProvider {
    private static String QUERY = "query";
    private String query = null;
    ...

    @NonNull
    @Override
    public Bundle saveState() {
        Bundle bundle = new Bundle();
        bundle.putString(QUERY, query);
        return bundle;
    }
}

Untuk mendaftarkan SavedStateProvider, panggil registerSavedStateProvider() di SavedStateRegistry, dengan meneruskan kunci untuk dikaitkan dengan data penyedia serta penyedia. Data yang disimpan sebelumnya untuk penyedia dapat diambil dari status yang disimpan dengan memanggil consumeRestoredStateForKey() pada SavedStateRegistry, yang meneruskan kunci yang terkait dengan data penyedia.

Dalam Activity atau Fragment, Anda dapat mendaftarkan SavedStateProvider dalam onCreate() setelah memanggil super.onCreate(). Atau, Anda dapat menyetel LifecycleObserver di SavedStateRegistryOwner, yang menerapkan LifecycleOwner, dan mendaftarkan SavedStateProvider setelah ON_CREATE peristiwa terjadi. Dengan menggunakan LifecycleObserver, Anda dapat memisahkan pendaftaran dan pengambilan status tersimpan sebelumnya dari SavedStateRegistryOwner itu sendiri.

class SearchManager(registryOwner: SavedStateRegistryOwner) : SavedStateRegistry.SavedStateProvider {
    companion object {
        private const val PROVIDER = "search_manager"
        private const val QUERY = "query"
    }

    private val query: String? = null

    init {
        // Register a LifecycleObserver for when the Lifecycle hits ON_CREATE
        registryOwner.lifecycle.addObserver(LifecycleEventObserver { _, event ->
            if (event == Lifecycle.Event.ON_CREATE) {
                val registry = registryOwner.savedStateRegistry

                // Register this object for future calls to saveState()
                registry.registerSavedStateProvider(PROVIDER, this)

                // Get the previously saved state and restore it
                val state = registry.consumeRestoredStateForKey(PROVIDER)

                // Apply the previously saved state
                query = state?.getString(QUERY)
            }
        }
    }

    override fun saveState(): Bundle {
        return bundleOf(QUERY to query)
    }

    ...
}

class SearchFragment : Fragment() {
    private var searchManager = SearchManager(this)
    ...
}

class SearchManager implements SavedStateRegistry.SavedStateProvider {
    private static String PROVIDER = "search_manager";
    private static String QUERY = "query";
    private String query = null;

    public SearchManager(SavedStateRegistryOwner registryOwner) {
        registryOwner.getLifecycle().addObserver((LifecycleEventObserver) (source, event) -> {
            if (event == Lifecycle.Event.ON_CREATE) {
                SavedStateRegistry registry = registryOwner.getSavedStateRegistry();

                // Register this object for future calls to saveState()
                registry.registerSavedStateProvider(PROVIDER, this);

                // Get the previously saved state and restore it
                Bundle state = registry.consumeRestoredStateForKey(PROVIDER);

                // Apply the previously saved state
                if (state != null) {
                    query = state.getString(QUERY);
                }
            }
        });
    }

    @NonNull
    @Override
    public Bundle saveState() {
        Bundle bundle = new Bundle();
        bundle.putString(QUERY, query);
        return bundle;
    }

    ...
}

class SearchFragment extends Fragment {
    private SearchManager searchManager = new SearchManager(this);
    ...
}

Menggunakan persistensi lokal untuk menangani penghentian proses untuk data yang kompleks atau besar

Penyimpanan lokal persisten, seperti database atau preferensi bersama, akan bertahan selama aplikasi Anda diinstal di perangkat pengguna (kecuali pengguna menghapus data untuk aplikasi). Meski penyimpanan lokal tersebut bertahan selama aktivitas yang diprakarsai oleh sistem dan penghentian proses aplikasi, penyimpanan lokal tersebut dapat menjadi mahal untuk diambil karena harus dibaca dari penyimpanan lokal ke dalam memori. Biasanya penyimpanan lokal persisten mungkin sudah menjadi bagian dari arsitektur aplikasi untuk menyimpan semua data yang ingin Anda pertahankan jika Anda membuka dan menutup aktivitas.

ViewModel atau status instance tersimpan bukan solusi penyimpanan jangka panjang, dan oleh karena itu bukan pengganti penyimpanan lokal, seperti database. Anda harus menggunakan mekanisme ini hanya untuk menyimpan status UI sementara dan menggunakan penyimpanan persisten untuk data aplikasi lainnya. Lihat Panduan Arsitektur Aplikasi untuk detail selengkapnya tentang cara memanfaatkan penyimpanan lokal untuk mempertahankan data model aplikasi dalam jangka panjang (mis., setelah perangkat dimulai ulang beberapa kali).

Mengelola status UI: membagi dan menyelesaikan tugas

Anda dapat menyimpan dan memulihkan status UI secara efisien dengan cara membagi tugas ke beberapa jenis mekanisme persistensi. Biasanya, masing-masing mekanisme ini harus menyimpan jenis data yang berbeda yang digunakan dalam aktivitas, berdasarkan keseimbangan kompleksitas data, kecepatan akses, dan masa pakai:

• Persistensi lokal: Menyimpan semua data yang ingin Anda pertahankan saat membuka dan menutup aktivitas.
  • Contoh: Kumpulan objek lagu, yang dapat mencakup file audio dan metadata.
• ViewModel: Menyimpan semua data yang diperlukan untuk menampilkan Pengontrol UI teratribusi ke dalam memori.
  • Contoh: Objek lagu dari penelusuran terbaru dan kueri penelusuran terbaru.
• onSaveInstanceState(): Menyimpan sejumlah kecil data yang diperlukan untuk memuat ulang status aktivitas dengan mudah jika sistem terhenti dan kemudian membuat ulang Pengontrol UI. Daripada menyimpan objek kompleks di sini, pertahankan objek kompleks pada penyimpanan lokal dan simpan ID unik objek tersebut di onSaveInstanceState()
  • Contoh: Menyimpan kueri penelusuran terbaru.

Sebagai contoh, pertimbangkan aktivitas yang memungkinkan Anda menelusuri koleksi lagu Anda. Berikut adalah cara menangani berbagai peristiwa yang berbeda:

Saat pengguna menambahkan lagu, ViewModel segera mendelegasikan untuk mempertahankan data ini secara lokal. Jika lagu yang baru ditambahkan ini akan ditampilkan di UI, Anda juga harus memperbarui data dalam objek ViewModel untuk mencerminkan penambahan lagu. Ingatlah untuk melakukan semua penyisipan database dari thread utama.

Saat pengguna menelusuri sebuah lagu, data lagu sekompleks apa pun yang Anda muat dari database untuk Pengontrol UI harus segera disimpan dalam objek ViewModel . Anda juga harus menyimpan kueri penelusuran tersebut dalam objek ViewModel.

Saat aktivitas ini beralih ke latar belakang, sistem akan memanggil onSaveInstanceState(). Anda harus menyimpan kueri penelusuran dalam paket onSaveInstanceState(). Jumlah data yang kecil seperti ini mudah untuk disimpan. Data ini juga merupakan semua informasi yang Anda perlukan untuk memulihkan aktivitas kembali ke statusnya saat ini.

Memulihkan status kompleks: menyusun ulang setiap bagian

Jika saatnya bagi pengguna untuk kembali ke aktivitas, ada dua kemungkinan skenario dalam membuat ulang aktivitas:

• Aktivitas dibuat ulang setelah dihentikan oleh sistem. Aktivitas ini memiliki kueri yang tersimpan di paket onSaveInstanceState(), dan harus meneruskan kueri tersebut ke ViewModel. ViewModel melihat bahwa hasil penelusuran belum disimpan ke cache, dan mendelegasikan pemuatan hasil penelusuran, menggunakan kueri penelusuran yang diberikan.
• Aktivitas dibuat setelah perubahan konfigurasi. Aktivitas tersebut memiliki kueri yang disimpan dalam paket onSaveInstanceState(), dan ViewModel telah menyimpan hasil penelusuran ke dalam cache. Anda meneruskan kueri dari paket onSaveInstanceState() ke ViewModel, yang menentukan bahwa paket tersebut telah memuat data yang diperlukan dan tidak perlu mengkueri ulang database.

Referensi lainnya

Untuk mempelajari cara menyimpan status UI lebih lanjut, lihat referensi berikut.

Blog

• ViewModels: Contoh sederhana
• ViewModels: Persistensi, onSaveInstanceState(), Memulihkan Status dan Loader UI
• Codelab komponen berbasis siklus proses Android