SharedPreferences: apa itu, penyimpanan kunci-nilai Android

Apa itu SharedPreferences?

SharedPreferences adalah mekanisme bawaan Android untuk menyimpan pasangan kunci-nilai dalam file XML di penyimpanan internal perangkat. Tersedia sejak API Level 1 dan tidak memerlukan pustaka tambahan. Tujuan utama — menyimpan pengaturan pengguna, status antarmuka, flag first-launch dan data sederhana lainnya yang tidak memerlukan basis data terstruktur.

Setiap file SharedPreferences terkait dengan nama tertentu dan mode akses. Secara default digunakan mode Context.MODE_PRIVATE, yang membatasi akses ke file hanya untuk aplikasi saat ini. Sebelumnya Android mendukung mode MODE_WORLD_READABLE dan MODE_WORLD_WRITEABLE, tetapi mode tersebut dinyatakan usang sejak API Level 17 dan dihapus sepenuhnya di Android 7.0 (API 24) karena alasan keamanan.

Meskipun sederhana, SharedPreferences digunakan di jutaan aplikasi Android. Menurut Google, lebih dari 90% aplikasi yang dipublikasikan di Google Play menggunakan SharedPreferences untuk menyimpan pengaturan. Namun untuk skenario kompleks (volume data besar, keamanan tipe, asinkronitas) Google merekomendasikan solusi yang lebih modern seperti Preferences DataStore dari pustaka Android Jetpack.

Format penyimpanan: XML di perangkat

Secara fisik, SharedPreferences disimpan sebagai file XML di direktori aplikasi: /data/data/{package_name}/shared_prefs/{file_name}.xml. File berisi elemen root <map> dengan elemen anak <string>, <int>, <boolean>, <float> dan <long> tergantung pada tipe nilai yang disimpan. Ukuran file tidak dibatasi, tetapi untuk volume data besar (lebih dari 100 KB) kinerja baca dan tulis mulai menurun secara signifikan.

File SharedPreferences tidak dienkripsi secara default. Data disimpan dalam bentuk terbuka di sistem file perangkat. Untuk menyimpan data sensitif (token, kata sandi) disarankan menggunakan EncryptedSharedPreferences dari pustaka AndroidX Security, yang secara otomatis mengenkripsi kunci dan nilai menggunakan AES256-GCM.

Bagaimana SharedPreferences bekerja di Android

SharedPreferences bekerja berdasarkan prinsip caching di memori dengan sinkronisasi periodik ke disk. Pada akses pertama ke file (melalui getSharedPreferences), Android memuat file XML ke dalam RAM dan mem-parse-nya menjadi objek Map. Semua operasi baca selanjutnya dilakukan dari memori, tanpa membaca ulang dari disk. Ini memastikan kecepatan akses data yang tinggi.

Operasi penulisan menggunakan Editor — buffer internal perubahan. Ketika pengembang memanggil putString atau putBoolean, perubahan disimpan dalam objek Editor di memori. Penulisan aktual ke disk terjadi saat metode commit (sinkron) atau apply (asinkron) dipanggil. Sampai metode ini dipanggil, data tidak disimpan dan jika aplikasi berhenti secara paksa, perubahan dapat hilang.

Mode akses dan konteks

Untuk mendapatkan instance SharedPreferences digunakan dua metode: getPreferences dan getSharedPreferences. Pertama hanya tersedia di dalam Activity dan membuat file dengan nama Activity. Kedua lebih fleksibel, menerima nama file dan mode akses, dan tersedia dari konteks mana pun (Application, Activity, Service). Disarankan menggunakan getSharedPreferences dengan nama file yang sesuai dengan modul atau fungsionalitas aplikasi.

// Mendapatkan SharedPreferences
val prefs = context.getSharedPreferences(
    "user_settings", Context.MODE_PRIVATE
)

// Menulis data
with(prefs.edit()) {
    putString("username", "Anna")
    putInt("age", 28)
    putBoolean("isLoggedIn", true)
    apply()
}

// Membaca data
val username = prefs.getString("username", "")
val age = prefs.getInt("age", 0)
val isLoggedIn = prefs.getBoolean("isLoggedIn", false)

Saat menggunakan MODE_MULTI_PROCESS (usang) SharedPreferences disinkronkan antar proses. Namun sinkronisasi ini tidak menjamin atomicitas, dan Google merekomendasikan untuk menghindari penggunaan SharedPreferences dalam skenario multi-process. Untuk kasus seperti itu, lebih baik menggunakan ContentProvider, Room dengan akses antar-proses atau DataStore.

Metode utama SharedPreferences

SharedPreferences menyediakan serangkaian metode untuk membaca data berdasarkan kunci dan antarmuka Editor untuk menulis. Setiap metode baca menerima dua parameter: kunci dan nilai default yang dikembalikan jika kunci tidak ditemukan. Nilai default juga menentukan tipe nilai yang dikembalikan: getString mengembalikan String, getInt mengembalikan Int dan seterusnya.

Editor dan apply vs commit

Editor — objek internal SharedPreferences yang mengumpulkan perubahan dalam buffer. Setelah semua perubahan dilakukan, pengembang memanggil commit() (penulisan sinkron) atau apply() (penulisan asinkron). Perbedaannya kritis: commit memblokir thread saat ini hingga penulisan ke disk selesai dan mengembalikan boolean (berhasil/gagal), sedangkan apply melakukan penulisan di thread latar belakang dan segera mengembalikan kontrol, tetapi tidak mengembalikan hasil.

Disarankan menggunakan apply daripada commit dalam semua kasus ketika hasil penulisan tidak perlu diketahui. apply lebih cepat dan tidak memblokir thread UI. commit hanya boleh digunakan ketika penting untuk mengetahui apakah data berhasil disimpan atau saat bekerja dengan mode multi-process. Untuk menghapus kunci individu digunakan metode remove, untuk pembersihan total — clear. Semua operasi penghapusan juga dilakukan melalui Editor.

// Beberapa perubahan - satu apply
prefs.edit {
    putString("theme", "dark")
    putBoolean("notifications", false)
    remove("old_key")
}

// Pendengar perubahan nilai
prefs.registerOnSharedPreferenceChangeListener { prefs, key ->
    Log.d("TAG", "Kunci berubah: $key")
}

Mulai Android 12 (API 31), SharedPreferences dilengkapi dengan dukungan untuk registerOnSharedPreferenceChangeListener dengan pembatalan langganan otomatis melalui Lifecycle. Ini memungkinkan menghindari kebocoran memori yang terkait dengan listener yang terlupakan. Di versi yang lebih lama, pengembang wajib memanggil secara manual unregisterOnSharedPreferenceChangeListener di onDestroy atau onStop komponen.

SharedPreferences vs alternatif penyimpanan

Meskipun tersebar luas, SharedPreferences bukanlah solusi universal untuk semua skenario penyimpanan data di Android. Tergantung pada volume data, persyaratan keamanan tipe dan kinerja, Google merekomendasikan berbagai alternatif yang termasuk dalam Android Jetpack dan pustaka standar Android.

DataStore — alternatif modern

DataStore — pustaka Android Jetpack, diperkenalkan oleh Google sebagai pengganti SharedPreferences. Menawarkan dua varian: Preferences DataStore (kunci-nilai, seperti SharedPreferences) dan Proto DataStore (penyimpanan bertipe melalui Protocol Buffers). DataStore menggunakan coroutine dan Flow untuk kerja asinkron, menjamin keamanan tipe dan secara otomatis menangani migrasi versi. Google merekomendasikan DataStore untuk semua proyek baru.

Keunggulan utama DataStore — asinkronitas di tingkat API. Semua operasi baca mengembalikan Flow, dan operasi tulis adalah fungsi suspend. Ini sepenuhnya menghilangkan pemblokiran thread UI yang mungkin terjadi saat pembacaan sinkron SharedPreferences. Selain itu, DataStore menjamin konsistensi data: penulisan dilakukan dalam transaksi, dan jika terjadi kegagalan, semua perubahan dibatalkan.

Contoh penggunaan SharedPreferences di aplikasi

Mari kita lihat contoh praktis: pengaturan tema (terang/gelap/sistem) di aplikasi Android. Pengguna memilih tema, dan pilihan disimpan di SharedPreferences. Pada startup aplikasi berikutnya, tema dipulihkan dari pengaturan yang disimpan. Untuk pembaruan antarmuka reaktif digunakan pengamatan perubahan melalui SharedPreferences.OnSharedPreferenceChangeListener.

Menyimpan pengaturan pengguna

Kita buat kelas ThemePreferences yang merangkum semua pekerjaan dengan SharedPreferences untuk tema. Kelas menyediakan metode getTheme (baca), setTheme (tulis) dan observeTheme (amati). Nama file pengaturan adalah "app_preferences" dengan mode MODE_PRIVATE. Untuk kenyamanan, kunci ditempatkan di companion object sebagai konstanta.

class ThemePreferences(context: Context) {
    companion object {
        private const val PREF_NAME = "app_preferences"
        private const val KEY_THEME = "theme_mode"
        const val THEME_LIGHT = "light"
        const val THEME_DARK = "dark"
        const val THEME_SYSTEM = "system"
    }

    private val prefs = context
        .getSharedPreferences(PREF_NAME, Context.MODE_PRIVATE)

    fun getTheme(): String =
        prefs.getString(KEY_THEME, THEME_SYSTEM) ?: THEME_SYSTEM

    fun setTheme(theme: String) {
        prefs.edit { putString(KEY_THEME, theme) }
    }

    fun observeTheme(callback: (String) -> Unit) {
        prefs.registerOnSharedPreferenceChangeListener { _, key ->
            if (key == KEY_THEME) {
                callback.invoke(getTheme())
            }
        }
    }
}

Di Activity atau Fragment, mendapatkan instance ThemePreferences dilakukan melalui konteks aplikasi. Saat inisialisasi, getTheme dipanggil untuk mengatur tema saat ini. Ketika pengguna memilih tema baru, setTheme dipanggil, dan melalui observeTheme antarmuka diperbarui tanpa memulai ulang Activity. Penting untuk tidak lupa berhenti berlangganan dari listener di onDestroy untuk mencegah kebocoran memori, terutama jika Activity dibuat ulang saat perubahan konfigurasi.

Untuk aplikasi dengan versi target minimum Android 12+, disarankan menggunakan registerOnSharedPreferenceChangeListener bersama dengan LifecycleObserver. Ini secara otomatis mengelola langganan dan pembatalan langganan saat siklus hidup komponen berubah. Untuk versi yang lebih lama, langganan dan pembatalan langganan harus dikelola secara manual, yang merupakan sumber kesalahan yang sering terjadi di aplikasi produksi yang menggunakan SharedPreferences.