décembre
2011
Un article de MathiasSeguy
Bonjour,
Comme je vous disais précédemment, quand vous manipulez les Handlers ou les AsynchTasks, il faut toujours faire en sorte d’accorder le cycle de vie de la thread avec celui du Handler qui est lui-même lié à celui de l’activité… Sinon, votre Thread devient orpheline.
Bon en creusant un peu (je vais vous poser sur Androi2EE un projet eclipse qui démontre ce que je dis), c’est pire, en effet: Lors du passage par onDestroy puis onCreate (bref je retourne l’appareil), non seulement la Thread devient orpheline, mais le Handler aussi (arg, quoi il n’est pas détruit o_O’) et pire votre activité devient fantôme… glooops.
Et oui c’est fou, la première activité n’est pas détruite, c’est elle qui est appelée par la première Thread au travers du premier Handler (d’où l’absence de levée d’exception du type NullPointer) et la seconde est créée avec son Handler et sa nouvelle Thread.
Là, j’entends DarkVador, Voldemor et Sauron rirent en pensant au nombre de Threads, de Handlers, d’AsynchTasks et d’activités fantômes qui peuplent les appareils Android à cause de développeurs inconscients du danger.
Donc: Gérer vos threads en accordant leur cycle de vie avec celui de l’activité.
Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)
Mathias Séguy
mathias.seguy.it@gmail.com
Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.
Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo
4 Commentaires + Ajouter un commentaire
Référence Android
Mots-clés
Archives
- mars 2015
- février 2015
- janvier 2015
- mai 2014
- mars 2014
- janvier 2014
- décembre 2013
- novembre 2013
- septembre 2013
- mai 2013
- mars 2013
- février 2013
- janvier 2013
- décembre 2012
- novembre 2012
- octobre 2012
- septembre 2012
- août 2012
- mai 2012
- avril 2012
- mars 2012
- janvier 2012
- décembre 2011
- novembre 2011
- septembre 2011
Oui, d’accord, il faut gérer la destruction de la thread dans onDestroy. Même tu peux la mettre en pause dans onPause et la relancer dans onResume. Bref, faut la lier au cycle de vie de l’appli ;o)
Par contre, je suis curieux, je me suis jamais demandé ce que l’on rate quand on gère soi-même le changement de configuration… T’as une idée de ce que fait le système?
C’est un plaisir de parler avec toi.
A bientôt.
Mathias
ps: n’hésite pas à aller télécharger les tutos, ils sont simples et très clair. Si t’as des retours dessus, je suis preneur aussi.
Effectivement, t’as raison
Un petit avantage à la méthode évoquée (pas suffisante certes), cela accélère pas mal la rotation, et évite le rechargement (onCreate) lorsque le layout est le même.
Sur la fait que la thread reste en vie, il suffit (je pense) de gérer le cas dans le onDestroy, qui, du coup n’est pas appelé sur le changement de rotation.
++
Yan.
Bonjour,
Je ne suis pas sûr du bien fondé de la méthode, effectivement tu empêches l’activité de se reconstruire (passage par onDestroy, onCreate)lors de la rotation (et du hide du clavier) et du coup tu ne perds pas ta thread. Mais j’ai deux objections:
1)A mon avis, si Android prend en charge les changements de configuration, ce n’est pas pour rien. La tu perds quand même l’état de tous tes composants et tu les réinitialises…
2)Quand l’utilisateur quitte ton application, ta thread reste en vie… et c’est là qu’est le mal. En effet ta thread étant vivante, elle pointe vers le handler (qui du coup n’est pas détruit) qui lui-même pointe vers l’activité qui ne peut pas être détruite non plus (le garbage collector identifiant qu’elle est utilisée). Et c’est la fuite mémoire.
Donc à mon avis, il vaut mieux mettre fin à la thread en sauvegardant son état d’avancement puis la relancer en restaurant cet état.
Pour finir, je vais faire un autre post qui est plus optimal que ta méthode, mais qui pour moi pose toujours le problème 2) précédent.
En tout cas merci de ta remarque, c’est toujours un plaisir d’échanger et de voir ce que les autres font (des fois je suis d’accord… là, pas de bol, je le suis pas :o)
Bonjour,
Pour le problème lors de la rotation, je l’avais résolu en mettant :
dans le manifest.
Et sur les activités qui ont un layout différent en fonction de l’orientation, j’ai mis :
@Override <br />
public void onConfigurationChanged(Configuration newConfig) { <br />
super.onConfigurationChanged(newConfig); <br />
setContentView(R.layout.main); <br />
} <br />
Merci pour l’article.