Petit aperçu de Java Fx

Anselme

Présentation

Au tout départ il y a eu AWT, qui fût la première bibliothèque  java pour concevoir des interfaces graphique. AWT a ensuite évolué en Swing qui est devenu la voie principale.

En digne successeur de Swing, JavaFX a été conçu pour réaliser des interfaces utilisateurs pouvant s’exécuter sur une large variété de support que ce soit ordinateur, appareil mobile, tv voire même console.

Cette librairie initialement créée en 2008 a beaucoup évolué depuis. Il y a peu cette bibliothèque était utilisable uniquement via un langage de script spécifique et il fallait la télécharger à part. Aujourd’hui Java Fx fait partie intégrante de java 8 et est full java.

Concepts de Base

En JavaFX toutes les applications doivent étendre la classe javafx.application.Application. Cette classe fournit le cycle de vie de l’application tel que le lancement (launch), le démarrage (start) ou encore l’arrêt de l’application (stop). Cela fourni un mécanisme pour les applications java de lancer une GUI JavaFX séparément de la méthode main.

Lors du lancement d’une application java faisant appel à du JavaFX, la méthode main doit appeler la méthode launch de la classe Application. Cette dernière appelle la méthode start que nous aurons préalablement redéfinie.

La redéfinition de la méthode start permet de s’assurer que la création des composants graphiques s’effectuera dans un seul thread. En effet, tous comme Swing l’utilisation de JavaFX est monothread et tous les appels de création ou de modification d’objet graphique doit se faire dans un seul thread, ici le JavaFX Application Thread.

Les éléments graphiques d’une gui JavaFX sont ordonnés dans une hiérarchie de conteneurs. Au plus haut niveau, il y a les Stages (javafx.stage.Stage) qui représentent les fenêtres. Dans ces Stages y sont disposés des Scenes (javafx.scene.Scene) qui contiennent des Nodes (javafx.scene.Node). Ces Nodes peuvent représenter des composants graphiques (tels que les labels, les boutons …) ou d’autres conteneurs (tel que des Panel avec leur stratégie de disposition de composants).

Hello World App

Comme dit précédemment, toutes les applications JavaFx doivent étendre la classe Application. La méthode start ainsi redéfinie créé et agence les composants graphiques.

Les lignes suivantes

créent un Node de type Button et y affecte du texte.

A l’aide de cette clouer, on ajoute au bouton un EventHandler qui appellera la méthode cliqueSurBouton() à chaque clique sur le bouton.

On crée un Node de type BorderPane et on lui ajoute dans la partie centrale le bouton précédemment créé.

Nous créons une Scene à laquelle nous passons en paramètre le Pan crée et les dimensions de la fenêtre. Et nous affectons au Stage, la fenêtre que nous venons de créer.

Nous avons créé les composants à afficher, nous pouvons donc affecter un titre et afficher la fenêtre avec les lignes suivantes :

Pour lancer notre application nous avons juste à lancer la méthode main comme pour tout programme en veillant bien appeler la méthode launch comme suit :

facebooktwittergoogle_plusmail

Bien commencer avec ReactJS

Vivien

ReactJS, on en parle beaucoup aujourd’hui. J’ai voulu voir ce que ça donnait.

Contrairement à Angular, ce n’est pas un framwork JavaScript mais une librairie. Cela induit donc qu’on a pas réellement de structure bien définie pour commencer. C’est d’ailleurs souvent le fouillis sur internet et on trouve de tout. Ce qui est parfois déroutant pour les nouveaux arrivants.
Je vous propose donc un petit “kit” que je me suis composé pour bien démarrer.

Avant de commencer, je pars du principe que vous avez déjà sur votre environnement :
– NodeJS (plus npm) => https://nodejs.org/en/
– Cygwin si vous êtes sur windows => http://cygwin.com/install.html

1- Venant du monde Java, je n’avais aucune connaissance sur comment gérer un projet JavaScript. En java, nous avons Maven que nous configurons via un pom.xml. En JavaScript, il y a npm. Et à la manière de maven, on passera ici par un fichier pour la configuration (Evidemment d’autres outils existent, mais nous utiliserons ici npm). Créez donc un fichier package.json à la racine de votre dossier :

Vous retrouvez dans ce fichier toutes les dépendances nécessaires à notre projet.

La première chose à laquelle je tenais, c’est d’utiliser la nouvelle norme ECMAScript 6. Même si les navigateurs ne la gèrent pas encore, c’est la norme de demain. Et venant du monde Java, je ne peux qu’apprécier cet effort de “typage” qui arrive dans le monde javascript.
Pour cela, nous allons utiliser BabelJS. C’est un outil qui nous permettra de compiler notre code JSX es6 au format es5 aujourd’hui géré par les navigateurs.

2- Configuration de notre projet pour utiliser babel et es6 (es2015) => Créer un fichier .babelrc à la racine

Ensuite, je tenais également à m’éviter les contraintes de lancer manuellement la compilation du code. Pour cela, nous allons utiliser Webpack. C’est un outil qui gère parfaitement la compilation à la volée. Concrètement, à chaque fois que vous sauvegardez un fichier, webpack le compile directement. Vous n’avez plus qu’à rafraîchir votre navigateur pour voir votre modification.
Mais pourquoi s’arrêter là ? Allons plus loin en faisant en sorte que le navigateur se rafraîchisse automatiquement. C’est ce que nous propose React Hot Loader

3- Configuration de webpack => Créer un fichier webpack.config.json à la racine

Ce fichier contient :
entry => Point d’entrée utilisé par notre serveur. Comme nous utilisons webpack-dev-server en mode hot replace, on rajoute les références, puis le fichier de départ (index.jsx)
output => Où seront compilé nos sources
plugins => Les plugins pour notre serveur. Ici le plugin pour recharger notre page à chaud
module => Les modules pour notre serveur. Contient les fichiers à prendre en compte et les loaders à utilisé.

4- Configuration du serveur node qui utilisera webpack => Créer un fichier server.js à la racine :

 

Et nous voilà avec notre configuration terminée. Avec ça vous avez de quoi commencer à développer en ReactJS. Vous trouverez évidemment pleins d’autres tuto sur internet présentant d’autres configurations. Celle-ci présente simplement un point de départ assez complet.

Passons maintenant à un petit “Hello, World!” pour tester notre configuration.
Pour mieux comprendre la suite, je vous invite à regarder le tutoriel Getting Started sur le site de react. Nous allons simplement adapter le code pour utiliser es6.
La première étape est de créer notre page html. Créez donc un fichier index.html à la racine

Ensuite créons un fichier index.jsx que l’on placera dans un dossier src.

Et le fichier App.jsx

Vous noterez la syntaxe qui diffère de ce que vous trouvez sur le tutoriel de React. Nous avons utilisé la nouvelle norme es6.
Maintenant que notre projet est enfin terminé, il ne nous reste plus qu’à essayer.

Dans votre dossier lancer les commandes suivantes :

Ouvrez votre navigateur sur http://localhost:3000. Vous devriez voir s’afficher Hello, world!
Changer maintenant le texte et regardez la magie s’opérer :)

N’hésitez pas à suivre le tutoriel complet dispo ici : https://facebook.github.io/react/docs/tutorial.html. Le challenge reste de développer en utilisant la norme es6 :)

facebooktwittergoogle_plusmail

SWING ou SWT, que choisir ?

Ali

En faisant le tour des projets professionnels Java proposant une IHM, on se rend rapidement compte que l’API la plus répandue est SWING. Lors de mon stage, j’ai dû faire un choix entre SWING et SWT, les deux API Java historiques d’interface graphique. Mais quelle différence y-a-t-il entre les deux ?

OS :
SWING utilise des composants graphiques complètement écrits en Java et donc indépendants de l’OS alors que SWT utilise des composants natifs de l’OS.
On voit déjà que la philosophie de SWING est « write once, run everywhere » quelque soit l’OS alors que pour SWT c’est « write once, test everywhere » ce qui peut apporter plus de charge de tests et de développement.

Portabilité :
Contrairement à SWT, SWING fait partie de l’API standard de Java JS2E. Ainsi pour un projet utilisant SWT, il y a une obligation d’installer les bibliothèques natives et les jars nécessaires dans le système du client.

Performance :
La question sur les performances des deux API est encore sujet à débats. Les composants natifs utilisés par SWT sont plus rapides à charger et offrent une meilleure réactivité aux sollicitations de l’utilisateur. Mais dans le cas d’un grand volume de données, pour SWT, il doivent être copiés dans ces composants natifs, alors qu’en SWING ils sont utilisés directement, ce qui offre à SWING une meilleure performance.

Pour mon stage, le but était de créer un Plugin Eclipse, et d’utiliser les différentes vues de l’IDE pour interagir avec l’utilisateur. Et vu que la libraire graphique SWT fait partie d’Eclipse RCP, notre choix s’est ramené à cette dernière.

facebooktwittergoogle_plusmail

Kata refactoring legacy code chez Ossia

Christian

Le premier kata ossiens s’est déroulé le 11/02/2016. Le thème était refactoring Legacy Code. Je me suis donc retrouvé, développeur .Net, avec une majorité de Java-iste :).

Ce fût une excellente soirée d’échanges autour de nos technologies respectives. J’espère que j’aurais l’occasion de faire un kata en Java la prochaine fois.

La base choisie était le kata TripService de Sandro Mancuso disponible ici sur github.

Les réflexions de la soirée sont disponibles ici sur github : https://github.com/MacReiben/KataOssia-201602.

N’oubliez d’envoyer vos idées pour la soirée du mois prochain !

@ bientôt !

facebooktwittergoogle_plusmail