Discussion :

[bydavy]

Bonjour,

Voici un article dédié à l'UI thread

http://davy-leggieri.developpez.com/...oid/ui-thread/

I. Introduction
II. Le fonctionnement de l'UI thread
III. Le responsable de l'affichage et des interactions avec l'utilisateur
IV. Un thread à préserver
V. Où mettre les instructions consommatrices en temps ?
VI. Ordonner des tâches à l'UI thread
VI-A. Ordonner depuis l'activity
VI-B. Ordonner depuis une view
VI-C. Ordonner grâce à un handler
VI-D. Ordonner grâce à une AsyncTask
VII. Conclusion
VIII. Remerciements

Vos remarques sont les bienvenues.

[nicolofontana12]

Franchement ton article est bien venu au bon moment quand même pour moi.
Car je suis en mode avancé sur les thread donc ton article completera l'ancien sur le thread.

Par ailleurs moi aussi je cherche à contribuer à un article sur la realité augmentée. Donc je sais pas comment ecrire un tutorial comme pour toi

[bydavy]

Salut jahbromo,

Je sui ravi que mon article puisse t'aider.
Si tu désires écrire un article, il te suffit d'ouvrir un topic ici : http://www.developpez.net/forums/f19...va/contribuez/

Les responsables viendront en parler avec toi. Une fois ton article finalisé au format Word ou simple texte, un compte rédacteur te sera ouvert.

Je te souhaite bonne chance, et @ très bientôt pour une relecture technique.

(La réalité augmenté me tente bien je me plongerai dans ce sujet cet été...)

[ulquiorra]

merci pour l ' article ^^

[_Xavier_]

Salut bydavy

Merci pour ton article intéressant et très intuitif.
Il y a pas mal de développeurs Java, avec leurs mauvaises habitudes , qui s'intéressent à Android, et c'est bien d'insister sur les bonnes pratiques à adopter pour éviter d'exploser les mobiles dont les ressources sont très limitées.

une question : C'est quoi la différence entre mettre du code dans un thread classique (exemple §V) et le mettre dans le thread de l'UI (exemple VI-A) ?

[bydavy]

La différence est très simple.
L'UI thread sert à impacter l'interface graphique et les autres threads font tout le reste, et je rajouterai même qu'ils font surtout les opérations consommatrices en temps.

Cependant, rien ne t'empêche de créer un thread qui va exécuter une opération consommatrice en temps et dont la finalité va être de déposer un Runnable dans l'UI thread dans l'intention de modifier l'interface graphique.

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
21
22
23
24
25
26
27
 
public class TestActivity extends Activity {
    ...
    public void onCreate(Bundle savedInstanceState) {
        //Code executé dans le thread principal
        super.onCreate(savedInstanceState);
        ...
        //On lie une action au bouton
        unButton.setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View v) {
                //Création et exécution d'un nouveau thread
                new Thread(new Runnable() {
            		@Override
            		public void run() {
                		// Instructions consommatrices en temps
                		// Et pour finir, déposer un Runnable dans l'UI Thread
                		post(new Runnable(){
                		     //Executé par l'UI thread 
                		     //Ex: modifier un TextView
                		});
            		}
                }).start();
        }
    }
    ...
}

Petite précision:

• L'UI thread: ce thread est dédié à l'affichage et à intercepter les actions de l'utilisateur;
• Les autres thread: ils servent à tout.

Donc, partant de ce constat, il faut utiliser l'UI thread uniquement ce pour quoi il est fait, c'est à dire de l'affichage et non des gros traitements sous peine de figer l'affichage le temps du calcul.

[bydavy]

Dans mon exemple, le code se déroule selon l'ordre suivant:

• Le UI Thread, executant le code de l'activity, va créer un nouveau thread;
• Le nouveau thread va exécuter son opération consommatrice en temps;
• Le nouveau thread va déposer le runnable dans l'UI thread;
• L'UI thread va exécuter le runnable.

En espérant t'avoir aidé !

[_Xavier_]

Donc, partant de ce constat, il faut utiliser l'UI thread uniquement ce pour quoi il est fait, c'est à dire de l'affichage et non des gros traitements sous peine de figer l'affichage le temps du calcul.

D'accord je vois mieux.

[Inrokuptible]

Pourquoi certains tutoriels ne sont pas visibles sur la page principale des tutoriels d'Android, celui-ci notamment ?

[MrDuChnok]

Les mises à jours vont se faire prochainement

[atha2]

Bonjour,

J'ai vu sur certain forum qu'il était déconseillé d'utiliser les threads dans une application Android. A la place ils préconise d'utiliser les services pour les taches longues.

Ce tuto est-il encore valable avec les nouvelles versions d'android ?

Ou alors ce conseille est donné parce que comme en Swing, la plupart des développeurs n'ont pas conscience du fonctionnement de l'UITread ? Et donc du coup l'utilisation de services force à utiliser des bonnes pratiques ?

[bydavy]

Salut atha2,

Ce tutoriel est toujours d'actualité et comme souvent en informatique il n'y a pas de réponse parfaite à ta question cela dépend de ton projet, tes besoins, etc. Mais je vais essayer d'éclaircir ta vision de ces deux éléments pour que tu comprennes mieux quand utiliser l'un ou l'autre.

Le thread :

• Il est un moyen d'executer un travail coûteux en arrière plan(comprend en dehors du main thread)

Le service (d'après la documentation officielle):

• Un service n'est pas un thread. Ce n'est pas en soit un moyen pour exécuter un travail coûteux hors du main thread (pour éviter l'écran d'erreur "Application Not Responding")
• Un moyen utilisé par l'application pour prévenir le système qu'on désire exécuter quelque chose en arrière plan (et celà même si ce n'est pas explicitement demandé par une action de l'utilisateur). Le service va s'exécuter jusqu'à ce qu'il se termine où que quelqu'un lui demande explicitement de se terminer.
• Un moyen d'exposer des fonctionnalités à d'autres applications. (Souvent recours à Context.bindService() et donc une communication s'inscrivant dans le temps).

Maintenant dans la pratique si tu veux faire une petite requête web pour compléter ton affichage, on utilise souvent un thread. Si tu veux créer quelque chose qui va questionner un serveur web toutes les 3h, c'est plutôt un service qu'il te faut.

J'espère que ça t'éclaire.

[atha2]

Merci bien pour ces éclaircissements !
Donc au final c'est la même chose que sous Windows

[Jebik]

J'ai une question qui peut paraitre légèrement hors sujet mais qui est totalement dans le thème j'ai une application qui montre deux web view en même temps ses deux web view montre des flash

Elles sont gérer dans mon UI Thread mais cela ram , sachant que je ne veut pas des interaction avec celle ci mais juste les afficher

Puis je faire une des webview dans un thread separer de l'UI thread?
Ou comme je semble l’avoir compris il est impossible de faire de l'affichage dans un autre thread?

[Feanorin]

Je ne pense pas la seule solution que je peux te donner c'est laisse soit tombé le flash soit les deux WebView .

[bydavy]

Salut Jebik,

Je ne me souviens plus des détails de l'implémentation des webviews mais elles sont déjà optimisées et utilisent plusieurs threads (chargement de données à partir d'Internet, composition de la page web, affichage, etc).
Je pense que ton problème vient d'ailleurs et principalement du flash. C'est une technologie mourante et plus disponible depuis ICS. Mon conseil serait de repartir de zéro, de te poser la question de tes besoins et revoir tes options pour l'implémentation.