Discussion :

[vivelapsp]

Bonjour à tous,

Je suis devant un problème que je n'arrive pas à résoudre : comment dois-je gérer la persistance des données dans mon application Android ?

Je dois stocker beaucoup de données, très confidentielles pour certaines, et je ne sais pas trop comment procéder.

Étant données que mes données peuvent être pour la plupart structurées, j’envisageais de faire une BDD SQLite. Seulement voila, j'ai peur d'utiliser trop de mémoire avec des requêtes intempestives.

Par exemple, je dois a chaque activity (et j'en ai pas mal !), savoir si mon utilisateur à un compte dans mon application (et en connaitre les détails). Comment faire au mieux dans pareil cas ? Je me vois mal faire une requête sur chaque activity pour voir si un compte existe !

J'ai donc pensé a SharedPreferences, mais j'ai l'impression que c'est pas vraiment destiné a stocké ce genre d'information, puis pour les informations structurées, le moins que l'on puisse dire, c'est que ce n'est pas du tout adapté.

J'ai également pensé à utiliser une BDD et à exécuter une seule fois toutes les requêtes à la première activity puis à les stockées dans sharedPreferences, mais j'ai l'impression que cette idée est encore pire et provoque une redondance de données inutile.

Vient ensuite la question de la confidentialité des données. Si je perd mon portable, je ne veux pas que n'importe qui accède aux données stockées.

Bref, avez vous des conseils sur la manière dont je dois procéder ? N'hésitez pas à me demander plus de détails si nécessaire :=)

[nicolofontana12]

Je pense que ton probleme n'est pas aussi compliqué dans la mesure s'il s'agit de checker simplement si l'utilisateur à un compte...Il suffit de checker une seule fois et passer cette parametres entre les differents activity pour les informer si un compte existe ou pas.

Dans tous les cas, SharePreference n'accepte pas des données importantes.
SQLite c'est pour des données importantes mais requetes lourds.

Question securité,je te signale que la base Android peut etre lis sur n'importe qu'elle appareil, par contre il y'a des données private à chaque application non accessible ailleurs.

[vivelapsp]

Tout d'abord, merci pour ta participation :=)

Je pense que ton probleme n'est pas aussi compliqué dans la mesure s'il s'agit de checker simplement si l'utilisateur à un compte...Il suffit de checker une seule fois et passer cette parametres entre les differents activity pour les informer si un compte existe ou pas.

Faux ! Il ne faut pas juste de checker si l'utilisateur à un compte, je me suis peut être pas bien fait comprendre : il faut également récupérer ses informations de compte (nombreuses) qui nécessiteront d'être affichés dans plusieurs activity différentes. Alors effectivement, l'information primordiale est de savoir si l'utilisateur à un compte, car l'activity lancé sera pas la même selon si c'est le cas ou pas. De plus, c'est pas un peu bourrin de devoir se trimballer l'info d'activity en activity via les intents ?

Dans tous les cas, SharePreference n'accepte pas des données importantes.
SQLite c'est pour des données importantes mais requetes lourds.

Qu'entends tu pas "n'accepte pas des données importantes" ?

Question securité,je te signale que la base Android peut etre lis sur n'importe qu'elle appareil, par contre il y'a des données private à chaque application non accessible ailleurs.

Je ne comprends pas ce passage, peux tu être plus précis STP ? Tu veux dire que le mode private permet aux autres apps de ne pas y toucher mais ne permet pas à une personne quelquonque de lire les données ?

[vivelapsp]

Personne pour répondre à mes interrogations ?
J'ai eu une idée, c'est de faire une classe static avec un pattern singleton, mais je ne sais pas si c'est une bonne idée. En plus, je ne sais pas si je dois faire des requêtes a chaque fois que j'ai besoin de données dans cette classe (lourd), ou faire une fois les requêtes et les stockés dans les variables globales de ma classe (redondance des données avec une écriture toujours doublée)

[grunk]

Alors effectivement, l'information primordiale est de savoir si l'utilisateur à un compte, car l'activity lancé sera pas la même selon si c'est le cas ou pas. De plus, c'est pas un peu bourrin de devoir se trimballer l'info d'activity en activity via les intents ?

Je vois pas vraiment de problème à celà. Tu créer un objet Utilisateur qui implémente Parcelable avec tous ce qu'il faut dedans, puis tu le transmet simplement d'activité en activité. Ça me semble être le plus simple et le plus souple.
Après si effectivement ton objet Utilisateur fait 3 Mo faudra peut ête réfléchir à une autre solution

[vivelapsp]

OK merci pour ta réponse.

Je pense pas que cela réponde à ma dernière question : "En plus, je ne sais pas si je dois faire des requêtes a chaque fois que j'ai besoin de données dans cette classe (lourd), ou faire une fois les requêtes et les stockés dans les variables globales de ma classe (redondance des données avec une écriture toujours doublée)".

Et pourquoi préférer l'envoie de cet objet d'activité en activité plutôt qu'une classe static singleton ?

[Feanorin]

Bonjour,

Et pourquoi préférer l'envoie de cet objet d'activité en activité plutôt qu'une classe static singleton ?

Si tu le sauvegarde dand un singleton cela veut dire que tu l'auras en mémoire tout le long de l'application si tu le passes d'activity en activity cela veut dire que tu l'auras en mémoire que lorsque tu en trouveras le besoin.

Maintenant on peut toujours polémiquer sur cet aspect , à toi de voir ce qui te semble le plus juste , après il ne faut pas oublier que l'on se trouve sur un espace mémoire réduit et qu'elle doit être privilégié sur son utilisation ( enfin il me semble ).

Je vois pas vraiment de problème à celà. Tu créer un objet Utilisateur qui implémente Parcelable avec tous ce qu'il faut dedans, puis tu le transmet simplement d'activité en activité. Ça me semble être le plus simple et le plus souple.

Et je pense que cela répondait à ta question .

Après tu peux toujours passer par une requête sur ta BD pour récupérer les infos à un moment t .

Après si effectivement ton objet Utilisateur fait 3 Mo faudra peut ête réfléchir à une autre solution

Comme te l'as fait remarquer grunk si les données deviennent importante alors il faudra que tu réfléchisses à une autre manière de procéder.( fichier,bd ) dans l'idée de stocker les informations quelque part et de chercher la partie de ce que l'on a besoin, au lieu de garder toutes les informations en mémoire de l'application .

[vivelapsp]

Merci merci pour cette nouvelle participation, ça fait plaisir d'être aidé si rapidement :=)

L'ennuie avec Parcelable par rapport au singleton est que cela crée une copie de l'objet, et donc que quand je le modifie et que je fais juste un retour (bouton du téléphone) par exemple, l'objet n'est pas à jour car n'a absolument pas changé (et ce n'est pas un problème de refresh, c'est que j'ai modifié la copie). Je ne sais pas si je me fais bien comprendre, mais vu que le singleton est "polémiquable", je vais opter pour celui-ci.

Mon utilisateur ne devrait pas faire 3mo, donc ça devrait aller comme ça.

"Je vois pas vraiment de problème à celà. Tu créer un objet Utilisateur qui implémente Parcelable avec tous ce qu'il faut dedans, puis tu le transmet simplement d'activité en activité. Ça me semble être le plus simple et le plus souple. "

Je vois toujours pas en quoi ça répond à la question, je vais donc l'illustrer, l'idée c'est de savoir si je fais une requête à chaque fois ou une seule fois ?

Illustration à titre d'exemple : un User avec un attribut name. Le getName fait t-il une requête dans ma base, ou va-t-il lire l'attribut, et faire une requête dans la base si celui ci est null ? Si j'opte pour la seconde solution, quand je ferais un setName(String name), je devrais modifier la base et l'attribut.

[Feanorin]

Bonjour,

L'ennuie avec Parcelable par rapport au singleton est que cela crée une copie de l'objet, et donc que quand je le modifie et que je fais juste un retour (bouton du téléphone) par exemple, l'objet n'est pas à jour car n'a absolument pas changé (et ce n'est pas un problème de refresh, c'est que j'ai modifié la copie). Je ne sais pas si je me fais bien comprendre, mais vu que le singleton est "polémiquable", je vais opter pour celui-ci.

Juste pour information ,tu as deux possibilités le Serializable ou le Parceable, avec le parceable tu deviens plus souple puisque c'est toi qui gère les objets à copier.
http://developer.android.com/referen...ializable.html

Maintenant si c'est vraiment un objet que tu veuilles pouvoir modifier et lire, alors l'option du singleton peut s'avérer une bonne idée ou sinon il faudra que tu gère les données via OnActivityResult pour les modifier .

Je vois toujours pas en quoi ça répond à la question,

Si je reprends ce que tu as expliqué , tu veux un objet modifiable donc si je résume bien t'as base de donnée , devrait elle aussi se maintenir à jour , donc de toutes manières tu auras plusieurs requête à faire .

La proposition que te proposait grunk était de construire un Objet user que tu initialiserais au début grâce à ta bd et que tu utiliserais par la suite en le transportant d'activity en activity. ( voilà pourquoi je disais que cela répondait à ta question, donc une seule requête)

Je vois toujours pas en quoi ça répond à la question, je vais donc l'illustrer, l'idée c'est de savoir si je fais une requête à chaque fois ou une seule fois ?

Maintenant si tu veux pouvoir modifier les données de cet Objet ( donc de la BD) , tu peux alors utiliser un singleton sur ton Objet qui lui maintiendra également ta BD à jour. Cela te permettra de centraliser toutes les informations relatives à ta BD , et sera plus lisible dans ton code .

Essaye de faire le moins de requête possible .

[vivelapsp]

D'accord, merci à tous pour vos réponses

Je crois que tout est clair, je vais donc utiliser un singleton qui ne fera des requêtes sur la BDD qu'à l'initialisation, ou à la création / mise à jour des données de la BDD.

Merci encore pour votre aide