Skálázhatóság a Flutter projektekben
Tervezz hosszú távra!

Flutter projekt skálázhatóság és nehézségei
Gyakori kódbázis képe

A sikeres digitális termékek építése nem csak a mostani eredményekről szól, hanem a jövőre is gondol. Egy skálázható és jól karbantartható megoldás nem csak jelentős költségmegtakarítást eredményez a cég számára hosszú távon, de a fejlesztők motivációját és megelégedettségét is növeli. Érdekes módon, ha egy fejlesztő átvesz egy projektet, és azt jól strukturáltan találja, kevésbé kísérti a kód újraírásának gondolata. Ebben a bejegyzésben bemutatom, milyen technikai szempontokra érdemes odafigyelni.

Mitől lesz egy projekt skálázható?

A mai posztban ezekre a kérdésekre keressük a választ: skálázhatóság és hogyan kezeljük okosan a függőségeket? Miért fontos mindez nem csak a fejlesztők, hanem a cégvezetők számára is? Kitérünk a pubspec.yaml fájl finomságaira, a monorepo előnyeire és buktatóira, valamint megvizsgáljuk, hogyan segíthetnek a saját package-ek.

Skálázhatóság alatt a rendszer képességét értjük arra, hogy megnövekedett terhelés mellett is megfelelően működjön. Nem csak a felhasználói szám növekedése okozhat terhelést, hanem például egy vállalat üzleti növekedése is.

Egy skálázható mobilapp rugalmas, és lehetővé teszi a kód könnyű karbantartását és fejlesztését.

Miért fontos ez?

Mert a skálázható rendszerek költséghatékonyak és időt takarítanak meg a jövőben. Nem csak a fejlesztők, hanem az egész vállalat számára.

Egy skálázható rendszer nem csak költségeket és időt takarít meg, hanem a fejlesztői csapat motivációját is növeli.

Amikor egy csapat egy jól szervezett, skálázható kódbázison dolgozik, a code-review-k gyakorisága és a refaktorálások szükségessége is csökken. Emiatt a fejlesztők több időt tölthetnek a valódi problémamegoldással és az innovációval, ami általában magasabb munkamorált és jobb termelékenységet eredményez.

Függőségkezelés: a pubspec.yaml alapjai

A pubspec.yaml egy Flutter projekt lelke. Nem csak egy sima konfigurációs fájl, hanem az alkalmazásod ‘központi irányítója’. Itt határozhatsz meg függőségeket, vagyis kódcsomagokat és könyvtárakat, amelyek az alkalmazás működéséhez szükségesek.

Ezáltal megkönnyíti az egész csapat munkáját és egy helyen van összegyűjtve minden, ami az app működéséhez kell.

Emellett lehetőséget biztosít az Open Source közösség megoldásainak újra felhasználására. Ezzel időt és erőforrást takarítunk meg. A függőségkezelés így kulcsfontosságú a skálázhatóság és a fejlesztési idő optimalizálása szempontjából.

A monorepo előnyei és kihívásai

A monorepo, vagyis egyetlen kódtárba szervezett projektstruktúra előnyöket és kihívásokat is rejt. A monorepo önmagában nem egy különleges Git repozitori, hanem a benne lévő tartalom szervezési módja teszi azzá.

Előnyei közé tartozik az egységes verziókezelés, a közös függőségek könnyebb kezelése és a csapatmunka megkönnyítése. Egy ilyen rendszerben könnyebben nyomon követhetők a változások és egyszerűbben menedzselhetők a projekten belüli függőségek.

Ugyanakkor a monoreponak kihívásai is vannak: megfelelő infrastruktúra és eszközök nélkül könnyen kezelhetetlenné válhat. Különösen fontos itt a függőségkezelés, hiszen egy rosszul kezelt monorepo gyorsan kaotikussá válhat.

A monorepo kaotikussá válhat, ha nincs jól szervezett függőségkezelés és verziókövetés. Ha több projekt vagy modul egymástól függ, és nincs megfelelően kezelve ezek kapcsolata, akkor a kódbázis könnyen instabillá válhat.

Egy nagy csapat esetében az egyes tagok változtatásai könnyen “összeütközhetnek”, ami hibákat és felesleges munkát generál. Ezért a kódminőség ellenőrzése, például code-review és tesztelés, kritikus jelentőségű egy monorepo esetében.

Saját Package-ek: a karbantarthatóság és skálázhatóság eszközei

A saját package-ek létrehozása segít modularizálni az alkalmazást. Ez lehetővé teszi a kód újrafelhasználását és a fejlesztői csapatok közötti együttműködést. A saját package-ek azért is jók, mert lehetővé teszik az alkalmazás egyes részeinek izolált fejlesztését és tesztelését. Ennek következtében a kód karbantarthatóbb és könnyen skálázható lesz.

Még jobb, ha ezek a package-ek Open Source közösséggel is megoszthatóak, ami további elismerést és visszajelzést generál. Nem beszélve az “ingyen” javításokról.

Leggyakoribb a domain-alapú szervezés. Ez lehetővé teszi a csapatok számára, hogy külön felelősségi körökre koncentráljanak. Ez nemcsak a fejlesztési időt csökkenti, hanem a kód minőségét is javítja, mivel minden csapat mélyebb szakértelmet fejleszthet ki a saját domainjében.

Ez az elképzelés tökéletesen illeszkedik a mikroszolgáltatásokhoz hasonló architektúrákhoz és a nagyobb, összetett rendszerekhez.

A modularizálásnál általában a következő szempontok alapján szokták az alkalmazást package-ekbe szervezni:

  1. Biztonságért felelős modul: Autentikáció, titkosítás, és jogosultság-kezelés.
  2. Hálózati Kommunikáció: API hívások, WebSocket kommunikáció.
  3. Domain Logika: Üzleti logika, adatmodellek, és adatmanipulációs metódusok.
  4. UI/UX Komponensek: Újrafelhasználható widgetek, stílusok, reszponzív design.
  5. Adattárolás: Lokális adatbázis kezelés, cache.
  6. Közös Funkcionalitás: Navigáció, állapotkezelés.
  7. Fizetési megoldások: Tranzakciók, online vásárlások, és kapcsolódó biztonsági intézkedések.

A fő cél itt a szorosan összefüggő funkciók csoportosítása és azok elkülönítése. Ezek különböző fejlesztési fázisokban vagy csapatok által lehetnek kezelve. Ezzel könnyebbé válik a karbantartás és a skálázás.

Összefoglalás

A skálázhatóság nem csupán technikai, de üzleti előnyöket is hoz.

Egy jól skálázható rendszer csökkenti a fejlesztési és karbantartási költségeket, növeli a fejlesztői csapat motivációját, és biztosítja a jövőbeni rugalmasságot. A monorepo struktúra és a modularizált kódbázis segíthetnek ebben.

A központi csomagkezelő (pubspec.yaml file) pedig lehetővé teszi, hogy könnyen integráljuk a már létező, kipróbált megoldásokat, időt és erőforrást spórolva.

Összességében, a skálázhatóság nem csupán a fejlesztők, hanem a cégvezetők számára is kulcsfontosságú.

A Flutter eszköztára rendkívül sokoldalú és hatékony, így skálázható és karbantartható alkalmazások fejlesztéséhez kiváló választás.

További írásaim is érdekelhetnek:

Egy cégvezető, aki bárcsak előbb váltott volna cross platform-ra
Egy keserű tapasztalat története

Not using cross platform is a guarantiueed failure.
A biztos bukás garantált. Forrás: Pixabay, @Kanerori

Ez a cikk egy megtörtént beszélgetés alapján született. A cégvezető kiléte természetesen nem publikus, de nem is ez a lényeg. Számos hasonló eset történhet meg bárkivel, aki nem vált időben cross platform-ra.

Előzetesen tisztázom a fogalmat, hogy mit is a cross platform (kereszt platform).

Cross platform: olyan technológiai megoldás, amivel úgy lehet több eszközön is működő megoldást létrehozni, hogy minimalizálja a ráfordított időt. Ez azt jelenti, hogy 2 fejlesztő helyett elegendő lehet 1 fejlesztő alkalmazása.

Natív vagy cross platform megoldás legyen?

Az alábbi eset egy partneremmel esett meg, ami szerintem nem egyedi.

Mobil app-ot kezdett fejleszteni, két csapattal, két platformra, Android és iOS. Klasszikus fejlesztési gyakorlat, amikor egyszerre kell mindkét operációs rendszert támogatni. A gyors felhasználóbázis növelés miatt az Android, a fizetési hajlandóság miatt az iOS tábort kell elcsábítanunk.

Történt aztán, hogy a két csapat nem egy ütemben tudott haladni a feladattal. Az egyiken már megvoltak a funkciók, de a másikon elakadtak. Ha a felhasználók felé 1 terméket kommunikálunk, akkor nem megengedhető a féllábas megoldás. Ez persze borította a projekttervet. Annál később lesz várható bemutatható verzió. Annál tovább kell várni a bevételekre.

A bajt tovább tetézte, hogy az egyik csapat nem tudta tovább folytatni a munkát. Az a platform elakadt. Tehát már van egy félig kész termék az egyik oldalon, és még sehogyan sem áll a másik. Ez látható, hogy igen gyorsan költséges folytatás lesz.

Most arról nem is szólnék, hogy mi van akkor, ha a két csapatnak azon kell egyezkedniük, hogy melyikük megoldása maradjon a végső? Nem pontosan ugyan úgy néz ki a két operációs rendszeren a felület, vannak eltérések.

A történet vége az lett, hogy el kellett dobni mindkét, natív megoldást, és újrakezdeni egy közös cross platform keretrendszerben. Ez végül a Flutter lett (bármelyik megfelelt volna). Látható, hogy a végén nagyon megdobta a fejlesztési költségeket, időt. Ez minden cégvezető rémálma.

Mutatok néhány ismerős megoldást, ami szóba jöhet, mint mentőöv.

Ezek bizonyítottak a cross platform megoldásokkal

Az első ilyen cross platform a Java nyelv volt. Írjuk meg egyszer az alkalmazást, és futtassuk azt többféle operációs rendszeren. Legyen az Windows, Linux vagy Mac OS. Az elmúlt években a Kotlin nyelv feltörekvőben van a Java mellett. Biztonságosabb kódot lehet benne írni, és ugyan azt az ökoszisztémát használja, mint a Java, a JVM-et.

A web-en hamar előjöttek a böngészők sokfélesége. A fejlesztők sokat babráltak egy adott kinézettel, mire elnyerte végső formáját az ismertebb böngészőkön. Ki ne emlékezne erre az időszakra, amikor a 2000-es évek elején többször kellett megírni azt a fránya FrontEnd kódot, hogy mindenhol pixel biztos legyen. A szabványok aztán ezt szabályozták, és mára ez könnyebbé vált. A keretrendszerek pedig levették a terhet a fejlesztők válláról.

A mobilos világban több megoldás létezik.

Ilyen a React Native, a Flutter, a Cordova, a Xamarin, a Native Script. Mindegyiknek megvan a maga létjogosultsága. Egy közös van bennük, hogy ha egy csapat ismeri valamelyiket, akkor abban gyorsabban tud haladni az Android és iOS operációs rendszerekre szánt appokban.

Mi lesz 5 év múlva a ma működő cross platform megoldásokkal?

Az informatikában nehéz több évet előre jósolni. A ma még divatos, vagy népszerű eljárások, programnyelvek hamar népszerűtlenné válnak. A fejlesztők elpártolnak mellőlük, és már nem lesz annyira vonzó. Ezután pedig nehézkes lesz olyan szakembert találni, aki a meglévő termékünket képes javítani, vagy továbbfejleszteni.

Ez egy trend, és nem új dolog. Ez elkerülhetetlen, ami várhatóan utolér egy terméket. Lehet körültekintően választani a különböző programozási nyelvek közül, de garancia nincsen. Egy jó megoldás lehet ilyenkor, ha körülnézünk, hogy egy adott nyelvet mire használják a fejlesztők, és ez alapján választunk.

Ha nem csak egy adott, speciális területre vethető be a nyelv, akkor jó eséllyel vonzó marad évek múltán is, és lesz, aki használja. Ilyen például a népszerű JavaScript nyelv, ami 1996-os megjelenése után a 2000-es évek elején kezdett elterjedni. Ma már szerver oldali kódokat is írnak benne, nem csak a böngészőkre szánt FrontEnd-et. Bár sokan nem szeretik, azonban várhatóan még sokáig velünk marad.

Ha a fenti rossz forgatókönyvet szeretnéd elkerülni, vagy már megtörtént a baj, de szeretnél több infót gyűjteni, akkor keress meg az elérhetőségeim egyikén. Egy rövid beszélgetéssel megnézzük, hogy neked mi válna előnyödre.

4 nyomós ok, amiért most megéri a Flutter fejlesztés
2021-ben a mobil app-ok további lendületet kapnak

A Flutter cross-platform terjedőben van.
forrás: Pixabay.com

A nyár nem telik el eseménytelenül. A Webuni szervezésében Augusztus 10-én velem együtt három, a mobil alkalmazások fejlesztésben jártas szakembert kérdeztek meg a Flutter fejlesztés előnyeiről, jövőjéről. Nagyon jó beszélgetés kerekedett, amiből elhoztam 4 fontos kérdést, amire érdemes figyelni. Lássuk is!

Az eredeti teljes YouTube videó megtekinthető, amiből összefoglaltam a lényeget.

A webináron társaim voltak Juhos István, Senior Software Engineer, a BME oktatója; valamint Vogel Csongor, Senior Android és Flutter Software Engineer, az ff.next nevű fintech startup senior munkatársa.

Aki nem akar kódolni, de érdekli a Flutter fejlesztés

Egy eszköznél mindig vonzó, ha minél előbb ki tudjuk próbálni. Bodor Ádám kérdésére, hogy mi kell hozzá, István válaszolt.

Az első és legegyszerűbbb, hogy a dartpad.dev, online felületén ki tudjuk próbálni a Dart nyelvet, valamint előre megírt Flutter minta alkalmazásokat. A kódot tudjuk módosítani, ami egyből kipróbálható.

Lehet-e a Dart nyelv ismerete nélkül, még egyszerűbben? Igen!

Ez a FlutterFlow, egy online felület, ahol Drag&Drop módon, össze lehet kattintgatni egy működő alkalmazást. Még eléggé kezdetleges, de folyamatosan kap új funkciókat. A lényege, hogy az ebből generált kód ténylegesen egy működő alkalmazást ad. Integrációt biztosít még a saját, meglévő szervereink API-jaival is.

Korábbi cikkeimben írtam a FlutterFlow online szerkesztőről és a Figma UICode pluginjáról. Ha bővebben olvasnál róluk, akkor kattints a linkekre.

Milyen a Flutter fejlesztés belépési szintje?

Amit ki lehet mondani, hogy a Flutter viszonylag kényelmes – mondja István. Az elején ugyan egy új nyelvet, a Dart-ot kell megtanulni. Ez azonban egy új, modern alapokra építkező nyelv. Ha valaki programozott már Java-ban, Kotlin-ban, Swift-ben, C-ben, akkor ez nem lesz idegen tőle. Az többi nyelvhez képest az eltéréseket megtanulja, átnézi a dokumentációt, és kezdhet fejleszteni. A Visual Studio Code (VS Code), Android Studio szerkesztők legenerálják a kezdő alkalmazást, ami működik, alap dolgokat meg lehet nézni benne. Sikerélmény van mindjárt az elején.

“Nincs még egy ilyen platform, amivel ilyen tooling-gal, ilyen gyorsan el lehet kezdeni fejleszteni.”
Juhos István

Le kell cserélni a régi kódbázist?

Ennél a résznél valós környezetből hallhattunk róla infót, hogy egy már megírt, régi alkalmazásnál ezt hogyan kell érteni. Csongor elhessegette azt az általános megközelítést, ami sok cégvezető rémálma: újra kell írni az egész alkalmazást.

Ennél vannak kifinomultabb módszerek. Egy nagy alkalmazásban, ha el tudunk különíteni modulokat / funkcionalitásokat (képernyőket), akkor oda befűzhető egy Flutter-ben megírt modul, ami Android-on vagy iOS-en jól működik.

Ez alapvetően már megköveteli a natív platform ismereteket. De jellemzően, ha 1 ilyen ember van egy csapatban, aki el tudja végezni az integrálást, akkor nagyban növelhető a produktivitás.

Milyen a munkapiaci kereslet a Flutter fejlesztés iránt?

Fontos kérdés, hogy ugyan sok fejlesztőt érdekel ez az újdonság, és szívesen fejlesztenek benne, de mégiscsak a piac fogja kifizetni a fejlesztő bérét. Erre a kérdésre többféle válasz született.

Nagyon le vagyunk maradva – kezdi ezzel a felütéssel Csongor. Európában a lengyelek élen járnak a technológia alkalmazásában. Nyugat-Európában felismerték, hogy a régen megírt alkalmazásokat vagy Flutterben érdemes újraírni, vagy apránként, a modulokat lecserélni benne. Merthogy erre is van lehetőség. Távol-keleten, Kínában egy nagyon erős növekedés látszik. Indiában pedig az olcsó fejlesztési költségek további versenyelőnyhöz juttatják a megrendelőket.

István azzal kezdi, hogy ha van angol tudás, és hajlandóság megtanulni valami újat, akkor nyugodtan pályázzunk külföldi állásokra. A mostani távoli munkavégzési lázban égve sokkal elérhetőbbek lettek a külföldi munkahelyek is. Nem szükségszerű a kiköltözés, hanem remote munkák itthonról is végezhetőek. Maga egy-egy interjúzás tapasztalata pedig felbecsülhetetlen.

Zárásként a magam véleménye erről az, hogy ha megvan már egy natív Android-os vagy iOS-es tudás, akkor amellé mindenképpen érdemes egy valamelyik cross-platformos keretrendszert megismerni. Előnye ennek, hogy a másik operációs rendszerre is tudunk fejleszteni, kevés hozzátanulással. Ha pedig a Flutter fejlesztés megtetszett, akkor érdemes azt elmélyíteni, és munkát keresni.

Ha megtetszett a Flutter, de nem tudod, hogy hogyan indulnál neki, vagy csak támogatásra van szükséged benne, akkor keress meg a kapcsolataim egyikén.

Low-code: A templatek hódítanak a mobil app fejlesztésben is

forrás: docs.getwidget.dev/gf-avatar/

A 2021-es év a low-code templatek jegyében indul. Egyre több eszköz jelenik meg, ami a digitális termékek előállítói életét megkönnyíti. Azt már megszokhattuk, hogy a Flutter csomagok között biztosan találunk olyat, ami megfelelő lesz számunkra. Itt van egy ingyenes, közösségi megoldás, ami egy egész csomagot ajánl.

A GetWidget oldala szerint egy “free” és “open source” megoldásról van szó. Tehát nyugodtan kipróbálhatjuk. Olyan könyvtárgyűjteményt kapunk, ami készen tartalmazza a beépíthető komponenseket.

Nem mindenki kedveli a készen kapott dolgokat. Ráadásul a Flutter pont arról ismeretes, hogy könnyen alakíthatóak ki új widget-ek benne. Minden esetre egy gyors Mock-up-ra, mint annak idején aminek a Bootstrap is indult, kiválóak.

Nézzük néhányat ezek közül, amik említésre méltóak.

Az Avatar ikonok

Minden valamire való app első számú összetevője. Ennek szerepe az egyediség érzetét kelti, és emiatt a ragaszkodás is jobb az alkalmazáshoz. Látjuk, hogy ez a “miénk”.

GW Avatar változatok a low-code templatek között
GW Avatar változatok

Kártyák (tile)

A Flutter alap beépített ListTile nem kellően testreszabható. Ezt érezték meg a szerzők, és több változatot készítettek belőle, ami low-code templatek formájában elérhetőek. Számos paraméterezhető beállítással.

GW Tiles a low-code templatek között
A title komponensek divatos formában

Sticky header

Van egy komponens rendszer a Flutterben, a Slivert. Ez a komponens működése ezt implementálja, csak jóval egyszerűbb beállítani.

Ha nem ismered ezt a fajta UI elemet, akkor érdemes megnézni működés közben.

Stick header a low-code templatek között
Slivert, egyszerűsítve a Sticky headers-ben

Shimmer effekt

A közösségi app-ok kedvelt vizuális megjelnítése. Töltés közben, amíg nem kapunk tartalmat, helykitöltők jelennek meg a képernyőn, és pár másodpercig nem az üres, fehér kijelzőt kell bámulnunk. Helyette egy pulzáló felületet, és jön a tartalom. Ez tipikusan egy olyan a low-code templatek közül, ami sok munkával lenne csak meg, itt viszont készen kapjuk.

Erről van szó.

On-boarding készen

Az első használatkor meg kell kedveltetni az alkalmazásunkat a felhasználóval. Erre van az on-boarding, vagy magyarul a bevezető folyamata. Az ehhez tartozó komponenst itt találjuk.

Ezek a low-code templatek, amik megragadták a figyelmemet. Remélhetőleg a csomag tovább fejlődik. Eddig ígéretes.

Ha még nem tetted meg, csatlakozz a Flutter (Dart) Hungary LinkedIn csoporthoz, ahol érdekes közösséggel beszélgetünk hasonló témákról.

Low-code témában a UICode Figma plugin-jéről korábban írtam.