[Scene] Agencement et architecture

Salut à tous,

Je commence à cerner le principe de JavaFX mais quelque chose reste en suspens dont je ne trouve que peut d'information.

Comment se déroule la vie de l'application JavaFX avec les objets Stage, Scene et root ?

La stage ne change jamais car elle représente la fenêtre dans le système host ou ce trouve la JVM ?

Il y a une unique Scene par application ? Dans ce cas nous devons conserver un objet root continuellement présent à l'écran et qui ne peut pas changer ?


Ainsi j'ai bien compris quels sont les objets de JavaFX mais ce que j'ai du mal à cerner c'est comment ces éléments vont vivre et mourir dans la cinématique de l'application ? Comment procéder pour concevoir architecturalement parlant nos différents écran de l'application, quel root, scene ou stage ?


En vous remerciant de votre éclairage.

Désolé je suis un peu surchargé ces dernières semaines et donc je ne vais pas faire une réponse trop longue.

Normalement oui une application a un Stage qui lui est fourni au démarrage via la méthode start() par l'API. Ce stage peut-etre une fenêtre ou une zone d'Applet dans un navigateur selon comment l'application fonctionne (pas trop testé les Applets avec JavaFX 2.x, mais en 1.x c’était ainsi). On peut aussi créer des Stage et Window satellites plus ou moins modaux puisqu'on peut chainer les Stage entre eux et changer leur décoration, ça permet de faire des boites de dialogue a l'ancienne (c-a-d dans des fenêtres séparées).

Le Stage a une Scene. Cependant cette dernière peut être changée a volonté mais j'ai cru comprendre sur les forums OTN qu'il y avait quelques bugs (probablement des gens qui oublient de déconstruire leur scène avant de la virer).

La Scene a un noeud racine, souvent un AnchorPane ou un BorderPane. Donc une autre manière de changer le contenu de la fenetre est de changer le root de la scène... ou alors on peut aussi changer le contenu du root de la scene (quand on sait de quel type il est on peut facilement faire un ((AnchorPane)scene.getRoot()).setAll(...). Personnellement je préféré cette méthode d'autant plus qu'avec un AnchorPane on peut facilement faire des boites de dialogue "soft" (c-a-d juste sans créer de fenêtre*, juste en rajoutant un noeud qui recouvre toute la surface actuelle de l'app).

*Créer une fenêtre dans un cadre d'utilisation mobile, touch, fullscreen ou Applet c'est pas génial. A noter que FileChooser et DirectoryChooser ouvrent hélas des fenêtres séparées.

Grosso modo, tu vas définir tes différents écrans dans des classes qui étendent Region ou AnchorPane ou dans des FXML+Controller séparés et tu vas changer le contenu du root de la scène lorsque tu changes d’écran. Tu peux aussi faire des animations / transitions comme ça (chose pas faisable si on change la scène ou si on se contente de changer le root de la scène).

Salut Bouye,

Qu'est ce que tu entends par des Stage et Window satellites plus ou moins modaux ?

On peut donc gérer plusieurs scene dans un Stage ok mais comment tu déconstruit une scene avant d'en placer une autre dans le Stage ? et que fait un AnchorPane)scene.getRoot()).setAll au juste ? J'ai cherché setAll dans l'API doc Javafx et n'ai rien trouvé pour la classe scene et parent.

Dans un cadre mobile on ne passe pas par un Stage alors ?

En tous cas merci pour ces précisions bien plus parlantes que d'éventuels tuto certes utiles mais pas vraiment très précis. D'ailleurs à quand un éditeur pour publier un livre référence en la matière..... Je sais qu'Oracle à quand même des explications en ligne de bonne facture (ormis d'éventuels spécifications soporifiques).

Des boites de dialogue tout simplement :

Code:

---

1 2 3 4 5 6

Stage palette = new Stage(): palette.setScene(anotherScene); palette.initStyle(StageStyle.UTILITY); palette.initModality(Modality.APPLICATION_MODAL); palette.initOwner(mainStage); palette.show();

---

Pour déconstruire une scène :

Code:

---

1 2 3 4

Scene oldScene = mainStage.getScene(); mainStage.setScene(null); // or the new scene. ((AnchorPane)oldScene.getRoot()).getChildren().clear();

---

Pour le reste c'est à toi de déconstruire ta scène en profondeur en ajoutant les méthodes qu'il faut à tes composants customs (moi je mets toujours une méthode nommé dispose() à cet effet), ce qui suppose non seulement nullifier les références des composants qu'on ne veut pas garder, mais aussi faire des unbind() sur les propriété ou encore retirer les listeners enregistrés sur les contrôles, propriétés FX ou Java Beans. On en profitera également pour arrêter toutes Timeline, Transition , Service ou autre background Thread en cours d’exécution tant qu'à faire.

Un moyen de se simplifier la vie avec les listeners est d'utiliser des WeakChangeListener et des WeakInvalidationListener (il faut penser à conserver des références sur les listeners "hard" qui ont servi à créer les listeners "weak" sous peine qu'ils soient garbagés trop tôt). Tous ces points ont été soulevés récemment dans des discussions sur les forums OTN.
Richard Bair a rajouté que les composants de base de l'API utilisent principalement des listeners "weak".

Le fait de devoir casser/nullifier les références est un piège classique de Java : on ne peut pas libérer la mémoire explicitement mais le garbage collector n'étant pas assez efficace (coté client en tout cas), il faut faire ce qu'on peut pour nullifier à tout va (ce qui revient au même en fait).

Pour le mobile c'est assez vague pour le moment (faute de JVM et outils dispos pour FX) mais dans le cas de Java Embedded (Raspberri Pi etc.) on s'en rapproche. Ces périphs ont peu de puissance et de mémoire, créer des fenêtres séparées (au lieu de simuler des fenêtres avec des noeuds) demande plus de mémoire. De plus certaines plateformes peuvent ne pas supporter plus d'une fenêtre active à la fois par application.

Dans le cadre d'Applets, on peut ne pas vouloir ouvrir de fenêtre hors de la surface du navigateur (c'est pour ça que c'est dommage que FileChooser et DirectoryChooser ne proposent pas un mode "soft" et se contentent d'ouvrir des boites de dialogue natives).

Pareil pour les applications en plein écran.

N'oublie pas que le stage t'es fourni tout près par la méthode start(). Ce n'est pas forcément une fenêtre comme dans les OS destop. En Applet et sur JavaFX 1 c'était tout bêtement la zone du navigateur dans laquelle l'Applet s'affiche. Ça impliquait plusieurs chose :
- elle est déjà visible et ne peut pas être cachée (sauf si en implémentant des interactions en JavaScript entre la JVM et le navigateur).
- on ne peut pas faire close() dessus (on peut juste provoquer le changement de page du navigateur).
- on ne peut pas l’agrandir ou la réduire (idem JavaScript).
- le seul moyen de la passer en plein écran était de faire une Applet signée.
- tout autre Stage créé et attaché au premier (JFXtras 1.x proposait une implémentation de Dialog) était une boite de dialogue séparée mais liée à la fenêtre du navigateur.

@Bouye tu ne voulais pas parler de addAll() au lieu de setAll() lorsque tu as dit AnchorPane)scene.getRoot()).setAll

Citation:

---

Envoyé par bouye

En Applet et sur JavaFX 1 c'était tout bêtement la zone du navigateur dans laquelle l'Applet s'affiche.

---

En tout c'est aussi la même chose en JavaFX 2.x j'ai travaillé sur quelques Applets.

Non j'ai bien parlé de ObservableList<E>.setAll(E... elements)

Le problème du addAll() c'est bien sur que ça conserve dans la scène ce qui était dedans avant.

Par contre, j'ai oublié le getChildren() comme souvent. En même temps, c'est implicite, vu qu'en FX2 on a généralement pas de méthodes d'ajout directement sur les conteneurs.

Après, évidement, si on fait des animations/des transitions pour le changement d’écran/de noeud, c'est bien add()/addAll() qu'il faut utiliser mais il faut bien penser a retirer l'ancien noeud une fois l'animation/la transition finie.