Discussion :

[Kepsylis]

Bonjour,

j'aimerais avoir un renseignement voir même une solution concernant le parsing de XML.

En faite, je développe actuellement une application pour tablette Androïd sous l'API 11 et j'essaye de parser mon script XML.

Concrètement, j'ai déjà réussi à parser du xml pour une ancienne application sous API 8 et lorsque j'ai voulu utiliser le même procédé, j'ai constaté qu'il y avais un soucis au niveau de la méthode parse sur un DocumentBuilder.

Donc je voulais savoir si quelques chose change entre les APIs inférieur à 11 et la 11 et qui ne me permet plus d'utiliser cette méthode.

Voici une partie de mon code :

Code :

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

1
2
3
4
5
6
7
8
9
DocumentBuilderFactory factory;
		DocumentBuilder builder;
		Document xml;
		String requestURL;
 
		requestURL = Constantes.interfaceURL + Constantes.getAccountMethod;
		factory = DocumentBuilderFactory.newInstance();
		builder = factory.newDocumentBuilder();
		xml = builder.parse(requestURL);

J'ai fais un test en mettant API 8 dans le Manifest et cela a fonctionné une fois néanmoins le fait que j'utilise des fragments et le fait que l'application est destiné aux tablettes, ce n'est pas très compatible avec une API 8.

Merci d'avance !

[nicroman]

Les fragments sont compatibles avec l'API-4 par le biais de la support library.
(il suffit de remplacer Fragment, FragmentActivity et autres par les versions de la librairie de support).

Par contre... il n'y a aucun changement dans la méthode "parse" (en tout cas pour l'utilisateur).
Si j'ai bien compris le code fonctionnait sous l'API 8, et ne fonctionne plus sous l'API 11 ?

Mais ne fonctionne plus dans quel sens ? L'application crashe ? (dans ce cas il nous faut le logcat avec l'exception) ?

Mon petit doigt me dit que c'est un appel à "parse" directement dans le thread principal (réservé à l'UI). Cela passait (hélas) sous Android pre 3.0 car le système ne vérifiait pas que le programmeur avait bien fait son taf... Par contre le système le vérifie à partir de 3.0 activement en lançant une exception NetworkOnMainThreadException c'est peut-être le soucis....

[Wawamaniac]

Bonjour,

Je fais aussi parti de l'équipe de développement et j'ai pas mal bosser sur ce problème cette après-midi. Donc j'ai bien compris qu'à partir de l'api 11, en gros, on avait plus le droit de faire les opérations de parsing sur le thread ui car elles sont libellées comme "lourdes" mais je suis tombé sur un autre problème, vraiment bizarre.

Voici en gros le code, j'ai mis des toast pour m'aider a mieux voir le problème:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
new Thread(){
			public void run(){
				Looper.prepare();
				Toast.makeText(MainActivity.this, "pre", Toast.LENGTH_SHORT).show();
				try 
				{
					Toast.makeText(MainActivity.this, "1", Toast.LENGTH_SHORT).show();
					accounts = new Accounts();
					Toast.makeText(MainActivity.this, "2", Toast.LENGTH_SHORT).show();
				} 
				catch (Exception e) 
				{
					Toast.makeText(MainActivity.this, "Echec telechargement accounts.", Toast.LENGTH_LONG).show();
				}
				Toast.makeText(MainActivity.this, "post", Toast.LENGTH_SHORT).show();
				Looper.loop();
			}
		}.start();

Et voila que les toast m'affiche, dans l'ordre:
pre
1
pre
1
2
post
2
post

Je ne sais pas pourquoi le code est appelé 2 fois dans un certains ordre d'enchevêtrement... du coup certaines données sont parsées 2 fois. Donc à moins de vérifier si elles ont déjà été traitées dans le parsing, je ne comprends vraiment pas comment je peux régler ça...

Quelqu'un a déjà eu ce problème ?

PS: On est toujours sur l'api 11 du coup

[nicroman]

Le thread est donc lancé deux fois....

L'appel de ce code a lieu quand ?

Donc j'ai bien compris qu'à partir de l'api 11, en gros, on avait plus le droit de faire les opérations de parsing sur le thread ui car elles sont libellées comme "lourdes"

Non, cela a toujours été interdit depuis l'API 1 (et comme dans tout programme tournant sur un système 'multi-tâche')... l'API-11 fait juste la vérification système que cela n'est vraiment pas fait.

[Wawamaniac]

Ces lignes de codes sont juste appelées au début du onCreate d'une activity. Mais je les utilise une seule fois.

[nicroman]

1. Essayes de remplacer les Toasts par des logs.... Difficile de dire comment se comportent plusieurs toasts simultannés....

Par exemple:
Log.d("MainActivity.Thread","Preparing");
...
Log.d("MainActivity.Thread","Step 1");
...
Log.d("MainActivity.Thread","Step 2");
...
(dans le catch)
Log.e("MainActivity.Thread","Echec téléchargement",e);


(déjà ca évitera de préparer un looper pour le thread...., entre new Thread() et Looper.prepare(), le thread va passer un temps fou à démarrer).
Log.d("MainActivityThread","Step 1");


2. Juste avant le "new Thread()", coller un debug:
Log.d("MainActivity","Starting download thread");


Ensuite on verra bien ce qu'il y a dans le logcat pour "MainActivity"....

[Wawamaniac]

Donc en gros par rapport a l'ancien code comme vous m'avez dis, j'ai remplacé les toast par des log.d, et enlevé les looper du coup.

Le log:



Même chose qu'avec les toast, on a une répétition et une sorte d'enchevêtrement. Mais là on peut voir qu'on tombe sur un "skipped X frames". Etant étudiant et n'ayant quasi pas fait de java en cours, franchement je n'ai aucune idée de la répercussion que ça peut avoir.

Et pourquoi pas un AsyncTask dans ce thread "annexe" ?

EDIT: Bon un asynctask n'était pas (je pense) une bonne idée. J'ai le même log mais sans le "skipped X frames".

[nicroman]

Non mais on voit surtout que le thread est bien appelé deux fois....
Comme si il y avait au départ deux intents... et deux appels à onCreate

On peut voir le code entier de l'activité ?

Quant à l'AsyncTask, c'est une bonne idée en REMPLACEMENT du thread, puisque toute la logique de post-synchronisation (et de cancel) est proposée d'entrée de jeu par l'AsyncTask.
Mais cela ne changera pas le problème... on aura deux tasks executées en parralèlle

[Wawamaniac]

J'ai trouvé. C'est notre

Code :

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

1
2
 
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);

qui duplique le thread ui, et vu qu'il est en tout début de code....

Vu que c'est une application tablette et qu'on voudrait mettre l'interface en paysage, c'est possible de bloquer l'orientation en paysage sans créer d'autre thread ? Ou sinon je kill un des 2 threads (dans ce cas, comment je vois lequel est l'ui ?) ?

[nicroman]

Il n'y a qu'un seul et unique thread UI...

Par contre on passe deux fois dans le onCreate() (pour chaque orientation) et donc, deux thread de parsing XML...

Sinon, dans le manifest, il est possible de forcer une orientation donnée.

[Wawamaniac]

Quand j'ai dis "dupliquer le thread ui" je voulais pas dire que je me retrouver avec 2 thread ui mais un ui et un "annexe", désolé je me suis mal exprimé ^^

Sinon, j'ai modifié le manifest pour locker l'orientation, nickel, plus de thread inutile qui se crée.

Merci beaucoup !