juin
2009
Un article de adiGuba
Je commence tout doucement à m’intéresser de plus près au développement sur Android, et même si je n’ai pas encore eu le temps de me plonger dans les spécificités de son API graphique, j’ai déjà pu remarquer qu’on y retrouve les mêmes concepts et les mêmes problèmes…
En effet, en parcourant le blog officiel des développeurs d’Android, je suis tombé sur un article de Romain Guy décrivant les problèmes de threading des applications Android.
Pour faire court : l’interface d’une application Android utilise un modèle mono-thread via l’UI-thread, et toute tâche un tant soit peu longue ne doit pas y être exécuter sous peine de bloquer l’interface utilisateur. Afin d’éviter cela on doit utiliser un nouveau thread, tout en continuant à mettre à jour l’affichage dans l’UI-thread afin de respecter le modèle mono-thread. On peut utiliser pour cela la classe AsynTask qui permet de simplifier toutes ces interactions entre threads…
Pour l’analogie : l’interface d’une application AWT/Swing utilise un modèle mono-thread via l’Event Dispatch Thread (EDT), et toute tâche un tant soit peu longue ne doit pas y être exécuter sous peine de bloquer l’interface utilisateur. Afin d’éviter cela on doit utiliser un nouveau thread, tout en continuant à mettre à jour l’affichage dans l’EDT afin de respecter le modèle mono-thread. On peut utiliser pour cela la classe SwingWorker qui permet de simplifier toutes ces interactions entre threads…
Et pour l’anedocte : on retrouve sur developpez.com un viel article de Romain concernant ce problème sur Swing : Threads et performance avec Swing
Bref pour le moment je ne suis pas trop perdu 
3 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- Possibilité d'accéder au type générique en runtime
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Classes, méthodes private
- Recuperation du nom des parametres
- Difference de performances Unix/Windows d'un programme?
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- Définition exacte de @Override
- [ fuite ] memoire
- jre 1.5, tomcat 6.0 et multi processeurs
Le comportement n’est pas tout à fait toujours identique entre l’émulateur et le vrai téléphone. J’ai rencontré plusieurs problèmes quant aux appels à de tierces applications (Email, …) ou à l’utilisation massive de composants hardware (bug dans l’émulateur pour les fonctionnalités de géolocalisation).
Pour ma part, je suis conquis par cette plateforme et mise sur une explosion de celle-ci les mois à venir. (j’ai 4 applications publiées sur le market). Il faut tout de même avouer que si le développement est super intuitif pour un développeur Java, l’ergonomie générale de l’UI n’égale pas celle de son principal concurrent : l’iPhone. Sur ce sujet, j’ai d’ailleurs participé à un petit contest/comparatif, celui-ci est disponible sur le site de Xebia :
http://blog.xebia.fr/2009/06/17/xebia-mobile-application-contest-java-fx-android-iphone/
Erwan
Pour le moment j’ai juste installé l’emulateur et le plugin eclipse. L’emulateur me semble un peu lent au lancement, mais semble suffire pour les tests.
Je n’ai pas encore essayé avec le téléphone en vrai (il va falloir que j’emprunte l’HTC Magic de mon frère pour cela).
Pour le mono-thread je sais bien cela
Une UI multi-thread serait « possible » mais rendrait le développement de composant bien plus ardu !
a++
Pour tester tes applications Android, l’émulateur du SDK suffit-il ? ou alors tu es obligé de passer par le téléphone ?
Concernant le mono-thread, il s’agit d’un principe assez répandu dans les boîtes à outils graphiques. SWT fonctionne de la même manière.
Mickael