Discussion :

[androidisme]

Bonjour,

J'ai toujours du mal à savoir si les deux sont corrélés ou non. Le cycle de vie d'une Activity est-il dépendant de celui de l'application qui l'a lancée?
Dit autrement, est-ce qu'une Activity peut être détruite alors que l'application qui l'a lancée est toujours en train de tourner?

Merci d'avance pour votre aide, j'ai beau lire la documentation, cette question reste toujours sans réponse pour moi!

[Pffft]

Brièvement, oui. Effectivement on est conseillé par Android de penser de nos Activitys comme des petits applications soi-même, isolées d’un et l’autre et toujours susceptibles d’être détruite par le système.

Mais il y a des circonstances dans laquelle une instance restera en mémoire pour certain – s’il attend la fermeture d’un autre Activity – c'est-à-dire si Activity A lance Activity B avec startActivityForResult. Dans ce cas, Activity A est traité comme parent de Activity B et le système essayera de garder Activity A dans un état de pause. Quand Activity B appelle sa méthode finish() il sera détruit et Activity A gagnera le focus (et sa méthode onResume() est appelée).

Aussi il est possible de causer accidentellement le système de garder un Activity en mémoire s’il partage des instances d’objets avec d’autres Activity, par exemple des statiques. C’est pour ça qu’il est préférable de passer valeurs entre des Activitys dans les extras de l’Intent, ou de les persister dans une base ou SharedSettings.

Ca ce n'est guère exhaustive, mais j’espere que ce t’aide.

Le cycle de vie d’un Activity est mieux expliqué ici http://developer.android.com/referen...ivityLifecycle (en anglais). Particulièrement il y a une graphe très utile avec les differentes états, comment un Activity peut arriver dans un état, et si, dans tel état, il est « killable » (susceptible d’être détruit par le système).

[androidisme]

Merci pour ta réponse.

Si je pose cette question, c'est parce que la première activity de mon application initialise dans sa méthode onCreate un TextToSpeech partagé par toutes les activitys de l'application (le TextToSpeech est donc un statique mais n'est pas déclarée dans la première activity mais dans une classe à part) et que dans sa méthode OnDestroy elle shutDown ce TextToSpeech.
D'après ce que tu me dis là :

Aussi il est possible de causer accidentellement le système de garder un Activity en mémoire s’il partage des instances d’objets avec d’autres Activity, par exemple des statiques.

Toutes mes activitys qui utilisent le TextToSpeech restent donc en mémoire si j'ai bien compris? Est-ce réellement gênant?

Je précise également que toutes les activitys qui utilisent le TextToSpeech ont dans leur manifest l'élément suivant : android:launchMode="singleTask"
qui signifie que ces Activitys ne sont lancées qu'une unique fois, ce qui limite le nombre d'activitys que le système garde en mémoire. Est-ce que ça en devient moins gênant?

C’est pour ça qu’il est préférable de passer valeurs entre des Activitys dans les extras de l’Intent, ou de les persister dans une base ou SharedSettings.

Donc si je comprends bien, il vaut mieux que je passe le TextToSpeech en paramètre dans les extras de l'Intent. Est-ce une bonne façon de faire, sachant que je vais toujours devoir le faire?
Sinon, pourrais-tu m'en dire plus sur les sharedSettings, je pense que ce serait la meilleure façon de faire vu mon cas, et j'ai rien trouvé de concluant dans mes recherches.

Enfin, dernière question (ça en fait beaucoup!), j'aimerais faire un bouton "quitter", comment fermer proprement mon application?

Merci d'avance!

[Pffft]

Si je comprends bien tu partage une instance de TextToSpeech statique, initialisé dans la onCreate du premier Activity et c’est la même Activity qui, sur onDestroy, appelle le shutdown() de cet instance. C’est bien ça ? Et tu veux éviter que onDestroy soit appelé ?

1. Je croix que c’est correct que launchMode="singleTask" signifie qu’il n’y’aura plus qu’une instance de l’Activity en mémoire mais il est également susceptible d’être nettoyé par le système. A mon compréhension "singleTask" est utile s’il est probable qu’il y aura plusieurs Intent qui appellent ton Activity, comme pour la gallérie ou l’appareil photo. Mais à part de ça à mon avis, non, ce n’est pas de tout gênant.
   
2. A mon avis tu as raison – si la référence au statique est dans un autre classe, comme des constants, ça n’empêche pas qu’une instance qui tiens une référence est supprimé de la mémoire. Mais puis-je proposer qu’au lieu de gérer le cycle de vie de ton instance de TextToSpeech dans un Activity que tu étends ApplicationContext et ajouts des méthodes Factory pour instancier et retourner une instance de TextToSpeech. Puis les Activity peuvent avoir un launchMode normal et leur existence restent la responsabilité du système, et l’instance de TextToSpeech n’est plus statique mais un membre de ton ApplicationContext. Il y’a toujours une seule instance de ApplicationContext, toujours disponible aux Activity par getApplicationContext(). Pour l’étendre il ne faut que d’ajouter une classe qui étend ApplicationContext et indique son nom comme attribut du balise « application » dans le manifest : android:name="path.TonApplicationContext".
   
3. TextToSpeech, comme objet complexe, n’est pas sérialisable dans SharedSettings ni les extras d’un Intent.

Pour quitter une application Android il y’a deux possibilités (selon mon compréhension, alors il est bien possible qu’il y’en a beaucoup plus) :

1. Mon préférence : c’est utilisateur qui décide de « quitter » l’application en revenant à l’écran d'accueil Android - c'est-à-dire, l'utilisateur clic le bouton de retour autant de fois que nécessaire pour revenir à l'écran d'accueil. S’il click the bouton « Home » tant pis, l’application peut rester en mémoire.
2. Si ça ce n’est pas pratique ou il est absolument obligatoire d’avoir un bouton pour quitter, tous les Activity a un bouton qui fait la même chose : change un variable dans l’ApplicationContext et appelle finish(). Tous les Activity , dans leur méthode onResume, vérifient le variable et s’il indique que l’application est en train de quitter, ils appellent aussi leur méthode finish(). Et puis tous les Activity dans la chaine de navigation terminent, un après l’autre.

J’espère que tu le trouves utile. J’aimerais bien savoir ce que tu chois comme solution.

[androidisme]

Merci beaucoup pour tes réponses, ça m'aide vraiment beaucoup, d'autant plus que j'ai eu du mal à trouver des éléments de réponses dans mes recherches sur Internet!

Je pense que je vais utiliser l'ApplicationContext, c'est ce qu'il y a de plus "propre" à faire pour mon application.

Sinon, pour quitter l'application, j'avais toujours fait comme tu le décris dans le 1 :

c’est utilisateur qui décide de « quitter » l’application en revenant à l’écran d'accueil Android - c'est-à-dire, l'utilisateur clic le bouton de retour autant de fois que nécessaire pour revenir à l'écran d'accueil. S’il click the bouton « Home » tant pis, l’application peut rester en mémoire.

mais je ne suis pas sûre qu'il quitte réellement l'application, à mon avis, comme pour le bouton "Home", l'application reste en mémoire.

Cette façon de procéder n'est pas gênante, du coup je ne vais pas changer la manière de quitter l'application, je posais cette question car j'avais supposé qu'Android offrait une sorte de convention sur "comment quitter une application".

Merci encore pour tes réponses.