novembre
2007
Après avoir été remisé au « second plan » par Sun qui privilégiait le coté serveur avec J2EE, voilà que Java revient petit à petit sur le devant de la scène coté client. D’ailleurs la prochaine update de Java 6 devrait déjà apporter pas mal de chose sur le sujet avec le « Consumer JRE« .
Et Java 7 continuera dans la même direction. Les versions en développement apportent déjà une solution permettant le mélange des composants AWT et Swing. On parle également d’un Java Media Components qui apporterait la gestion de lecture des vidéos en standard (sans passer par l’extension JMF).
Mais il faut surtout retenir l’ajout de deux nouvelles API facilitant le développement d’application Swing : Swing Application Framework et Beans Binding…
JSR 296 : Swing Application Framework
Swing a beau être une API graphique très évolué, elle est malgré tout assez « brut de décoffrage », c’est à dire que même si elle comporte tout ce qu’il faut pour développer une interface graphique, il faut quasiment tout gérer à la main !
L’objectif de la JSR 296 est donc de combler ce gros trou en proposant une infrastructure commune à la plupart des applications de bureau :
- Gestion du cycle de vie de l’application via une classe
Application
. - Support de la gestion et du chargement des ressources de l’application (chaines, images, couleurs, etc.).
- Gestion amélioré des
Actions
et de leurs associations avec les composants de l’interface. - Gestion de la persistance de l’application, en sauvegardant ses caractéristiques (taille, position, etc.) d’une exécution à l’autre.
- Gestion des traitements en tâche de fond afin de ne pas surchargé l’EDT.
- etc.
Je ne vais rentrerais pas plus en détail mais je vais simplement retranscrire ici l’exemple typique du « Hello World » :
public class SingleFrameExample2 extends SingleFrameApplication {
public void startup(String[] args) {
JLabel label = new JLabel();
label.setName("label");
show(label);
}
public static void main(String[] args) {
launch(SingleFrameExample2.class, args);
}
}
La méthode d’entrée standard des applications Java (main()) n’est ici utilisé que pour lancer notre application via la méthode statique launch(). Cette dernière se chargera entre autre de créer et initialiser notre application et d’appeler sa méthode startup() dans l’EDT. Cette dernière se contentera donc d’implémenter le code de la création de l’interface, et utilise ici la méthode show() permettant de créer automatiquement la JFrame
qui contiendra notre application.
Mais là ou cela devient plus intéressant, c’est que le framework permet d’associer automatiquement les données d’un fichier properties aux différents composants de notre interface via leurs noms (et c’est tout l’intérêt du label.setName("label")
). Ainsi en liant cette application avec le fichier properties suivant :
label.opaque = true
label.background = 0, 0, 0
label.foreground = 255, 255, 255
label.text = Hello World
label.font = Lucida-PLAIN-48
label.icon = earth.png
On obtient ceci :
Swing Application Framework proposera également un grand nombre d’autres fonctionnalités facilitant la conception d’interface graphique, que je ne peux malheureusement pas détailler ici…
Mais si le sujet vous intéresse je vous invite fortement à consulter le projet appframework sur java.net, qui permet entre autre de télécharger la version en développement (compatible Java 6) ou de consulter une introduction au framework assez claire et intéressante.
JSR 295 : Beans Binding
La JSR 295 permettra de synchroniser des beans entre eux. Actuellement il est nécessaires d’utiliser des PropertyChangeListeners
afin d’être averti des changements d’une propriété, afin de la répercuter sur l’autre. En effet, chaque composant Swing gère des PropertyEvents
qui permettent de signaler les changements de n’importe quelle propriété du composant. Si cela peut se révéler très utile, dans la pratique cela devient vite lourd à gérer et assez fastidieux. Les Beans Binding faciliteront tout cela !
Prenons un exemple tout simple ou une case à cocher (JCheckBox
) permettrait d’activer ou non une zone de saisie (JTextArea
). Beans Binding proposera tout le nécessaire pour relier ces deux propriétés ensemble :
JCheckBox checkBox = ...
JTextArea textArea = ...
Bindings.createAutoBinding(UpdateStrategy.READ_WRITE,
textArea, BeanProperty.create("enabled"),
checkBox, BeanProperty.create("selected"))
.bind();
Dorénavant, la propriété « enabled » de la zone de texte sera liée à la propriété « selected » de la case à cocher, et une modification de l’une de ces propriétés sera immédiatement répercutée sur l’autre tout en mettant à jour l’affichage des composants, en utilisant implicitement les PropertyChangeListeners
. Il n’y a rien de plus à faire !
Il sera également possible d’utiliser des convertisseurs afin de relier des propriétés apparemment incompatible (par exemple relier la valeur d’un champ texte vers un propriété de type Date), et d’effectuer une validation préalable des données. Sans oublier la gestion de propriété plus spécifique comme une cellule d’une JTable, ou bien la possibilité de lier une propriété à une ressource externe (Web-Service ou base de donnée).
Les Beans Binding possèdent également leur projet sur java.net qui permet d’avoir un aperçu de la version en développement…
Avis
Ces deux nouvelles APIs vont beaucoup apporter à la simplification du développement des applications graphiques Swing, tout en offrant un cadre standardisé qui permettra de les utiliser directement via les EDI Java. D’ailleurs NetBeans 6.0 a déjà commencer à intégrer la gestion de ces JSRs dans son outil de conception graphique…
4 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- [ fuite ] memoire
- Classes, méthodes private
- Difference de performances Unix/Windows d'un programme?
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- Recuperation du nom des parametres
- Possibilité d'accéder au type générique en runtime
- Définition exacte de @Override
- jre 1.5, tomcat 6.0 et multi processeurs
L’élaboration de tels framework est une bonne chose meme si j’avoue préférer développer « a la main » mes IHM surtout pour des applications complexes afin de respecter au mieux le DP MVC qui garantie l’évolutivité de l’interface.
J’ai déjà travaillé sur des IHM à base de Swing et pour être franc… d’accord c’est puissant mais question productivité… c’est loin d’être ça. Sans compter que la « méthode Swing » n’est pas très naturelle pour moi.
Mais là franchement ces deux JSR semblent être de très très bon augure !!!
Viva Java !
Merci pour cette entrée et ces informations
après toutes ces améliorations, je ne vois plus l’intérêt d’utiliser un EDI comme Delphi sauf pour concevoir une application légère mais non portable