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:
ViewModel | Status instance tersimpan | Penyimpanan persisten | |
---|---|---|---|
Lokasi penyimpanan | dalam memori | diserialisasi ke disk | pada disk atau jaringan |
Tetap bertahan saat terjadi perubahan konfigurasi | Ya | Ya | Ya |
Tetap bertahan saat terjadi penghentian proses yang dimulai oleh sistem | Tidak | Ya | Ya |
Tetap bertahan saat terjadi penutupan aktivitas menyeluruh pengguna/onFinish() | Tidak | Tidak | Ya |
Keterbatasan data | objek kompleks tidak masalah, tetapi ruang dibatasi oleh memori yang tersedia | hanya untuk jenis primitif dan objek kecil sederhana seperti String | hanya dibatasi oleh ruang disk atau biaya/waktu pengambilan dari resource jaringan |
Waktu baca/tulis | cepat (hanya akses memori) | lambat (memerlukan serialisasi/deserialisasi dan akses disk) | lambat (memerlukan akses disk atau transaksi jaringan) |
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.
Kotlin
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) } }
Java
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.
Kotlin
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) ... }
Java
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 dionSaveInstanceState()
- 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 keViewModel
.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()
, danViewModel
telah menyimpan hasil penelusuran ke dalam cache. Anda meneruskan kueri dari paketonSaveInstanceState()
keViewModel
, 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.