ISerializable Interface

Définition

[Android.Runtime.Register("java/io/Serializable", "", "Java.IO.ISerializableInvoker")]
public interface ISerializable : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("java/io/Serializable", "", "Java.IO.ISerializableInvoker")>]
type ISerializable = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Dérivé

Android.Icu.Math.BigDecimal

Android.Icu.Math.MathContext

Android.Icu.Text.CurrencyPluralInfo

Android.Icu.Text.DateFormatSymbols

Android.Icu.Text.DateIntervalInfo

Plus…

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable IDisposable

Remarques

La sérialisabilité d’une classe est activée par la classe implémentant l’interface java.io.Serializable.

<fort>Avertissement : la désérialisation des données non approuvées est intrinsèquement dangereuse et doit être évitée. Les données non approuvées doivent être validées avec soin. </strong>

Les classes qui n’implémentent pas cette interface n’auront aucun de leur état sérialisé ou désérialisé. Tous les sous-types d’une classe sérialisable sont eux-mêmes sérialisables. L’interface de sérialisation n’a pas de méthodes ou de champs et sert uniquement à identifier la sémantique d’être sérialisable.

Pour autoriser la sérialisation des sous-types de classes non sérialisables, le sous-type peut assumer la responsabilité de l’enregistrement et de la restauration de l’état des champs de package publics, protégés et (si accessibles) du supertype. Le sous-type peut assumer cette responsabilité uniquement si la classe qu’elle étend a un constructeur no-arg accessible pour initialiser l’état de la classe. Il s’agit d’une erreur de déclarer une classe Serializable si ce n’est pas le cas. L’erreur est détectée au moment de l’exécution.

Lors de la désérialisation, les champs des classes non sérialisables sont initialisés à l’aide du constructeur public ou protégé no-arg de la classe. Un constructeur no-arg doit être accessible à la sous-classe sérialisable. Les champs des sous-classes sérialisables seront restaurés à partir du flux.

Lors de la traversée d’un graphique, un objet peut être rencontré qui ne prend pas en charge l’interface Serializable. Dans ce cas, notSerializableException est levée et identifie la classe de l’objet non sérialisable.

Les classes qui nécessitent une gestion spéciale pendant le processus de sérialisation et de désérialisation doivent implémenter des méthodes spéciales avec ces signatures exactes :

private void writeObject(java.io.ObjectOutputStream out)
                throws IOException
            private void readObject(java.io.ObjectInputStream in)
                throws IOException, ClassNotFoundException;
            private void readObjectNoData()
                throws ObjectStreamException;

La méthode writeObject est chargée d’écrire l’état de l’objet pour sa classe particulière afin que la méthode readObject correspondante puisse la restaurer. Le mécanisme par défaut permettant d’enregistrer les champs de l’objet peut être appelé en appelant out.defaultWriteObject. La méthode n’a pas besoin de s’inquiéter de l’état appartenant à ses superclasses ou sous-classes. L’état est enregistré en écrivant les champs individuels dans ObjectOutputStream à l’aide de la méthode writeObject ou en utilisant les méthodes pour les types de données primitifs pris en charge par DataOutput.

La méthode readObject est chargée de lire à partir du flux et de restaurer les champs de classes. Il peut appeler in.defaultReadObject pour appeler le mécanisme par défaut pour restaurer les champs non statiques et non temporaires de l’objet. La méthode defaultReadObject utilise des informations dans le flux pour affecter les champs de l’objet enregistré dans le flux avec les champs nommés correspondants dans l’objet actif. Cela gère le cas où la classe a évolué pour ajouter de nouveaux champs. La méthode n’a pas besoin de s’inquiéter de l’état appartenant à ses superclasses ou sous-classes. L’état est restauré en lisant les données de ObjectInputStream pour les champs individuels et en effectuant des affectations aux champs appropriés de l’objet. La lecture des types de données primitifs est prise en charge par DataInput.

La méthode readObjectNoData est chargée d’initialiser l’état de l’objet pour sa classe particulière dans l’événement où le flux de sérialisation ne répertorie pas la classe donnée en tant que superclasse de l’objet désérialisé. Cela peut se produire dans les cas où la partie de réception utilise une version différente de la classe de l’instance désérialisée que la partie émettrice, et la version du destinataire étend les classes qui ne sont pas étendues par la version de l’expéditeur. Cela peut également se produire si le flux de sérialisation a été falsifié ; par conséquent, readObjectNoData est utile pour initialiser correctement les objets désérialisés malgré un flux source « hostile » ou incomplet.

Les classes sérialisables qui doivent désigner un autre objet à utiliser lors de l’écriture d’un objet dans le flux doivent implémenter cette méthode spéciale avec la signature exacte :

ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException;

Cette méthode writeReplace est appelée par sérialisation si la méthode existe et qu’elle serait accessible à partir d’une méthode définie dans la classe de l’objet sérialisé. Ainsi, la méthode peut avoir un accès privé, protégé et privé à package. L’accès de sous-classe à cette méthode suit les règles d’accessibilité Java.

Les classes qui doivent désigner un remplacement lorsqu’une instance de celui-ci est lue à partir du flux doivent implémenter cette méthode spéciale avec la signature exacte.

ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;

Cette méthode readResolve suit les mêmes règles d’appel et règles d’accessibilité que writeReplace.

Le runtime de sérialisation associe à chaque classe sérialisable un numéro de version appelé serialVersionUID, qui est utilisé lors de la désérialisation pour vérifier que l’expéditeur et le récepteur d’un objet sérialisé ont chargé des classes pour cet objet compatibles avec la sérialisation. Si le récepteur a chargé une classe pour l’objet qui a un serialVersionUID différent de celui de la classe de l’expéditeur correspondant, la désérialisation entraîne une InvalidClassException. Une classe sérialisable peut déclarer explicitement son propre serialVersionUID en déclarant un champ nommé "serialVersionUID" qui doit être statique, final et de type long:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

Si une classe sérialisable ne déclare pas explicitement un serialVersionUID, le runtime de sérialisation calcule une valeur serialVersionUID par défaut pour cette classe en fonction de différents aspects de la classe, comme décrit dans la spécification de sérialisation de l’objet Java(TM). Toutefois, il est <>fortement recommandé</em> que toutes les classes sérialisables déclarent explicitement des valeurs serialVersionUID, car le calcul serialVersionUID par défaut est très sensible aux détails de classe qui peuvent varier en fonction des implémentations du compilateur et peut donc entraîner des s inattendues InvalidClassExceptionpendant la désérialisation. Par conséquent, pour garantir une valeur serialVersionUID cohérente entre différentes implémentations du compilateur Java, une classe sérialisable doit déclarer une valeur serialVersionUID explicite. Il est également fortement recommandé que les déclarations serialVersionUID explicites utilisent le private modificateur si possible, car ces déclarations s’appliquent uniquement aux champs class--serialVersionUID ne sont pas utiles en tant que membres hérités. Les classes de tableau ne peuvent pas déclarer un serialVersionUID explicite. Elles ont donc toujours la valeur calculée par défaut, mais l’exigence de correspondance des valeurs serialVersionUID est annulée pour les classes de tableau.

L’implémentation Android du calcul serialVersionUID change légèrement pour certaines classes si vous ciblez android N. Pour préserver la compatibilité, cette modification n’est activée que si la version du Kit de développement logiciel (SDK) cible de l’application est définie sur 24 ou version ultérieure. Il est vivement recommandé d’utiliser un champ serialVersionUID explicite pour éviter les problèmes de compatibilité.

<H3>Implémenter Serializable Judiciously</h3> Reportez-vous au chapitre de Java effectif sur la sérialisation pour une couverture complète de l’API de sérialisation. Le livre explique comment utiliser cette interface sans nuire à la facilité de maintenance de votre application.

<>Les alternatives recommandées</h3><fort JSON</strong>> sont concises, lisibles par l’homme et efficaces. Android inclut à la fois une android.util.JsonReader streaming API et une org.json.JSONObject tree API pour lire et écrire JSON. Utilisez une bibliothèque de liaison comme GSON pour lire et écrire des objets Java directement.

Ajouté dans la version 1.1.

Documentation Java pour java.io.Serializable.

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.

Propriétés

Méthodes

Méthodes d’extension

S’applique à