Discussion :

[Fellowes]

Bonjour à tous, j’ai une petite question qui me taraude !

Je vous explique : je réalise actuellement une sorte de «*Messenger*» en java sous netbeans. J’ai une interface utilisateur qui affiche les messages et les fils de discussions d’autre utilisateur via un serveur et une base de donnée. Bref le problème c’est que quand un autre utilisateur créé un nouveau message, comment je fais pour «*actualiser*» mon interface pendant que l’utilisateur navigue dessus ?
Comment faire pour que la mise des fils de discussion afficher dans un coin de l’interface s’actualise et notifie qu’il y a un nouveau message ?
Dois-je relancer une fenêtre ?
Mais comment faire pour savoir qu’un message est arrivé pendant que la fenêtre est active ?

Voilà je sais pas si c’est très clair, mais merci infiniment à ceux qui m’aideront 😊

[Fellowes]

J'ai trouvé!

Pour ceux que ça intéresse:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
int delay = 1000; //milliseconds
        ActionListener taskPerformer;
        taskPerformer = (ActionEvent evt) -> {
            System.out.println("1");
        };
        Timer t = new Timer(delay, taskPerformer);
        t.start();

Vous mettez ça direct dans le constructeur, vous mettez l'instruction que je voulez à la place de syso("1) et c'est bon

[joel.drigo]

Salut,

Le Timer est une solution, mais tu vas mettre à jour souvent inutilement. Le mieux est de faire une mise à jour uniquement lorsqu'il y a une notification. Pour faire ça, il y a le pattern Notifier/Observer. En MVC, le principe est qu'on met à jour le modèle et la vue va se mettre à jour par écoute des changements du modèle.

[Fellowes]

Salut! effectivement le timer n'est pas très pratique finalement, c'est un peu du bidouillage mais ton idée m'intéresse fortement!!

Mais je ne vois pas très bien comment faire, je dois mettre un pattern dans mon constructeur? Comment ça marche?

Merci

[joel.drigo]

Les design patterns sont juste des structures définies de classes, souvent utilisées dans les programmes, donc qui ont été décrites pour faciliter leur implémentation. Tu as une description du pattern ici.

Il ne s'agit que d'un ensemble de classes et rien n'oblige vraiment à reproduire les structures exactement. Simplement, ça t'évitera de réfléchir à comment le faire. Le pattern observer est simplement un système qui repose sur un objet qui produit des notifications (ou événement si tu préfères) et un (ou plusieurs) objet(s) qui les écoute(nt), et, donc, qui vont réagir à la réception de ces notifications. C'est le système qui est mis en place pour gérer les événements Swing, par exemple ceux de souris ou de boutons. Quand tu écris button.addActionListener( ... ) tu enregistres un observateur qui va réagir aux événements de type ActionEvent produits par un notifieur interne à Swing. Dans ce cas tu n'écris que l'observateur. Dans le cas de tes messages, j'imagine que tu as une Socket dans laquelle un message est écrit : tu peux simplement à la fin de la réception du message, ajouter le message à une "liste" de messages, produire un événement "nouveau message reçu", et l'interface graphique écoutant ce type d'événements pourra rafraîchir l'interface à ce moment (à partir de la liste). A noter qu'il est important de prend en compte que les événements vont être produits et écouter dans 2 threads différents et donc qu'il faut protéger quelque chose contre les accès concurrents. Comme, dans ton cas, le but est d'afficher les messages (dans le thread Swing) et de les produits après réception sur la socket, dans le second thread, tu peux simplement déléguer dans un premier temps le traitement post réception au thread Swing (avec SwingUtilties.invokeLater). Ainsi, tu n'auras pas d'accès multithread sur la liste de messages et donc pas de risque d'accès concurrents.