JavaFX 8 vagy Qt desktop + mobil fejlesztéshez?

Java

Most nézem, a JavaFX egész jó úton halad mostanság, már ami a feature listát illeti.

Nekem leginkább desktop és mobil alkalmazások fejlesztésére kéne valami cross-platform megoldás, leginkább csak saját igények kielégítésére. Qt jó lenne, de irgalmatlan mennyiségű dolgot kellene megtanulni hozzá, ami persze jó, de ha lehet, egyelőre kihagynám. JavaFX-ből viszont egyelőre hiányzik a mobil támogatás (Android, iOS).

Esetleg tudtok olyat, ami tud natív look&feel-t mobilon (+ desktopon) (vagy ha nem natív, legalább az alap téma nem szörnyű), Java, Ruby, Python (esetleg JS, de inkább ne) a nyelv és lehetőleg elérhető ingyenesen?

Köszi!

http://en.wikipedia.org/wiki/JavaFX#JavaFX_8

  • 9955 megtekintés

( sz332 v | 2014. 11. 06., cs – 18:19 )

Szia,

Egy megoldás, hogy csinálsz egy közös szerver oldali felületet, és eléhúzod az UI-t, amit aztán olyan nyelven implementálsz, amiben akarsz.
Ennek egy variációja, hogy webes frameworköt használsz, aminek van mobilos változata. Példák SmartGWT, angularjs, kendo (ez fizetős), sencha touch, etc.

http://moduscreate.com/5-best-mobile-web-app-frameworks-sencha-touch/

De akár a javafx2 is jó lehet, igazából ilyenkor jön a próbáljuk ki és meglátjuk történet...

Én magam támogatom a HTML5-öt JS-sel (bármennyire is utált nyelv legyen), abban egyet tudok értni, hogy html alapú "mobil appokat" ebben a formában, jelenleg nem érdemes fejleszteni. Amellett, hogy kimértem, s lassú, megbízahatatlan, még szól maga a Facebook alapítójának mondata, mieszerint "Our Biggest Mistake Was Betting Too Much On HTML5"... A piac nem szereti, a fejlesztők nem imádják. Ennyi. Ma, ez halott (talán a jövőben megváltozik)

Jelenleg mobilra - sajnos - csak a natív fejlesztést tartom elképzelhetőnek, és kellően hatékonynak. Ha valami nagyon durva ui-t vagy üzleti logikát (amit úgysem, mert az ugye "szerveroldali") implementáltok, akkor előbb javasolnám a(z akár) JNI-s libet...

Amúgy Qt-nak van valami reklámozott megoldása, de őszintén szólva... kihagyni a - most már - többmilliárd konzisztens UI-ra vágyó usert csak balgaság.

( sunmao v | 2014. 11. 07., p – 10:29 )

Úúú nagyon örülök ennek a topic-nak, két okból is.

1, Pont most gondolkodom azon, hogy le kéne cserélni a Swing app-jainkat amik a terminálokon (normális PC) futnak.
2, Mi is most fejlesztünk egy Cordova app-ot, Angular alapokon. Sajnos azt kell mondjam, hogy a plugin-ok megbízhatatlanok és kaotikusak. A WP8 kompatibilitás meg katasztrófa. Szerintem az mindent elárul, hogy míg Android-ra ott a Chrome, IOS-re ott a Safari, addig WP-re nincs mód arra, hogy debuggold a telefonra deployolt JavaScript app-ot. Illetve egyetlen megoldást találtam a neten, de a debugger is olyan volt, hogy előtte azt kellett debuggolni, hogy működjön a dolog.

Ami számomra inkább érdekes most az az 1. pont.
Én valami olyasmire gondoltam, hogy egy browser-ben futó HTML5 app-ra cserélném le a Swing-es megoldást. Ezek az egyes terminálklienseken standalone programként futnának, mint egy rendes kliensszoftver. Csak még arra nem jöttem rá, hogy hogyan lehet megoldani, hogy a browserben futó app egy HTTP szerver is legyen egyben, mert a Swing program is úgy működik, hogy várja a szervertől a requesteket és aztán váltja a screen-t. Illetve van amikor ő küld adatot a szerver felé, tehát kétirányú a kommunikáció. Szerintem minden X másodpercben pingelni a szervert, hogy van-e új state, az nem egy szép megoldás.
Ha erre van ötletetek, vagy működő megoldásotok akkor ne tartsátok vissza.

Mivel mi Spring-ezünk, ezért legelsőnek azt néztem meg, hogy hogyan lehetne Spring-el megoldani ezt a WebSocket dolgot. A Spring 4 már támogatja a WebSocket-eket.
Viszont a példákat elnézve nem nagyon értettem meg az elvet. Az összes leírásban az van, hogy setup-olj fel egy Spring Controller szerű valamit, mappold fel az URL-eket és ha jön a WebSocket request, akkor majd megy rá a válasz. Hát ez eddig is ment, WebSocket nélkül is...

Hol van az a rész mikor mondjuk a business logic-ból jön egy event és azt akarom mondani, hogy akkor most az XY azonosítójú WebSocket váltson state-et?
Szóval azt a részt nem értem mikor én szólítom meg a browser oldalt, anélkül hogy a browser bármit is csinált volna...

Itt az egyik példa amit néztem.

A websocket az lényegében pont úgy működik, mint egy tcp/ip socket kapcsolat, és kb. pont ugyanazt nyújtja. Nálunk ez úgy néz ki, hogy van egy szerver, amihez tcp/ip-n lehet kapcsolódni, és a bináris adatok asn.1 enkódolva mennek. Eddig egy swing-es kliensünk volt, ami csatlakozott a szerverhez. Ezt most lecseréltük egy olyan kombinációra, hogy van egy előtét appunk, ami a szerverhez csatlakozik, és lényegében egy standard socket - websocket proxy, és a kliensünk pedig ennek a proxynak a websocket lábához. Mivel GWT-ben fejlesztünk, ezért elég könnyen át tudtuk venni az eddig is meglévő logikánkat, illetve az asn.1 osztályokat, így a kódunk egy része simán közös tudott maradni. A logika a szerver oldalon van lekódolva, a kliens felé csak kb. annyit küld, hogy itt vannak ezek a panelok, jelenítsd meg őket, ahogy tudod, a kliens felől pedig utasítások jönnek: erre meg arra az elemre klikkelt, stb.

A websocket előnye, hogy egy kétirányú kapcsolatod van, tehát nincs polling, meg ilyesmi, csomagok jönnek és mennek, annyi extrával, hogy biztosítva van, hogy a csomag egyben érkezik meg, nem pedig darabokban.

Igazából jó lenne tudni, hogy nálatok mi a logika, úgy jobban el lehetne dönteni, hogy ez-e a jó irány számotokra, vagy valami más.

A logika nagyon hasonló (pont az) ahhoz amit te leírtál.

Van egy JBoss-on futó Java app és van több kliens PC (terminál) amiken egy Swing app fut. A termináloknak nincs saját businesslogic-juk, csak simán mutatják a "paneleket" és ha kapnak a szervtől egy requestet akkor panelt váltanak. Illetve ha a user megnyom egy gombot a kliensen oldalon akkor azt elküldjük a szerver felé.

Ezt a Swing appot szeretném esetleg átköltöztetni browserbe (először csak úgy magamnak PoC szinten) és JS+HTML5-el megoldani. Csak ugye a Swing app amikor elindul, akkor indít egy kis HTTP szervert is, amit a browserből nem tudok megoldani. Erre lenne megoldás a WebSocket, csak nem tudom, hogy hogyan lehet a WebSocketet Spring MVC-vel vagy REST szerűen megoldani.

Köszönöm a példákat!

A fentebbieken felbátorodva, feldobtam egy IntelliJ-t (életemben nem használtam eddig) és összeraktam egy HelloWorld-ot Java 7-el meg Wildfly 8.1-el, meg EJB-vel (egyik el sem volt még dolgom :)).

Sok mindent megértek azért, de a Spring-es XML-ben injektálunk, meg *-servlet.xml routolunkhoz képest eléggé más világ, plusz egy hotkey-t sem ismerek az IntelliJ-ben, de már annyira untam a munkahelyi tool-okat, hogy valami izgalmast akartam.

Na a lényeg, hogy mutattad ezt a két osztályt és amit nem értek, hogy miért vannak ezek a class-ok a backend package-ben, mikor ezek az osztályok az én értelmezésemben olyanok mint a frontend controllerek, tehát ők csak elkapják a requestet/websocket kommunikációt (mondjuk DTO-ba csomagolják ha kell) és tovább dobják a backendnek.

Illetve egy EJB kezdő kérdés: A Service/Manager oldalon megértem, hogy miért van szükség a Stateless annotációra, de a frontend class-okban mit szolgálnak, nem elég ha nem definiálok global variable-t? Illetve mi történik, ha elhagyom ezeket az annotációkat?

"Sok mindent megértek azért, de a Spring-es XML-ben injektálunk, meg *-servlet.xml routolunkhoz képest eléggé más világ,"

Nincs XML. Néhány annotáció van csak. :)

"Na a lényeg, hogy mutattad ezt a két osztályt és amit nem értek, hogy miért vannak ezek a class-ok a backend package-ben, mikor ezek az osztályok az én értelmezésemben olyanok mint a frontend controllerek, tehát ők csak elkapják a requestet/websocket kommunikációt (mondjuk DTO-ba csomagolják ha kell) és tovább dobják a backendnek."

Mert a frontend az vagy natív mobil alkalmazás vagy egy Javascript-es MVC... mostanság már nem szokás olyan frontend-et készíteni, amelynek egy része a szerveren fut.

"A Service/Manager oldalon megértem, hogy miért van szükség a Stateless annotációra, de a frontend class-okban mit szolgálnak, nem elég ha nem definiálok global variable-t?"

Ezt most nem teljesen értem. :)

"Illetve mi történik, ha elhagyom ezeket az annotációkat?"

Nem fog működni.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( kisg v | 2014. 11. 07., p – 14:54 )

Amennyiben az Android + iOS platform a cél, akkor Java alapú keresztplatformos fejlesztésre több megoldás is van.

Az egyik ilyen a Migeran, amit mi fejlesztünk (full disclosure!).

Az első nyilvános verziónkat a hétvégén fogjuk kiadni. Emellett december elejéig a teljes platformot nyílt forráskódúvá tesszük.

Az Android ART runtime-ot portoltuk iOS-re, közben továbbfejlesztettük az ART debuggerét is, amely mergelés előtt áll a hivatalos Android forrásba. (Kis kitérő: bizonyos esetekben az ART debugger "step over" művelete 10 - 30 percig tartott. Ezt sikerült a normális <1s tartományba lenyomni.)

Persze az ART önmagában csak egy VM. A Migeran a teljes iOS API-t hozzáférhetővé teszi, egy új Java to native library, a Nat/J segítségével. A fő különbség a többi hasonló eszközhöz képest, hogy a Nat/J Generator segítségével nem kézzel kell ezeket a bindingokat karbantartani, hanem automatikusan generálódnak. Természetesen kézi kiegészítésekre is van lehetőség, ezeket a generátor nem módosítja.

A Java nyelv mellett a Scala-t is támogatjuk, de bármilyen Android ART-on működő nyelvet lehet használni. A Gradle-t használjuk buildeléshez, jelenleg Eclipse IDE-be integrálódunk (pl. speciális code assist az objective-c specifikus funkciókhoz, futtatás, debuggolás), de az Intelli/J-t is tervezzük támogatni.

Sok nem triviális projektben előkerül, hogy bizonyos részeket natív eszközökkel kellene fejleszteni, vagy meglevő natív komponenseket felhasználni. A Migeran esetében ez nagyon kényelmesen működik: a natív komponenseket fejlesztheti Xcode-ban, amit a Nat/J segítségével
elérhetővé lehet tenni Java-ból.

Még sokat írhatnék, de már így is elég hosszú lett.

Meg kell említenem két másik lehetőséget is:
1. Codename One: Egy Swing szerű, keresztplatformos API-t készítettek, ami működik sok platformon. iOS-re korábban XMLVM-mel fordítottak, most egy új saját VM-en dolgoznak, ami még nem nyílt forrású. Az üzleti modelljük cloud alapú fordításra épül: elküldöd nekik a forrást, kapsz vissza kész appot. Van egy Java SE alapú szimulátoruk, amivel bármilyen platformon fejleszthetsz, de a célhardveren hibakeresés, illetve a natív kódok integrálása nem egyszerű.

2. RoboVM: Saját Ahead of Time VM LLVM-re építve, nyílt forrású projekt. Dolgoznak az iOS API támogatáson, részben készen van. Jelenleg nincs debugger támogatásuk, bár igérik, hogy lesz.

A különböző lehetőségek (+ Xamarin + Cordova ... etc.) összehasonlításáról fogok beszélni az App!Mobile konferencián, illetve egy hosszabb Migeran tutorial is lesz a szegedi Szabad Szoftver Konferencián.

Üdv,
Gergely

( uid_720 | 2014. 11. 09., v – 21:32 )

Xamarin? (Kisg előadása engem is érdekel)
Android-ot, iOS-t, WP8-at támogatja, desktopra meg WPF.
Csak egy egészen vékony réteget kell platformfüggőre megírni.

Fuszenecker_Róbert