Accueil > Code > Trucs et astuces divers

Trucs et astuces divers

mercredi 19 octobre 2011, par Nicolas

Les assets et le Galaxy S

Les assets sous Android sont très pratiques, notamment pour afficher des pages d’aide au format HTML dans une application, via une WebView.

Le fichier à afficher est chargé via la méthode loadUrl(). En utilisant un chemin relatif (même répertoire par exemple) pour les images, elles s’affichent comme attendu. Il est bien sûr possible de faire plusieurs pages, avec des liens entre elles.

Et là j’ai heurté ce qui semble être un bug sur le Galaxy S. Les images s’affichent bien depuis les assets, mais quand je suis un lien vers une autre page, le navigateur retourne une erreur « 404 non trouvé ». Sur l’émulateur Android tout fonctionne correctement.

Une solution de contournement existe, assez simple au final :

    WebView help = (WebView)findViewById(R.id.web);
    help.loadUrl("file:///android_asset/help.html");
    help.setWebViewClient(new WebViewClient() {
      /** {@inheritDoc} */
      @Override
      public boolean shouldOverrideUrlLoading(WebView view, String url) {
        if (url.startsWith("file:///")) {
          view.loadUrl(url);
        } else {
          Intent show = new Intent(Intent.ACTION_VIEW);
          show.setData(Uri.parse(url));
          startActivity(show);
        }
        return true;
      }
    });

En résumé, le programme intercepte le clic sur les liens, et appelle loadUrl() pour les fichier locaux, ou lance le navigateur pour les URLs. À noter que cela implique de coder les liens vers les fichiers locaux avec file :///, une alternative est de traiter les liens commençant par http:// via un Intent et les autres par loadUrl().

Il est bien sûr possible que j’ai omis quelque chose, un paramétrage ou un appel, qui provoque l’erreur 404, mais mes recherches sur ce sujet ont été infructueuses...

NetBeans et le mode debug GWT

Le plugin Gwt4nb, qui fournit le support GWT à NetBeans, ajoute une fonction « GWT Dev Mode w/o a JEE server » sur tout projet utilisant GWT (soit un projet « application Java » avec le framework GWT, soit un projet créé via la ligne de commande).

L’utilisation de cette option va lancer le console GWT en mode debug, mais généralement sur une mauvaise URL, notamment dans le cas où le projet GWT existe sans serveur JEE.

Le contournement est de simplement utiliser l’adresse standard du projet, et de rajouter  ?gwt.codesvr=127.0.0.1:9997 [1] à celle-ci. Ceci, en supposant que le navigateur ait le plugin GWT [2], connectera navigateur et console.

Ce qui permet de mettre des points d’arrêt dans NetBeans pour débugger le projet GWT ou de voir les exceptions soulevées par le code, ce qui accélère nettement les temps de développement. En bonus, le code GWT n’a pas besoin d’être converti en JavaScript, ce qui évite d’attendre plus de 30s à chaque modification devant être testée, les modifications sont quasiment prises en compte à la volée (pire des cas, rafraîchir la page est nécessaire).

Transfert d’objets Java entre GWT et serveur Java

Dans le cas d’une application écrite avec serveur Java et interface cliente en GWT, l’utilisation de la couche de communication fournie par GWT simplifie énormément les développements, car les objets peuvent être partagés entre serveur et client.

Tel que décrit dans la documentation, il est possible de transférer de nombreux objets simples, tant qu’ils implémentent IsSerializable. En particulier, il est possible de transférer des collections d’objets via ArrayList<>.

Les avantages sont de ne pas avoir de souci de conversion entre client et serveur, et une mise en commun des classes.

Point négatif, mais peut-être qu’il me manque une option ou un paramétrage comme un quelque part, les classes communes doivent être dans le même package que le code principal de GWT.

Version minimum d’un programme Android

C’est plus une bonne pratique voire une nécessité, d’ailleurs décrite sur la documentation Android, mais spécifier un <uses-sdk android:minSdkVersion= est une habitude à prendre.

Le plugin NBAndroid ne semble pas l’inclure dans ses modèles de base, tout en utilisant correctement la version du SDK choisie dans l’interface.

Une conséquence amusante de ne pas spécifier cet attribut est que les permissions ne correspondent pas à ce qui est déclaré dans le Manifest.xml, par exemple l’application peut accéder à l’état du téléphone, ce genre de choses [3].

Bien sûr, pour distribuer sur le Android Market, cet attribut est obligatoire, mais pas requis en distribution via .apk.


[1Port par défaut, à ajuster selon la configuration.

[2Firefox 7.0 n’est pas encore supporté, ce que je peux comprendre vu le rythme de sortie des versions, mais Chromium fonctionne parfaitement.

[3Certainement pour des raisons de compatibilité ascendante.