données non persistante d'une application

Version imprimable

19/05/2010, 22h54
yan

données non persistante d'une application

Bonjour.
Depuis 2 J je suis devenue expert android et java 8-)

Je suis assez surpris par l'architecture et la philosophie d'une application android...

Par exemple, que l'activity soit recréé à chaque rotation du téléphone me perturbe... Ou son cycle de vie 8O
Mais bon, faut un temps d'adaptation. Le temps de bien comprendre le rôle de chaque acteurs.

J'aimerais savoir quel est votre méthode pour manipuler des données entre les activity, service et receiver.
J'ai trouvé cela (Non-Persistent Objects)
http://developer.android.com/guide/a...amework.html#3

Mais faire des static ou le fameux pattern de diable Singleton me fait un peux froid dans le dos.

Mais comme je suis un gros débutant JAVA/Android, je viens en amis pour apprendre et recevoir la lumière des super experts android :king:
...:aie:
21/05/2010, 09h32
Jilkaren

Salut yan ! Bon alors étant moi même débutant en android (j'ai du m'y mettre pendant mon stage), je peux te conseiller 2, 3 adresses utiles pour commencer :

Cet article, qui explique comment rendre son application compatible avec de nombreuses configurations (tres important)

Anddev.org -> un forum (en anglais) qui est centré sur le développement android. J'ai trouvé pas mal de tutos la-bas et de posts intéressants la-bas.

Pour finir, je finirais par dire que le point le plus contrariant avec android, c'est les nombreuses versions dont il faut tenir compte avec android. Pour exemple, je developpe sous android 1.5 en ce moment, et des points qui plantent sous cette version marche avec la v2.0 ... c'est assez pénible.

J'espère t'avoir aidé (même si je suis pas sur d'être totalement dans le sujet)
21/05/2010, 09h49
yan

Citation:

Envoyé par Jilkaren

J'espère t'avoir aidé (même si je suis pas sur d'être totalement dans le sujet)

:merci: pour les liens, y as des choses trés intéressante :mrgreen:

Ma questions est plutôt, quelles méthodes utilisez vous pour partager les données de l'application entre activity/service/receiver.
21/05/2010, 10h06
MrDuChnok

Salut,

En faite, y'a pas une manière qui est mieux qu'une autre, celà dépend vraiment de beaucoup de paramètres pour décider quelles solutions adoptés :
- type de données à échanger
- quantité de données
- lecture seule
- notification de modification
- habitude de programmation ?
- etc

Sans tout cité, voici quelques moyens qu'on peut retrouver :
- sérialisation, stokage SQLlite, stockage fichier, stockage content provider, preference, etc.
21/05/2010, 13h30
yan
Citation:

Envoyé par MrDuChnok

Sans tout cité, voici quelques moyens qu'on peut retrouver :
- sérialisation, stokage SQLlite, stockage fichier, stockage content provider, preference, etc.

ceci est plutôt pour des données persistant.

Je parle des données du programme pendant une exécution, pas entre plusieurs exécution différente.

C'est le lien que j'ai donnée de la FAQ android:
- android.app.Application : ma semble le plus intéressant
- public static field/method ou singleton : ça va un peu à contre sens de ce que l'on m'as appris.
- HashMap of WeakReferences to Objects : pas trop d'avis encore.
Pour moi, il me manque quelque chose dans ce trio activity-service-receiver. Un point central, là où est la données de l'application en cours d'exécution.

Comme je débute, y as surement quelque chose que j'ai du mal à comprendre. C'est pour cela que je demandais vos préférences.
25/05/2010, 12h05
Pffft

Quand j'ai encontré la même question initiallement j'ai utilisé des accessors statiques fortement typés (pas de Map d'Objects) pour chaqu'un de mes objets. Je me suis tôt aperçu que ce n'était pas idéal car les statiques risquent de limiter la capacité de Android de vider le memoire.

Alors j'ai étendu android.app.Application par une classe qui encore expose mes accesseurs et configuré AndroidManifest pour remplacer le Application défaut avec le mien (android:name="path.Class"). Maintenant mes Activity, Services and Receivers reçoient le seul instance de mon Application quand ils appellent getContext().

Mais encore j'ai l'avantage de savoir en avance tous les instances dont je pourrait avoir besoin. Sinon je te conseil d'utiliser ton propre Application en tout cas mais malhereusement avec un un Map faiblement typé.

J'espère que c'est utile.
25/05/2010, 14h05
yan

Citation:

Envoyé par Pffft

Sinon je te conseil d'utiliser ton propre Application en tout cas

C'est ce qui me semble aussi le plus intéressant pour une appli un peu plus gros qu'un hello word. Par contre, je suppose qu'il faut protéger un minimum les accès au données pour éviter trop d'accès concurrent, non?
Si j'ai bien compris, on peut avoir un service qui s'exécute dans un process à part et donc dans un thread différent. Pour le receiver, il me semble que c'est forcement le main thread.

Citation:

mais malhereusement avec un un Map faiblement typé.

Par contre, j'ai pas compris l'utilité de cette map.
25/05/2010, 16h52
Pffft

T'as raison, c'est toujours bon pratique de garder contre l'acces concurrent. Pour nous la risque n'existe pas - notre instance d'Application est utilisé pour exposer des objets complexes entre instances d'Activity alors point de risque d'acces à partir d'un deuxieme thread.

Et selon mon comprehension du doc (http://developer.android.com/referen...p/Service.html) même les Services sont lancées dans le "main thread of the application process", également pour les Receivers ((http://developer.android.com/referen...tReceiver.html) - "normalement" - onReceive "is normally called within the main thread of its process".

En tous cas on est encouragé d'utiliser un Timer dans nos Services alors c'est bien probable qu'il faut au moins synchroniser les accessors exposés par l'instance d'Application. Je suppose que l'objet le plus logique de fonctionner comme lock est l'Application soi-même.

Je serais très interessé de savoir ce que tu decide.

EDIT - je voulais dire que j'ai mentionné un Map seulement au cas où t'avais besoin de stocker des objets faiblement typés. Honnêtement, je ne peux imaginer un exemple dans lequel on voudrait le faire.
25/05/2010, 17h11
yan

Citation:

Envoyé par Pffft

Et selon mon comprehension du doc (http://developer.android.com/referen...p/Service.html) même les Services sont lancées dans le "main thread of the application process", également pour les Receivers ((http://developer.android.com/referen...tReceiver.html) - "normalement" - onReceive "is normally called within the main thread of its process".

Par défaut ça semble bien être le cas. Mais je me méfie un peu. J'adore le normally pour un receiver, ça rassure :aie:

Pour le service, on peut le lancer en "remote" :
http://developer.android.com/referen...rServiceSample

Je débute donc je ne suis sure de rien.

Citation:

Je serais très interessé de savoir ce que tu decide.

Pour l'instant je fais de petit programme. Pour l'appli finale, je pense que l'on va créer une classe Application. Ca me semble le plus propre et le plus simple à maintenir.

:merci: pour tes explications.
30/05/2010, 10h24
nicolofontana12

Les Acitivité peuvent communiquer avec SharePreferences
30/05/2010, 21h05
yan

Citation:

Envoyé par jahbromo

Les Acitivité peuvent communiquer avec SharePreferences

quelle serait l'avantage par rapport à un singleton ou sa propre application?