Discussion :

[Grumpy64]

Considérons le bout de code suivant :

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
19
20
 
    	File xmlConfigFile;
    	SAXBuilder sxb;
    	sxb =new SAXBuilder();
    	listDict = new ArrayList<DictioElem>();
    	try
    	{
          xmlConfigFile = new File(addpath+configFile);
    	  document = sxb.build(xmlConfigFile); //Erreur sur cette ligne
    	}
    	catch (IOException e) {
            System.out.println("Erreur lors de la lecture du fichier " + e.getMessage() );
            e.printStackTrace();
        } catch (JDOMException e){
            System.out.println("Erreur lors de la construction du fichier JDOM " + e.getMessage() );
            e.printStackTrace();
        } catch (Exception e){
            System.out.println("Erreur autre " + e.getMessage() );
            e.printStackTrace();
        }

Il fonctionne parfaitement en java classique, mais me donne sous Android l'erreur suivante : StringIndexBoundsException .

Une idée du phénomène ?

Merci.

[MrDuChnok]

Elle vient d'où la classe SaxBuilder ?

Tu à l'air de vouloir parser ton XML via la méthode JDOM... Sous Android, il faut utiliser la méthode SAX.
http://java.developpez.com/faq/xml/?...XML#saxDomXslt
et
http://java.developpez.com/faq/xml/?page=sax#parserSax

[Grumpy64]

Elle vient effectivement de JDom.
Je souhaite développer la même application pour différent mobile os, et donc ne faire intervenir les api spécifiques que pour le côté visuel : séparer l'accès aux datas des skins...
Ne puis-je pas ? Est-ce une illusion ?

Par ailleurs, dans l'un des liens que tu as cité :

JDOM : JDOM se veut une API légère, rapide et facile d'utilisation, pour travailler avec des documents XML. Son fonctionnement est "comparable" à DOM. Compatible avec SAX, DOM et JAXP.

[MrDuChnok]

Il est de convention d'utiliser l'API Sax pour parser les XML. Elle offre des avantages notables : le temps de parsing est réduit, et la consommation mémoire est réduite au maximum.
Ces deux atouts font qu'elle est favorisée dans une environnement mobile (peu de ressource mémoires disponible, et un processeur assez léger).
Donc je te conseillerais de passer sous SAX, tu aura moins de soucis.

[Grumpy64]

Si je dois, je le ferai. Mais ce n'est pas satisfaisant : je n'ai pas de réponse, je ne sais pas pourquoi ça plante !

[MrDuChnok]

La classe "SAXBuilder" n'est pas présente dans le SDK d'Android.
L'as tu réécrite ? utilise tu une librairie compatible Android ?
Si tu n'as rien de cela, ton plantage vient surement de là.

[Grumpy64]

Certes non, SAXBuilder appartient à JDom.
Si c'était l'absence de SAXBuilder dans le SDK qui faisait tout planter, cela aurait dû arriver plus tôt, lors de la création de l'instance de SAXBuilder sxb.
Me trompe-je ?

[MrDuChnok]

Dans mon environnement de dev je n'ai pas cette API / classe. Donc chez moi ça ne compile même pas.

[Grumpy64]

Peut-être ne l'as-tu pas. Mais à la lecture de la méthode, c'est ce qu'il me semblait.

Aurais-tuy entendu parler d'une incompatibilité du bytecode sun et android ? Qui pourrait être la raison de mon échec actuel.....

[MrDuChnok]

non ils ne sont pas entièrement compatible.
Je t'invite à lire cette actualité :
http://www.developpez.net/forums/d96...es-fondements/

[Grumpy64]

Google a en effet conçu Android dès le départ en faisant bien attention de ne pas utiliser de brevets de Sun. L'obligation de recompiler une application Java avec Dalvik pour qu'elle tourne sous Android en serait la parfaite illustration.

Or donc,pour être sûr que jdom soit compatible, il faudrait que je le recompile avec Dalvik.
Sais-tu où je puis choper un compilateur dalvik ?

[MrDuChnok]

Si tu compiles tes programmes pour ton téléphone Android, alors tu en as déjà un