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...