| Penser en Java 2nde édition | - | Sommaire | Préface | Avant-propos | Chapitre : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Annexe : A B C D | Tables des matières | - | Thinking in Java |
Une directive de conception fondamentale est « rendre les choses simples faciles, et les choses difficiles possibles ».
L'objectif initial de la conception de la bibliothèque d'interface utilisateur graphique [graphical user interface (GUI)] en Java 1.0 était de permettre au programmeur de construire une GUI qui a un aspect agréable sur toutes les plateformes. Ce but n'a pas été atteint. L'Abstract Window Toolkit (AWT) de Java 1.0 produit au contraire une GUI d'aspect aussi mé diocre sur tous les systèmes. De plus, elle est restrictive : on ne peut utiliser que quatre fontes, et on n'a accès à aucun des éléments de GUI sophistiqués disponibles dans son système d'exploitation.Le modèle de programmation de l'AWT Java 1.0 est aussi maladroit et non orienté objet. Un étudiant d'un de mes séminaires (qui était chez Sun lors de la création de Java) m'a expliqué pourquoi : l'AWT original avait été imaginé, conçu, et implémenté en un mois. Certainement une merveille de productivité, mais aussi un exemple du fait que la conception est importante.
La situation s'est améliorée avec le modèle d'événements de l'AWT de Java 1.1, qui a une approche beaucoup plus claire et orientée objet, avec également l'ajout des JavaBeans, un modèle de programmation par composants qui est tourné vers la création facile d'environnements de programmation visuels. Java 2 termine la transformation depuis l'ancien AWT de Java 1.0 en remplaçant à peu près tout par les Java Foundation Classes (JFC), dont la partie GUI est appelée « Swing ». Il s'agit d'un ensemble riche de JavaBeans faciles à utiliser et faciles à comprendre, qui peuvent être glissés et déposés (ou programmés manuellement) pour créer une GUI qui vous donnera (enfin) satisfaction. La règle de la « version 3 » de l'industrie du logiciel (un produit n'est bon qu'à partir de la version 3) semble également se vérifier pour les langages de programmation.
Ce chapitre ne couvre que la bibliothèque moderne Swing de Java 2, et fait l'hypothèse raisonnable que Swing est la bibliothèque finale pour les GUI Java. Si pour une quelconque raison vous devez utiliser le « vieux » AWT d'origine (parce que vous maintenez du code ancien ou que vous avez des limitations dans votre browser), vous pouvez trouver cette présentation dans la première édition de ce livre, téléchargeable à www.BruceEckel.com (également incluse sur le CD ROM fourni avec ce livre).
Dès le début de ce chapitre, vous verrez combien les choses sont différentes selon que vous voulez créer une applet ou une application normale utilisant Swing, et comment créer des programmes qui sont à la fois des applets et des applications, de sorte qu'ils puissent être exécutés soit dans un browser soit depuis la ligne de commande. Presque tous les exemples de GUI seront exécutables aussi bien comme des applets que comme des applications.
Soyez conscients que ceci n'est pas un glossaire complet de tous les composants Swing, ou de toutes les méthodes pour les classes décrites. Ce qui se trouve ici a pour but d'être simple. La bibliothèque Swing est vaste, et le but de ce chapitre est uniquement de vous permettre de démarrer avec les notions essentielles et d'être à l'aise avec les concepts. Si vous avez besoin de plus, alors Swing peut probablement vous donner ce que vous voulez si vous avez la volonté de faire des recherches.
Je suppose ici que vous avez téléchargé et installé les documents (gratuits) de la bibliothèque Java au format HTML depuis java.sun.com et que vous parcourrez les classes javax.swing dans cette documentation pour voir tous les détails et toutes les méthodes de la bibliothèque Swing. Grâce à la simplicité de la conception de Swing, ceci sera souvent suffisant pour régler votre problème. Il y a de nombreux livres (assez épais) dédiés uniquement à Swing et vous vous y réfèrerez si vous avez besoin d'approfondir, ou si vous voulez modifier le comportement par défaut de Swing.
En apprenant Swing vous découvrirez que :
Swing contient tous les composants attendus dans une interface utilisateur moderne, depuis des boutons contenant des images jusqu'à des arborescences et des tables. C'est une grosse bibliothèque mais elle est conçue pour avoir la complexité appropriée pour la tâche à effectuer ; si quelque chose est simple, vous n'avez pas besoin d'écrire beaucoup de code, mais si vous essayez de fairedes choses plus compliquées, votre code devient proportionnellemnt plus complexe. Ceci signifie qu'il y a un point d'entrée facile, mais que vous avez la puissance à votre disposition si vous en avez besoin.
Ce que vous aimerez dans Swing est ce qu'on pourrait appeler l' « orthogonalité d'utilisation ». C'est à dire, une fois que vous avez compris les idées générales de la bibliothèque, vous pouvez les appliquer partout. Principalement grâce aux conventions de nommage standards, en écrivant ces exemples je pouvais la plupart du temps deviner le nom des méthodes et trouver juste du premier coup, sans rechercher quoi que ce soit. C'est certainement la marque d'une bonne conception de la bibliothèque. De plus, on peut en général connecter des composants entre eux et les choses fonctionnent correctement.
Pour des question de rapidité, tous les composants sont « légers » , et Swing est écrit entièrement en Java pour la portabilité.
La navigation au clavier est automatique ; vous pouvez exécuter une application Swing sans utiliser la souris, et ceci ne réclame aucune programmation supplémentaire. Le scrolling se fait sans effort, vous emballez simplement votre composant dans un JScrollPane lorque vous l'ajoutez à votre formulaire. Des fonctionnalités telles que les « infobulles » [tool tips] ne demandent qu'une seule ligne de code pour les utiliser.
Swing possède également une fonctionnalité assez avancée, appelée le « pluggable look and feel », qui signifie que l'apparence de l'interface utilisateur peut être modifiée dynamiquement pour s'adapter aux habitudes des utilisateurs travaillant sur des plateformes et systèmes d'exploitation différents. Il est même possible (quoique difficile) d'inventer son propre « look and feel ».
Un des buts de la conception Java est de créer des applets, qui sont des petits programmes s'exécutant à l'intérieur d'un browser Web. Parce qu'ils doivent être sûrs, les applets sont limitées dans ce qu'ils peuvent accomplir. Toutefois, les applets sont un outil puissant de programmation côté client, un problème majeur pour le Web.
Programmer dans un applet est tellement restrictif qu'on en parle souvent comme étant « dans le bac à sable », car il y a toujours quelqu'un (le système de sécurité Java lors de l'exécution [Java run-time security system] ) qui vous surveille.
Cependant, on peut aussi sortir du bac à sable et écrire des applications normales plutôt que des applets ; dans ce cas on accède aux autres fonctionnalités de son OS. Nous avons écrit des applications tout au long de ce livre, mais il s'agissait d'applications console, sans aucun composant graphique. Swing peut aussi être utilisé pour construire des interfaces utilisateur graphiques pour des applications normales.
On peut en général répondre à la question de savoir ce qu'une applet peut faire en considérant ce qu'elle est supposée faire : étendre les fonctionnalités d'une page Web dans un browser. Comme en tant que surfeur sur le Net on ne sait jamais si une page Web vient d'un site amical ou pas, on veut que tout le code qu'il exécute soit sûr. De ce fait, les restrictions les plus importantes sont probablement :
Si on admet ces restrictions, les applets ont des avantages, en particulier pour la création d'applications client/serveur ou réseaux :
Comme les applets s'intègrent automatiquement dans le code HTML, on dispose d'un système de documentation intégré et indépendant de la plateforme pour le support de l'applet. C'est une astuce intéressante, car on a plutôt l'habitude d'avoir la partie documentation du programme plutôt que l'inverse.
Les bibliothèques sont souvent groupées selon leurs fonctionnalités. Certaines bibliothèques, par exemple, sont utilisées telles quelles. Les classes String et ArrayList de la bibliothèque standard Java en sont des exemples. D'autres bibliothèques sont conçues comme des briques de construction pour créer d'autres classes. Une certaine catégorie de bibliothèques est le squelette d'applications [application framework], dont le but est d'aider à la construction d'applications en fournissant une classe ou un ensemble de classes reproduisant le comportement de base dont vous avez besoin dans chaque application d'un type donné. Ensuite, pour particulariser le comportement pour ses besoins propres, on hérite de la classe et on redéfinit les méthodes qui nous intéressent. Un squelette d'application est un bon exemple de la règle « séparer ce qui change de ce qui ne change pas », car on essaie de localiser les parties spécifiques d'un programme dans les méthodes redéfinies [62].
les applets sont construites à l'aide d'un squelette d'application. On hérite de la classe JApplet et on redéfinit les méthodes adéquates. Quelques méthodes contrôlent la création et l'exécution d'une applet dans une page Web :
| Method | Operation |
|---|---|
| init() | Appelée automatiquement pour effectuer la première initialisation de l'applet, y compris la disposition des composants. Il faut toujours redéfinir cette méthode. |
| start() | Appelée chaque fois que l'applet est rendue visible du navigateur Web, pour permettre à l'applet de démarrer ses opérations normales (en particuliers celles qui sont arrêtées par stop()). Appelée également après init(). |
| stop() | Appelée chaque fois que l'applet redevient invisible du navigateur Web, pour permettre à l'applet d'arrêter les opérations coûteuses. Appelée également juste avant destroy(). |
| destroy() | Appelée lorsque l'applet est déchargée de la page pour effectuer la libération finale des ressources lorsque l'applet n'est plus utilisée. |
Avec ces informations nous sommes prêts à créer une applet simple :
Remarquons qu'il n'est pas obligatoire qu'une applet ait une méthode main(). C'est complètement câblé dans le squelette d'application ; on met tout le code de démarrage dans init().
Dans ce programme, la seule activité consiste à mettre un label de texte sur l'applet, à l'aide de la classe JLabel (l'ancien AWT s'était approprié le nom Label ainsi que quelques autres noms de composants, de sorte qu'on verra souvent un « J » au début des composants Swing). Le constructeur de cette classe reçoit une String et l'utilise pour créer le label. Dans le programme ci-dessus ce label est placé dans le formulaire.
La méthode init() est responsable du placement de tous les composants du formulaire en utilisant la méthode add(). On pourrait penser qu'il devrait être suffisant d'appeler simplement add(), et c'est ainsi que cela se passait dans l'ancien AWT. Swing exige quant à lui qu'on ajoute tous les composants sur la « vitre de contenu » [content pane] d'un formulaire, et il faut donc appeler getContentPane() au cours de l'opération add().
Pour exécuter ce programme, il faut le placer dans une page Web et visualiser cette page à l'aide d'un navigateur Web configuré pour exécuter des applets Java. Pour placer une applet dans une page Web, on place un tag spécial dans le source HTML de cette page [63] pour dire à la page comment charger et exécuter cette applet.
Ce système était très simple lorsque Java lui-même était simple et que tout le monde était dans le même bain et incorporait le même support de Java dans les navigateurs Web. Il suffisait alors d'un petit bout de code HTML dans une page Web, tel que :
Ensuite vint la guerre des navigateurs et des langages, et nous (programmeurs aussi bien qu'utilisateurs finaux) y avons perdu. Au bout d'un moment, JavaSoft s'est rendu compte qu'on ne pouvait plus supposer que les navigateurs supportaient la version correcte de Java, et que la seule solution était de fournir une sorte d'extension qui se conformerait au mécanisme d'extension des navigateurs. En utilisant ce mécanisme d'extensions (qu'un fournisseur de navigateur ne peut pas supprimer -dans l'espoir d'y gagner un avantage sur la concurrence- sans casser aussi toutes les autres extensions), JavaSoft garantit que Java ne pourra pas être supprimé d'un navigateur Web par un fournisseur qui y serait hostile.
Avec Internet Explorer, le mécanisme d'extensions est le contrôle ActiveX, et avec Netscape c'est le plug-in. Dans le code HTML, il faut fournir les tags qui supportent les deux. Voici à quoi ressemble la page HTML la plus simple pour Applet1 : [64]
Certaines de ces lignes étaient trop longues et ont été coupées pour être insérées dans cette page. Le code inclus dans les sources de ce livre (sur le CD ROM de ce livre, et téléchargeable sur www.BruceEckel.com) fonctionne sans qu'on doive s'occuper de corriger les sauts de lignes.
Le contenu de code fournit le nom du fichier .class dans lequel se trouve l'applet. Les paramètres width et height spécifient la taille initiale de l'applet (en pixels, comme avant). Il y a d'autres éléments qu'on peut placer dans le tag applet : un endroit où on peut trouver d'autres fichiers .class sur Internet (codebase), des informations d'alignement (align), un identificateur spécial permettant à des applets de communiquer entre eux (name), et des paramètres des applets pour fournir des informations que l'applet peut récupérer. Les paramètres sont de la forme :
et il peut y en avoir autant qu'on veut.
Le package de codes source de ce livre fournit une page HTML pour chacune des applets de ce livre, et de ce fait de nombreux exemples du tag applet. Vous pouvez trouver une description complète et à jour des détails concernant le placement d'applets dans des pages web à l'adresse java.sun.com.
Le JDK de Sun (en téléchargement libre depuis java.sun.com) contient un outil appelé l'Appletviewer qui extrait le tag du fichier HTML et exécute les applets sans afficher le texte HTML autour. Comme l'Appletviewer ignore tout ce qui n'est pas tags APPLET, on peut mettre ces tags dans le source Java en commentaires :
De cette manière, on peut lancer « appletviewer MyApplet.java » et il n'est pas nécessaire de créer de petits fichiers HTML pour lancer des tests. Par exemple, on peut ajouter ces tags HTML en commentaires dans Applet1.java:
Maintenant on peut invoquer l'applet avec la commande
