Erwaege JavaFX Einstieg

Hallo,

ich habe viel Erfahrung mit Swing. Ueber JavaFX hab ich immer nur News-Meldungen gelesen. Am liebsten wuerde ich einsteigen indem ich ein Beispiel-Projekt sehr genau unter die Lupe nehme.

Gibt es vielleicht ein Projekt (z.B. Github) wo man z.B. durch einen guten Gradle Build sowohl fuer Desktop, Android, Browser als auch iOS die Faehigkeiten von JavaFX deutlich sehen kann?

vielen Dank,
sb
 
Gibt es vielleicht ein Projekt (z.B. Github) wo man z.B. durch einen guten Gradle Build sowohl fuer Desktop, Android, Browser als auch iOS die Faehigkeiten von JavaFX deutlich sehen kann?
Dürfte daran scheitern, dass JavaFX in erster Linie für Desktops ist, für den Einstieg dürfte das auch erstmal genug sein.

Für Web und Mobile braucht man jeweils passende Libs, zB JPro oder Gluon Mobile, wir gut die sind kann ich nicht beurteilen.


Hier finden sich einige Beispiele: https://gluonhq.com/developers/samples/, ein paar für Mobile sind auch dabei.
 
Vielen Dank. Ich nehme an du bist nicht extrem tief in JavaFX eingestiegen bzw. nur auf dem Desktop?

Waere toll wenn jemand der einen Gesamtueberblick hat auch nochmal zum Thema JavaFX im Browser bzw. Mobile kommentieren koennte. Ist das Weg dahin Open Source oder muss man bei Gluon und Co. einkaufen (haette ich prinzipiell jetzt nichts dagegen) bzw. macht sich abhaengig wenn deren Support mal eingestellt wird (das waere natuerlich ein Problem)?
 
Ist das Weg dahin Open Source oder muss man bei Gluon und Co. einkaufen (haette ich prinzipiell jetzt nichts dagegen) bzw. macht sich abhaengig wenn deren Support mal eingestellt wird (das waere natuerlich ein Problem)?
Gluon Mobile ist kostenlos nutzbar, allerdings gibts dann Werbung für die volle Version innerhalb der App. JPro kostet sobald man es kommerziell nutzt.



Am ehesten fällt mir zu dem Thema @dzim ein, der kann zu JavaFX immer was sagen.

Hier war Gluon Mobile auch schon mal Thema: https://www.java-forum.org/thema/javafxports-erfahrungen.175167/#post-1107692
 
Puhh...klingt ja nicht gerade verlockend bzgl. Gluon Mobile und JPro. Bin nicht so der Fan von Closed Source...hab mir da in der Vergangenheit mal heftig die Finger verbrannt.
 
Das scheint sehr hilfreich zu sein. Vielen Dank nochmal.

Vielleicht hat @dzim mittlerweile ein paar Updates zu dem Thema die er fuer erwaehnenswert haelt (ist immerhin fast 4 Jahre alt der Thread). Oder vielleicht will jemand Links zu Artikeln posten die das Thema JavaFX auf Mobile und im Browser mal ausfuehrlich im Jahre 2019 beleuchten.
Irgendwie schade, dass es da nicht mehr Aufmerksamkeit gibt, da der Standard-Weg fuer iOS und Android zu entwickeln nun auch nicht gerade super ist und keine Fallstricke hat. Eine plattformuebergreifende Methode waere echt super (CodeNameOne hat glaube ich einen Alternativansatz wobei ich mich da auch nicht so gut auskenne).

Sehr super waere ein Vorschlag fuer 2-3 kleinere bis mittlere Github Projekte die JavaFX auf Mobile beleuchten und wo man ausgiebig rumspielen kann.
 
Eine plattformuebergreifende Methode waere echt super
Das Problem ist, dass sich das Interesse der Massen in Richtung des Browsers als universelle, plattformunabhängige Anwendungsumgebung verschoben hat und das in Zukunft noch verstärkt der Fall sein wird.

Andere Ansätze werden dadurch natürlich in den Hintergrund gedrängt, was nicht ganz unproblematisch zu sehen ist. Es wird auch in Zukunft auf das jeweilige System zugeschnittene Umgebungen brauchen, die durch den "Browser-Shift" zur Nische werden könnten.
 
Das Problem ist, dass sich das Interesse der Massen in Richtung des Browsers als universelle, plattformunabhängige Anwendungsumgebung verschoben hat und das in Zukunft noch verstärkt der Fall sein wird.

Andere Ansätze werden dadurch natürlich in den Hintergrund gedrängt, was nicht ganz unproblematisch zu sehen ist. Es wird auch in Zukunft auf das jeweilige System zugeschnittene Umgebungen brauchen, die durch den "Browser-Shift" zur Nische werden könnten.
Du meinst der Browser wird bald 80% aller Apps abdecken und der Rest ist Nische? Und ist Java damit raus?

Irgendwie war der Trend vor wenigen Jahren ja noch umgekehrt. Wo grosse Browser-basierte Projekte eingestampft wurden weil die "letzten 10%" nicht zu erreichen waren. Ich nenne nur mal Facebook.
 
K

kneitzel

Also meine Sicht darauf ist sehr kritisch. Ich habe mir in der Vergangenheit diverse Möglichkeiten für eine Cross Plattform Entwicklung angesehen und die konnten mich alle nicht begeistern.

a) So toll die Idee auch klingt, dass man da in einer Sprache gleich ganz viel abdecken kann: Das wird in den Details extrem schwer. Es gibt halt unterschiedliche "typische Bedienparadigmen" zwischen Android und iOS. Desweiteren kommt sehr schnell eine höhere Komplexität hinzu, denn man will ja mehr machen als nur eine "Hello World" Applikation und dann kommen Abhängigkeiten hinzu. Oft gibt es da dann fertige Plugins - sonst muss man halt doch wieder mehr oder weniger native Dinge für iOS, Android, ... machen.
==> Hier sind im Detail immer wieder massive Probleme aufgekommen. Ich habe da aber in der Vergangenheit nur Xamarin und Cordova im Detail getestet.

b) Ich würde generell raten, immer auf etwas zu setzen, das Mainstream ist oder wo dies zu erwarten ist. Deinen ersten Link verstehe ich als ein: Heya - das tote Pferd ist doch noch nicht ganz tot. Ja super...

Das JPro ist auch - so ich die Seite auf die Schnelle richtig verstanden habe, lediglich ein "Die Applikation läuft auf Deinem System und die Anzeige ist lediglich im Browser." Das ist keine wirkliche Webentwicklung. Heute sind wir doch deutlich weiter und die Entwicklung schreitet weiter voran. Web-Applikationen, die auch offline funktionieren können und so ... Also evtl. eine Lösung, wenn man JavaFX Applikationen hat und diese irgendwie im Web anbieten will ... aber wirklich gut und durchdacht klingt das nicht, denn ich sehe da einige Dinge, die man vor einem Einsatz auf jeden Fall im Detail prüfen möchte bezüglich Security und so.

Für mich war damals dann die klare Entscheidung:
Native Entwicklung für Android und iOS. Klar: Viel Arbeit, aber man konnte Dinge aus dem Mainstream mitnehmen und es wurde so sehr viel einfacher, Informationen zu gewinnen und die Komplexität war am geringsten.

Auf Grund der Entwicklung derzeit sehe ich aber auch die Web Applikationen weiter im kommen. Und wo native Applikationen benötigt werden, könnte man dann ggf. Electron / Cordova / ... einsetzen. Electron sehe ich als sehr gut platziert im Markt an (Wird von vielen genutzt, ein prominenter Vertreter ist z.B. Microsoft mit Visual Studio Code). Cordova ist die Open Source Lösung hinter kommerziellen Angeboten wie PhoneGap (Adobe). Aber da habe ich auch schon Anbieter gesehen.
(Die sind auch sehr interessant, da diese Build Services anbieten. Also man benötigt nicht mehr auf Zwang einen Mac um iOS Applikationen zu bauen.)

Wenn man derzeit nicht auf eine aktuelle Mainstream Technologie setzen möchte, dann würde ich wenigstens auf einen großen Anbieter setzen. (Ich rate aber explizit nicht dazu! Ich habe da bei Microsoft schlechte Erfahrungen sammeln dürfen ....) So könnte z.B. Flutter von Google eine interessante Variante sein. Unterstützt auch native Dinge und so ....

Aber ich selbst habe für mich halt den Weg, dass ich Server Backends mit Java / JEE / Spring angehe und dann das Frontend mit Vaadin erstellt ist. Wo die Web Applikation nicht ausreicht, da kommen dann halt Android / iOS Applikationen ins Spiel, die dann per REST auf das Backend zugreifen.
==> Aber ich bin auch in der Anwendung stark limitiert. Es geht bei meinen Entwicklungen in erster Linie um Applikationen, die auf Daten basieren. Aber da haben wir ja auch noch nicht weiter über die Art der Applikation gesprochen. Z.B. für Spiele gibt es diverse Engines und so, die auch Multi Plattform sind... (Die sind auch sehr gut, denn da gibt es die Unterschiede in der Bedienung nicht mehr so massiv.)
 
Du meinst der Browser wird bald 80% aller Apps abdecken und der Rest ist Nische? Und ist Java damit raus?
Die erste Frage beantworte ich mal mit einem Ja, wenn wir zu allen Apps nur die zählen, die nicht sowieso schon auf dem Browser laufen. Offline Anwendungen können schon länger entwickelt werden (PWA) und in Zukunft soll das nicht mehr per offenem JavaScript ablaufen, sondern in kompilierter Form (Bytecode) als WebAssembly und damit sprachunabhängig, womit auch die zweite Frage beantwortet wäre. Hier gibt es einen Compiler für Java. Ob sich WebAssembly (oder doch etwas anderes) durchsetzen wird, ist noch offen, aber in meinen Augen ist klar, wohin die Reise geht.
 
Die erste Frage beantworte ich mal mit einem Ja, wenn wir zu allen Apps nur die zählen, die nicht sowieso schon auf dem Browser laufen. Offline Anwendungen können schon länger entwickelt werden (PWA) und in Zukunft soll das nicht mehr per offenem JavaScript ablaufen, sondern in kompilierter Form (Bytecode) als WebAssembly und damit sprachunabhängig, womit auch die zweite Frage beantwortet wäre. Hier gibt es einen Compiler für Java. Ob sich WebAssembly (oder doch etwas anderes) durchsetzen wird, ist noch offen, aber in meinen Augen ist klar, wohin die Reise geht.
Von WebAssembly hoert man ja immer wieder was und auch das Java da mitspielen soll. So richtig kann ich mir aber noch nicht vorstellen wie eine "komplexe Anwendung" damit entwickelt wird und wie der Workflow und die technischen Details aussehen werden. Gibt es schon ernstzunehmende Beispielprojekte die man sich anschauen sollte um einen besseren Ueberblick zu bekommen?
 
Von WebAssembly hoert man ja immer wieder was und auch das Java da mitspielen soll.
Java hat damit gar nichts zu tun. Von der Website, die ich oben verlinkt habe: "WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine." Das läuft also zu Java nicht ganz unähnlich ab, aber das können Dir andere wesentlich besser erklären:
Dort erzählt er auch ein wenig über ernst zu nehmende Projekte (ich denke mal, AutoCAD kann man als ernst zu nehmend bezeichnen...)
 
K

kneitzel

Mit dem Framework oder nur den Komponenten?
Das Framework habe ich eine Zeit direkt genutzt, ehe ich dann nach gewissen Tests auf die Cuba Platform gewechselt bin. Aber da tickt dann Vaadin drunter.

Hatte mir diverse Möglichkeiten angesehen. Angular hatte ich zuerst angesehen, aber da bin ich nicht wirklich mit Spring glücklich geworden (Aber evtl. war ich auch einfach zu ungeduldig - aber ich bin da nicht wirklich zurecht gekommen muss ich gestehen. Bei .Net kenne ich da eine gute Integration aber bei Spring fehlte mir das total.) React war auch noch ein Kandidat, den ich etwas näher betrachtet hatte ...

Ach ja - ganz angefangen hatte ich ohne großes Framwork: Thymeleaf als Template Engine und dann halt DataTables.net (mit dem Editor, den ich mir lizensiert hatte) und Daten dann auch stark per REST in die Tabellen geladen und so ...
 
Zum Thema JavaFX auf mobilen Geräten und Da ich mal erwähnt wurde (und sorry, dass ich im Moment etwas inaktiv bin): Ausser etwas Produktpflege habe ich im Moment nichts zu vermelden. Soweit ich es verstehe, will Gluon mehr oder weniger den gesamten Plugin-Zoo etwas konsolidieren. Ich glaube, das Ziel ist, ein OpenJFX-Plugin für alle Plattformen zu haben und das bisherige javafxmobile-Plugin auszufaden. So hab ich jedenfalls einige der Tweets vom Gluon-Chef und JavaFX-Co-Lead Johan Vos verstanden.
Ich bin anfangs Dezember wieder auf den JavaFX-Days in Zürich, wo u.a. er etwas zum Thema präsentieren wird. Eventuell hab ich dann etwas zu berichten oder es gibt dann zeitnah die Talks auf YouTube oder so. Ich würde dann vielleicht mal einen separaten Thread zum Thema verfassen.
Momentan bin ich zwar auf Mobile unterwegs, aber mit Dart/Flutter, statt JavaFX.
 
Nachtrag: die JPro-Leute präsentieren wohl auch wieder, aber die sind etwas chaotisch (waren sie jedenfalls letztes Jahr). JPro läuft wohl ganz gut mit all den verschiedenen Platformen (also dass man eine App für Desktop, Mobile und Web erstellen kann), solange man im Mobile-Bereich Gluon-Charm nicht braucht. Das scheint im Moment JPro wohl nicht so gut hinzubekommen.
 
K

kneitzel

Ich möchte da auch noch kurz etwas zu schreiben. Heute hatten wir von der Abteilung eine nette Versammlung, im Rahmen dessen es einen interessanten Einblick in ein Projekt gab, welches von einer Gruppe durchgeführt wurde:

Bei den Aussagen des UXUI Experten fand ich das Vorgehen interessant ... wie die da die ganze Bedienung vorab planen, damit ‚spielen‘ und was da alles berücksichtigt wird. Da waren dann auch ganz klar die Vorgaben von Apple bezüglich iOS Bedienung/Aussehen sowie das Gleiche auf Android Seite von Google. Ich werde morgen schauen, ob ich da noch Aussagen bezüglich Multi Platform Frameworks bekommen kann (die waren halt nie im Fokus), denn der Kollege hat in dem Bereich halt viel Erfahrung und kann da evtl noch eine Einschätzung geben ....

Da im Projekt war aber dann jeweils native Android und native iOS Entwicklung (mit jeweils einem nem Entwickler mit Erfahrung in dem Bereich). Die Hauptarbeit war aber im Backend Bereich (mehrere Microservices mit RabbitMQ als Bus dahinter und so) ...

Das ist also eine Herangehensweise, wie ich sie jetzt gesehen habe .... vielleicht gibt es da morgen Abend etwas mehr zu ....
 
Ich habe mal die JavaFxPorts und Gluon Samples durchgespielt. Erstere sind super simpel und der build ist meistens broken - man muss rumspielen dann lief das Meiste.

Die Gluon samples - kommerziell - sind deutlich komplexer und der build ist auch nicht broken. Leider ist die Performance super mies. Auch die GluonVM samples (mit der VM soll alles schneller sein) waren sehr zaeh. Ich habe auf einem Nexus4 getestet - mit Absicht, weil ich sehen wollte wie es da performed. Mit meinem S9 ist es bestimmt akzeptabel schnell aber wenn es auf dem N4 so grottenlahm ist (Start und Bedienung), dann lass ich erstmal die Finger davon. Schade eigentlich...sah nett aus :(
 
Krass ist der Unterschied Android <-> iOS - wenn es erst mal läuft, rennt es auf iOS wie blöde!

Das Nexus 4 ist defintiv nicht mehr ein Target. MinSDK bei neueren Versionen des Plugins is API Level 24 (also Android 7). Auf unserem Nexus 5 (das aber auch mit Flutter schon langsam läuft) ist es auch kein Spass mehr. Bedenke einfach: Altes Gerät und fragmentierter Speicher = kein Vergnügen, egal mit welchem Framework.

Demnächst (was auch immer das bedeutet) soll auch für Android ein Preview der neuen und auf GraalVM aufsetzenden Variante folgen. Es soll wohl Java(FX)-13-Code fit für Android und iOS (und natürlich auch Desktop) machen.
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben