Article complet: Petit parallèle entre Swing et l'UI d'Android

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