Discussion :

[steph68b]

Bonjour,

Je me penche sur la gestion de rotation de l'écran parce que mon application plante quand je change d'orientation pendant le chargement de données.

Sur un écran fixe, aucun souci... normal je suppose...

Bref, j'ai écumé le net à la recherche d'un tutoriel efficace mais le seul que je trouve est celui-ci: http://nbenbourahla.developpez.com/t...ation-android/

Malheureusement, il ne m'est d'aucune utilité car il n'y a que quelques lignes de principes théoriques et c'est tout, aucun exemple concret...

Bref, je ne sais absolument pas quoi/comment faire...

Que veut-il dire par "sauver ses data dans un bundle" ? Où, quoi, quand, comment ?

Quelqu'un aurait-il un bout de code/tutoriel plus explicite ?

Merci d'avance pour votre aide.

[nicroman]

Heu... je crois qu'il y a un mélange entre rotation et gestion de l'activité...

Code :

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

1
2
 
 parce que mon appli crache quand je change d'orientation pendant le chargement de data!!

C'est que tu ne gère pas le chargement correctement, et l'appli doit aussi cracher si tu lances une autre appli (ou que tu quittes simplement celle-ci) pendant le chargement... D'abord que dit le logcat ? Aucune information sur pourquoi elle crash ? hein ?

Pour la rotation oui c'est très simple...

Par défaut toutes les activités acceptent la rotation... ceci peut-être surchargé dans le manifest mais comme expliqué dans le tuto, c'est fortement déconseillé (à part cas évidents comme un jeu, etc...).

Ensuite, dans l'activité, ou bien la rotation est gérée "manuellement" (on demande dans le manifest à être averti des screen rotation) et dans ce cas, il faut surcharger la fonction onScreenOrientationChange() ou un truc du genre, et y mettre le code qu'on veut... Le plus simple: recréer les views avec un setContentView(), ne pas oublier quand même de restaurer leur contenu si besoin...

Ou on laisse le système s'en occuper... et dans ce cas, il fait dans le bourrin: destruction de l'activité, et recréation... donc on passe dans les phases onPause(), onDestroy(), ... et onCreate(), onResume() sur un autre objet. Mais il le fait (c'est bien expliqué dans la "vie d'une activité" chez google), comme si il libérait le système pour de la place mémoire (donc cette séquence n'est pas uniquement appelée par la rotation, elle peut l'être à tout moment)... Donc sauvegarde de l'état de la "vue" par appel à onSaveInstanceState()... puis passage de cette sauvegarde au onCreate() (le bundle 'savedInstanceState'). Du coup, le contenu des vues est inchangé.

[steph68b]

Ok, j'essaie de fournir une explication plus claire et je reviens développer tout ça

[steph68b]

ok alors:

1.) si je comprends bien on n'est pas obligé de gérer le changement d'orientation? le système se demmerde très bien tout seul..... tant qu'il n'y a pas de layout à changer, par exemple... ce qui est bien mon cas, même layout H & V (en tout cas pour le moment).

2.) ce qui tombe bien parce que dans mon cas, ce ne seraient pas des data à sauvegarder, mais des thread d'initialisation........ et c'est là que je ne vois pas comment faire une copie de cet état
-> j'ai juste un champ de saisie... dont je retrouve bien la valeur qq soit l'orientation
-> pour le reste: boutons & spinners

3.) log cat

Code :

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

1
2
 
Activity com.toto.test.Test has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@40f81f28 that was originally added here

sur la ligne

Code :

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

1
2
 
chargement = ProgressDialog.show(this, "","Chargement en cours, veuillez patienter...", true);

4.) l'appli ne plante effectivement que durant mes moments de chargements de tâches en fond

DONC, ce ne serait que le ProgressDialog qui pose problème finalement?


EDIT: ce qui veut dire qu'un "bête"

Code :

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

1
2
3
4
5
public void onDestroy()			//en cas de destruction de l'activité (changement d'orientation) IL FAUT fermer la																
	{								//progressBar si elle était active... sinon crash applicatif (Activity com.toto.test.Test has leaked window)
		if (chargement.isShowing()) chargement.cancel();  
		super.onDestroy();
	}

suffirait finalement?

[Hephaistos007]

Dans ton cas, je pense qu'il faut overrider les méthodes onRetainNonConfigurationInstance ()/getLastNonConfigurationInstance() afin de pouvoir conserver l'état de l'objet qui s'occupe de charger les données (un AsynTask ou un Handler je suppose). De la lecture intéressante sur http://developer.android.com/guide/t...e-changes.html

[steph68b]

Ok, je suppose que tu fais référence au paragraphe "Retaining an Object During a Configuration Change"... qui dans mon cas, éviterait de relancer les threads d'init à chaque changement d'orientation.

Bonne idée oui, appli plus fluide!

Par contre, même à partir de l'exemple donné,

Code :

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

1
2
3
4
5
@Override
public Object onRetainNonConfigurationInstance() {
    final MyDataObject data = collectMyLoadedData();
    return data;
}

je ne vois pas du tout comment faire un "backup" de mes threads/async pour qu'ils se poursuivent dans la nouvelle activité, sans repartir de zéro...
-> conceptuellement, je ne vois pas quel "objet" je suis censé manipuler
-> ni surtout comment

Par ailleurs, comme parmi mes init il y a 2 spinner de sélection à remplir, est ce que c'est toujours possible puisque la doc elle même précise que ce n'est pas faisable (memory leak) pour des adapter (setadapter des spinner) ou tout autre objet en rapport avec un context?