SharedPreferences: ano ito, imbakan ng susi-halaga sa Android

Ano ang SharedPreferences?

SharedPreferences ay isang built-in na mekanismo ng Android para sa pag-imbak ng mga pares ng susi-halaga sa isang XML file sa panloob na imbakan ng device. Ito ay magagamit mula sa API Level 1 at hindi nangangailangan ng pagkonekta ng mga karagdagang library. Ang pangunahing layunin — pag-save ng mga setting ng user, estado ng interface, mga flag ng first-launch at iba pang simpleng datos na hindi nangangailangan ng structured database.

Ang bawat SharedPreferences file ay nauugnay sa isang tiyak na pangalan at mode ng pag-access. Bilang default, ginagamit ang mode na Context.MODE_PRIVATE, na naglilimita ng access sa file sa kasalukuyang app lamang. Dati, ang Android ay sumusuporta sa mga mode na MODE_WORLD_READABLE at MODE_WORLD_WRITEABLE, ngunit ang mga ito ay idineklarang luma na mula sa API Level 17 at ganap na tinanggal sa Android 7.0 (API 24) para sa mga kadahilanang pangseguridad.

Sa kabila ng pagiging simple nito, ang SharedPreferences ay ginagamit sa milyun-milyong Android app. Ayon sa Google, higit sa 90% ng mga app na nai-publish sa Google Play ay gumagamit ng SharedPreferences para sa pag-imbak ng mga setting. Gayunpaman, para sa mga kumplikadong scenario (malaking dami ng data, kaligtasan ng uri, asinkronisidad) inirerekomenda ng Google ang mas modernong solusyon tulad ng Preferences DataStore mula sa Android Jetpack library.

Format ng imbakan: XML sa device

Sa pisikal, ang SharedPreferences ay iniimbak bilang isang XML file sa direktoryo ng app: /data/data/{package_name}/shared_prefs/{file_name}.xml. Ang file ay naglalaman ng root element na <map> na may mga child element na <string>, <int>, <boolean>, <float> at <long> depende sa uri ng naka-imbak na halaga. Ang laki ng file ay hindi limitado, ngunit para sa malaking dami ng data (higit sa 100 KB) ang pagganap ng pagbasa at pagsulat ay nagsisimulang bumaba nang kapansin-pansin.

Ang mga file ng SharedPreferences ay hindi naka-encrypt bilang default. Ang data ay naka-imbak sa bukas na anyo sa file system ng device. Para sa pag-imbak ng sensitibong data (mga token, password) inirerekomenda ang paggamit ng EncryptedSharedPreferences mula sa AndroidX Security library, na awtomatikong nag-e-encrypt ng mga susi at halaga gamit ang AES256-GCM.

Paano gumagana ang SharedPreferences sa Android

SharedPreferences ay gumagana sa prinsipyo ng caching sa memory na may pana-panahong pag-sync sa disk. Sa unang pag-access sa file (sa pamamagitan ng getSharedPreferences), nilo-load ng Android ang XML file sa RAM at ini-parse ito sa isang Map object. Ang lahat ng kasunod na operasyon ng pagbasa ay isinasagawa mula sa memory, nang hindi muling nagbabasa mula sa disk. Tinitiyak nito ang mataas na bilis ng pag-access sa data.

Ang mga operasyon ng pagsulat ay gumagamit ng Editor — isang panloob na buffer ng mga pagbabago. Kapag tinawag ng developer ang putString o putBoolean, ang mga pagbabago ay iniimbak sa Editor object sa memory. Ang aktwal na pagsulat sa disk ay nagaganap kapag tinawag ang pamamaraang commit (sabay) o apply (hindi sabay). Hanggang sa tawagin ang mga pamamaraang ito, ang data ay hindi nai-save at sa biglaang pagtigil ng app, ang mga pagbabago ay maaaring mawala.

Mga mode ng pag-access at konteksto

Para sa pagkuha ng instance ng SharedPreferences dalawang pamamaraan ang ginagamit: getPreferences at getSharedPreferences. Ang una ay magagamit lamang sa loob ng Activity at lumilikha ng file na may pangalan ng Activity. Ang pangalawa ay mas flexible, tumatanggap ng pangalan ng file at mode ng pag-access, at magagamit mula sa anumang konteksto (Application, Activity, Service). Inirerekomenda ang paggamit ng getSharedPreferences na may pangalan ng file na tumutugma sa modyul o functionality ng app.

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

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

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

Kapag gumagamit ng MODE_MULTI_PROCESS (luma na) nag-sa-sync ang SharedPreferences sa pagitan ng mga proseso. Gayunpaman, ang pag-sync na ito ay hindi ginagarantiyahan ang atomicity, at inirerekomenda ng Google na iwasan ang paggamit ng SharedPreferences sa mga multi-process scenario. Para sa mga ganitong kaso, mas mainam na gumamit ng ContentProvider, Room na may inter-process access o DataStore.

Mga pangunahing pamamaraan ng SharedPreferences

SharedPreferences ay nagbibigay ng isang set ng mga pamamaraan para sa pagbasa ng data ayon sa susi at interface ng Editor para sa pagsulat. Ang bawat pamamaraan ng pagbasa ay tumatanggap ng dalawang parameter: ang susi at ang default na halaga na ibinabalik kung ang susi ay hindi natagpuan. Ang default na halaga ay tumutukoy din sa uri ng ibinalik na halaga: ang getString ay nagbabalik ng String, getInt ay nagbabalik ng Int at iba pa.

Editor at apply vs commit

Editor — ang panloob na object ng SharedPreferences na nagtitipon ng mga pagbabago sa buffer. Pagkatapos gawin ang lahat ng pagbabago, tinatawag ng developer ang commit() (sabay na pagsulat) o apply() (hindi sabay na pagsulat). Ang pagkakaiba ay kritikal: hinaharangan ng commit ang kasalukuyang thread hanggang sa kumpletong pagsulat sa disk at nagbabalik ng boolean (tagumpay/pagkabigo), habang ang apply ay nagsasagawa ng pagsulat sa background thread at agad na nagbabalik ng kontrol, ngunit hindi nagbabalik ng resulta.

Inirerekomenda ang paggamit ng apply sa halip na commit sa lahat ng kaso kapag hindi kailangang malaman ang resulta ng pagsulat. Ang apply ay mas mabilis at hindi humaharang sa UI thread. Ang commit ay dapat gamitin lamang kapag mahalagang malaman kung ang data ay matagumpay na nai-save o kapag nagtatrabaho sa multi-process mode. Para sa pag-alis ng mga indibidwal na susi, ginagamit ang pamamaraang remove, para sa kumpletong paglilinis — clear. Ang lahat ng operasyon ng pag-alis ay isinasagawa din sa pamamagitan ng Editor.

// Maramihang pagbabago - isang apply
prefs.edit {
    putString("theme", "dark")
    putBoolean("notifications", false)
    remove("old_key")
}

// Tagapakinig ng pagbabago ng halaga
prefs.registerOnSharedPreferenceChangeListener { prefs, key ->
    Log.d("TAG", "Nagbago ang susi: $key")
}

Mula sa Android 12 (API 31), ang SharedPreferences ay dinagdagan ng suporta para sa registerOnSharedPreferenceChangeListener na may awtomatikong pag-unsubscribe sa pamamagitan ng Lifecycle. Ito ay nagbibigay-daan upang maiwasan ang pagtagas ng memory na nauugnay sa mga nakalimutang listener. Sa mas lumang bersyon, ang developer ay obligadong manu-manong tumawag ng unregisterOnSharedPreferenceChangeListener sa onDestroy o onStop ng component.

SharedPreferences kumpara sa mga alternatibo ng imbakan

Sa kabila ng malawakang paggamit, ang SharedPreferences ay hindi isang unibersal na solusyon para sa lahat ng scenario ng pag-imbak ng data sa Android. Depende sa dami ng data, mga kinakailangan sa kaligtasan ng uri at pagganap, inirerekomenda ng Google ang iba't ibang alternatibo na kasama sa Android Jetpack at standard na Android library.

DataStore — modernong alternatibo

DataStore — isang Android Jetpack library, na ipinakilala ng Google bilang kapalit ng SharedPreferences. Nag-aalok ito ng dalawang variant: Preferences DataStore (susi-halaga, tulad ng SharedPreferences) at Proto DataStore (na-type na imbakan sa pamamagitan ng Protocol Buffers). Gumagamit ang DataStore ng coroutine at Flow para sa asinkronong trabaho, ginagarantiyahan ang kaligtasan ng uri at awtomatikong humahawak ng mga migrasyon ng bersyon. Inirerekomenda ng Google ang DataStore para sa lahat ng bagong proyekto.

Ang pangunahing bentahe ng DataStore — asinkronisidad sa antas ng API. Lahat ng operasyon ng pagbasa ay nagbabalik ng Flow, at ang mga operasyon ng pagsulat ay mga suspend-function. Ito ay ganap na nag-aalis ng pagharang sa UI thread, na posible sa sabay na pagbasa ng SharedPreferences. Bukod pa rito, ginagarantiyahan ng DataStore ang pagkakapare-pareho ng data: ang pagsulat ay isinasagawa sa isang transaksyon, at sa kaso ng pagkabigo, lahat ng pagbabago ay ibinabalik.

Halimbawa ng paggamit ng SharedPreferences sa app

Tingnan natin ang isang praktikal na halimbawa: mga setting ng tema (maliwanag/dilim/sistema) sa isang Android app. Pumili ang user ng tema, at ang pagpili ay nai-save sa SharedPreferences. Sa mga susunod na paglunsad ng app, ang tema ay naibabalik mula sa mga naka-save na setting. Para sa reaktibong pag-update ng interface, ginagamit ang pagmamasid ng mga pagbabago sa pamamagitan ng SharedPreferences.OnSharedPreferenceChangeListener.

Pag-save ng mga setting ng user

Gagawa tayo ng klase na ThemePreferences, na nagsasama-sama ng lahat ng trabaho sa SharedPreferences para sa tema. Ang klase ay nagbibigay ng mga pamamaraang getTheme (pagbasa), setTheme (pagsulat) at observeTheme (pagmamasid). Ang pangalan ng file ng mga setting ay "app_preferences" na may mode na MODE_PRIVATE. Para sa kaginhawahan, ang mga susi ay inilalagay sa companion object bilang mga constant.

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

Sa Activity o Fragment, ang pagkuha ng instance ng ThemePreferences ay ginagawa sa pamamagitan ng konteksto ng app. Sa pagsisimula, ang getTheme ay tinatawag upang itakda ang kasalukuyang tema. Kapag pumili ang user ng bagong tema, ang setTheme ay tinatawag, at sa pamamagitan ng observeTheme ang interface ay naa-update nang hindi ni-restart ang Activity. Mahalagang huwag kalimutan na mag-unsubscribe mula sa listener sa onDestroy upang maiwasan ang pagtagas ng memory, lalo na kung ang Activity ay muling nilikha sa pagbabago ng configuration.

Para sa mga app na may minimum na target na bersyon na Android 12+, inirerekomenda ang paggamit ng registerOnSharedPreferenceChangeListener kasama ng LifecycleObserver. Ito ay awtomatikong namamahala ng subscription at pag-unsubscribe sa pagbabago ng lifecycle ng component. Para sa mas lumang bersyon, ang subscription at pag-unsubscribe ay dapat pamahalaan nang manu-mano, na isang madalas na pinagmumulan ng error sa production apps na gumagamit ng SharedPreferences.