Version imprimable
Bonjour, je fais appel à vous car j'ai fait une application qui au chargement de l'application télécharge un fichier...
Pour le téléchargement j'ai fais appel à un Thread, le problème est que si l'utilisateur change l'orientation de l'écran l'application ferme suite a une erreur, j'ai donc cherché comment corriger ce problème et je n'arrive a rien auriez vous une suggestion ?
J'ai également essayé de faire un .join(), mais cela retarde juste le plantage de mon application ...:cry:
Pour pouvoir corriger l'erreur, encore faudrait-il la voir :)
Merci de poster le stacktrace complet du logcat, ainsi que de montrer les lignes correspondantes aux "caused by ...".
Je pense que le problème viens du fais que onCreate(), onResume() et tout ça sont appellé.
Je ne suis pas sûre que ce soit la solution, mais dans le manifest rajoute ça pour ton Activity :
Code:android:configChanges="keyboardHidden|orientation"
MERCIIIIIII :)
mes problèmes ne sont plus :) grâce a cette toute petite ligne
android:configChanges="keyboardHidden|orientation"
encore merci merci merci :)
Sans vouloir jouer les rabats-joie... Cette solution est un "cache-bug" ;)
D'autant qu'il y a de fortes chances pour que cette solution ne soit que "temporaire", il y a pleins de cas, ou les même fonctions (que lors d'une rotation d'écran) sont appelées... Sans compter que tu perds la possibilité de tourner l'écran....
Ouais je pensais aussi que c'était peut être du bricolage et qu'il valait mieux régler le problème autrement.
Cela dit cette méthode n'empêche absolument pas de tourner l'écran.
Et je pense que maintenant la rotation d'écran ne provoque plus d'erreur chez cet utilisateur, même si il n'arrête pas de tourner l'écran pendant un traitement.
Grosso-modo, cette ligne dit "je m'occupe de la rotation".
Donc, s'il ne fait rien pour s'en occuper (comprendre "méthodes responsables vide"), oui, ça doit être résolu.
Pour le coup, s'il reste en portrait (ce qui est un cas de figure possible ici), autant bloquer le changement d'orientation directement.
Juste au cas où, ce cours aide aussi dans ce cas-là : http://mathias-seguy.developpez.com/...async_memleak/
Mais ça ne bloque pas l'orientation de l'Activity.
Ça passe toujours de landscape à portrait sans problème.
Enfin pas tout à fait, je viens de tester, si on a une layout dans res/layout/ et une layout dans res/layout-land/ ça va garder la layout utilisé lorsqu'on a crée l'activité.
Donc si au moment où on a lancé l'activity on est en paysage on va avoir la layout paysage même si on repasse en portait.
Cela dit, pour celui qui n'a pas une layout spécifique par orientation ça passe.
Mes excuses alors.
Je ne pouvais pas tester, et au vu de ce que j'ai trouvé sur le net, j'avais pensé à un comportement différent.
Oui je me suis mal exprimé... la rotation automatique ne se fera plus sans gestion par code appropriée... Et effectivement au lancement de l'application, un "layout" sera choisi en fonction de l'orientation actuelle.
Mais ca n'empeche pas que les fonctions onPause/onDestroy/onCreate/onResume peuvent être appelées dans d'autres cas de figures, et donc le bug est toujours là.
Si android:configChanges="keyboardHidden|orientation" n'est pas la solution, comment faire pour lancer une AsyncTask dans onResume() et que ça ne plante pas si on tourne l'écran ?
Encore faudrait-il savoir ce qui plante....
Tu n'as jamais posté de trace, d'exception, de code... dur de savoir ;)
Ensuite tout ce que je disais c'est que gérer soit même la rotation évite de passer par le onPause/onDestroy/onCreate/onResume à la rotation de l'écran, mais n'empêche aucunement ces fonctions d'être appelées... Par exemple, si un appel arrive sur le téléphone, l'appli de téléphonie va s'afficher (onPause/onResume pendant le chargement pour sur), et si le coup de téléphone dure un peu, et que la batterie est faible ou la mémoire saturée, le onDestroy/onCreate seront *aussi* appelées vu que l'application n'est pas en avant plan...
Maintenant reste a savoir le niveau d'interruption qu'on veut...
Il peut être tout à fait acceptable d'interrompre l'opération (et de la redémarrer) sur un changement d'orientation...
Il peut être voulu de ne l'interrompre que si l'application est tuée.
On peut aussi vouloir ne *jamais* l'interrompre avant la fin.
...