SharedPreferences : qu'est-ce que le stockage clé-valeur Android

Qu'est-ce que SharedPreferences ?

SharedPreferences est un mécanisme intégré d'Android pour stocker des paires clé-valeur dans un fichier XML sur le stockage interne de l'appareil. Il est disponible depuis l'API Level 1 et ne nécessite aucune bibliothèque supplémentaire. Son objectif principal est de sauvegarder les préférences utilisateur, l'état de l'interface, les indicateurs de premier lancement et d'autres données simples qui ne nécessitent pas de base de données structurée.

Chaque fichier SharedPreferences est associé à un nom spécifique et un mode d'accès. Par défaut, le mode Context.MODE_PRIVATE est utilisé, ce qui limite l'accès au fichier à l'application actuelle uniquement. Auparavant, Android prenait en charge les modes MODE_WORLD_READABLE et MODE_WORLD_WRITEABLE, mais ils ont été déclarés obsolètes à partir de l'API Level 17 et complètement supprimés dans Android 7.0 (API 24) pour des raisons de sécurité.

Malgré sa simplicité, SharedPreferences est utilisé dans des millions d'applications Android. Selon Google, plus de 90 % des applications publiées sur Google Play utilisent SharedPreferences pour stocker des paramètres. Cependant, pour les scénarios complexes (grands volumes de données, sécurité des types, asynchronie), Google recommande des solutions plus modernes comme Preferences DataStore de la bibliothèque Android Jetpack.

Format de stockage : XML sur l'appareil

Physiquement, SharedPreferences est stocké sous forme de fichier XML dans le répertoire de l'application : /data/data/{package_name}/shared_prefs/{file_name}.xml. Le fichier contient un élément racine <map> avec des éléments enfants <string>, <int>, <boolean>, <float> et <long> selon le type de valeur stockée. La taille du fichier n'est pas limitée, mais pour de grands volumes de données (plus de 100 Ko), les performances de lecture et d'écriture commencent à se dégrader sensiblement.

Les fichiers SharedPreferences ne sont pas chiffrés par défaut. Les données sont stockées en texte clair sur le système de fichiers de l'appareil. Pour stocker des données sensibles (jetons, mots de passe), il est recommandé d'utiliser EncryptedSharedPreferences de la bibliothèque AndroidX Security, qui chiffre automatiquement les clés et les valeurs à l'aide d'AES256-GCM.

Comment SharedPreferences fonctionne sur Android

SharedPreferences fonctionne sur le principe de mise en cache en mémoire avec synchronisation périodique sur disque. Lors du premier accès au fichier (via getSharedPreferences), Android charge le fichier XML dans la RAM et l'analyse en un objet Map. Toutes les opérations de lecture ultérieures sont effectuées à partir de la mémoire, sans relecture du disque. Cela garantit une vitesse d'accès élevée aux données.

Les opérations d'écriture utilisent Editor — un tampon interne de modifications. Lorsque le développeur appelle putString ou putBoolean, les modifications sont stockées dans l'objet Editor en mémoire. L'écriture réelle sur le disque se produit lorsque la méthode commit (synchrone) ou apply (asynchrone) est appelée. Tant que ces méthodes ne sont pas appelées, les données ne sont pas sauvegardées et, en cas de plantage inattendu de l'application, les modifications peuvent être perdues.

Modes d'accès et contexte

Pour obtenir une instance de SharedPreferences, deux méthodes sont utilisées : getPreferences et getSharedPreferences. La première n'est disponible qu'à l'intérieur d'une Activity et crée un fichier portant le nom de l'Activity. La seconde est plus flexible, accepte un nom de fichier et un mode d'accès, et est accessible depuis n'importe quel contexte (Application, Activity, Service). Il est recommandé d'utiliser getSharedPreferences avec un nom de fichier correspondant au module ou à la fonctionnalité de l'application.

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

// Écrire des données
with(prefs.edit()) {
    putString("username", "Anna")
    putInt("age", 28)
    putBoolean("isLoggedIn", true)
    apply()
}

// Lire des données
val username = prefs.getString("username", "")
val age = prefs.getInt("age", 0)
val isLoggedIn = prefs.getBoolean("isLoggedIn", false)

Lors de l'utilisation de MODE_MULTI_PROCESS (obsolète), SharedPreferences se synchronise entre les processus. Cependant, cette synchronisation ne garantit pas l'atomicité, et Google recommande d'éviter SharedPreferences dans les scénarios multiprocessus. Pour de tels cas, il est préférable d'utiliser ContentProvider, Room avec accès inter-processus ou DataStore.

Méthodes principales de SharedPreferences

SharedPreferences fournit un ensemble de méthodes pour lire des données par clé et l'interface Editor pour écrire. Chaque méthode de lecture accepte deux paramètres : une clé et une valeur par défaut qui est retournée si la clé n'est pas trouvée. La valeur par défaut détermine également le type de retour : getString retourne String, getInt retourne Int, et ainsi de suite.

Editor et apply vs commit

Editor est un objet interne de SharedPreferences qui collecte les modifications dans un tampon. Après avoir effectué toutes les modifications, le développeur appelle commit() (écriture synchrone) ou apply() (écriture asynchrone). La différence est cruciale : commit bloque le thread actuel jusqu'à l'écriture complète sur le disque et retourne un boolean (succès/échec), tandis que apply effectue l'écriture dans un thread d'arrière-plan et retourne immédiatement le contrôle, mais ne retourne pas de résultat.

Il est recommandé d'utiliser apply plutôt que commit dans tous les cas où il n'est pas nécessaire de connaître le résultat de l'écriture. apply est plus rapide et ne bloque pas le thread de l'interface utilisateur. commit ne doit être utilisé que lorsqu'il est essentiel de savoir si les données ont été sauvegardées avec succès, ou lors du travail en mode multiprocessus. Pour supprimer des clés individuelles, la méthode remove est utilisée, pour un effacement complet — clear. Toutes les opérations de suppression sont également effectuées via Editor.

// Modifications multiples - un apply
prefs.edit {
    putString("theme", "dark")
    putBoolean("notifications", false)
    remove("old_key")
}

// Écouteur de changement de valeur
prefs.registerOnSharedPreferenceChangeListener { prefs, key ->
    Log.d("TAG", "Clé modifiée : $key")
}

À partir d'Android 12 (API 31), SharedPreferences a été amélioré avec la prise en charge de registerOnSharedPreferenceChangeListener avec désabonnement automatique via Lifecycle. Cela permet d'éviter les fuites de mémoire associées aux écouteurs oubliés. Dans les versions plus anciennes, le développeur doit appeler manuellement unregisterOnSharedPreferenceChangeListener dans onDestroy ou onStop du composant.

SharedPreferences vs alternatives de stockage

Malgré son utilisation répandue, SharedPreferences n'est pas une solution universelle pour tous les scénarios de stockage de données sur Android. Selon le volume de données, les exigences de sécurité des types et les performances, Google recommande diverses alternatives incluses dans Android Jetpack et la bibliothèque standard Android.

DataStore — alternative moderne

DataStore est une bibliothèque Android Jetpack présentée par Google comme remplacement de SharedPreferences. Elle propose deux variantes : Preferences DataStore (clé-valeur, comme SharedPreferences) et Proto DataStore (stockage typé via Protocol Buffers). DataStore utilise des coroutines et Flow pour un fonctionnement asynchrone, garantit la sécurité des types et gère automatiquement les migrations de version. Google recommande DataStore pour tous les nouveaux projets.

Le principal avantage de DataStore est l'asynchronie au niveau de l'API. Toutes les opérations de lecture retournent Flow, et les opérations d'écriture sont des fonctions suspend. Cela élimine complètement le blocage du thread de l'interface utilisateur qui peut se produire avec la lecture synchrone de SharedPreferences. De plus, DataStore garantit la cohérence des données : l'écriture est effectuée dans une transaction et, en cas d'échec, toutes les modifications sont annulées.

Exemple d'utilisation de SharedPreferences dans une application

Considérons un exemple pratique : les paramètres de thème (clair/sombre/système) dans une application Android. L'utilisateur sélectionne un thème, et le choix est sauvegardé dans SharedPreferences. Lors des lancements ultérieurs de l'application, le thème est restauré à partir des paramètres sauvegardés. Pour les mises à jour réactives de l'interface, l'observation des modifications via SharedPreferences.OnSharedPreferenceChangeListener est utilisée.

Sauvegarde des paramètres utilisateur

Créons une classe ThemePreferences qui encapsule tout le travail avec SharedPreferences pour le thème. La classe fournit les méthodes getTheme (lecture), setTheme (écriture) et observeTheme (observation). Le nom du fichier de paramètres sera «app_preferences» avec le mode MODE_PRIVATE. Pour plus de commodité, les clés sont placées dans un objet companion en tant que constantes.

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

Dans une Activity ou un Fragment, l'obtention d'une instance de ThemePreferences se fait via le contexte de l'application. Lors de l'initialisation, getTheme est appelé pour définir le thème actuel. Lorsque l'utilisateur sélectionne un nouveau thème, setTheme est appelé, et via observeTheme, l'interface est mise à jour sans redémarrer l'Activity. Il est important de se désabonner de l'écouteur dans onDestroy pour éviter les fuites de mémoire, surtout si l'Activity est recréée lors d'un changement de configuration.

Pour les applications avec une version minimale cible Android 12+, il est recommandé d'utiliser registerOnSharedPreferenceChangeListener conjointement avec LifecycleObserver. Cela gère automatiquement l'abonnement et le désabonnement lors des changements de cycle de vie du composant. Pour les versions plus anciennes, l'abonnement et le désabonnement doivent être gérés manuellement, ce qui est une source fréquente d'erreurs dans les applications de production utilisant SharedPreferences.