Fil d'IU fil d'IU d'alerte si l'erreur se produit

Question

J'ai une question de client/serveur que j'essaye de trouver la meilleure solution pour. Si un client se déconnecte du serveur, pour quelque raison que ce soit, je voudrais que le thread de sortie d'entrée signale au thread gui que quelque chose s'est mal passé et que le thread gui imprime une erreur et gère il (probablement revenir à l'interface de connexion). Après la création du thread graphique initial, le client peut changer de guis, en fonction de ce qu'il fait, donc je pense que j'ai besoin d'un moyen de voir dynamiquement ce que gui est en cours d'exécution.

La façon dont je pensais à le faire jusqu'à présent:

1) Créer un objet qui crée et montre tous les IUG. Donc, au lieu d'appeler invokeLater ... SomeGui.CreateAndShoGui() ... nous aurions cet objet responsable de faire cela, c'est-à-dire GuiObject.showSomeGui();

2) Demander à chaque interface graphique de mettre en œuvre une interface, ce qui assurera qu'il existe une méthode qui, une fois appelée, arrêtera gracieusement cette interface lorsque nous aurons perdu la connexion au serveur.

3) Avoir un thread qui surveille le thread IO et l'objet GUI. Si quelque chose se passe mal sur le thread IO, le thread IO se fermera et avisera le thread de surveillance que nous avons perdu la connexion au serveur. Le thread de surveillance pourrait alors alerter tout guis ouvert (de l'objet gui) que nous avons perdu la connexion et qu'il doit fermer.

Je viens juste de commencer à réfléchir à cela, et jusqu'à présent, c'est la meilleure solution que j'ai trouvée. Est-ce que cela semble être une solution raisonnable qui ne va pas ajouter trop de complexité au code? Ou quelqu'un peut-il recommander une solution qui serait plus simple pour les personnes lisant le code à comprendre?

Merci

EDIT: L'autre option que je suis en train de jouer avec un objet est d'avoir sur le thread IO, qui obtient également transmis à chaque nouvelle IUG comme il est ouvert. Cet objet donnera la référence guis actuellement ouverte au thread io, de sorte que le thread io peut l'alerter si quelque chose ne va pas. Je penche cependant contre cette solution, car il semblerait que ce serait plus facile à lire si vous aviez un objet dédié pour que cela fonctionne (comme la solution ci-dessus), au lieu de passer un objet obscur à chaque gui.

Answer 1

Permettez-moi de passer à travers chacun de vos idées:

1) Mauvaise idée - vous liez votre application tout ensemble par un seul objet. Cela rend la maintenabilité difficile et est l'antithèse de la modularité.

2) C'est la voie à suivre à mon humble avis. Puisqu'il semble que chaque gui a une logique unique dans un scénario d'échec, alors il va de soi que l'objet qui comprend le mieux ce qu'il doit faire est l'objet gui lui-même.

Une autre version de cette idée serait de créer un adaptateur pour chaque interface graphique pour mettre cette logique d'échec. L'avantage serait que vous ayez une dépendance de moins entre votre framework d'application et votre gui. L'inconvénient est que c'est une couche supplémentaire de complexité. Si votre interface graphique est déjà assez couplée à votre application, alors je choisirais la méthode d'interface. Si vous voulez réutiliser votre guis dans une autre application, la manière de l'adapter pourrait faciliter cela.

3) Ceci complète bien le # 2. Alors laissez-moi comprendre: vous auriez 3 threads: le thread IO, le thread monitor et le thread UI. Je ne sais pas si vous avez besoin du fil du moniteur.D'après ce que vous disiez, le thread IO serait capable de détecter lui-même un problème de connexion (probablement parce qu'une forme d'exception IOException a été interceptée). Quand un problème de connexion est découvert, le thread d'E/S n'est pas occupé car il va juste se fermer bientôt, donc il pourrait tout aussi bien avoir la responsabilité de signaler à l'utilisateur qu'il y avait un problème. Le guis devrait avoir sa méthode d'interface appelée sur le thread de l'interface utilisateur de sorte que le thread IO appelle juste un tas d'appels invokeLater() (ou appels asyncExec() pour SWT), puis le thread IO peut simplement se fermer.

4) (Votre édition) Vous décrivez essentiellement le modèle de visiteur. Je ne pense pas que ce soit une bonne solution car l'appel provient du thread d'E/S vers le gui et non l'inverse. Je ne suis pas sûr que le fait de passer un objet visiteur puisse aider dans ce cas.

Une dernière pensée. Si vous générez votre interface générique (pas spécifique à gui), vous pouvez appliquer ce modèle à d'autres ressources. Par exemple, vous pouvez vouloir vider vos informations d'identification utilisateur lorsque vous perdez la connexion (puisque vous avez parlé d'aller à l'écran de connexion à nouveau). Ce n'est pas vraiment logique et ne devrait pas être fait à partir d'une classe gui.

Modifier: J'utiliserais un modèle d'événement. Disons que vous créez une interface comme ceci:

public interface ConnectionFailureListener { 
    void handleConnectionFailure(); // Add an event object if you need it 
} 

Vous pourriez alors avoir des méthodes d'enregistrement dans un objet (peut-être le Runnable pour le thread IO ou ailleurs qui vous convient). Ces méthodes seraient assez standard:

public void addConnectionFailureListener(ConnectionFailureListener l) {} 
public void removeConnectionFailureListener(ConnectionFailureListener l) {} 

Lorsque vous affichez une interface utilisateur graphique sur l'écran que vous ajoutez à votre objet d'inscription et lorsque vous fermez le IUG vous retirer de l'objet d'enregistrement. Vous pouvez ajouter d'autres types d'objets si nécessaire. Par exemple, lorsque vous vous connectez, vous pouvez ajouter un écouteur pour votre système d'informations d'identification et le supprimer à nouveau lorsque la déconnexion est traitée. De cette façon, lorsque vous avez une condition d'échec, vous faites simplement une boucle dans les écouteurs actuellement enregistrés et l'auditeur fait ce qu'il veut.