Discussion :

[SoeurRoberte]

Bonjour à tous et à toutes,

Je travaille actuellement sur un projet en javaFX lié à la pédagogie pour une ESC. Celui-ci consiste en la réalisation d'un lecteur multimédia. Ce lecteur doit être capable de lire une vidéo tout en affichant des diapositives (issues de ppts) illustrant les propos de l'interlocuteur. De plus, il y a un(/une ?) slide sous la diapo qui représente l'avancée des diapos et offre la possibilité d'avoir un aperçu des diapositives suivantes/précédentes.

Voici mon soucis (enfin MES soucis) :

- Je rencontre des difficultés à lire une vidéo autre qu'un flv standard, enfin autant dire que je n'y arrive absolument pas.
(un simple "MediaPlayer mediaplayer = new MediaPlayer(new Media(<MEDIA_URL>));")

- Niveau portabilité, je pensais embarquer le java runtime au projet, mais je ne sais comment faire (si c'est possible).

- Installer la sdk android pour netbeans pour porter mon appli sur tablette android. J'ai lu qu'il avait été fait une démonstration de javaFX sur tablette android et sur ipad, est-ce toujours possible ?

Il vous manque peut-être des précisions pour pouvoir me répondre, alors je suis tout ouïe.

[bouye]

Salut

1. Je ne peux pas trop t'aider de ce cote-la. Le mieux serait d'aller voir la FAQ et les spécifications de JavaFX sur le site officiel et ensuite de faire des recherches (d'autres l'ont posée avant toi) et de poster une question a ce propos (en anglais) sur le forum OTN de JavaFX.
2. Oui, c'est possible mais pas forcement aise :
   
   • il te faut un launcher natif, il existe des outils payants, gratuit ou alors si tu fais tu C++, C# ou VB.NET tu peux le créer toi-même.
     Avec JavaFX 1.x j'utilisais Launch4J mais j'ai quelques problèmes avec pour JavaFX 2.x et donc j'utilise WinRun4J a la place pour le moment.
   • Packager la JVM dans un des sous-répertoires de l'application. Cependant la JVM pèse son poids et il faut faire un peu de nettoyage, ; il faut aller lire dans la licence de redistribution de la JVM chez Oracle pour savoir quel fichiers conserver et lesquels tu peux virer (il faut conserver entre autres tous les fichiers README et ceux contenant les licenses). Après il faudra tester un peu au petit bonheur la chance pour savoir quel DLLs et JAR tu peux virer ; pour les exécutables c'est assez facile au contraire. Comme tu voudra redistribuer probablement sur m'importe quelle machine Windows, tu packageras sans doute la JVM 32bit.
   • Packager les runtimes Windows 32bit de JavaFX dans un autre sous-répertoire. La aussi suivant ce que tu utilises ou pas tu peux faire le ménage (ex : WebPaneJava.dll qui pèse 10Mo inutile si tu n'utilises pas WebPane).
   • Mettre les JAR et DLLS/lib de ton app dans un 3eme répertoire.
   • bien configurer ton launcher (Launch4J c'est dans l’éditeur de config, WinRun4J c'est dans un fichier ini) pour qu'il lance la JVM embarque, mette tous les JAR de ton app ainsi que jfxrt.jar dans le CLASSPATH et ensuite lance la classe de ton application (ou la classe launcher de l'API JavaFX mais ça marche pas a tous les coup dans mes tests).
   
   Ensuite, il existe certaines apps payantes qui permettent de faire ça plus aisément notamment pour ce qui est de la cure d'amaigrissement de la JVM et aussi de faire des installeurs par la même occasion. Dans son article "Packaging JavaFX Applications as Native Installers", Jasper Potts mentionne qu'il utilise Install4J (qui n'a pas un coût négligeable hélas).
3. C'est théoriquement possible et il y a surement quelques chose en interne chez Oracle qui permet de le faire mais pour le moment rien n'a été rendu publique et donc il ne faut pas espérer grand chose de ce cote la (en tout cas venant d'Oracle) d'autant plus que le démarrage du procès entre Oracle et Google n'arrange pas les choses.
   Dans le principe ce n'est pas super éloigné de ce que j'ai expliqué plus haut et ça revenait a packager la JVM en tant que lib/dll d'une app et a utiliser un launcher natif. Par contre, il faut une version des runtimes de JavaFX (notamment de la partie Glass) pour Android et ca tant qu'Oracle ne les publie pas c'est pas gagne (idem pour iOS). Pour Windows Mobile x86 c'est un peu plus facile car les runtimes Windows desktop fonctionnent directement sur Windows Mobile (en théorie).

[Limack]

Bonjour Tous,

Ce sujet m'intéresse vraiment parce que j'ai justement le problème de faire tourner mon application javafx2.0 sur une autre machine qui n'a pas les librairies requises. Alors, je vais suivre les conseils de bouye décris ci-haut pour voir si je peux arriver à quelque chose.
Bonne suite!

[bouye]

Voila ce que ça donne chez moi (avec WinRun4J donc).

• racine -> launcher exécutable (renommer le launcher fourni par WinRun4J et lire la doc pour savoir comment lui mettre une icone) & fichier ini
• bin -> le contenu du repertoire dist de mon app genere par NetBeans
• jfx -> une copie des runtimes JavaFX 32bit Windows (actuellement pour les test une copie de la 2.1 beta 18 ou 19, a remplacer par la version finale quand elle sortira - on a pas le droit de redistribuer les runtimes beta il me semble).
• jre -> une copie du JRE 1.7.0_04 beta qq chose (idem a remplacer plus tard par la version finale).

Code TUMAS.ini :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
classpath.1=bin\TUMAS-j.jar
classpath.2=jfx\lib\jfxrt.jar
classpath.3=bin\lib\*.jar
 
main.class=org.spc.ofp.project.tumas.TUMAS
 
vm.version.min=1.7
vm.location=jre\bin\client\jvm.dll
vm.heapsize.preferred=512
 
log=TUMAS.log
log.overwrite=true

A noter que je n'ai pas encore fait la cure d'amaigrissement de la JVM ou de JavaFX faute de temps pour bien tout tester.
Ainsi :

• racine = 250ko
• bin = 7.3Mo
• jfx = 28.2Mo
• jre = 86.5Mo

Peut mieux faire !

Et comme je suis occupe sur une autre tache importante ces derniers temps, je n'ai pas pu finir mes tests (entre autre vérifier que tout se lance bien sur une machine sans Java ou sans JFX).
Ensuite je comptais packager le tout dans un installeur NSIS.

[Limack]

Voila ce que ça donne chez moi (avec WinRun4J donc).

• racine -> launcher exécutable (renommer le launcher fourni par WinRun4J et lire la doc pour savoir comment lui mettre une icone) & fichier ini
• bin -> le contenu du repertoire dist de mon app genere par NetBeans
• jfx -> une copie des runtimes JavaFX 32bit Windows (actuellement pour les test une copie de la 2.1 beta 18 ou 19, a remplacer par la version finale quand elle sortira - on a pas le droit de redistribuer les runtimes beta il me semble).
• jre -> une copie du JRE 1.7.0_04 beta qq chose (idem a remplacer plus tard par la version finale).

Code TUMAS.ini :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
classpath.1=bin\TUMAS-j.jar
classpath.2=jfx\lib\jfxrt.jar
classpath.3=bin\lib\*.jar
 
main.class=org.spc.ofp.project.tumas.TUMAS
 
vm.version.min=1.7
vm.location=jre\bin\client\jvm.dll
vm.heapsize.preferred=512
 
log=TUMAS.log
log.overwrite=true

A noter que je n'ai pas encore fait la cure d'amaigrissement de la JVM ou de JavaFX faute de temps pour bien tout tester.
Ainsi :

• racine = 250ko
• bin = 7.3Mo
• jfx = 28.2Mo
• jre = 86.5Mo

Peut mieux faire !

Et comme je suis occupe sur une autre tache importante ces derniers temps, je n'ai pas pu finir mes tests (entre autre vérifier que tout se lance bien sur une machine sans Java ou sans JFX).
Ensuite je comptais packager le tout dans un installeur NSIS.

Salut bouye,

Actuellement, mon application javafx se connecte à une base de données Java db. Les fichiers de cette base de données sont dans un repertoire, lui-même à la racine de mon application.
Ma crainte est que lors du «build», il ne génère pas ce repertoire, ce qui semble être normal.
Comment faut-il embarquer la base de données avec cette application?
Ou bien, il faut copier le répertoire à part et l'exécutable à part?
Si tu as déjà eu à le faire, ça me serait d'une aide.
Merci.

[bouye]

En fait la tu n'a qu'un launcher, rien n'est packagé. Ça, ça sera l’équivalent du répertoire que tu auras sur le disque dur de ton client une fois l'app installée.

WinRun4J ne génère pas de launcher (on prend celui existant, on le renomme ou le modifie -pour y inclure une nouvelle icone-, le reste est fait par modification du fichier ini).
Le launcher de Launch4J ne package pas grand chose a part le JAR principal quand sa GUI cree l'exe (et même ça on peut lui dire de ne pas le faire et de conserver le fichier a cote et de créer un exe ultralight qui se contente de modifier le CLASSPATH et de lancer la JVM qui se trouve dans le sous-rep exactement comme celui de WinRun4J).

Donc désormais il faut créer un installeur qui packagera le tout et se chargera de le décompresser au bon endroit, d'inscrire ce qu'il faut dans la base de registre si nécessaire et enregistrer les type de fichiers si besoin.
C'est avec NSIS qu'on voit ça puisque c'est lui sert d'installeur (dans mon cas). Dans NSIS on décrit quels fichiers et répertoires sont a inclure dans l’installeur a générer.
Donc tu peux y inclure le répertoire de ta base qui sera décompressé au même endroit que ton app. Ensuite a voir dans la doc du launcher s'il est possible de spécifier le répertoire d’exécution de l'app (j'ai pas trop regardé ça puisque moi j'utilise un répertoire dans mes documents - que l'app régénère s'il est absent- pour mes données -qui ne sont pas dans une base-).

Un générateur de launcher natif payant plus complexe et avec plus de fonctionnalités serait probablement capable de déguiser tout ça dans des fichiers quelconques pour éviter que n'importe qui puisse aller y fouiller.