Discussion :

[ChPr]

Bonjour à toutes et à tous,

Dans une application, je dois enregistrer les paramètres de divers opérateurs. Ces paramètres sont nombreux et variés. De ce fait, je me suis penché sur l'enregistrement de structures.

Après avoir bien pataugé, j'ai enfin réussi. A savoir que la structure (ou classe) que vous enregistrez doit être sérialisable ou que s'i elle ne l'est pas, vous devez la rendre sérialisable, ce qui se fait on ne peut plus simplement en ajoutant dans sa déclaration : "implements serializable".

Pour autant, ce n'est pas gagné. il faut de plus :

• que chaque membre de votre classe soit aussi sérialisable, ce qui semble logique,
• mais ce qui l'est moins : que votre classe ne soit pas incluse dans une classe qui comprend des éléments non sérialisable. Exemple tout bête, vous créer une application avec une vue principale (qui étend Activity) et vous déclarer votre classe à l'intérieur de cette classe. Et bien cela ne fonctionnera pas car Activity n'est pas sérialisable. Il faut être sûr que votre classe ne dépend d'aucune classe qui serait non sérialisable ou qui contient des éléments non sérialisables.

Bien, je suppose que vous le saviez. Pour autant, j'ai cherché dans les fichiers de mon smartphone le fichier que je venais de créer. Je ne l'ai pas trouvé. Grâce à l'instruction context.getFileDir, j'ai su où il était : c'est dans le répertoire :

/data/data/com.example.monappli/files

Mais j'ai été infoutu de trouver ce répertoire. Où est-il ? Est-il possible de copier ce fichier pour l'exporter vers un PC par exemple.

Merci de votre aide.

Pierre

[Hizin]

Je pense que le mot-clef "transient" pourrait aussi t'aider dans ta quête du Serializable.
Sur Android, tu as aussi un "format créé pour", qui est "Parcelable". Un site web a été réalisé pour rendre sa classe Parcelable automatiquement ( http://www.parcelabler.com/ ).

Concernant le répertoire "data", je crois que celui-ci est invisible pour les non-rootés par défaut.
De ce que je lis, tu peux y accéder via le shell adb (dans un terminal : "adb shell", puis tu y navigues).

[grunk]

Dans une application, je dois enregistrer les paramètres de divers opérateurs

Ne tomberais tu pas dans le cadre de l'utilisation des sharedpreference et des preferencescreen ?
http://developer.android.com/guide/t.../settings.html

mais ce qui l'est moins : que votre classe ne soit pas incluse dans une classe qui comprend des éléments non sérialisable. Exemple tout bête, vous créer une application avec une vue principale (qui étend Activity) et vous déclarer votre classe à l'intérieur de cette classe. Et bien cela ne fonctionnera pas car Activity n'est pas sérialisable. Il faut être sûr que votre classe ne dépend d'aucune classe qui serait non sérialisable ou qui contient des éléments non sérialisables.

Ca me parait très étrange. T'as une documentation sur le sujet ? J'ai des classes Parcelable que j'utilise dans des activity qui ne le sont pas , et rien ne m’empêche de les sérialiser quand j'ai envie. Il ne faut juste pas que ta classe est une référence vers un objet non sérialisable.

/data/data/com.example.monappli/files

C'est le dossier privé de ton application , accessible uniquement par elle et rien d'autre. Sur un appareil rooté tu as accès à ce dossier mais tu compromet par la même occasion la sécurité.
Tu peux écrire le fichier dans un dossier public avec par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

File path = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);

[Hizin]

mais ce qui l'est moins : que votre classe ne soit pas incluse dans une classe qui comprend des éléments non sérialisable. Exemple tout bête, vous créer une application avec une vue principale (qui étend Activity) et vous déclarer votre classe à l'intérieur de cette classe. Et bien cela ne fonctionnera pas car Activity n'est pas sérialisable. Il faut être sûr que votre classe ne dépend d'aucune classe qui serait non sérialisable ou qui contient des éléments non sérialisables.

Ca me parait très étrange. T'as une documentation sur le sujet ? J'ai des classes Parcelable que j'utilise dans des activity qui ne le sont pas , et rien ne m’empêche de les sérialiser quand j'ai envie. Il ne faut juste pas que ta classe est une référence vers un objet non sérialisable.

Tiré de la doc (source) :

When traversing a graph, an object may be encountered that does not support the Serializable interface. In this case the NotSerializableException will be thrown and will identify the class of the non-serializable object.

Si tu as des attributs non-serializable dans ton objet serializable, l'exception "NotSerializableException" est levée.
Plusieurs choix alors :
- faire soi-même la serialization (je ne me suis jamais interrogé sur ce point)
- déclarer ces attributs "transient" (i.e. : "ne pas sauvegarder")
- rendre ces attributs serializable (quand c'est possible, c'est le plus rapide)

Tu as aussi un warning dans les IDE indiquant les classes notées comme Serializable et possédant des attributs non-serializable.

[Hephaistos007]

Je suis très étonné par ta remarque sur l'Activity. Si c'est l'Activity qui possède un référence à ta classe, alors je ne vois pas pourquoi elle devrait être à son tour serializable. En revanche, si c'est ta classe qui possède une référence à l'Activity, alors c'est normal que le processus de sérialisation exige d'elle qu'elle soit serializable. Et dans ce cas, un simple mot clé transient devant la référence règle le problème.

[ChPr]

Je pense que le mot-clef "transient" pourrait aussi t'aider dans ta quête du Serializable.
...

Faudra que j'essaie

... Un site web a été réalisé pour rendre sa classe Parcelable automatiquement ( http://www.parcelabler.com/ ). ...

C'est effectivement pratique sauf quand la classe contient des éléments non parcelable et/ou non serializable. J'ai la remarque suivante :

Check that the following classes implement either Parcelable or Serializable.
Otherwise you'll get a RuntimeException.

Rect
Paint

@ grunk C'est d'ailleurs ces exceptions qui m'ont amené à écrire le début de ce post. Je n'ai pas de documentation spécifique à ce sujet ; ce sont des tas d'essais infructueux qui m'ont amené à cela. Je pense en avoir fait suffisamment pour maintenir ce que j'ai écrit. Mais bon, il est possible que je n'ai pas tout bien vu.

Je ne pense pas être dans le cas des "sharePreferences" car dans mon application, je crée un schéma qui peut contenir de 2 à n opérateurs selon ce que je veux simuler. Ces opérateurs sont tous issu d'une classe de base et partage donc des paramètres communs. Pour régler (momentanément) ce problème j'ai créé un classe spéciale "Parametres" qui ne comporte que des variables sérialisables (les Rect et RectF, non sérialisables, sont remplacés par des left, top, right et bottom).

Toutefois, je prends bonne note de toutes vos remarques, dont je vous remercie, car j'aurai certainement l'occasion de les mettre en œuvre.

Question :Quand je lis un des fichiers créés, je n'ai pas trouvé, pour l'instant, d'autres méthodes pour lire les paramètres de mes "n" opérateurs que de faire une boucle comptant jusqu'à "n". La voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        try {
            ObjectInputStream is = null;
            FileInputStream fis = context.openFileInput(nom);
            listOpe.clear();
            is = new ObjectInputStream(fis);
            Parametres prm = (Parametres) is.readObject();
            int nbOps = prm.nbOpes; // je lis le premier dans lequel j'ai mis le nombre d'opérateurs
            for (int i = 0; i < nbOps-1; i++)
                prm = (Parametres) is.readObject(); // je lis les n-1 suivants
            is.close();
            fis.getChannel().close();
        } catch (IOException e) {
            e.printStackTrace();
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }

Existe-t-il une fonction du type "End of File (EoF)", auquel cas, je ferais une boucle "while(! EoF) {...} (comme je fais avec ce bon vieux Pascal )

Cordialement.

Pierre

[ChPr]

... Tu peux écrire le fichier dans un dossier public avec par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

File path = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);

Là, je n'ai pas compris. J'avais cru voir que les enregistrements "sérialisés" ne pouvaient se faire que dans la mémoire interne (et comme vous dites non visible si non rooté).

Cordialement.

Pierre

[grunk]

Tiré de la doc (source)

C'est bien ce que je dit, le fait que ton objet serializable soit référencé par une classe qui ne l'est pas ne devrait pas être un problème. L'inverse évidemment l'est , d'où l'utilisation de transient. Ou alors j'ai pas compris de quoi on parlais ^^

Là, je n'ai pas compris. J'avais cru voir que les enregistrements "sérialisés" ne pouvaient se faire que dans la mémoire interne (et comme vous dites non visible si non rooté).

Un enregistrement sérialisé c'est ni plus ni moins qu'un fichier. Le contenu du fichier n'a pas d'incidence sur l'endroit ou tu peux écrire. Tu as le droit d'écrire dans les dossiers public , quelque soit le contenu du fichier.

[ChPr]

C'est bien ce que je dit, le fait que ton objet serializable soit référencé par une classe qui ne l'est pas ne devrait pas être un problème. L'inverse évidemment l'est , d'où l'utilisation de transient. Ou alors j'ai pas compris de quoi on parlais ^^ ...

Peut-être que je me suis mal exprimé. Actuellement, ma classe "Pärametres" fait l'objet d'un fichier à elle toute seule. Je l'ai rendu sérialisable et tout fonctionne bien.

Maintenant, cette classe, je l'introduis en classe interne à ma classe "Operateur" qui n'est pas sérialisable à cause d'un RectF. Je recompile le tout en modifiant les imports nécessaires pour que ma classe "Parametres" soit localisée. Ça compile sans problème. J'essaie maintenant de faire un enregistrement.J'obtiens :

} catch (IOException e) { "e:java.io.NotSerializableException : android.graphics.Rect"

... Un enregistrement sérialisé c'est ni plus ni moins qu'un fichier. Le contenu du fichier n'a pas d'incidence sur l'endroit ou tu peux écrire. Tu as le droit d'écrire dans les dossiers public , quelque soit le contenu du fichier.

Je ne dois pas être bien malin, mais je ne vois pas comment faire pour que ce fichier se trouve à un emplacement que je puisse voir (usbStorage, je suppose). Si tu peux me donner un exemple de code.

Cordialement.

Pierre

[grunk]

Pourquoi rendre ta classe internet si elle existe déjà indépendamment ?


Pour le code : pas testé mais quelque chose comme ça devrait fonctionner :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
File path = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);
FileOutputStream fos = new FileOutputStream(new File(path, "myfile.ext"));
ObjectOutputStream os = new ObjectOutputStream(fos);
os.writeObject(MonObjetSerializable);
os.close();
fos.close();

Il faut aussi penser à l'autorisation d'écriture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

[ChPr]

Pourquoi rendre ta classe internet si elle existe déjà indépendamment ? ..

Tu auras voulu dire "serializable", je suppose

Maintenant, si c'est serializable que tu as voulu dire, je ne vois pas la relation avec son indépendance. Ma classe ne comporte que des éléments sérialisables : String et byte, int, double, boolean que je suppose sérialisables. Je n'ai donc plus rendu ma classe sérialisable (ta question : Pourquoi rendre ta classe ...) en supprimant "implements Serializable). Du coup, cela ne fonctionne plus (exception NonSerializable).

Par contre, lorsque j'avais trouvé ce moyen d'enregistrement sur internet, j'avais cru comprendre que les fichiers ne pouvaient être enregistrés que dans la mémoire interne. C'est Génial, tu me montres que c'est possible. Je peux même les enregistrer dans un répertoire personnel sur la mémoire usb ou sur une carte SD externe. Merci grunk.

Par ailleurs, s'il existait une réponse à cette question que j'avais posée :

Question :Quand je lis un des fichiers créés, je n'ai pas trouvé, pour l'instant, d'autres méthodes pour lire les paramètres de mes "n" opérateurs que de faire une boucle comptant jusqu'à "n". La voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        try {
            ObjectInputStream is = null;
            FileInputStream fis = context.openFileInput(nom);
            listOpe.clear();
            is = new ObjectInputStream(fis);
            Parametres prm = (Parametres) is.readObject();
            int nbOps = prm.nbOpes; // je lis le premier dans lequel j'ai mis le nombre d'opérateurs
            for (int i = 0; i < nbOps-1; i++)
                prm = (Parametres) is.readObject(); // je lis les n-1 suivants
            is.close();
            fis.getChannel().close();
        } catch (IOException e) {
            e.printStackTrace();
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }

Existe-t-il une fonction du type "End of File (EoF)", auquel cas, je ferais une boucle "while(! EoF) {...} (comme je fais avec ce bon vieux Pascal )

Cordialement.

Pierre

[nicroman]

J'arrive un peu tard dans la discussion... mais en gros:

1. Il faut séparer absolument les "données" brutes (si j'ai bien compris tes classes opérateurs, etc..) des éléments affichables (qui risquent de contenir des choses non sérialisables justement).

2. Le mot clé "transient" permet de le faire mais uniquement dans des cas particuliers (l'objet maintient une donnée "cache", ou encore un objet de logger) mais en aucun cas ne devrait "cacher" un manquement à la première règle.

3. Je n'ai jamais utilisé de ObjectInputStream pour trois raisons principales:
- La complexité de l'introspection Java est parfois "too-much" pour juste sauver deux éléments.
- La non interopérabilité des fichiers entre des machines virtuelles différentes (rien ne dit dans la doc Java que cette interopérabilité doit être respectée).
- L'énorme difficulté à rendre lisible un fichier issu d'une version antérieure (et différente) du code.

C'est surtout le dernier point qui pose problème: demain tu rajoutes un élément à sauvegarder dans le fichier... tu modifies les objets (et tu changes le serialize-id du coup)... et bim, les anciens fichiers ne sont plus lisibles. En général je préfère personnellement passer par des formats de fichiers "connus" (json, xml) voir même à des bases de données (sqlite) pour les fichiers qui ne doivent être lus qu'en partie.
La mise en place est plus complexe (quoique... une interface IXMLSerializable à implémenter pour chaque objet n'est pas non plus la mer à boire), mais au moins, on peut gérer à la lecture les versions plus anciennes, les fichiers mal-formés et autres joyeusetés.


Quant à la location du fichier, c'est hélas *toujours* en mémoire interne.

Je peux même les enregistrer dans un répertoire personnel sur la mémoire usb

c'est ce qu'on appelle la mémoire interne (getExternalFileStorage = mémoire interne vue comme disque USB quand branchée à un PC).

ou sur une carte SD externe.

ce n'est plus possible depuis Android 4.1

[ChPr]

@ nicroman : En cours de développement, j'ai besoin de faire des enregistrements/lectures sans trop à avoir à me casser les pieds à écrire des procédures spécifiques et la méthode des objets me convient bien.

Pour autant, si je vais jusqu"au bout, je ferai des procédures spécifiques afin de pouvoir échanger avec mes applications qui tournent sous Windows et Linux.

Je retiens tous les défauts dont tu me parles.

Par contre, au niveau de la carte SD, je pense que la version à partir de laquelle cela ne sera plus permis est postérieure à la 4.1. J'en veux pour preuve mon smartphone qui est en 4.1.2 et sur lequel cela fonctionne très bien.

Cordialement.

Pierre