Swing (Java)
Swing est un cadre d’interface graphique « modèle-vue-contrôleur » indépendant de la plate-forme pour Java, qui suit un modèle de programmation à un seul thread. En outre, ce cadre fournit une couche d’abstraction entre la structure du code et la présentation graphique d’une interface graphique basée sur Swing.
FondationsEdit
Swing est indépendant de la plate-forme car il est entièrement écrit en Java. Une documentation complète pour toutes les classes Swing peut être trouvée dans le guide de l’API Java pour la version 6 ou dans la spécification de l’API de la plate-forme Java Standard Edition 8 pour la version 8.
ExtensibleEdit
Swing est une architecture hautement modulaire, qui permet le « branchement » de diverses implémentations personnalisées d’interfaces de cadre spécifiées : Les utilisateurs peuvent fournir leur(s) propre(s) implémentation(s) personnalisée(s) de ces composants pour surcharger les implémentations par défaut en utilisant le mécanisme d’héritage de Java via javax.swing.LookAndFeel.
Swing est un framework basé sur des composants, dont les composants sont tous finalement dérivés de la classe javax.swing.JComponent. Les objets Swing déclenchent des événements de manière asynchrone, ont des propriétés liées et répondent à un ensemble documenté de méthodes spécifiques au composant. Les composants Swing sont des composants JavaBeans, conformes à la spécification JavaBeans.
ConfigurableEdit
La forte dépendance de Swing à l’égard des mécanismes d’exécution et des modèles de composition indirecte lui permet de répondre au moment de l’exécution à des modifications fondamentales de ses paramètres. Par exemple, une application basée sur Swing est capable de permuter à chaud son interface utilisateur pendant l’exécution. En outre, les utilisateurs peuvent fournir leur propre mise en œuvre d’apparence, ce qui permet de modifier uniformément l’apparence des applications Swing existantes sans aucune modification programmatique du code de l’application.
Lightweight UI
Le haut niveau de flexibilité de Swing se reflète dans sa capacité inhérente à remplacer les contrôles d’interface graphique du système d’exploitation (OS) hôte natif pour s’afficher. Swing « peint » ses contrôles à l’aide des API 2D de Java, plutôt que d’appeler une boîte à outils d’interface utilisateur native. Ainsi, un composant Swing n’a pas de composant d’interface graphique native de l’OS correspondant, et il est libre de se rendre de n’importe quelle manière possible avec les interfaces graphiques sous-jacentes.
Cependant, à son cœur, chaque composant Swing repose sur un conteneur AWT, puisque (Swing) JComponent étend (AWT) Container. Cela permet à Swing de se brancher sur le cadre de gestion de l’interface graphique du système d’exploitation hôte, y compris les mappages appareil/écran cruciaux et les interactions de l’utilisateur, comme les pressions sur les touches ou les mouvements de la souris. Swing « transpose » simplement sa propre sémantique (agnostique au système d’exploitation) sur les composants sous-jacents (spécifiques au système d’exploitation). Ainsi, par exemple, chaque composant Swing peint son rendu sur le périphérique graphique en réponse à un appel à component.paint(), qui est défini dans Container (AWT). Mais contrairement aux composants AWT, qui déléguaient la peinture à leur widget « poids lourd » natif de l’OS, les composants Swing sont responsables de leur propre rendu.
Cette transposition et ce découplage ne sont pas simplement visuels, et s’étendent à la gestion et à l’application par Swing de sa propre sémantique indépendante de l’OS pour les événements déclenchés dans ses hiérarchies de confinement de composants. D’une manière générale, l’architecture Swing délègue au conteneur AWT la tâche de faire correspondre les différents types de sémantique d’interface graphique du système d’exploitation à un modèle simple, mais généralisé. En s’appuyant sur cette plate-forme généralisée, elle établit sa propre sémantique d’interface graphique riche et complexe sous la forme du modèle JComponent.
La bibliothèque Swing fait un usage intensif du patron de conception logicielle modèle-vue-contrôleur, qui découple conceptuellement les données visualisées des contrôles d’interface utilisateur par lesquels elles sont visualisées. Pour cette raison, la plupart des composants Swing sont associés à des modèles (spécifiés en termes d’interfaces Java), et les programmeurs peuvent utiliser diverses implémentations par défaut ou fournir les leurs. Le framework fournit des implémentations par défaut des interfaces de modèles pour tous ses composants concrets. L’utilisation typique du framework Swing ne nécessite pas la création de modèles personnalisés, car le framework fournit un ensemble d’implémentations par défaut qui sont associées de manière transparente, par défaut, à la classe enfant correspondante JComponent dans la bibliothèque Swing. En général, seuls les composants complexes, tels que les tableaux, les arbres et parfois les listes, peuvent nécessiter les implémentations de modèles personnalisés autour des structures de données spécifiques à l’application. Pour avoir une bonne idée du potentiel que l’architecture Swing rend possible, considérons la situation hypothétique où les modèles personnalisés pour les tableaux et les listes sont des wrappers sur des services DAO et/ou EJB.
Typiquement, les objets de modèle de composant Swing sont responsables de la fourniture d’une interface concise définissant les événements déclenchés et les propriétés accessibles pour le modèle de données (conceptuel) à utiliser par le JComponent associé. Étant donné que le modèle MVC global est un modèle de relation entre objets collaboratifs faiblement couplés, le modèle fournit les moyens programmatiques pour attacher des écouteurs d’événements à l’objet de modèle de données. Typiquement, ces événements sont centrés sur le modèle (ex : un événement « row inserted » dans un modèle de table) et sont mappés par la spécialisation JComponent en un événement significatif pour le composant GUI.
Par exemple, le JTable a un modèle appelé TableModel qui décrit une interface pour la façon dont une table accéderait aux données tabulaires. Une implémentation par défaut de ce modèle opère sur un tableau à deux dimensions.
Le composant de vue d’un JComponent Swing est l’objet utilisé pour représenter graphiquement le contrôle conceptuel de l’interface graphique. Une distinction de Swing, en tant que cadre d’interface graphique, réside dans sa dépendance à l’égard des contrôles d’interface graphique rendus par programme (par opposition à l’utilisation des contrôles d’interface graphique du système d’exploitation hôte natif). Avant la mise à jour 10 de Java 6, cette distinction était une source de complications lors du mélange de contrôles AWT, qui utilisent des contrôles natifs, avec des contrôles Swing dans une interface graphique (voir Mélange de composants AWT et Swing).
Enfin, en termes de composition et de gestion visuelles, Swing favorise les mises en page relatives (qui spécifient les relations de position entre les composants) par opposition aux mises en page absolues (qui spécifient l’emplacement et la taille exacts des composants). Ce parti pris en faveur d’un ordonnancement visuel « fluide » est dû à ses origines dans l’environnement d’exploitation des applets qui a encadré la conception et le développement de la boîte à outils originale de l’interface graphique Java. (Conceptuellement, cette vision de la gestion de la mise en page est assez similaire à celle qui informe le rendu du contenu HTML dans les navigateurs, et répond au même ensemble de préoccupations qui ont motivé la première.)
Relation avec AWTEdit
Depuis les premières versions de Java, une partie de l’Abstract Window Toolkit (AWT) a fourni des API indépendantes de la plate-forme pour les composants de l’interface utilisateur. Dans AWT, chaque composant est rendu et contrôlé par un composant homologue natif spécifique au système de fenêtrage sous-jacent.
Par contraste, les composants Swing sont souvent décrits comme légers car ils ne nécessitent pas l’allocation de ressources natives dans la boîte à outils de fenêtrage du système d’exploitation. Les composants AWT sont qualifiés de composants lourds.
Une grande partie de l’API Swing est généralement une extension complémentaire de l’AWT plutôt qu’un remplacement direct. En fait, chaque interface légère Swing existe en fin de compte dans un composant lourd AWT, car tous les composants de premier niveau de Swing (JAppletJDialogJFrame et JWindow) étendent un conteneur de premier niveau AWT. Avant la mise à jour 10 de Java 6, l’utilisation de composants légers et lourds au sein d’une même fenêtre était généralement déconseillée en raison des incompatibilités d’ordre Z. Cependant, les versions ultérieures de Java ont corrigé ces problèmes, et les composants Swing et AWT peuvent maintenant être utilisés dans une interface graphique sans problèmes d’ordre Z.
La fonctionnalité de rendu de base utilisée par Swing pour dessiner ses composants légers est fournie par Java 2D, une autre partie du JFC.
Relation avec SWTEdit
Le Standard Widget Toolkit (SWT) est une boîte à outils concurrente développée à l’origine par IBM et maintenant maintenue par la communauté Eclipse. L’implémentation de SWT a plus de points communs avec les composants lourds de AWT. Cela lui confère des avantages tels qu’une fidélité plus précise avec la boîte à outils de fenêtrage native sous-jacente, au prix d’une exposition accrue à la plate-forme native dans le modèle de programmation.
Il y a eu un débat et des spéculations importants sur les performances de SWT par rapport à Swing ; certains ont laissé entendre que la forte dépendance de SWT à l’égard de JNI le rendrait plus lent lorsque le composant GUI et Java doivent communiquer des données, mais plus rapide au niveau du rendu lorsque le modèle de données a été chargé dans le GUI, mais cela n’a pas été confirmé dans un sens ou dans l’autre. Un ensemble assez complet de benchmarks en 2005 a conclu que ni Swing ni SWT ne surpassaient clairement l’autre dans le cas général.