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 que les composants ne sont pas affichés ou ne se comportent pas comme prévu.
maintenant ma question:
comment planifiez-vous ces interfaces utilisateurs? Que faites-vous lorsque vous devez faire des changements? Comment réfuter les comportements étranges?!
cela s'applique à presque tous les types d'interface graphique. Bien sûr, avec Microsofts Visual Studio vous avez un grand avantage parce que vous obtenez presque ce que vous voyez dans le concepteur.
bonne et open-source (ou freeware) designer for AWT existent? J'ai déjà regardé autour de moi et je n'ai rien trouvé de vraiment intelligent.
EDIT: Jusqu'à présent, j'ai aussi créé toutes mes interfaces graphiques à la main. Bien sûr, c'est du code plus propre, mais parfois il est très difficile de trouver les bogues layouting. Si Visual Studio by MS est capable de créer approximativement du code propre, pourquoi les autres?
j'ai entendu parler d'un concepteur visuel D'Eclipse. Est-ce que celui-ci est déjà prêt pour la production?
10 réponses
Je ne suis pas un grand fan des constructeurs de GUI: ils autogénèrent typiquement des tas de codes qui bloquent ensuite toute votre équipe de développement à l'aide d'un seul IDE. De plus, ce code est souvent illisible (cochez le code généré lors de L'utilisation de Matisse sous Netbeans).
Mes recommandations pour l'interface graphique de conception / débogage serait:
- Ajouter un
mainméthode de mise en œuvre de chaque panel (ou composante "de haut niveau"), permettant aux autres développeurs de déterminer facilement ce qu'un composant ressemble. - favorisez l'utilisation de
ActionsurActionListeners et enregistrez ces actions avec chaqueJComponentActionMap. Cela permet de les "extraire" et de les ajouter à d'autres parties de L'interface utilisateur (par exempleJToolBar) tout en ayant encore leur état contrôlé par le "propriétaire"JComponent(C.-à-d. accouplement lâche). - utiliser assert pour s'assurer que toutes les modifications des composants de L'interface utilisateur se produisent sur le thread Event Dispatch; e.g.
assert SwingUtilities.isEventDispatchThread(). - pour déboguer la disposition étrange comportement pensez à peindre le fond d'un composant en rouge!
- centraliser la saisie et le compte-rendu des événements et des exceptions du flux de travail. Par exemple, j'implémente typiquement un
TaskManagerclasse qui est inscrite à la barre de statut de mon IU. Tout traitement d'arrière-plan (effectué dansSwingWorkers) est passé une poignée à unTaskcréé par l'TaskManager. Interracting avec la Tâche (en appelantsetDescription(String),setThrowable(Throwable),cancel()) provoque la mise à jour de la barre d'état. Elle provoque également la vitre à afficher pour les tâches" globales"... mais tout cela est découplé / caché des échangistes individuels. - N'utilisez pas le
Observer/Observableclasses, mais au contraire favoriser lesChangeListener,PropertyChangeListenerou votre propre implémentation listener personnalisée pour propager des événements.ObserverpasseObjectcomme c'est l'é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 classes moins lisibles clair. - favorisez l'utilisation de
JTableJListmême dans les situations où votre table n'a qu'une colonne.JLista quelques fonctionnalités désagréables dans son API, y compris le fait que vous devez fournir une valeur prototype pour qu'il calcule sa taille correctement. - ne Jamais utiliser
DefaultTableModelcomme il en résulte généralement que vous stockez vos données de "modèle" à deux endroits: dans vos objets d'affaires réels et aussi dans le tableau 2D quiDefaultTableModels'assoit dessus. Au lieu de cela, simplement sous-classeAbstractTableModel-très facile pour ce faire et signifie que votre implémentation peut tout simplement déléguer à travers la structure de données (par exempleList) stocker vos données.
je suis un de ces gars archaïques qui font la mise en page de GUI à la main. Je suis également pas peur de l'infâme GridBagLayout!
je garde les choses simples pour moi-même en imitant la norme de codage utilisée par Visual Age, Il ya des années: j'utilise beaucoup de JPanels pour organiser des parties de L'interface graphique, et chacun obtient son propre makeXXX() méthode pour créer, aménager et de le remettre à un panneau parent ou le constructeur. De cette manière, chaque
certains composants doivent être accessibles par diverses méthodes d'instance; je les déclare comme champs d'instance. Le reste, c'est juste de la décoration ou de la mise en page, n'a pas besoin d'être exposé à l'extérieur de la makeXXX méthodes.
C'est presque tout. Fonctionne pour moi.
le Faire à la main. Les constructeurs de GUI ne sont pas bons à moins que vous ayez le concept de "classe partielle" dans C#, et même alors ils causent souvent plus de problèmes qu'ils ne résolvent. Utilisez les outils de GUI builder pour faire un prototype - sûr, mais pas pour le code de production.
aussi, un autre petit truc que j'ai utilisé au cours des années pour avoir un bon effet lors de la tentative de débogage ou "quel panneau est-ce que je vois vraiment ici" problèmes est de donner à chaque panneau "conteneur" une couleur de fond vraiment criarde (jaune, bleu, etc). Quelque chose d'assez évident pour que vous le voyiez, même s'il n'a qu'un pixel de large.
et ma mise en page préférée pour les dialogues simples est BoxLayout. Ce n'est pas génial, vous devez écrire beaucoup de boilerplate, mais au moins il fonctionne généralement la façon dont vous vous attendez à ce que dans votre tête. Ne pas overthink mises en page jusqu'à ce que vous avez à.
NetBeans pourrait être la meilleure option pour construire GUI de la manière WYSIWYG, mais de nombreux développeurs java écrivent leur GUI à la main, car ce n'est pas si difficile. Attention à l'épaisseur de vos bordures et les écarts 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 (!) pour communiquer les idées (.. il suffit de lire, que vous avez déjà un plan sur papier)
- planifiez la mise en oeuvre d'un modèle de contrôleur de vue de modèle (MVC) ou d'un modèle de présentateur de vue de modèle
- liaison de données est une bonne technique considérer. Il garantit la synchronisation entre votre modèle (données) et la vue (GUI) et offre la validation des entrées, la conversion à la volée et bien d'autres choses utiles (pourvu que le lien pour la datation JFace, mais je suis sûr, il y a d'autres cadres pour Swing/AWT aussi)
Il y a eu temporairement-morts (mais maintenant, apparemment, au moins à la moitié de son vivant) plugin pour Eclipse pour le design graphique et Netbeans a toujours le support pour cela. Le code résultant était moins que stellaire, cependant. Au moins pour les gens qui doivent travailler avec cette base de données après c'est assez pénible.
quant à moi, j'ai tendance à planifier sur le papier à l'avance et essayer d'obtenir tous les nids de panneaux avec leurs dispositions directement sur le premier essai. Java GUI code est intrinsèquement écrit-seulement dans de 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 je les ai assemblés en plusieurs panneaux et configurations, etc. Cette façon de faire é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 de, comme vous l'avez noté aussi, le soutien fort concepteur. En outre, WPF est très facile à manipuler, même dans XAML. Ans les classes partielles font travailler avec code partiellement créé par le designer et partiellement écrit à la main très agréable. Hélas, rien de Tel dans le monde de Java.
j'utilise JFormDesigner pour l'interface graphique de génération. Il génère du code java propre et agréable, et j'ai appris quelques choses en lisant le code généré. Fait de la localisation un claquement.
c'est un moyen très rapide pour assembler une mise en page impliquée, particulièrement les ménubars complexes et les mises en page de grille.
j'ai pour ma part utiliser
pour certains prototypage d'abord, puis commencer à coder "à la main" (c.-à-d. sans utiliser d'éditeur GUI).
je vous suggérerais d'utiliser netbeans pour le développement de GUI en AWT / SWING.
ce qui Concerne, Sameer
alors que L'éditeur Matisse de NetBeans est certes pratique, le code qu'il produit est assez ésotérique et les mises en page sont fragiles. Donc j'ai pris le meilleur des deux mondes, en utilisant NetBeans pour le prototypage de WYSIWYG et en recodant tout ça à la main.