SharedPreferences: mi ez, kulcs-érték tároló Androidban

Mi az a SharedPreferences?

SharedPreferences egy beépített Android-mechanizmus kulcs-érték párok XML-fájlban történő tárolására az eszköz belső memóriájában. API Level 1 óta elérhető, és nem igényel további könyvtárak csatlakoztatását. Fő célja — felhasználói beállítások, interfész állapot, first-launch jelzők és más egyszerű adatok mentése, amelyek nem igényelnek strukturált adatbázist.

Minden SharedPreferences fájl egy adott névhez és hozzáférési módhoz van kötve. Alapértelmezés szerint a Context.MODE_PRIVATE mód használatos, amely a fájlhoz való hozzáférést csak az aktuális alkalmazásra korlátozza. Korábban az Android támogatta a MODE_WORLD_READABLE és MODE_WORLD_WRITEABLE módokat, de ezek az API Level 17-től kezdve elavulttá váltak, és teljesen eltávolításra kerültek az Android 7.0 (API 24) verzióban biztonsági okokból.

Egyszerűsége ellenére a SharedPreferences milliónyi Android-alkalmazásban használatos. A Google adatai szerint a Google Play-en közzétett alkalmazások több mint 90%-a használ SharedPreferences-t a beállítások tárolására. Az összetett forgatókönyvekhez (nagy adatmennyiség, típusbiztonság, aszinkronitás) azonban a Google modernebb megoldásokat javasol, mint például a Preferences DataStore az Android Jetpack könyvtárból.

Tárolási formátum: XML az eszközön

Fizikailag a SharedPreferences XML-fájlként tárolódik az alkalmazás könyvtárában: /data/data/{package_name}/shared_prefs/{file_name}.xml. A fájl a <map> gyökérelemet tartalmazza <string>, <int>, <boolean>, <float> és <long> gyermekelemekkel a tárolt érték típusától függően. A fájlméret nem korlátozott, de nagy adatmennyiségek (100 KB felett) esetén az olvasási és írási teljesítmény észrevehetően csökkenni kezd.

A SharedPreferences fájlok alapértelmezés szerint nem titkosítottak. Az adatok nyílt formában tárolódnak az eszköz fájlrendszerében. Érzékeny adatok (tokenek, jelszavak) tárolásához ajánlott az EncryptedSharedPreferences használata az AndroidX Security könyvtárból, amely automatikusan titkosítja a kulcsokat és értékeket AES256-GCM segítségével.

Hogyan működik a SharedPreferences Androidban

SharedPreferences a memóriában történő gyorsítótárazás elvén működik, időszakos lemezszinkronizációval. A fájl első elérésekor (getSharedPreferences segítségével) az Android betölti az XML-fájlt a RAM-ba, és egy Map objektummá elemzi. Az összes további olvasási művelet a memóriából történik, a lemez újbóli olvasása nélkül. Ez biztosítja az adatok gyors elérését.

Az írási műveletek az Editor-t használják — egy belső változás puffert. Amikor a fejlesztő meghívja a putString vagy putBoolean metódust, a változások az Editor objektumban tárolódnak a memóriában. A tényleges lemezre írás a commit (szinkron) vagy apply (aszinkron) metódus meghívásakor történik. E metódusok meghívásáig az adatok nem kerülnek mentésre, és az alkalmazás váratlan leállásakor a változások elveszhetnek.

Hozzáférési módok és kontextus

A SharedPreferences példány megszerzéséhez két metódus használatos: getPreferences és getSharedPreferences. Az első csak Activity-n belül érhető el, és az Activity nevével hoz létre fájlt. A második rugalmasabb, elfogadja a fájlnevet és a hozzáférési módot, és bármilyen kontextusból (Application, Activity, Service) elérhető. Ajánlott a getSharedPreferences használata olyan fájlnévvel, amely megfelel az alkalmazás moduljának vagy funkciójának.

// SharedPreferences lekérése
val prefs = context.getSharedPreferences(
    "user_settings", Context.MODE_PRIVATE
)

// Adatok írása
with(prefs.edit()) {
    putString("username", "Anna")
    putInt("age", 28)
    putBoolean("isLoggedIn", true)
    apply()
}

// Adatok olvasása
val username = prefs.getString("username", "")
val age = prefs.getInt("age", 0)
val isLoggedIn = prefs.getBoolean("isLoggedIn", false)

A MODE_MULTI_PROCESS (elavult) használatakor a SharedPreferences szinkronizál a folyamatok között. Ez a szinkronizáció azonban nem garantálja az atomitást, és a Google azt javasolja, hogy kerüljük a SharedPreferences használatát multi-process forgatókönyvekben. Ilyen esetekben jobb a ContentProvider, a folyamatok közötti hozzáféréssel rendelkező Room vagy a DataStore használata.

A SharedPreferences fő metódusai

SharedPreferences metóduskészletet biztosít az adatok kulcs alapján történő olvasásához és az Editor interfészt az íráshoz. Minden olvasási metódus két paramétert fogad: a kulcsot és az alapértelmezett értéket, amely akkor kerül visszaadásra, ha a kulcs nem található. Az alapértelmezett érték meghatározza a visszatérési érték típusát is: a getString String-et, a getInt Int-et ad vissza, és így tovább.

Editor és apply vs commit

Editor — a SharedPreferences belső objektuma, amely a változásokat egy pufferben gyűjti. Az összes változtatás elvégzése után a fejlesztő meghívja a commit() (szinkron írás) vagy apply() (aszinkron írás) metódust. A különbség kritikus: a commit blokkolja az aktuális szálat a teljes lemezre írásig, és boolean-t (siker/kudarc) ad vissza, míg az apply a háttérszálon végzi az írást, és azonnal visszaadja a vezérlést, de nem ad vissza eredményt.

Ajánlott az apply használata a commit helyett minden olyan esetben, amikor nem szükséges tudni az írás eredményét. Az apply gyorsabb, és nem blokkolja az UI szálat. A commit csak akkor használandó, ha kritikus tudni, hogy az adatok sikeresen mentésre kerültek-e, vagy multi-process módban történő munkavégzéskor. Az egyes kulcsok eltávolításához a remove metódus, a teljes törléshez a clear használatos. Az összes törlési művelet szintén az Editoron keresztül történik.

// Több változtatás - egy apply
prefs.edit {
    putString("theme", "dark")
    putBoolean("notifications", false)
    remove("old_key")
}

// Értékváltozás figyelő
prefs.registerOnSharedPreferenceChangeListener { prefs, key ->
    Log.d("TAG", "Kulcs megváltozott: $key")
}

Az Android 12-től (API 31) kezdve a SharedPreferences kiegészült a registerOnSharedPreferenceChangeListener támogatásával, automatikus leiratkozással a Lifecycle segítségével. Ez lehetővé teszi az elfelejtett listener-ekkel kapcsolatos memóriaszivárgások elkerülését. Régebbi verziókban a fejlesztő köteles manuálisan meghívni az unregisterOnSharedPreferenceChangeListener-t a komponens onDestroy vagy onStop metódusában.

SharedPreferences vs tárolási alternatívák

Széles körű elterjedtsége ellenére a SharedPreferences nem univerzális megoldás az összes adattárolási forgatókönyvre Androidban. Az adatmennyiségtől, a típusbiztonsági és teljesítménykövetelményektől függően a Google különböző alternatívákat javasol, amelyek az Android Jetpack és a szabványos Android könyvtár részét képezik.

DataStore — modern alternatíva

DataStore — egy Android Jetpack könyvtár, amelyet a Google a SharedPreferences helyettesítőjeként mutatott be. Két változatot kínál: Preferences DataStore (kulcs-érték, mint a SharedPreferences) és Proto DataStore (típusos tárolás Protocol Buffers segítségével). A DataStore korutineket és Flow-t használ az aszinkron munkához, garantálja a típusbiztonságot, és automatikusan kezeli a verziómigrációkat. A Google a DataStore-t ajánlja minden új projekthez.

A DataStore fő előnye — az aszinkronitás API szinten. Az összes olvasási művelet Flow-t ad vissza, az írási műveletek pedig suspend-függvények. Ez teljesen kiküszöböli az UI szál blokkolását, ami a SharedPreferences szinkron olvasásakor lehetséges. Ezenkívül a DataStore garantálja az adatok konzisztenciáját: az írás tranzakcióban történik, és hiba esetén az összes változás visszaállításra kerül.

SharedPreferences használati példa alkalmazásban

Tekintsünk egy gyakorlati példát: téma beállítások (világos/sötét/rendszer) egy Android-alkalmazásban. A felhasználó kiválasztja a témát, és a választás elmentődik a SharedPreferences-be. Az alkalmazás későbbi indításakor a téma visszaáll a mentett beállításokból. A reaktív felületfrissítéshez a változások megfigyelése történik a SharedPreferences.OnSharedPreferenceChangeListener segítségével.

Felhasználói beállítások mentése

Hozzunk létre egy ThemePreferences osztályt, amely a SharedPreferences-szel való összes munkát beágyazza a témához. Az osztály getTheme (olvasás), setTheme (írás) és observeTheme (megfigyelés) metódusokat biztosít. A beállításfájl neve "app_preferences" lesz MODE_PRIVATE móddal. A kényelem kedvéért a kulcsok a companion object-ben konstansként vannak kiemelve.

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

Activity-ben vagy Fragment-ben a ThemePreferences példány megszerzése az alkalmazás kontextusán keresztül történik. Az inicializáláskor a getTheme meghívásra kerül az aktuális téma beállításához. Amikor a felhasználó új témát választ, a setTheme meghívásra kerül, és az observeTheme segítségével a felület frissül az Activity újraindítása nélkül. Fontos, hogy ne felejtsen el leiratkozni a listener-ről az onDestroy-ban a memóriaszivárgás megelőzése érdekében, különösen ha az Activity újra létrejön konfigurációváltozáskor.

Az Android 12+ minimális célverziójú alkalmazásokhoz ajánlott a registerOnSharedPreferenceChangeListener használata a LifecycleObserver-rel együtt. Ez automatikusan kezeli a fel- és leiratkozást a komponens életciklusának változásakor. Régebbi verziók esetén a fel- és leiratkozást manuálisan kell kezelni, ami gyakori hibák forrása a SharedPreferences-t használó éles alkalmazásokban.