Preferences Klasse

Definition

[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

Vererbung

Object

JavaObject

Object

Preferences

Abgeleitet

Java.Util.Prefs.AbstractPreferences

Attribute

RegisterAttribute

Hinweise

Ein Knoten in einer hierarchischen Sammlung von Einstellungsdaten. Diese Klasse ermöglicht Anwendungen das Speichern und Abrufen von Benutzer- und Systemeinstellungen und Konfigurationsdaten. Diese Daten werden dauerhaft in einem implementierungsabhängigen Sicherungsspeicher gespeichert. Typische Implementierungen umfassen Flatfiles, betriebssystemspezifische Registrierungen, Verzeichnisserver und SQL-Datenbanken. Der Benutzer dieser Klasse muss sich nicht mit Details des Sicherungsspeichers befassen.

Es gibt zwei separate Strukturen von Einstellungsknoten, eine für Benutzereinstellungen und eine für Systemeinstellungen. Jeder Benutzer verfügt über eine separate Benutzereinstellungsstruktur, und alle Benutzer in einem bestimmten System verwenden dieselbe Systemeinstellungsstruktur. Die genaue Beschreibung von "Benutzer" und "System" variiert von Implementierung zu Implementierung. Typische Informationen, die in der Benutzereinstellungsstruktur gespeichert sind, können Schriftartauswahl, Farbauswahl oder bevorzugte Fensterposition und -größe für eine bestimmte Anwendung umfassen. Typische Informationen, die in der Systemeinstellungsstruktur gespeichert sind, können Installationskonfigurationsdaten für eine Anwendung enthalten.

Knoten in einer Einstellungsstruktur werden ähnlich wie Verzeichnisse in einem hierarchischen Dateisystem benannt. Jeder Knoten in einer Einstellungsstruktur hat einen Knotennamen (der nicht unbedingt eindeutig ist), einen eindeutigen absoluten Pfadnamen und einen Pfadnamenrelativ zu jedem Vorgänger einschließlich selbst.

Der Stammknoten hat einen Knotennamen der leeren Zeichenfolge (""). Jeder andere Knoten hat einen beliebigen Knotennamen, der zum Zeitpunkt der Erstellung angegeben wird. Die einzigen Einschränkungen für diesen Namen sind, dass es sich nicht um die leere Zeichenfolge handelt und nicht das Schrägstrichzeichen ('/') enthalten kann.

Der Stammknoten hat einen absoluten Pfadnamen von "/". Untergeordnete Elemente des Stammknotens weisen absolute Pfadnamen von < Knotenname>. Alle anderen Knoten weisen absolute Pfadnamen von < Absoluter Pfadname des übergeordneten Elements>< Knotenname>. Beachten Sie, dass alle absoluten Pfadnamen mit dem Schrägstrich beginnen.

Der Pfadname eines Knotens n relativ zu seinem Vorgänger ist einfach die Zeichenfolge, die an den absoluten Pfadnamen eines Knotens angefügt werden muss, um den absoluten Pfadnamen von n zu bilden, wobei das ursprüngliche Schrägstrichzeichen (sofern vorhanden) entfernt wird. Beachten Sie: <Ul><li>No relative Pfadnamen beginnen mit dem Schrägstrich. <li>Der Pfadname jedes Knotens relativ zu sich selbst ist die leere Zeichenfolge. <li>Der Pfadname jedes Knotens relativ zum übergeordneten Knoten ist der Knotenname (mit Ausnahme des Stammknotens, der kein übergeordnetes Element aufweist). <li>Der Pfadname jedes Knotens relativ zum Stamm ist der absolute Pfadname, wobei der ursprüngliche Schrägstrich entfernt wird. </ul>

Beachten Sie schließlich: <Ul><li>No Pfadname enthält mehrere aufeinander folgende Schrägstriche. <li>No path name with the exception of the root's absolute path name ends in the slash character. <li>Eine beliebige Zeichenfolge, die diesen beiden Regeln entspricht, ist ein gültiger Pfadname. </ul>

Alle Methoden, die Einstellungen ändern, dürfen asynchron ausgeführt werden; sie können sofort zurückgegeben werden, und Änderungen werden schließlich mit einer implementierungsabhängigen Verzögerung an den permanenten Sicherungsspeicher weitergegeben. Die flush Methode kann verwendet werden, um aktualisierungen im Sicherungsspeicher synchron zu erzwingen. Die normale Beendigung des Java virtuellen Computers führt nicht zum Verlust ausstehender Updates – ein expliziter flush Aufruf ist nicht erforderlich, um sicherzustellen, dass ausstehende Updates dauerhaft ausgeführt werden.

Alle Methoden, die Einstellungen aus einem Preferences Objekt lesen, erfordern den Aufrufer, um einen Standardwert bereitzustellen. Der Standardwert wird zurückgegeben, wenn zuvor kein Wert festgelegt wurde oder der Sicherungsspeicher nicht verfügbar ist. Die Absicht besteht darin, Anwendungen den Betrieb zu ermöglichen, wenn auch mit geringfügig beeinträchtigter Funktionalität, auch wenn der Sicherungsspeicher nicht mehr verfügbar ist. Mehrere Methoden, wie z flush. B. Semantik, die verhindern, dass sie ausgeführt werden, wenn der Sicherungsspeicher nicht verfügbar ist. Gewöhnliche Anwendungen sollten keine dieser Methoden aufrufen müssen, die durch die Tatsache identifiziert werden können, dass sie ausgelöst BackingStoreExceptionwerden.

Die Methoden in dieser Klasse können gleichzeitig von mehreren Threads in einem einzigen JVM aufgerufen werden, ohne dass eine externe Synchronisierung erforderlich ist, und die Ergebnisse entsprechen einer seriellen Ausführung. Wenn diese Klasse gleichzeitig von mehreren JVMs verwendet wird, die ihre Präferenzdaten im selben Sicherungsspeicher speichern, wird der Datenspeicher nicht beschädigt, aber es werden keine anderen Garantien hinsichtlich der Konsistenz der Präferenzdaten gemacht.

Diese Klasse enthält eine Export-/Importeinrichtung, sodass Einstellungen in ein XML-Dokument "exportiert" werden können, und XML-Dokumente, die Einstellungen darstellen, die zurück in das System importiert werden sollen. Diese Einrichtung kann verwendet werden, um den gesamten oder einen Teil einer Einstellungsstruktur zu sichern und anschließend aus der Sicherung wiederherzustellen.

Das XML-Dokument weist die folgende DOCTYPE-Deklaration auf:

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

Beachten Sie, dass der System-URI (http://java.sun.com/dtd/preferences.dtd) beim Exportieren oder Importieren von Einstellungen nicht zugegriffen wird; er dient lediglich als Zeichenfolge, um die DTD eindeutig zu identifizieren, d. h.:

{@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 >
            }

Jede Preferences Implementierung muss über eine zugehörige PreferencesFactory Implementierung verfügen. Jede Java(TM)-SE-Implementierung muss ein gewisses Mittel bereitstellen, um anzugeben, welche PreferencesFactory Implementierung zum Generieren der Stammeinstellungsknoten verwendet wird. Auf diese Weise kann der Administrator die Standardeinstellungsimplementierung durch eine alternative Implementierung ersetzen.

Implementierungshinweis: In Suns JRE befindet sich die PreferencesFactory Implementierung wie folgt:

<ol>

<li>

Wenn die Systemeigenschaft java.util.prefs.PreferencesFactory definiert ist, wird der vollqualifizierte Name einer Klasse verwendet, die die PreferencesFactory Schnittstelle implementiert. Die Klasse wird geladen und instanziiert. Wenn dieser Vorgang fehlschlägt, wird ein nicht angegebener Fehler ausgelöst.

</li>

<li>

Wenn eine PreferencesFactory Implementierungsklassendatei in einer Jar-Datei installiert wurde, die für die java.lang.ClassLoader#getSystemClassLoader system class loaderJar-Datei sichtbar ist und diese Jar-Datei eine Anbieterkonfigurationsdatei enthält, die im Ressourcenverzeichnis java.util.prefs.PreferencesFactorybenannt META-INF/services ist, wird der in dieser Datei angegebene Vorname verwendet. Wenn mehr als eine solche Jar-Datei bereitgestellt wird, wird die erste Gefundene verwendet. Die Klasse wird geladen und instanziiert. Wenn dieser Vorgang fehlschlägt, wird ein nicht angegebener Fehler ausgelöst.

</li>

<li>

Wenn schließlich weder die oben genannte Systemeigenschaft noch eine Erweiterungs-Jar-Datei bereitgestellt wird, wird die systemweite Standardimplementierung PreferencesFactory für die zugrunde liegende Plattform geladen und instanziiert.

</li>

</ol>

In 1.4 hinzugefügt.

Java Dokumentation für java.util.prefs.Preferences.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.