[Videó] A Flutter helye a modern alkalmazásfejlesztésben

Címkék

Körbejárjuk a Google új keretrendszerét, a Fluttert, mellyel könnyedén lehet multiplatform alkalmazásokat készíteni. Pásztor Dániel, az AutSoft Flutter fejlesztőjének a HWSW free! meetup-sorozat 2020. július 21-i Flutteres állomásán rögzített előadásában röviden megismerjük a keretrendszer történetét, a Flutterhez szorosan kapcsolódó Dart programozási nyelvet, illetve az architektúra felépítését, végül kitekintést adunk a Flutter várható jövőjére.

Az érdeklődők a Flutterrel a HWSW 2020. szeptember 14-én kezdődő, 8 alkalmas, 24 órás, Flutter alapú mobilfejlesztés című gyakorlatorientált, online képzésén közelebbről is megismerkedhetnek, ugyancsak Pásztor Dániel, illetve Juhos István vezetésével  - akivel a fenti meetup előadói között szintén találkozhattunk.

Hozzászólások

Szerkesztve: 2020. 08. 12., sze - 16:07

Érdekes megoldás, voltak már hasonló kezdeményezések, és AFAIK egyik sem lett túl sikeres. de ha kitart a projektben a gőz, akkor érdemes lehet új projekthez kipróbálni. Jól hangzik, hogy nagyok állnak mögötte, de rosszul hangzik, hogy kevesen használják eddig. És mi lesz, ha a Google-nek sem lesz érdeke, hogy könnyű legyen multiplatform alkalmazást írni, és egy kézmozdulattal leállítják az egészet? Megannyi kérdés.

>És mi lesz, ha a Google-nek sem lesz érdeke, hogy könnyű legyen multiplatform alkalmazást írni, és egy kézmozdulattal leállítják az egészet?

Vagy mondjuk úgy döntenek, hogy a PWA a jövő és a hagyományos app ökoszisztémába nem locsolnak többé pénzt. Vagy jön egy újabb Next Big Thing 1-2 év múlva, elfogy a cucc mögül a momentum és rövid úton kukázza a gugli. Vagy egyszerűen "csak", sok példát láttunk már ilyenre is ennél a cégnél.

Így, hogy valami megmagyarázhatatlan okból erre a Dartra építették a cuccot, amit eddig lényegében egy kihalófélben lévő zsákutcának gondolt mindenki, jó kérdés full community alapon mennyire lenne életképes a projekt akár csak középtávon.

A Dart fejlődésének motorja immár a Flutter, ergo újrapozicionálták. Azért raktak mögé Dartot, mert házon belül ez hozta a legjobb teljesítményt. Ez fontos szempont, lévén pont az egyik legnagyobb kritika a népszerű React Native-vel szemben, hogy lassú mint a dög. A dizájn függőségek kiiktatása mellett a megfelelő sebesség volt az egyik fő cél, közelíteni akarták a nativ mobilappok sebességét.

>A Dart fejlődésének motorja immár a Flutter, ergo újrapozicionálták.

Igen, többek közt ez a baj vele. Ha a Google dobja ezt is 1-2 év után (mint szinte mindenét), akkor majd a community supportálhatja a Dartot is mellé.

>Azért raktak mögé Dartot, mert házon belül ez hozta a legjobb teljesítményt.

Első ránézésre nem igazán látom miért kéne a Dartnak triviálisan gyorsabbnak lennie mint mondjuk egy Typescriptből fordított JS. Több a hasonlóság, mint a különbség.
Azt persze értem, hogy lemérték két prototípus implementációjukat házon belül és a Dart alapú jött ki nyertesen (bár számok nem ártanának ezt alátámasztani), de csak ez alapján ilyen horderejű döntést hozni...

>Ez fontos szempont, lévén pont az egyik legnagyobb kritika a népszerű React Native-vel szemben, hogy lassú mint a dög. 

A React Native elég nagy kalap szar nagyon sok szempontból, nekem pl. stabilitással volt a legtöbb bajom vele. Egy tákolmány, nem csoda ha lassú.

Ellentétben olyan szempontból jó példa, hogy mégis rengetegen használták. Azért az elég nagy fegyvertény, hogy a model típusaidat, vagy akár a logika egy részét újra fel tudod használni a node.js backend, a webes és a mobil kliens között, utóbbi kettő között akár az alkalmazás állapotkezelés (redux store) nagy részét is. Vagy hogy nem kell valami egészen újat megtanulni hozzá, keresztbe be tud segíteni egymásnak a mobil és a webes frontend fejlesztő.

A Flutter ezzel szemben minden téren más, a Dart pont annyira tér el a Typescripttől, hogy ne tudj újra felhasználni semmit JS alapú másik projektből, valóban tapasztalt senior fejlesztőt meg még jó ideig elég nehéz lesz találni rá.

Komolyabb (támogatott) Gui több platformra eléggé hiánycikk:

- Javas szörnyűségek

- Qt - jó és natív, de drága

- Xamarin - 1-2 év, mire a Gui majd eljut a használható szintre

És most jön a Flutter, ami natívan, ingyen tud majd multiplatformot... én nagyon szurkolok neki.

Szerkesztve: 2020. 08. 13., cs - 16:36

használja ismeri vki ezt a Flutter? Olyan akinek van tapasztalata más GUI-kban is? (swing, qt, android, html css javascript, egyéb)

jó cucc?

nézegettem a leírásokat de nem jutottam a végére

Szerkesztve: 2020. 08. 15., szo - 12:33

Hasonló módon deklaratív mint a jetpack kotlinos deklaratív megoldása, csak Dartban. A jetpack/kotlin megoldást nem ismerem, nem tudom, hogy az is ugyanilyen "minden is Widget" alapú környezet-e mint a Flutter. A Flutter nem csodaszer abban az értelemben, hogy akinek eddig bármely más GUI keretrendszerrel nem sikerült karbantartható kódot összehoznia, annak ez Flutterrel sem fog sikerülni.

ami eszembe jut hirtelen, lóugrásokban: kezdetben kiforrott state management sem volt, emiatt született legalább 1 tucat (vagy több) teljesen különböző megoldás, kezdetben a Google saját BLOC megoldását nyomták aztán végül az egyik srác egyszerűbb, Provider nevű megoldását kezdték favorizálni hivatalosan, de a lényeg az, hogy ez is a kedves fejlesztőre van bízva hogy ölje bele az időt és találja meg a saját céljainak megfelelő állapotkezelő megoldást, vagy elindul az egyikkel és ha nem lesz jó majd utólag átírja az egész appot másikra. Persze aki webfejlesztésből jön az hozza magával a React/Redux megoldásokat, tele van velük a pub. Nekem legjobban az egyik flutter fejlesztő köztes megoldása tetszik, bár kezdőként érdemes a providernél maradni. Egyszerűnek tűnik hogy minden Widget és csak gyiá, de valójában nagyon is rá kell szánni az időt és elmerülni a részletekben hogy hogyan is működik belülről, mert aki nem érti a működését annak rövid úton hullani fog a haja. És persze nem árt a Dart-ra magára is időt szánni, sőt legjobb CLI toolokkal kezdeni. Az async/stream körüli dolgokat is érdemes körbejárni (és a mikrotaszkban keletkező kivételek kezelését), illetve érteni pontosan, hogy async/await ide vagy oda, egy szálon fut (szemben mondjuk egy ASP.NET Core konzol alkalmazással). Aki C#-ban használja a Task.Wait metódusát annak újra kell majd gondolnia a megszokásait Flutterben Dart kód írásakor. Lehet persze létrehozni "szálakat" (isolate) is de ezek teljesen szeparáltak ahogy a neve is mutatja, nincs osztott memória, és (érthető módon) közöttük csak néhány primitív adattípus mozgatható. A megoldás előnye, hogy "nincsenek szinkronizációs problémák". Azért van idézőjelben mert ettől még a kezdő Dart programozó simán fog majd szinkron ciklusban (for vagy foreach) async metódusokat hívni (pl. file write) amelyek ezáltal "fire&forget"-ként mikrotaszkban futnak majd így még azelőtt újra hívásra kerül az adott metódus mielőtt az első hívása befejeződött volna és jönnek a problémák (meg a kivételek). Ezen a ponton strukturális módosítás következik a kódban vagy ha az nem járható út, akkor lock, bár ez utóbbi használatát még sikerült elkerülnöm. Továbbá itt jön képbe hogy hiába "típusos" a nyelv, mégis nélkülözhetetlen a static analyzer használata, bár ez sem csodaszer. A Dart alapvetően a Java-ra hasonlít leginkább. Itt nincs paraméter overloading és nem lehet primitív típust referenciaként paraméterben átadni, és csak egy visszatérési érték lehet. Ez azért kritikus probléma mert a jól karbantartható kód egyik alapköve a korrekt hibakezelés, viszont referencia paraméter és/vagy több visszatérési érték nélkül a kivétel dobás marad az egyetlen hibakezelési lehetőség, amit nehéz jól csinálni és rengeteg boilerplate kóddal jár. Dart esetén ehhez hozzájön még az is, hogy az a kivétel szinkron (async/await) vagy mikrotaszkban keletkezik (fire&forget) ami még tovább komplikálhatja a kódot. Aki szeret bíbelődni kivételekkel annak ez nem gond, én más úton próbálkozom hasonlóan ehhez és ehhez. Az előbbi tetszik csak ahhoz nagyon kellene az overloading lehetősége ami nincs, és nem is lesz (opcionális paraméterek használata az ajánlás helyette).

Továbbá még csak azután jön a null-safety (ami célját tekintve ugyanaz lesz mint a C# 8-ban megjelent Nullable Reference Types történet) ami a 2.9-es Dart-ban már benne van csak alapból nincs engedélyezve (ahogy C#8-ban sincs alapból engedélyezve), mert ez töri az eddigi kódokat, ennek megfelelően a Flutter kódja sem áll még készen erre, de folyamatban van. Itt is lesz még bukkanó. Érdemes tudni, hogy a Flutterben lévő Dart SDK az nem teljesen ugyanaz mint a külön letölthető csak Dart SDK. Előbbi itt/ott flutterhez van igazítva. Aztán ott a Dart formatter, aki nem tud együtt élni a 2 szóközös behúzással és a sor végén lévő { jellel annak fájni fog a Dart. Flutter UI deklaráció kapcsán probléma még, hogy pillanatok alatt nagyra nő a build metódus és könnyű elveszni a widget deklarációkban. Ennek a problémának feloldása megint csak (tapasztalati) időbe telik. A kezdő első megoldása hogy akkor widget subtreeket külön metódusba kiszervezi és akkor lesz (leegyszerűsítve) az hogy build() => column[header(), body(), footer()] de ez csak tűzoltás továbbá Flutterben ez antipattern. :) Minden Widget, ez a megoldás. Boldog "haladó" júzer elkezdi gyártani a Widgeteket amikor belefut abba a problémába a stateful widgetek boilerplate kódjainak újrahasznosítása erősen problémás, de már erre is kezd alakulni egy lehetséges megoldás, ami majd vagy beválik vagy nem. Ja, igen, a Web támogatása béta a desktop támogatás aplha, de ennek ellenére (szerintem) mindkettő használható. A Web irányban az fáj a legjobban a közösségnek, hogy a szövegeket (Text widget) nem lehet kijelölni. Bár van SelectableText widget, nekem ez mondjuk pont nem fáj, engem pont mindig is az zavart hogy gyakran véletlenül kijelölődik ez/az a weboldalakon. Persze aki nem DOS/Win 3.1-en hanem már browserben nőtt fel, az mást szokott meg, érthető.

Szumma: ugyanúgy bele kell ölni a nem kevés időt mint bármelyik másikba, el fog még törni az összes kód ami már készen van, de amiért megéri az szerintem az, hogy lesz egy eszköz amivel akár 1 ember is gyorsan összerak bármilyen PoC megoldást, legyen az app, web, desktop, illetve ha sikerül jól szétválasztani a UI/mindenmást akkor tényleg elég sok kód újrahasznosítható ami később, idővel szintén csökkenti a fejlesztési időt. Majd. :) Dart meg nem rossz csak szokni kell. Mondjuk arra például még nem találtam módot hogy könyvtárat binárisra (AOT) lehessen fordítani és azt binárisként hivatkozni másik projektben (mint C/C++ .obj vagy Java class, stb.)...

UI: KGer-nek ment volna, csak mellément...