Choisir son interface graphique en Java

Dans une application, la partie graphique est aussi importante que la partie
traitement car c’est cette partie qui reste le plus visible pour l’utilisateur.
Une application dont l’interface utilisateur n’est pas claire sera fatalement
peu utilisée. Nous allons voir quelles sont les librairies Java à votre
disposition pour réaliser l’interfaçage ainsi que ces  certains outils,
libres ou payants,  que vous pourrez utiliser.

Les librairies graphiques

Aujourd'hui, la majorité des développements graphiques en Java
utilisent Swing. Vous connaissez peut-être AWT (Abstract Windowing
Toolkit), l'ancêtre de Swing apparut dès la version 1.0 de Java. Cette
API graphique est compatible avec toutes les versions de Java, y
compris Java Mobile Édition. Les composants sont dits « lourds »
car ils sont dessinés et contrôlés par le système et non par Java.
C'est pourquoi AWT utilise assez peu de ressources, pourtant il
se fait vieux et rend difficile l’utilisation d’architecture en couches.
Le principe d’MVC (modèle-vue-contrôleur) ne peut pas être respecté
en AWT. Il se limite aux composants communs à tous les systèmes,
il faut donc souvent les personnaliser. AWT reste un choix pour les
systèmes limités.
Pour lui succéder, Sun a entrepris de développer la librairie Swing.
Respectant l'architecture vue-contrôleur, Swing est un standard complet.
Aspect décisif, les composants Swing sont légers (c'est à dire dessinés
par Java2D et contrôlés en pur Java). De cette caractéristique qui reflète
l'objectif "Write once, run everywhere" découlent plusieurs
inconvénients : les composants manquaient d’esthétique, le rendu
pouvait paraître lent, … Swing consomme beaucoup de mémoire mais
est-ce aussi lent qu'on le dit   Codée en pur Java et n’utilisant pas de
fonction native, il est normal qu'elle ne soit pas aussi rapide qu'une API
graphique native au système d’exploitation. Mais la puissance des
ordinateurs évoluant rapidement, cela se fait de moins en moins ressentir.
Le choix d’objets graphique dessinés directement par Java2D fait à la
fois la force et la faiblesse de Swing : la portabilité du même code quelques
soit la plateforme de destination est possible grâce à Swing, cependant,
la contrepartie de cette portabilité était un manque de réactivité des
applications graphique Java. L'utilisateur est souvent frustré lors de
l'utilisation pour quelques dixièmes de secondes de latence qui sont
le reflet de l'architecture même de Swing. Cette impression est provoquée
par exemple lors d'un clic de bouton, si ce dernier effectue quelque chose
de long comme un accès sur un réseau il faut jouer avec les threads pour
éviter que l'interface ne se gèle et pose des problèmes de rafraîchissement.
Java 6 a fait un véritable bond en avant pour aider les programmeurs à
annuler cet effet. De nombreuses autres nouveautés de Swing dans
JSE 6 : les "look & feel" qui ont été améliorés car l'apparence dans les
versions précédente se faisait désuète sans utilisation de librairies
spécialisées comme JGoodies (une API LGPL) qui permet d’améliorer
le rendu des objets graphiques.
Si vous souhaitez mixer des éléments AWT et Swing, sachez qu'il est
difficile de le faire même si la syntaxe est proche. Les objets se
superposent, le problème vient de leur nature : les composants
AWT (lourds) seront toujours en dessous des composants Swing
(légers) car la machine virtuelle dessine les composants AWT avant
les composants Swing. Ce problème est résolu dans Java 6 : il est donc
déconseillé d'avoir AWT et Swing dans la même fenêtre jusqu'à Java 5.

Application en Swing : Aerith

Avec une approche croisée entre AWT et Swing, l'API SWT mise sur
l'utilisateur au dépit de la portabilité. En effet, cette librairie (initialement
développée par IBM sous licence libre) possède une partie native. Elle
permet de réaliser des interfaces plus rapides en utilisant une majorité de
composants natifs aux différents systèmes d’exploitation pour lesquels
vous souhaiter destiner votre application. Cette librairie peut également
dessiner des composants graphiques n'existent pas sur une plateforme.
Souvent, l'utilisateur pense qu'un logiciel Java développé à l’aide d’SWT
est un programme natif. Côté développeur et sans l'utilisation de JFace,
SWT n'est pas aussi agréable à coder que Swing, surtout pour les
habituer de Swing car les principes de base ne sont pas du tout les
mêmes. Dû à la partie native, le "garbage collector" Java n'est plus...
Les objets parents s'occupent de la libération de mémoire de leurs enfants
lorsqu'on les supprime. Revenons maintenant sur Jface : permettant de
respecter l'architecture MVC, il améliore le code qui devient
plus facile à maintenir. Il est plus judicieux de comparer Swing avec
SWT+JFace (il faudra quand même coder des parties en SWT pour
les utilisations avancées).

N'étant ni standard ni indépendant du système d'exploitation,
l'apparence est différente suivant la plateforme. On doit maintenir autant
de versions que de systèmes, on perd alors un des grands avantages
de Java.

Parmi les problèmes de SWT, certains sont solutionnés par la nouvelle API
SwingWT. Elle couvre Swing à 90% et offre un pont entre ces deux mondes.
Un développeur Swing peut alors programmer en utilisant la syntaxe Swing
puis compiler avec SwingWT (il suffit de remplacer les packages Swing par
SwingWT). L'application obtenue utilise SWT lors de l'exécution. De plus, un
programme écrit pour Swing peut être compilé en SWT. A l'inverse, grâce à
l'API SWTSwing, nous avons désormais le pont dans l'autre sens.
Dans ce cas, un programme SWT pourra utiliser pour son affichage SWT ou
Swing sans recompilation.

Application en SWT : Azureus

Maintenant que nous avons vu les avantages et les inconvénients de
chaque API, vous pourrez choisir précisément l'API qui vous convient.
Les développeurs Java Mobile et Applets choisirons sûrement AWT. Swing
sera plus à même de répondre à des projets portables de grande ampleur
faciles à maintenir. SWT quand à lui, sera parfait pour les petits et grands
développements ou pour prouver qu'une interface Java peut être aussi
réactive qu'une interface en C. Finalement SwingWT et SWTSwing seront
peut-être une façon de réconcilier tout le monde et de profiter à
la fois des avantages de Swing et d’SWT...

SwingX

SwingX, pour Swing eXtension, est une partie d’un projet développé par
SwingLabs, visant à créer de nouveaux composants à intégrer rapidement
dans nos applications. SwingX est basé sur la librairie Swing, l’une des
API graphiques les plus utilisées.

Il contient les extensions de l’interface graphique de Swing en incluant de
nouveaux composants qui fournissent des fonctionnalités requises par les
applications "rich client" (c'est-à-dire des
applications qui se connectent à des serveurs d'application comme le
ferait un navigateur web classique, mais en proposant une interface plus
avancée que le HTML traditionnel).

Certains codes et concepts de ce projet devraient faire partie des
futures plateformes de Java.

Les nouveautés les plus importantes comprennent :
Le tri , le filtrage, la mise en valeur des éléments des  tables,
des arbres et des listes

Chercher/Trouver
L’ Auto-completion
Le Login / Un framework d’authentication
Le composant TreeTable
Le composant panel que l’on peut rendre invisible
Le composant de choix de date (calendrier)
Le composant  "Tip-of-the-Day " (astuce du jour)
Voici des exemples de composants SwingX :
Le calendrier :
On peut créer un calendrier permettant de sélectionner une date.
Il apparaît comme un JTextField banal avec un bouton sur le côté et le
calendrier se déroule lorsque l'on clique dessus.

Auto-completion

L'auto-completion survient lorsque l'on commence à entrer du texte dans
un champ et que celui-ci se complète automatiquement. C'est le cas
dans beaucoup de logiciels, comme par exemple lors du choix de la
langue de l'application :

 Auto-completion sur un JTextField et une Jlist
Panneau de conseils
Le composant JXTipOfTheDay permet de créer une boite de dialogue de
conseils que l'on affiche au lancement de l'application. Il suffit de créer une
petite base de "Tips" et de les afficher comme on le ferai grâce à un
JDialog.

Eclipse RCP
Eclipse RCP (Rich Client Platform) est une réelle révolution dans la
conception d’interface graphique en Java. Entièrement intégré à Eclipse,
cet outil permet de créer des projets plug-in pour Eclipse, mais aussi des
applications fenêtrées en standalone. Bien entendu,
chaque projet étant un plug-in, vous pouvez les réutiliser dans
n’importe quelle autre application basé sur RCP.

En utilisant Eclipse RCP, vous pourrez créer des applications en SWT/JFace.
L’intérêt, comme évoqué plus haut, étant que les composants graphiques
sont natifs au système d’exploitation (dans le cas où l’OS les supporte),
sinon ils sont dessinés en Java2D, comme si on utilisait Swing. Cela permet
d’obtenir des performances élevées. Un autre avantage en utilisant Eclipse
RCP est de se baser sur l’architecture modulaire d’Eclipse : vous pouvez
donc profiter des onglets, du système des vues déplaçable,
des perspectives, de l’éditeur textuel, …
Niveau visuel, l’une des plus grandes force de cette API est la présence de
PLAF (Pluggable Look n’ feel) qui permet au développeur de créer lui-même
son propre look n’ feel.

Cependant, cet outil se révèle assez complexe pour les utilisations avancées,
mais cela tente à être corrigé au fil des versions car cela permet d’accélérer le
développement de manière considérable en profitant des apports ayant été
fait à Eclipse.
Voilà un exemple tout simple de ce que l’on peut faire : Une application RCP à
laquelle on a intégré un plug-in :

Pour plus d’information, veuillez consulter les magazines Programmez! N° 84 et
85 (Mars et Avril 2006) et / ou visiter l’article suivant :
http://www.labo-sun.com/
resource-fr-articles-1185-1-eclipse-eclipse-eclipse-rcp.htm

Léonardi

Nous allons voir ici un produit permettant de développer rapidement et
simplement une IHM (Interface Homme-Machine) grâce au produit Leonardi.
Ce produit conviendra aussi bien aux débutants non familiarisés avec les
outils de modélisation IHM qu'aux utilisateurs chevronnés qui voudront
bénéficier de la puissance de Leonardi.
En effet, ce produit édité par la société Lyria (http://www.lyria.com/) est un
framework Model-Driven ce qui permet le développement de fonctionnalités
indépendamment de la plate-forme et donc d'automatiser les développements
des clients légers (applications accessibles via une interface web), lourds
(applications graphiques exécutées localement) ou riches (compromis entre
client léger et client lourd).
Nous pourrons donc faire évoluer ces clients en toute simplicité, ce qui est
permis par le fait que le moteur Leonardi produit une description XML des
vues (indépendante de l'afficheur) vers des cibles (SWT, Swing, Eclipse RCP)
dont nous avons parlé précédemment. De plus, il existe une cinquantaine
d'actions pré-implementées que l'on pourra utiliser à sa guise et que nous
n'aurons pas besoin de recoder, ce qui entraîne un bon gain de temps.

Parlons maintenant de l'installation du produit: tout d'abord, il est important
de noter qu'il existe quatre versions : la version « free » qui est la déclinaison
libre du produit Leonardi et qui supporte tous les projets basés sur des
technologies Open Source.

Les outils WYSIWYG