Dotaz: V čem psát multiplatformní aplikaci ?

[Martin F.]

Plánujeme multiplatformni aplikaci. Cílem je v maximální míře (95% a více) využít stejné kódy pro všechny platformy: Win, Lin, Mac, Web, Android, iOS. V podstatě váháme mezi Electron+React native vs QT (tam by se Web verze musela dobastlit nějak přes Webassembly). Řeší někdo podobný problém? Poradíte ?

---

---

Odpovědi

[debian+]

Co to ma byt za apku? Vyukovy program, nejaky manazer niecoho, hra, sever-klient?

[Martin F.]

To není moc podstatné, teamwork nástroj. Můžete si to představit třeba jako email klient - když je online tak se syncne, a i když je offine tak je možné nadále téměř plnohodnotně pracovat. Řešíme tu hlavně aplikaci, serverová část není podstatná. Musí to samozřejmě zvládat multimédia, jak přehrávání tak recording. Hlavně na linuxu je to peklo, takže proto asi ten Electron kde to je vyřešeno v Chromiu na pozadí.

[Kit]

Je více možností, záleží na typu aplikace. Java, Haskell, Clojure, webovka, Python, Rust,...

[Martin F.]

Už není 1.april, já svůj dotaz myslím vážně a tak s Haskelem, Rustem a podobnými akademickými záležitostmi které si u iOS a Androidu ani neškrtnou jděte do sekce humor. Java u aplikace nemá co dělat, nemůžeme uživatele nutit ji doinstalovávat a u mobilů to stejně nejde. Clojure je taky na Javě závislé, knihoven poskrovnu, syntax z pekla jak u Lispu, to asi neprojde

[⧠ A = 0]

QBasic+DOSBox, to rozjedeš na všem!

[⧠ A = 0]

DOSBox bohužel dost žere elektřinu.

No, to vlastně tzv. moderní web taky, takže nakonec ten DOSBox bude možná lepší varianta, protože ten alespoň není náročný na paměť.

[jiwopene]

Na Androidu to bez Javy tak nějak úplně nejde.

[NUKE GAZA! 🎆]

kotlin hele ale jeto skoro java :O ;D

[Martin F.]

No go. Na desktopu si Kotlin apka bez Javy neškrtne. Navíc já tu chci praktické zkušenosti, ne něco co jsi vygooglil.

[OldFrog {Ondra Nemecek}]

Jenže ono vyhodnotit vhodnost nástroje není jednoduchý úkol a nepředstavujte si, že vám někdo poradí platformu, kde dostanete podporu pro všechny platformy úplně zadarmo a bez práce. IMHO Nodejs, java i QT jsou všechno použitelné varianty... Java je základní jazyk pro Android, takže tam by bylo možné sdílení podstatné části kódu mezi všemi platformami. Clojure nebo Rust může působit exoticky, ale opět to není tak divná volba, pokud by v tom byla třeba implementovaná základní knihovna té aplikace. Neposkytujete moc informací o tom, co má aplikace dělat, co máte hotové a jaké máte k dispozici vývojáře, tak se nedivte, že dostáváte obecné odpovědi.

[Martin F.]

Samozřejmě domácí úkol jsme už udělali a prošli vše co připadá v úvahu. V zadání sám píšu že se rozhodujeme mezi Electronem a QT. Java je děravý věčně látaný vopruz, chtít po uživatelích a by ji měli na desktopu je sadismus a na iOS stejně nejde. Nechci tu něco co tu začnou lidi googlit ale praktické zkušenosti. Detaily připravované aplikace jsou v tomhle pohledu nepodstatné. Odhadem 50% bude napsáno od nuly (UI, BL) a 50% budou hotové knihovny na síťařinu, šifrování, multimédia a pod.

[xxxs]

aj tak sa ti to zredukuje na lenivy bloat a pohodlnejsi vyvoj, vs mensia a rychlejsia aplikacia s pomalsim vyvojom. na roote by ti dali odpovede na niekolko stranok. tam miluju flame na temu ci je lepsie toto, alebo hento.

[OldFrog {Ondra Nemecek}]

Jestli si myslíš, že detaily tý aplikace nejsou podstatný, tak jste si domácí úkoly rozhodně ještě neudělali... Co a jak to má dělat je totiž ta zcela zásadní otázka, protože u většiny typů aplikací prostě principielně nelze mít stejně fungující desktopovou verzi a mobilní verzi. Takže i když ti Qt a web (velmi) teoreticky umožňuje mít jeden codebase, pro reálnou lidma používanou aplikaci stejně skončíš s velkou pravděpodobností alespoň se dvěma aplikacema - desktop + mobil. A pokuď ta mobilní aplikace má být složitější a netriviálně interagovat se systémem, nevyhneš se ani separátní Android a IOS aplikaci.

[Martin F.]

Vyhnutí se separátní desktop / mobil / web aplikaci je alfou a omegou celého problému. Při použití Electronu a teda webových technologií pro GUI lze tento problém celkem zdárně řešit (React pro desktop/web, React Native pro mobily). Množství NodeJS knihoven zároveň zaručuje celkem slušné možnosti řešení BL pod kapotou.

[fibre]

Ja len podotknem, ze kod v Reacte a React Native sa lisi, lebo prehliadac a "native" ma rozne API.

[Martin F.]

S tím již máme praktické zkušenosti. Liší se víceméně jenom ve view-u což je náš předpoklad 5-10% práce navíc v mobilní verzi.

[achjo]

Dalsi chytrak, staci cist ty tve blogy.

[OldFrog {Ondra Nemecek}]

No je potřeba stavět na nepolovičatých znalostech a šmahem neodsuzovat jen na základě dojmu. Pohybuju se v java světě a tak pro představu doplňuji...

Na Adroidu je Java standard, částečně se tam tlačí i Kotlin, naproti tomu vývoj s nativními knihovny tak běžný není a přináší další vrstvu komplexity. Pokud na to máte lidi klidně to dělejte v QT, ale nedivte se, že lidé navrhují javu.

Stejně tak je matoucí názor na javu na desktopu. Pro distribuci java aplikací tam javu nainstalovanou mít nutně nepotřebujete, můžete ji mít přibalenou u aplikace, jpackage je teď už součástí JDK a umí dělat MSI instalačky zahrnující i java runtime (a na linuxu umí udělat DEB nebo RPM balíčky a pro MacOS ten jeho standardní formát - neznám). Pokud chcete mít aplikaci malou, můžete použít navíc jlink (opět součást JDK) a přibalit jen ty části, které se z runtime opravdu používají. JavaFX je rozumně vypadající a fungující GUI framework (ve světě javy jde asi první úspěch tohoto druhu). Gluon Mobile má podporu pro běh JavaFX aplikací na iOS a Android včetně podpory pro hardware. Navíc se pracuje na integraci Graalvm, který by umožnil překlad do plně nativních binárek (to ale ještě asi není production ready, fungují jen jednoduché příklady).

Já vám cestu javy rozhodně nenutím - stejně byste museli pilotně vyzkoušet, jak se to hodí pro váš případ. Ale chci tím ilustrovat, že je vždy více možností a rozhodovat by měl někdo, kdo má s uvedenými technologiemi dostatečnou zkušenost. Jinak pohoříte a u multiplatformního vývoje to platí dvojnásob.

[Martin Tůma]

JavaFX je sice oproti Swingu velký krok kupředu, ale nativně to na žádné platformě taky nevypadá (nechová se). A stále tady je oproti nativním GUI aplikacím znatelný výkonostní propad (Mluvím o standardním uživatelském PC - 6 let starý notebook, 2-4GB RAM, rotační disk a antivirus. Na vývojářském 32 jádrovém Threadripperu se to už možná neprojevuje).

[OldFrog {Ondra Nemecek}]

Nevím, mě přijde odezva i vzhled +- na úrovni QT aplikací. Narozdíl od Swingu je i chování dost blízké nativnímu, resp. nevybočuje oproti rozdílům mezi QT a GTK na linuxu a na Windows oproti rozdílům těch jejich toolkitů (které také nemají jednotné chování ani vzhled). U JavaFX spíš vadí menší vývojářská komunita a menší dostupnost pokročilých widgetů, dokovacích nástrojů apod. pro rozsáhlé aplikace.

[Martin Tůma]

Ten nenativní vzhled je stále velmi patrnej. Pro OS X dokonce vznikaj projekty (např. AquaFX), který se snaží to dohnat custom stylem. Ale i na Windows je to prostě znát, že to není nativní aplikace (i když tady pravda při současné roztříštěnosti nativních Windows toolkitů už začíná být otázka, co to ten nativní look&feel na Windows vlastně je...). A v KDE to rozhodně jako KDE aplikace taky nevypadá. A to ještě pominu to, že neostylovanou reálnou JavaFX aplikaci jsem snad ještě neviděl, z nějakého důvodu má každý potřebu tam plácnout vlastní "skin"...

I u Qt se na detailech dá poznat, že to (na Windows a Macu) není zcela nativní aplikace, ale člověk se musí mnohem víc "snažit". Na druhou stranu v dnešní době, kdy každej korporát má své oddělení hipsterů, kteří nedělají nic jiného, než tu jejich aplikaci vzhledově odlišit od ostatních, je nativní look&feel už možná přežitek. Al já jsem "konzerva" a mě to vadí.

[OldFrog {Ondra Nemecek}]

U OS X budou rozdíly asi nápadnější. Souhlas, že je to dnes co se týče toolkitů podobná džungle na Windows i Linuxu. Ale jednotlivé toolkity se naštěstí vzájemně ovlivňují a některé užitečné koncepty od sebe přebírají. Tak alespoň to je pozitivní...

[Martin F.]

Integrovaná či vykuchaná Java nijak neřeší problém bezpečnostních update a vydávat každý týden novou verzi apky jen protože nová záplata v Javě je blbost. A pořád je tu problém s iOS takže vás už prosím se k Javě nevracet.

[OldFrog {Ondra Nemecek}]

Ale s Electronem budete mít s aktualizacemi přeci úplně stejný problém... Jde o obecný problém, který nastává kdykoli k aplikaci dodáváte vlastní runtime. Týká se to i těch ostatních multiplatformních nástrojů, stejně jako třeba internetového prohlížeče (proto patří k nejčastěji aktualizovaným programům). Pokud chcete bezpečnostní aktualizace víceméně zdarma, tak použijte buď nativní vývoj (a doufejte, že dodavatel systému zajišťuje bezpečností aktualizace všech vámi používaných knihoven) anebo použijte ten prohlížeč a nějaký offline mód aplikace (local storage).

[Martin F.]

Nesouhlasím. Cedník jménem Java se MUSÍ updatovat, protože není opensource a jen Bůh ví co tam vlastně látají a proč. Chromium+NodeJS jsou opensource a lze posoudit co bylo změněno a jestli update je nutný. V praxi se Electron apky updatují spíše z důvodu feature updates než z důvodu bezpečnostního update Electronu.

[dustin]

Open source nejsou rozšíření od oraclu v placené javě, do javy můžeš normálně poslat přes mailing list patch https://github.com/openjdk/jdk

[Martin F.]

Taky můžeš hlavou praštit o zeď ale děláš to ? No neděláš Z pohádky o opensource Javě jsme už dávno vyrostli.

[dustin]

Zatím jsem se k tomu nedostal, ale dojde na to, protože to potřebuji pro své projekty

https://mail.openjdk.java.net/pipermail/sound-dev/2019-June/000698.html

[LarryL]

Chromium+NodeJS jsou opensource a lze posoudit co bylo změněno a jestli update je nutný.

Máte ve firmě tak velký tým, že dokáže ručně zkontrolovat každou změnu v kódu Chromia a NodeJS nebo čtete reporty od nějakého auditora, který ten kód kontroluje místo vás?

[Martin F.]

Ano jsou zdroje na bezpečnostní audit. A není to žádný rocket science, když si sjedeš aktuální CVE pro chromium tak 90% bugů je networking, open malicious file, url bar, CORS atd. což u lokální apky která Chromium využívá v podstatě jen na rendering je nepodstatné.

[OldFrog {Ondra Nemecek}]

Každý si naštěstí může sám ověřit fakta.

[OldFrog {Ondra Nemecek}]

Elektron se všema těma JS knihovnama je to samé v bledě modrém. To že se tak často neupgraduje je dáno spíš stylem vývoje v daných technologiích, kdy polovina projektů ani netuší co všechno a odkuď se do jejich aplikace vzalo...

Pokuď chcete mít rychlej a multiplatformní vývoj, vždy za něj něčím zaplatíte na straně funkčnosti/kvality tý aplikace. Jde jenom o to, která strana misek vah je pro vás důležitější. Pokuď děláte nějakej unikátní projekt s jedinečnou funkčností, ale potřebujete být na trhu první, budete mít jiné priority, než když budete dělat nějakou hipsterskou apku s trilionem alternativ, kde musíte být hlavně cool, abyste mezi tou tunou klonů prorazili...

[OldFrog {Ondra Nemecek}]

Přesně tak. Je to něco za něco. A podobně komplexní nástroje budou pravděpodobně tíhnout i k podobnému typu problémů. Ale zdá se, že to tazatel nechce slyšet, neboť sám ví vše nejlépe. S tímto přístupem je ovšem škoda času diskutujících.

[debian+]

https://hackernoon.com/9-popular-cross-platform-tools-for-app-development-in-2019-53765004761b

[OldFrog {Ondra Nemecek}]

Jojo, ale to je hlavně pro mobily, vývoj pro desktopy slibuje jen Corona (podle toho přehledu). A co znám zprávy od kolegů, stejně je s tím práce, rozhodně ta multiplatformita není úplně automatická a chce to trochu péče :)

Když už jsme u toho, ještě bych doplnit toto https://www.codenameone.com/ Opět to z praxe neznám, ale slibují toho hodně. Jeden z prvních projektů tohoto druhu.

Nicméně i přes tyto možnosti bych počítal i s možností mít mobilní a desktopovou verzi diverzifikovanou. Takže mít rozhraní zvlášť pro mobil a používat tak maximálně společné aplikační jádro.

[frr]

Spíš na okraj, v changelogu Ultimate++ jsem si všiml, že kluci pracujou na nějaké podpoře pro Android. Ale nedokážu říct, jakou to má přesně podobu a jak je to daleko.

https://www.ultimatepp.org/app$ide$AndroidBuilder$en-us.html

https://www.ultimatepp.org/www$uppweb$SupportedPlatforms$en-us.html

Kdyžtak se zeptejte na fóru, oficiální "dokumentace" může být pozadu za bleeding edge.