Discussion :

[steph68b]

hello!

grâce à vous tous j'ai pas mal avancé maintenant!

mais un truc me turlupine toujours au retour sur mainActivity...
(pas facile à expliquer, je vais essayer de faire au mieux!)

mainActivity -> activityFille -> bouton "back" -> retour mainActivity

ma mainActivity initialise 2 spinners et selon le choix fait dans ces spinners, on débranche sur activityFille avec la ligne du spinner.

au retour, j'aimerais que les spinners soient réinitialisés, sans mémoriser le choix précédent... ce qui est bien le cas sur ma GT 10.1 (page rechargée de A à Z!)... mais pas avec la NEXUS7 & les emulator 2.3/3.0/4.0 & 4.1 qui gardent mainActivity en l'état!
-> càd que les spinners affichent les lignes sélectionnées avant de passer à activityFille...
-> ce qui ne serait pas gênant en soit, mais problème, on ne peut re-sélectionner la même ligne!

ex:
* main (choix spinner 1 = TOTO) -> fille -> back main
* spinner1 = toujours TOTO
* mais si je ne peux pas resélectionner TOTO pour débrancher sur fille
* je suis obligé de sélectionner d'abord spinner1=TATA, back sur main et re-select TOTO... pas vraiment pratique quoi!


alors:
1.) déjà je ne comprends pas cette différence de comportement(?)
(mais je suppose que le comportement normal est de conserver l'état, et que c'est la GT qui fonctionne différemment?)

2.) mais surtout je n'arrive pas à faire en sorte que ma main se recharge complètement (comme au run de l'appli!)... même avec un restore de bundle en début de onCreate()!

alors que pourtant, en faisant une rotation de l'écran, toute la main est réinitialisée, dont les spinners!

donc quelle est la différence?

là, j'avoue sécher...

merci.

[Hephaistos007]

A toi de mettre à jour (notifyDataChanged) le contenu de tes spinners dans la méthode onResume()

Pour ce qui est du changement d'orientation, les vues de l'activités sont entièrement détruites puis recréées. Ce comportement est normal.

[nicroman]

Tout dépend de ce que fait Android....

Disons qu'on a deux activité A & B et que B overlap entierement A (on ne voit plus A à travers)... on peut avoir deux "types" de comportements:

Cas 'simple':
A.onCreate()
A.onStart()
A.onResume()
... l'utilisateur est sur A
A.onClick()
A.onPause() <= A n'est plus le "focus"
B.onCreate()
A.onStop() <= on ne voit plus A (les animations s'arrêtent par exemple)
B.onStart()
B.onResume()
... l'utilisateur est sur B
B.onPause()
B.onStop()
B.onDestroy()
A.onRestart()
A.onStart()
A.onResume()
....l'utilisateur est à nouveau sur A



Cas 'low-memory'
A.onCreate()
A.onStart()
A.onResume()
... l'utilisateur est sur A
A.onClick()
A.onPause() <= A n'est plus le "focus"
B.onCreate()
A.onStop() <= on ne voit plus A (les animations s'arrêtent par exemple)
... ici android a besoin de mémoire...
A.onSaveInstanceState()
A.onDestroy()
n.b. .. L'instance de A est alors *détruite* toutes les données stockées dans l'instance (membres) seront à recréer
B.onStart()
B.onResume()
... l'utilisateur est sur B
B.onPause()
A.onCreate() <= avec le bundle obtenu lors de onSaveInstanceState()
B.onStop()
B.onDestroy()
A.onStart()
A.onResume()
....l'utilisateur est à nouveau sur A

[steph68b]

encore une embrouille donc... moi qui pensais toucher au but, je me retrouve encore perdu...

bon je vais me pencher sur la question, mais en attendant, 2 questions (connes?) me viennent là, tout de suite:

1.) il faut donc implémenter les 2 cas, simple ET low memory?
-> d'ailleurs n'est-il pas paradoxale qu'un device physique (ma GT ici) manque de mémoire et se retrouve donc dans le cas "low memory"
-> alors que mes émulateurs (& la nexus) déroulent le cas "simple"?

2.) peut-on simuler une rotation ou un low memory, pour ne gérer que ce dernier cas, et tout recréer à chaque fois, plus + simple (trop??) finalement?

et pour répondre à une de tes interrogation: mes activités sont toutes en plein écran, elles s'overlapent donc systématiquement.

[nicroman]

Ben non... il faut juste implémenter les bonnes choses aux bons endroits....

Si a chaque fois que l'activité A revient à l'avant-plan il faut "recharger" une liste... le code doit alors être dans onResume()... si ce n'est pas la cas, dans le onCreate().

Il y a pas grand chose à implémenter au bout du compte: onCreate/onDestroy (gain/perte du 'context') et onResume/onPause (gain/perte du 'focus')....

Éventuellement onSaveInstanceState dans quelques cas complexes (quand on veut conserver un état après le onDestroy)...

Et onStart/onStop (gain/perte de la visibilité) pour les cas d'activités animées (il ne sert à rien de décoder une vidéo si on ne la voit plus par exemple).

Et bien faire les passages de paramètres entre activités par les Intents....


Quant à la mémoire, il ne faut surtout pas confondre mémoire physique (celle du device) et mémoire dalvik (celle de java ou tourne l'appli)... la dernière est très limitée (entre 16Mo et 64Mo selon les versions d'android !!!)
A noter qu'il est possible dans l'émulateur de spécifier cette dernière (heap).

[steph68b]

Je viens de me refaire les cycles ce matin oui.

Par contre, moi d'instinct, dans mon cas, j'aurais plutôt implémenté onRestart() (uniquement lancé au retour sur 1 Activity) que onResume() (lancé systématiquement à chaque fois!)!

Je m'espique:

onCreate()

Code :

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

1
2
3
4
...
initSpinner1();
initSpinner2();
...

onRestart()

Code :

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

1
2
initSpinner1();
initSpinner2();

Avantage pour moi: ne pas avoir à déplacer dans le onResume() des imbrications complexes de tests de pre-launch.

Peut être pas 100% Andro-philosophique, mais fonctionnel malgré tout je pense... d'un point de vue logique en tout cas.

PS: merci pour la précision "mémoire", très important en effet!