Preferences Classe

Définition

[Android.Runtime.Register("java/util/prefs/Preferences", DoNotGenerateAcw=true)]
public abstract class Preferences : Java.Lang.Object

[<Android.Runtime.Register("java/util/prefs/Preferences", DoNotGenerateAcw=true)>]
type Preferences = class
    inherit Object

Héritage

Object

JavaObject

Object

Preferences

Dérivé

Java.Util.Prefs.AbstractPreferences

Attributs

RegisterAttribute

Remarques

Nœud dans une collection hiérarchique de données de préférence. Cette classe permet aux applications de stocker et de récupérer les données d’utilisateur et système et de configuration. Ces données sont stockées de manière persistante dans un magasin de stockage dépendant de l’implémentation. Les implémentations classiques incluent des fichiers plats, des registres spécifiques au système d’exploitation, des serveurs d’annuaires et des bases de données SQL. L’utilisateur de cette classe n’a pas besoin d’être concerné par les détails du magasin de stockage.

Il existe deux arborescences distinctes de nœuds de préférence, une pour les préférences utilisateur et une pour les préférences système. Chaque utilisateur a une arborescence de préférences utilisateur distincte, et tous les utilisateurs d’un système donné partagent la même arborescence de préférences système. La description précise de « l’utilisateur » et du « système » varie de l’implémentation à l’implémentation. Les informations classiques stockées dans l’arborescence des préférences utilisateur peuvent inclure le choix de police, le choix de couleur ou l’emplacement et la taille de fenêtre préférés pour une application particulière. Les informations classiques stockées dans l’arborescence des préférences système peuvent inclure des données de configuration d’installation pour une application.

Les nœuds d’une arborescence de préférences sont nommés de la même manière que les répertoires dans un système de fichiers hiérarchique. Chaque nœud d’une arborescence de préférences a un nom de nœud (qui n’est pas nécessairement unique), un nom de chemin absolu unique et un nom de chemin d’accès relatif à chaque ancêtre, y compris lui-même.

Le nœud racine a un nom de nœud de la chaîne vide ( » « ). Chaque autre nœud a un nom de nœud arbitraire, spécifié au moment de sa création. Les seules restrictions sur ce nom sont qu’il ne peut pas s’agir de la chaîne vide et qu’elle ne peut pas contenir le caractère de barre oblique ('/').

Le nœud racine a un nom de chemin d’accès absolu de "/". Les enfants du nœud racine ont des noms absolus de chemin d’accès de < nom du nœud>. Tous les autres nœuds ont des noms de chemin d’accès absolus de < nom absolu du chemin d’accès du parent>< nom du nœud>. Notez que tous les noms de chemin d’accès absolus commencent par le caractère barre oblique.

Le nom du chemin d’accès d’un nœud n par rapport à son ancêtre est simplement la chaîne qui doit être ajoutée au nom de chemin absolu d’un pour former le nom du chemin absolu de n, avec le caractère de barre oblique initiale (le cas échéant) supprimé. Notez que : <ul><li>Aucun nom de chemin relatif commence par le caractère oblique. <le>nom du chemin d’accès de chaque nœud par rapport à lui-même est la chaîne vide. <li>Chaque nom de chemin d’accès de chaque nœud par rapport à son parent est son nom de nœud (à l’exception du nœud racine, qui n’a pas de parent). <Li>Chaque nom de chemin d’accès de chaque nœud par rapport à la racine est son nom de chemin absolu avec le caractère de barre oblique initiale supprimé. </ul>

Notez enfin que : <ul><li>No path name contient plusieurs caractères de barre oblique consécutive. <Li>Aucun nom de chemin d’accès à l’exception du nom de chemin absolu de la racine se termine par le caractère oblique. <li>Toute chaîne conforme à ces deux règles est un nom de chemin d’accès valide. </ul>

Toutes les méthodes qui modifient les données de préférences sont autorisées à fonctionner de manière asynchrone ; ils peuvent retourner immédiatement, et les modifications se propageront finalement au magasin de stockage persistant avec un délai dépendant de l’implémentation. La flush méthode peut être utilisée pour forcer de manière synchrone les mises à jour du magasin de stockage. L’arrêt normal de la machine virtuelle Java n’entraîne pas la perte de mises à jour en attente . Un appel explicite flush n’est pas requis lors de l’arrêt pour s’assurer que les mises à jour en attente sont rendues persistantes.

Toutes les méthodes qui lisent les préférences d’un Preferences objet nécessitent que l’appelant fournisse une valeur par défaut. La valeur par défaut est retournée si aucune valeur n’a été définie précédemment ou si le magasin de stockage n’est pas disponible. L’intention est de permettre aux applications de fonctionner, bien qu’avec des fonctionnalités légèrement dégradées, même si le magasin de stockage devient indisponible. Plusieurs méthodes, comme flushcelles-ci, ont une sémantique qui les empêche de fonctionner si le magasin de stockage n’est pas disponible. Les applications ordinaires ne doivent pas avoir besoin d’appeler l’une de ces méthodes, qui peuvent être identifiées par le fait qu’elles sont déclarées à lever BackingStoreException.

Les méthodes de cette classe peuvent être appelées simultanément par plusieurs threads dans une même machine virtuelle JVM sans avoir besoin de synchronisation externe, et les résultats sont équivalents à une exécution série. Si cette classe est utilisée simultanément par plusieurs machines virtuelles JV qui stockent leurs données de préférence dans le même magasin de stockage, le magasin de données ne sera pas endommagé, mais aucune autre garantie n’est faite concernant la cohérence des données de préférence.

Cette classe contient une installation d’exportation/importation, ce qui permet aux préférences d’être « exportées » vers un document XML et les documents XML représentant les préférences à « importer » dans le système. Cette fonctionnalité peut être utilisée pour sauvegarder toute ou partie d’une arborescence de préférences, puis restaurer à partir de la sauvegarde.

Le document XML a la déclaration DOCTYPE suivante :

{@code
<!DOCTYPE preferences SYSTEM "http://java.sun.com/dtd/preferences.dtd">
            }

Notez que l’URI système (http://java.sun.com/dtd/preferences.dtd)n’est pas accessible lors de l’exportation ou de l’importation de préférences ; il sert simplement de chaîne pour identifier de manière unique le DTD, qui est :

{@code
<?xml version="1.0" encoding="UTF-8"?>

<!-- DTD for a Preferences tree. -->

<!-- The preferences element is at the root of an XML document
                    representing a Preferences tree. -->
<!ELEMENT preferences (root)>

<!-- The preferences element contains an optional version attribute,
                     which specifies version of DTD. -->
<!ATTLIST preferences EXTERNAL_XML_VERSION CDATA "0.0" >

<!-- The root element has a map representing the root's preferences
                    (if any), and one node for each child of the root (if any). -->
<!ELEMENT root (map, node*) >

<!-- Additionally, the root contains a type attribute, which
                    specifies whether it's the system or user root. -->
<!ATTLIST root
                         type (system|user) #REQUIRED >

<!-- Each node has a map representing its preferences (if any),
                    and one node for each child (if any). -->
<!ELEMENT node (map, node*) >

<!-- Additionally, each node has a name attribute -->
<!ATTLIST node
                         name CDATA #REQUIRED >

<!-- A map represents the preferences stored at a node (if any). -->
<!ELEMENT map (entry*) >

<!-- An entry represents a single preference, which is simply
                     a key-value pair. -->
<!ELEMENT entry EMPTY >
<!ATTLIST entry
                         key   CDATA #REQUIRED
                         value CDATA #REQUIRED >
            }

Chaque Preferences implémentation doit avoir une implémentation associée PreferencesFactory . Chaque implémentation se Java(TM) doit fournir un moyen de spécifier l’implémentation PreferencesFactory utilisée pour générer les nœuds de préférences racines. Cela permet à l’administrateur de remplacer l’implémentation des préférences par défaut par une autre implémentation.

Remarque d’implémentation : Dans le JRE de Sun, l’implémentation PreferencesFactory se trouve comme suit :

<ol>

<li>

Si la propriété java.util.prefs.PreferencesFactory système est définie, il est nécessaire d’être le nom complet d’une classe implémentant l’interface PreferencesFactory . La classe est chargée et instanciée ; si ce processus échoue, une erreur non spécifiée est levée.

</li>

<li>

Si un PreferencesFactory fichier de classe d’implémentation a été installé dans un fichier jar visible par le java.lang.ClassLoader#getSystemClassLoader system class loaderfichier jar et que ce fichier jar contient un fichier de configuration de fournisseur nommé java.util.prefs.PreferencesFactory dans le répertoire META-INF/servicesde ressources, le nom de la première classe spécifié dans ce fichier est pris. Si plusieurs fichiers jar de ce type sont fournis, le premier trouvé est utilisé. La classe est chargée et instanciée ; si ce processus échoue, une erreur non spécifiée est levée.

</li>

<li>

Enfin, si ni la propriété système mentionnée ci-dessus ni un fichier jar d’extension n’est fourni, l’implémentation par défaut PreferencesFactory à l’échelle du système pour la plateforme sous-jacente est chargée et instanciée.

</li>

</ol>

Ajouté dans la version 1.4.

Java documentation pour java.util.prefs.Preferences.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par le projet Android Open Source et utilisés en fonction des termes décrits dans la licence d’attribution Creative Commons 2.5.