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.