Ha szükséged volna egy kereskedelmi célú, nemopengl-es, lightweight Android és iOS appot készíteni, akkor

 ( carlcolt | 2018. február 28., szerda - 14:59 )
Megírnám Javaban/Swiftben nulláról
15% (34 szavazat)
Megbíznék valakit, aki Javaban és Swiftben írja meg (nem generált kóddal)
4% (9 szavazat)
Megírnám magamnak generált kódos megoldással (phonegap, react native, ionic, etc.)
18% (41 szavazat)
Megbíznék valakit, aki megírja generált kódos megoldással (phonegap, react native, ionic, etc.)
2% (5 szavazat)
Megírnám magamnak lehetőleg Javaban/Swiftben nulláról, kivéve ha egy generált kódos megoldással rengeteg időt spórolok
9% (21 szavazat)
Megbíznék valakit, de csak akkor fogadnám el a generált kódos megoldást, ha lényegesen kevesebb pénzbe kerül
3% (7 szavazat)
Nem ismerem a natív Java/Swift kód és a generált ionic/react native/phonegap kód előnyeit/hátrányait
50% (115 szavazat)
Összes szavazat: 232

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem kekeckedés, de a React Native nagyon nem ugyan az, mint a PhoneGap (és az arra épített Ionic).

A React Native ahogy a neve is mondja, natív kódot ad, JS-ben írod, de nem a JS fut, ez a generált kód.

A PhoneGap (vagy Cordova) JS kódot futtat, nincs fordítás, nincs semmi varázslás, van egy WebView, és abban fut egy html+css+js kódbázis. Natív részeket is tartalmazhat, de azt natív kódban kell megírni, pl. java-ban írt plugin-ek Android-ra vannak, nem JS-ből generálódik.

Amiatt tennék különbséget, hogy a JS felől a teljesítménnyel állítólag lehetnek problémák (fejlesztettem ilyen appot), a React Native esetén a generált kódot még lehet optimizálni, és azért jóval vasközelibb, mint a JS.

Érdemes lenne inkább úgy kérdezni az ilyen témájú kérdéseket, hogy melyik nyelveket ismered, egy Java fejlesztő nehezen ismeri be, hogy amúgy nem is tudná-akarja js-ben írni, még ha gyorsabban meg is van, mert neki nem az a gyorsabb. Ahogy a js fejlesztő is azt mondja, hogy ezt-azt minek java-ban írni, megy az js-ben is, és úgyis gyorsabb abban írni (amihez viszont egy java és js tapasztalattal is rendelkező fejlesztő kéne, mindkét nyelven aktív tudással, szubjektivitás nélkül).

A react native esetében se fordítja a programozó által írt js kódot natívra, hanem v8-on futtatja, viszont natív UI komponenseket használ (innen a név).

iOS-en JSC futtatja a JS kódot, nem V8 (mondjuk a lényegen nem változtat :) ).

i stand corrected, nekem az maradt meg, hogy egy js subset-et natívra fordít, de valószínűleg keverem mással

Tudtam, hogy lesz ilyen is a valaszadok kozt. Nem erdekel, a lenyeg, hogy a vegen react native appot kell karbantartani, vagy Javasat/Swifteset.

ha sok üzleti logika van alkalmazás oldalon, akkor azt valszeg megpróbálnám valami közösben megírni, egyszerre.

UI-t nem biztos, hogy szívesen heggesztenék a különböző platformok fölé húzott UI-szerkesztőben.

A html+css sokkal szabadabb UI szerkesztésre szerintem, mint pl. az Android xml-jei, de kevés a tapasztalatom benne. Framework7 és hasonlók elég jól megoldják a html+css-ben épített natívnak kinéző megjelenést, de nem tudom érzésre valaki kiszúrná-e, hogy nem natív a UI.

Nagyon könnyen ki lehet szúrni, ha egy alkalmazás webviews és nem natív.

tesla mobilalkalmazasa pl. react native. (amivel a kocsit tudod nyitni zarni, futest kapcsolni, miegyeb).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem véletlen hogy ha lehet, kerülik sokan a natívot.

a reactot?:-D

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem, hanem a natív swift / java környezetre gondolok. Az egész mobil platform el van cseszve cross-platform meg bonyolultság szempontjából, persze ez nem véletlen. Mindenki védeni akarja a piacát, és ez a mechanizmus gáncsolja a standard-ek kiemelkedését. Sajnos.

szojatek volt. Bar tenyleg bena.:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

ja jó :)

-1

Lasd szavazas eredmenye

"Mindenki"

Nem

te kiszúrod, felhasználók nagyrésze szerintem nem. és ne kézzel taknyolt css-re gondolj, hanem framework7 szintűre

Ránéztem fw7-re, nézd meg az alábbi oldalt és görgess le az aljáig és nézd hogy ugrál görgetés közben a jobb oldali mobil logó :D

https://framework7.io/docs/button.html

Rengeteg JS fw van, csak szerintem mindegyiknek az a baja hogy JS-ből implementálják :) A legalja az, mikor a scrollbar-t is és olyan lassú hogy inkább bezárod az oldalt :)

A jobb oldali mobil logo alatt a preview-t érted? Azért a dokumentációs oldalon levő hickupból (vagy mi a fene az, nem értem én sem miért ugrik néha meg) ne következtess a library állapotára, mindenben van hiba. Nézd meg ezt mondjuk:

https://framework7io.github.io/framework7-template-tabs/

Vagy még jobb lenne a play store-ból egy framework7-es template-et nézned, van egy rakás ilyen app, ami direkt csak a gyári doksit becsomagolja, preview jelleggel.

A login gombra nyomva alulról felfelé beúszik a login screen ami jó, viszont bármilyen about gombra (tab-ra) nyomva eléggé szaggat az alulról felfelé beúszó animáció az i5-ös gépemen (ubi 16 x64 + intel vga, a vga-m gyors mindenhol). Ezt JS-ben fejleszthették le vajon?

Nem a legjobb példát adtam, mert az android-os verzióban ebbe belefutottam már én is, nem tudom milyen körülmények között, de ugyan ez volt. Volt utána a project-ben design változtatás, azt hiszem másik animációra lett váltva, ezért nem vizsgáltam. Nagy képernyőméreten jelentkezett, nézd meg 720px széles képernyőn kb. ott már nem akad. Mobilon szintén nem.

Nézd meg ezt, itt mindent egyszerűen tudsz tesztelni:

https://framework7.io/kitchen-sink/?theme=ios

https://framework7.io/kitchen-sink/?theme=md

(Android az f7-ben sokmindenben fattyúként van kezelve, iOS-re több eszköz van benne.

Nem rossz a koncepció és elfogadható a létjogosultsága, nyilván sok munkát tud adott esetben spórolni, csak ha már újra feltalálják a webet, akkor én drasztikusabb lennék. Akkor ne csak kicsit változtassanak a tag-ekben meg egyéb struktúrában, hanem dobjanak mindent, és ami a legfontosabb, hogy ne alulról kelljen építkezni, hanem felülről.

Tehát a leíró nyelvvel mindig csak elvegyünk, ne pedig mindig mindent hozzá kelljen adni. Tehát egy "about" parancs csinálja meg a komplett alkalmazást (komolyan gondolom :) ) és a tulajdonságait cseréljük le.

Na mindegy, ezt így nyilván nem lehet megoldani 2 mondatban, meg ennél sokkal bonyolultabb a téma, csak nem látok átütő eredeti újragondolásokat a fw-ökben amire azt mondanám hogy akkora kontrasztot teremtenek szabadságban és produktivitásban, mint például a web előtti és utáni technológiák különbsége.

egyetértek, részben. egy webes, js-html-css framework lehet nagyon absztrakt is, de lehet reset.css+fancydefaults szintű is, az F7 az inkább egy widget készlet, és pár framework elem, mint egy totál újragondolt UI leírásmód. gondolom okkal, mert így mindenki aki webes, az könnyebben bele tud nyúlni.

a létjogosultsága pedig szerintem pont az, ami a kérdés volt fentebb, üzleti alkalmazás, nem opengl, kb. amit böngészőben is el lehet készíteni.

Xiaomi A1-en reccenés nélkül működik. Pedig ez csak egy mobil telefon :)
--
openSUSE - KDE user

Xamarin-os dolgokkal találkoztam régebben, az nagyon-nagyon feltűnő volt, hiába akart hasonlítani az Androidos UI-ra.

de lehet, csak a rosszat könnyű észrevenni, s a jól megírt dolgoknál nem tűnne fel.

Xamarin, leginkább azért, mert mostani tudásommal ott a legkisebb (kb 0) a learning curve.

Androidra megirnam Javaban, iOS-re meg nem adnam ki. Esetleg ha akkora siker Androidon, akkor megbiznek valakit, hogy a mar kifejlesztett kod ismereteben irja meg.

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Javas vagyok, Swiftet kevesbe ismerem, de en inkabb az iOS oldalt irnam meg, es az Androidot adnam ki bermunkaba :)

Nem vagyok sem Android sem iOS fejleszto, de meg programozo sem. Van viszont nalunk Android meg iOS fejlesztes is. Nalunk jelenleg az az irany, hogy amit lehet egy kozos C++ alapba (engine) raknak, ezen felul a UI az switfben/Javaban van.

En mindkettot nativan irnam meg. Vannak jo es rossz tapasztalataink egyeb megoldasokkal, de en nem lovom magam terden.
Ha HATALMAS nyereseg lenne a shared code hasznalata, akkor beajanlanam a kliensnek hogy csinaltassa meg valaki massal. En ugyan nem nyulok hozza, de ebben az esetben NEKI megerheti.

Ha jól értem Xamarinnal nem fejlesztenél? Mik a legfőbb lábon lövések? (Üzleti jellegű appról beszéljünk, ne játékról)

Üdv,
Marci

Amikor neztem cross-platform megoldasokat, akkor mindig hianyzott valami, amit nativ libbel megoldhatsz, de ha mar nativan kodolsz, akkor irhatod az egeszet is nativban a szenvedes helyett.

Plusz ujabb layer ami komplikalja a debugolast.

MOE-val egy iOS lib hozzáadása ugyanannyi, mintha natív projekted lenne (használhatsz CocoaPods-ot, vagy amit akarsz, nincs megkötve a kezed). Java binding generálás mondjuk 1 óra, de akkor már ki is próbáltad.

Debuggolhatsz Java-ból (IntelliJ, Android Studio, Eclipse, Visual Studio Code), illetve Xcode-ból. Sőt, akár csinálhatod egyszerre, hogy Xcode-ba és Java IDE-be is pakolsz breakpointot, és mindegyiknél megáll.

React Java-val már a UI-t sem kell (teljesen) külön megírni.

Vs van egy nativ kornyezeted ahol nem kell taknyolni.

*kettő

Minimum. :)

Szarbol is lehet varat lehet epiteni. Valaki biztos megcsinalja, csak talaljon valakit a vallalat aki meg hozzanyul miutan kesz van az egy kerdeses... Ez egy uzleti hatrany.

Az a fejleszto akinek jo egy utangyartott vacak, tehat pl. megfelel a Xamarin, az rosszabb minosegu appet fog csinalni mert egyszeruen nem erdekli, neki csak munka es legyen minel egyszerubb.
Aki inkabb Xamarin-t hasznalja (nyilvan mert native-et nem tudja megfeleloen), az nem eli bele magat a temaba annyira, nyilvan nem erdekli, kulonben megtanulna, nem is tudja az igazan hardcore temakat megirni, foleg 2 plattformra ugyebar. Technikailag meg esetleg csak megoldhato (native code), ha nem futsz bele egy bug-ba, de akkor mar 3 specialistara lesz szukseged. Xamarin/c#, Android/Java es iOS/Swift/Objc. Egyre rosszabb a helyzet szvsz.

Es az sem garantalt, hogy holnap meg mukodni fog, mert a Microsoft kegyeben van a sajat termeked, kovetkezo riziko.

Fejlesztokent: Miguel de Icaza mindig is csak pofazott es igergetett, nem szimpatikus, nincs vele jo tapasztalatom. Pont ugy ahogy a Microsoft-tal sem.

Mindent egybe: Xamarin egy csomag szar amibe belehanytak.

> a Microsoft kegyeben van a sajat termeked

Igazad van, ne is menjünk bele olyanba, hogy amúgy a Google és az Apple is ráakasztja a maga harapófogóit az érzékenyebb testrészeidre, hiszen egy tollvonással el tudnak lehetetleníteni, pl. ha kidobnak a Store-ból.

Azzal már nem is hergelném a közönséget, hogy abban a pillanatban, amikor veszélyben érzed a projektedet, innen tudsz csinálni egy forkot a teljes Xamarin SDK-ról, hogy biztosan ne legyen baj.

> nem eli bele magat a temaba
> nem erdekli, neki csak munka
> legyen minel egyszerubb
> nem szimpatikus

Ha volt negatív tapasztalatod a Xamarinnal, azt nem akarom vitatni, de ennél azért használhatnánk tudományosabb megközelítést a QA-hez. Semmi garancia nincs rá, hogy a natív alkalmazás fejlesztője nem szarik a világba, főleg mivel az emberek tekintélyes része úgy rendezkedett be, hogy kap valakitől pénzt, cserébe napi ~8 órában megmondják neki, mit kell csinálnia. A natív kódon fejlesztés ugyanúgy lehet "csak munka", mint ahogy a xamarinos is lehet hobbiprojekt.

Abban a szerencsés helyzetben vagyunk, hogy van saját fejlesztésű megoldásunk: https://multi-os-engine.org (Igen, eredetileg mi csináltuk, megvette az Intel, aztán kiadták open-source-ba, azóta mi vezetjük a fejlesztést)

És a React Native-ból is csináltunk Java verziót a MOE-ra építve - hamarosan itt az Early Access, iratkozzatok fel: https://migeran.com/react-java

„Develop with MOE on Mac or Windows (Linux Coming Soon!).”
És mikorra soon?

Csak le kéne fordítani a libimobiledevice-t Linuxra is, és becsomagolni az SDK-ba. A fordításhoz egy távoli Mac-re szükség van Linuxnál is, mint Windowsnál. Mivel nincs ügyfél, aki így akarná használni, ezért ez mindig hátra sorolódik a backlogban.

kizárt dolog, hogy native appba csinálnám.

--
GPLv3-as hozzászólás.

+1

-------
It is our choices that define us.

Qt-vel vajon nem lehet?

En mint C++ fejleszto vszleg ezzel probalkoznak. A Qt Quick-ot is ismerem, nekem messze a legszimpatikusabb UI framework ami van.
A JS+HTML+CSS vszleg legutolso valasztas lenne, utalok ezzel a stack-el UI-t taknyolni (dolgoztam ilyenen).
--
:wq

KDE3-4 idejében használtam, nagyon jó volt, ha már erre az idióta tapizós platformra kéne programozni, én is sokkal szívesebben használnám ezt.

Egyeb: PWA


alias killall='echo "Wenn ist das Nunstück git und Slotermeyer? Ja. Beiherhund das Oder die Flipperwaldt gersput." | espeak -vde' #That's not funny.

iOS-en ez hogy áll? legutóbb amikor néztem még kb. semmit nem lehetett PWA-ban csinálni iOS-en

jol all, es egyre jobban, de egy csomo alap dolog mar egy eve is teljesen jol mukodott. eleg tag mondjuk ez a "kereskedelmi celu, nemopengl-es, lightweight", nyilvan vegul azon all vagy bukik a dolog, hogy milyen Mobile API-okra van szukseged, illetve azok tamogatasa hogy all Safariban (iOS-en, ha jol tudom, meg mindig nem mukodik Chrome-bol az "Add to home screen", csak Safaribol, es talan nem is fog soha).


alias killall='echo "Wenn ist das Nunstück git und Slotermeyer? Ja. Beiherhund das Oder die Flipperwaldt gersput." | espeak -vde' #That's not funny.

Attol mentsen meg az eg.

Igy is elegge elbasztak mar a webet a kugliek, nem kene megjobban.

Nem vagyok fejlesztő, kiröhögném a főnökömet. Legrosszabb esetben másik állás után néznék. :-P

és min röhögnél, ha natív vagy nem natív megoldást akarna? :)

[x] Előbb megnézném, hogy mi a feladat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"kereskedelmi célú, nemopengl-es, lightweight"

pl. webshop mobilappja

Olyat meg miért írnék? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

infinite scroll!
autoplay gif!

meg, hogy a userek ne tudjak a reklamokat blokkolni.... ;)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Kapcsolódik, hogy épp a napokban jelent meg a Flutter.io béta. Csak távolról nézegettem eddig.

Ami jól hangzik:
- IOS, Android, Fuchsia
- AOT compiled
- Nem használ natív widgeteket (jól customizálható), de szinte pixel pontos IOS, és Android Material desing koppintás van benne
- Reaktív
- gyors iteráció, live update-es fejlesztés
- Van nagy céges hátszele (Google)

Két dolog tűnt fel ami kicsit riaszt (azon túl hogy béta):
Dart..., és a layout nem deklaratív hanem code-ból definiált

Megbiznek valakit es rabiznam, hogy hogyan kesziti el.

Csak akkor fogadnam el az eredmenyt, ha az elvarasaimnak megfelel.

Ha csak valamiféle kalkulátorszerűség:
html-be ágyazott javascript. Működik androidon is meg ios-en is

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Hát ez nagyon-nagyon attól függ...

Ha egy webappot kellene felokosítani jelszómegjegyzéssel, esetleg ujjlenyomatolvasóval, akkor bevágni phonegapbe aztán csókolom.

Mivel mi vállalati mobil appokat rule-of-thumb android materialra írunk, ha ez egy form-táblázatok-admin cucc, lehet egy kört érdemes futni a google javascriptes material toolkitjével, és ugyanígy bevágni html-ben.

Ha komolyabb dolog kell, de nem business critial az app, megnézném a react native-ot, és keresnék egy ilyen céget.

Ha business critical, akkor natív dizájn mindkét platformra, akár két külön natív fejesztőcéggel, minden javascript és xamarinhuszártól távol tartva.

Láttam már ionic appot, többet nem szeretnék találkozni a platformmal közelről ha nem muszáj, megrendelő informatikai tanácsadójaként főleg nem, barmolásszagu az onnan kikerült app, persze, a fejlesztő nem tudja megkülönböztetni, de ez kb olyan, mint ez: https://youtu.be/ubNF9QNEQLA

"minden javascript és xamarinhuszártól távol tartva"

Ez tetszik ez a megfogalmazas :DDDD

Amugy a valasz is jo, jol szetszedi a "teszteseteket".

Arról írhatnál még, hogy milyen tapasztalat alapján húzod meg ott a vonalat, hogy business critical-ban már nem akarsz javascript-et látni? Maga a JS nem való oda, vagy csak a phonegap/cordova, react, ..., mint technológiák? Van valami, amit csak a natív alkalmazás tud, és elvárás?

(Komolyan kérdezem, mert a témában nagy százalékban mindenki azt mondja, arról ír, amelyik technológiát ismeri, aki mindkettőt ismeri eddig azt mondta nekem, hogy kb. az van, hogy UI html+css, gyors kicsi egyszerű js, összetettebb műveletek natív, de ezek egy része amúgyis natív plugin-ben történik.)

Ha a szolgáltatás érintkezési idejének többsége az appon keresztül zajlik, vagy jelentős szerepe van a konverzioban (érdeklődőből fizető ügyféllé vagy egyéb módon bevételforrássá válásban).

Pl egy revolut mobilappot meg se próbálnám nem natív technológiával megírni, mert ez a sok kicsi idegesítő hiba, különbség, gixer, ami ezekre az “almost entirely but not quite unlike tea” frameworkökre jellemző, és amit a fejlesztőknek egyesével újra es újra meg kell mutatni, fenyegetődzni kell nemfizetéssel, stb (mert ugye a speckóba nem írtuk le hogy ne csússzon szét a dizájn iPhone 5S-en, neki 6SPlus-sza van azon jó és mit hisztizünk), ölik a bevételt (mert a user kifordul az appból), és rontják a piacra jutási időt.

Ezekkel a nem nativ fejlesztés teli van, és egy ponton mindenképp kompromisszumhúzás lesz. A kérdés, ezzel mennyi pénz esik ki, de ezt csak egy párhuzamos univerzumból tudnánk meg.