Java AWT / SWT / Swing: Comment planifier une interface graphique?
J'ai déjà réalisé quelques applications avec une petite interface utilisateur graphique. Rien de complexe, mais j'ai rencontré plusieurs problèmes selon lesquels les composants ne sont pas affichés ou ne se comportent tout simplement pas comme prévu.
Maintenant, ma question:
Comment planifiez-vous ces interfaces utilisateur? Que faites-vous lorsque vous devez apporter des modifications? Comment déboguer des comportements étranges?!
Cela s'applique à presque tous les types de conception d'interface graphique. Bien sûr, avec Microsofts Visual Studio, vous avez un gros avantage parce que vous obtenez presque ce que vous voyez dans le concepteur.
Existe-t-il un bon et un concepteur open-source (ou freeware) pour AWT? Déjà regardé autour de lui et n'a rien trouvé de vraiment intelligent.
EDIT: Jusqu'à présent, j'ai également créé toutes mes interfaces graphiques à la main. Bien sûr, c'est un code plus propre, mais il est parfois très difficile de trouver les bogues de mise en page. Si Visual Studio by MS est capable de créer du code approximativement propre, pourquoi les autres ne le sont-ils pas?
J'ai entendu parler de certains Eclipse Concepteur visuel. Est-ce déjà prêt pour la production?
10 answers
Je ne suis pas un grand fan des constructeurs d'interfaces graphiques: Ils générent généralement des tas de code qui verrouillent ensuite toute votre équipe de développement à l'aide d'unE. De plus, ce code est souvent illisible (vérifiez le code généré lors de l'utilisation de Matisse sous Netbeans).
Mes recommandations pour la conception / le débogage de l'interface graphique seraient:
- Ajoutez une méthode
mainà chaque implémentation de panneau (ou composant de" niveau supérieur"), permettant aux autres développeurs de déterminer facilement à quoi ressemble un composant comme. - Faveur de l'utilisation de
Actions surActionListeners et enregistrer ces actions avec chaqueJComponent'sActionMap. Cela leur permet d'être "extraits" et ajoutés à d'autres parties de l'interface utilisateur (par exempleJToolBar) tout en ayant leur état contrôlé par le "propriétaire"JComponent(c'est-à-dire le couplage lâche). - Utilisez assert pour vous assurer que toutes les modifications des composants de l'interface utilisateur se produisent sur le thread de répartition des événements; par exemple
assert SwingUtilities.isEventDispatchThread(). - Pour déboguer un comportement de mise en page étrange, envisagez de peindre l'arrière-plan d'un composant dans rouge!
- Centraliser la capture et le reporting des événements de workflow et des exceptions. Par exemple, j'implémente généralement une classe
TaskManagerenregistrée dans la barre d'état de mon interface utilisateur. Tout traitement en arrière-plan (effectué dansSwingWorkers) est transmis un handle à unTaskcréé par leTaskManager. Interracting avec la tâche (en appelantsetDescription(String),setThrowable(Throwable),cancel()) provoque la mise à jour de la barre d'état. Cela provoque également l'affichage de la vitre pour les tâches "globales"... mais tout cela est découplé / caché des SwingWorkers individuels. - Ne pas utiliser le
Observer/Observableclasses, mais plutôt favoriserChangeListener,PropertyChangeListenerou votre propre implémentation d'écouteur personnalisée pour propager des événements.Observerpasse unObjectcomme son événement, forçant le code client à vérifier le type en utilisant instanceof et à effectuer des downcasts, rendant le code illisible et rendant les relations entre les classes moins claires. - Privilégiez l'utilisation de
JTablepar rapport àJList, même dans les situations où votre table n'a qu'une seule colonne.JLista quelques fonctionnalités désagréables dans son API, y compris le fait que vous devez fournir une valeur de prototype pour calculer sa taille correctement. - N'utilisez jamais
DefaultTableModelcar cela vous oblige généralement à stocker vos données "modèle" à deux endroits: Dans vos objets métier réels et également dans le tableau 2D sur lequelDefaultTableModelse trouve. Au lieu de cela, il suffit de sous-classer {[26] } -C'est très facile de le faire et signifie que votre implémentation peut simplement déléguer à la structure de données (par exempleList) le stockage vos données.
Je suis un de ces gars archaïques qui font la mise en page GUI à la main. Je n'ai pas non plus peur de l'infâme GridBagLayout!
Je garde les choses simples pour moi en émulant la norme de codage utilisée par Visual Age, il y a des années: j'utilise beaucoup de JPanels pour organiser des parties de l'interface graphique, et chacun obtient sa propre méthode makeXXX() pour le créer, l'exposer et le retourner à un panneau parent ou au constructeur. De cette façon, chaque makeXXX ne doit se concentrer que sur une petite partie de l'ensemble des œuvres.
Certains composants ont besoin pour être accessible par diverses méthodes d'instance; je les déclare comme champs d'instance. Les autres éléments, qui ne sont que de la décoration ou de la mise en page, n'ont pas besoin d'être exposés en dehors des méthodes makeXXX.
C'est surtout ça. Fonctionne pour moi.
Faites-le à la main. Les constructeurs d'interfaces graphiques ne sont pas bons sauf si vous avez le concept de "classe partielle" en C#, et même dans ce cas, ils causent souvent plus de problèmes qu'ils n'en résolvent. Utilisez les outils GUI builder pour créer un prototype, mais pas pour le code de production.
De plus, une autre petite astuce que j'ai utilisée au fil des ans pour déboguer la mise en page ou les problèmes "quel panneau vois-je vraiment ici" est de donner à chaque panneau "conteneur" une couleur de fond vraiment criarde (jaune, bleu, etc.). Quelque assez évident pour que vous le voyiez même s'il ne fait qu'un pixel de large.
Et ma disposition préférée pour les dialogues simples est BoxLayout. Ce n'est pas génial, vous devez écrire beaucoup de passe-partout, mais au moins cela fonctionne généralement comme vous vous y attendez dans votre tête. Ne pensez pas trop aux mises en page jusqu'à ce que vous ayez à le faire.
NetBeans pourrait être la meilleure option pour construire une interface graphique de manière WYSIWYG, mais de nombreux développeurs java écrivent leur interface graphique à la main, car ce n'est pas si difficile. Souciez-vous de l'épaisseur de vos frontières et des espaces entre vos contrôles et vous êtes ok:)
En dehors de la discussion sur les outils, juste quelques idées et réflexions
- Avant de toucher le clavier, dessinez les éléments de l'interface graphique sur papier. Comme le storyboard classique utilisé pour la production vidéo. Si vous avez des clients, utilisez le dessin à la main (! des conceptions de communiquer les idées.. il suffit de lire, que vous planifiez déjà sur papier)
- Prévoyez d'implémenter un modèle MVC (model-view-controller) ou model-view-presenter
- La liaison de données est une excellente technique à considérer. Il garantit synchronisation entre votre modèle (données) et la vue (GUI) et offre une validation d'entrée, une conversion à la volée et bien d'autres choses utiles (Fourni le lien pour la liaison de données JFace, mais je suis sûr qu'il existe également d'autres frameworks pour Swing/AWT)
Il y a eu un plugin temporairement mort (mais maintenant apparemment au moins à moitié vivant) pour Eclipse pour la conception graphique visuelle et Netbeans a toujours le support pour cela. Le code résultant était moins que stellaire, cependant. Au moins pour les personnes qui doivent travailler avec cette base de code par la suite, c'est assez pénible.
Quant à moi, j'ai tendance à planifier sur papier à l'avance et à essayer d'obtenir tous les imbriqués des panneaux avec leurs dispositions dès le premier essai. Le code Java GUI est intrinsèquement écrit uniquement dans mon expérience.
La dernière fois que j'ai fait une telle chose, j'ai d'abord créé tous les contrôles dont j'avais besoin, puis les ai assemblés dans plusieurs panneaux et mises en page, etc. Cette façon était au moins gérable et fonctionnait sans trop de douleur lorsque des changements devaient être apportés.
J'ai tendance à ne pas trop penser à la mise en page particulière dans Winforms et WPF en raison du, comme vous l'avez également noté, fort soutien du concepteur. De plus, WPF est très facile à manipuler même en XAML. Les classes partielles Ans permettent de travailler avec partiellement code généré par le concepteur et partiellement manuscrit très agréable. Hélas, rien de tel dans le monde Java.
J'utilise JFormDesigner pour la génération d'interface graphique. Il génère un bon code java propre, et j'ai appris quelques choses en lisant le code généré. Rend la localisation un jeu d'enfant.
C'est un moyen très rapide de rassembler une mise en page impliquée, en particulier les barres de menus et les mises en page de grille complexes.
J'utilise pour moi-même
Pour un prototypage d'abord, puis commencez à coder "à la main" (c'est-à-dire sans utiliser d'éditeur GUI).
Je vous suggère d'utiliser netbeans pour le développement de l'interface graphique dans AWT/SWING.
Cordialement, Sameer
Si l'éditeur Matisse de NetBeans est certes pratique, le code qu'il produit est assez ésotérique et les mises en page sont fragiles. J'ai donc pris le meilleur des deux mondes, en utilisant NetBeans pour le prototypage WYSIWYG, puis en recodant le tout à la main.