Rotation en détail (exemples à l'appui)

Version imprimable

05/12/2012, 14h33
steph68b

Rotation en détail (exemples à l'appui)

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.
05/12/2012, 14h54
nicroman
Heu... je crois qu'il y a un mélange entre rotation et gestion de l'activité...
Code:

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é.
05/12/2012, 15h24
steph68b

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

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:

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:

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:

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?

05/12/2012, 16h23
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
06/12/2012, 09h01
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! :ccool:

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

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... 8O
-> 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?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private final AsyncTask<Void,Void,Void> loader; //AsyncTask qui charge les données
 
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
 
    loader = (AsyncTask<Void,Void,Void>) getLastNonConfigurationInstance();
    if (loader == null) {
        loader = AsyncTask<Void,Void,Void>();
    }
}
 
@Override
public Object onRetainNonConfigurationInstance() {
    return loader;
}

En fait, je pense qu'il faut être plus complet que cela et gérer les 2 situations :
- Soit l'orientation a eu lieu pendant le chargement des données par un thread : il faut conserver (retain) l'objet de threading (comme le montre mon exemple avec un AsyncTask)
- Soit l'orientation a eu lieu après le chargement des données, c-a-d une fois les données affichées à l'écran : il faut conserver (retain) l'objet collection des données ou même carrément l'objet Adapter

Donc, dans l'idée, ça donnerait ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
private final AsyncTask<Void,Void,Void> loader; //AsyncTask qui charge les données
private final ArrayListAdapter<String> adapter;  //Adapter pour les données
private boolean loadingDone = false;
 
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
 
    Object o = getLastNonConfigurationInstance();
 
     if (o == null) { //Cas où il n'y a pas eu de destruction puis recréation de l'activité
        loader = new MyAsyncTask<Void,Void,Void>(); //dans le onPostExecute() de l'asyncTask, il faut faire passer le champs loadingDone à true !
        adapter = new ArrayListAdapter<String>(...);
     } else {  //Cas où il y a destruction suite à un changement d'orientation
           if (o instanceOf MyAsyncTask<Void,Void,Void>) {
                  loader = (MyAsyncTask<Void,Void,Void>) o;
           } else if (o instanceOf ArrayListAdapter<String>) {
                  adapter = (ArrayListAdapter<String>) o;
           }
     }
}
 
@Override
public Object onRetainNonConfigurationInstance() {
    if(loadingDone) { return adapter; } else { return loader; }  //Conservation en fonction de la situation
}

06/12/2012, 11h31
Hephaistos007

En consultant la doc http://developer.android.com/guide/c...d-threads.html, je vois que dans la section AsyncTask ils évoquent ce problème de changement d'orientation, et conseilles de regarder comment cela a été géré dans l'application Shelves :ccool:

Tiens nous au courant de tes découvertes.
06/12/2012, 15h07
steph68b

Ok, ça risque de me prendre un moment, mais pas de soucis pour le retour d'info! ;)

Au pire, je laisse ma V1 en l'état, avec le cancel de ma PB dans le onDestroy si nécessaire... au moins plus de crash suite à un leak, même si pas optimal.

Et puis je planche sur l'optimisation pour une V1.1.
06/12/2012, 17h32
Feanorin

Bonjour,

Un tutoriel sur le sujet ;)
http://mathias-seguy.developpez.com/...async_memleak/
07/12/2012, 08h41
steph68b

Merci, je vais voir ça aussi. :ccool:

C'est pour ça qu'on aime développez par rapport à d'autres forums:
-> la compétence réelle! ;)

:ave:
11/12/2012, 16h21
steph68b

Bon, redéfinition de priorités oblige, je dois laisser ça de coté pour le moment.
J'y reviendrai dès que possible. :ccool: