Élő kódolás demó : Flutter alapok

Május 3-án a Veszprémi Technology Meetup (VTM) meghívott vendégelőadónak, hogy beszéljek a mobil crossplatform előretöréséről 2022-ben. Ezen belül is a Flutter keretrendszerről, ami kilőtt az utóbbi időkben, és hamar a mobil app fejlesztők kedvence lett. Egy látványos, élő demó keretében adtam ízelítőt a Flutter lehetőségeiről.

Ha inkább a videó formátumot kedveled, akkor itt megtekintheted a kb. 45 perces előadásomat az élő demó bemutatóval. A cikkben kiemelem a fontosabb részeket, amikről szó volt.

GitHub repo: https://github.com/vborbely/english_words

Mi a Flutter?

A Flutter egy UI kit a Google-től, ami a cross-platformos fejlesztést támogatja Android-ra, iOS-re, Web-re, asztali alkalmazásokra (Desktop). A Flutter 2017-ben került először a nagyközönség elé.

A keretrendszer nyelve a Dart, ami mai modern alapokra épít. Nagyban hasonlít a C# és a Java nyelvekre, így könnyedén elsajátítható.

Ez készült el a Flutter demó során

Az alábbi videó a kész alkalmazást mutatja be. Ez készült el a demó alatt, kb. 25 percben.

Flutter demó app crossplatform-ra megírva
A kész Flutter demó app

Az alapoktól indulva, hogy hogyan kell egy projektet létrehozni. Az első váz átalakításával 2 képernyőt hoztam létre.

A főképernyő (HomeScreen) egy véletlen szópárokból álló lista képernyő, ahol a kedvencnek megjelölt szavakat megjegyzi.

Ezután a kedvencek (FavouriteScreen) képernyőre lehetett navigálni, ami ezt a kiválogatott listát mutatta be.

A feladat érdekessége volt, hogy hogyan lehet más csomagokat (package) felhasználni. Egy mobil appokban megszokottan használt tárolóból, vagy távoli API hívásból vette a szimulált adatokat. Ez az un. “mock-olt repozitori”.

Az is megvalósításra került, hogy amikor elértük a lista alját, akkor új elemeket “töltött” be a tárolóból, un. “lazy loading” megoldás, vagy más néven lapozás.

Természetesen a megoldásban az volt a legcsodálatosabb, hogy keresztplatform lévén, a megírt kis demó app futott gond nélkül iOS szimulátoron, Chrome böngészőben és MacOS natív desktopos alkalmazásként is. Emellett támogatja még a Linux és Windows desktop operációs rendszereket is.

Egy tesztelési demó is következett. A Flutter a Unit, az Integrációs és Widget teszteket támogatja. Ezek közül a widget tesztek egy speciális formáját, a Golden sample testing-et mutattam be.

A Golden tesztelés egy olyan tesztelési eljárás, ahol a meglévő UI kinézetünknek megvan a pixelpontos képe JPG, PNG formátumban, és ehhez hasonlítjuk a tesztelés során keletkezett képeket. Ha valamit módosítunk az alkalmazásunkban, és a kinézet megváltozik, és a minta-képnek nem megfelelő, a teszt megbukik.

Automatizált teszteléshez nagyon jó. A videóban a 28:30-tól kezdődően.

Kinek ajánlott?

A Flutter keretrendszer piaci fogadtatása nagyon jó. Ehhez hozzájárul az, hogy a crossplatform keretrendszerekkel a kb. 50-70%-os megtakarítás ténylegesen elérhető. Fele annyi fejlesztő kell. Nem szükséges minden fejlesztőnek Mac gépeket vásárolni, hanem az olcsóbb x86-x64-es architektúrák is jó.

A végleges app elkészítésére pedig számos online eszköz létezik: CodeMagic.io, Bitrise.io, GitHub Actions, stb.

Tény, hogy Magyarországon lassan indult be az elfogadottsága, de Nyugat-Európában már csak ezt keresik, a keresztplatformos fejlesztőket (a React Native mellett). Mivel nagy a kereslet a fejlesztők iránt, ezért Freelancerként könnyű lesz változatos feladatokat találni.

A keretrendszer megtanulhatóságában segít, hogy sokat kölcsönöz a meglévő frameworkökből: React Native, Android Jetpack Compose, Apple SwiftUI

 FrontEnd fejlesztőként a meglévő (csapat)tudás nagyon jól újrahasznosítható. Ha nincsen frontendes előélet, akkor annak is jó, aki BackEnd fejlesztésről, vagy más területről érkezik, mert tudásfrissítésnek is megfelel.

Olyan nagy autógyártók ismerték el, és kezdték el használni, mint a Toyota, BMW. Az infotainment fedélzeti rendszereiket bízzák rá. Nem meglepő, hiszen folyamatos a teljesítményre optimalizálás: 60 FPS képernyő frissítési frekvencia; kis memóriaigény; stb.

A bankok közül elsőként a NuBank gondolt egy nagyot, és kezdte el használni.

A játékfejlesztők szeretni fogják, mert egyre több támogatás érkezik rá (Rive, Flame). Az, hogy egy nagyon vékony réteggel kapcsolódik a hardverhez, és kihasználja a CPU-t, nem meglepő ez a lelkesedés.

Lehet, hogy a Flutter most egy “hype”, és nem lesz mindenre jó, de nagyon sok mindenre igen. Érdemes vele megismerkedni, mert ígéretes jövő elé néz.

A videóban bemutatott cross-platform módszert érdemes minél előbb alkalmazni a mobil app fejlesztési projektekben. Persze nem csak ott!

Ha még bizonytalan vagy, vannak kérdéseid, nem tudod, hogy hogyan vágjál bele, akkor keress meg az elérhetőségeim egyikén. Szívesen átbeszélem veled a lehetőségeket, a szükségleteidet.

Igény esetén beindítom a projektet, együtt dolgozva a meglévő csapatoddal.

2 év és 10 ügyfelem kiszolgálásának tapasztalatai
Egyszer fent, egyszer lent

Amikor belekezdtem a saját vállalkozásomba, kevés elgondolásom volt a vállalkozói létről. Halványan körvonalazódott egy cél, egy vízió, de a gyakorlat hozta meg az igazi tapasztalást. Tudtam, hogy szeretek emberekkel foglalkozni, szeretem a vállalkozás vezetést. Sok mindennel találkoztam az elmúlt 2 év és több, mint 10 ügyfelem projektje kapcsán, amit összegyűjtöttem.

Honnan lesznek ügyfeleim?

Kezdőként a legnehezebb bejutni a piacra. Nem kezdőként pedig bent maradni 🙂

A viccet félre téve, valahol el kell kezdeni. Először érdemes egy listát készíteni, hogy mihez értesz. Mi jöhet számításba? Hogyan fog a saját szolgáltatásod beleilleszkedni a mindennapjaidba. Igen, jól olvasod! Ha a munkaidőd után kell még plusz tanulással, ismeretek elsajátításával és munkával foglalkoznod, akkor azzal kalkulálnod kell.

Kicsit könnyebb, ha már pl. a meglévő tudásodat kell eladnod. Persze felkészültnek kell lenned, ezért bele kell tenned a munkát, minden nap.

Nem árt, ha van egy víziód, hogy merre fog tartani a piacod. Ha meglátod a lehetőséget egy felfutó vagy felkapott dologban. Ezért kezdtem én a Flutter irányába fordulni. Az egyre nagyobb programozói hiány, és a digitalizáció miatt egyre több és több IT projekt kiszolgálását nem lehet könnyen megoldani. Paradigma váltásra van szükség. Ezt hozza el a Flutter cross-platform (keresztplatformos) megoldása. Szükség lesz Webre, mobil app-okra, esetleg asztali alkalmazásokra, amit egyre kisebb, de hatékonyabb csapatokkal kell megoldani. Erről írtam korábban pár gondolatot.

Keresd a saját területeden, hogy miben vagy jó? Nem kell világmegváltás, csak a saját, más nézőpontod.

Számos helyen kereshetsz ügyfeleket: LinkedIN, Facebook, freelancer portálok, stb.. A lényeg, hogy passzívból aktívba kell átmenned! A “várakozóból” a “cselekvőbe”. Meg kell szólítanod Ügyvezetőket, CEO-kat, CTO-kat! Céges honlapokat kell böngészned, hogy szükség lehet-e valamire nekik, ami neked van. Ez egy másfajta gondolkozást igényel, mert észre kell venni, hogy te most nem terméket akarsz vásárolni tőlük, hanem pontosan annak a terméknek a fejlesztésében akarsz segíteni.

Ez talán az egyik legnehezebb része: láthatónak lenni. Én alapvetően nagyon nehezen írok emailt, hívok fel telefonon cégvezetőt, de ezt kell tenni. Minél többet gyakorolsz, annál jobban fog menni! Kitartás!

Ki mondja meg a következő lépést?

Bármibe is kezdj, senki sem fogja megmondani, hogy hogyan csináld. Ez nagyon jó, és felemelő érzés, hiszen ezért kezdted el az egészet 🙂

Másrészről kőkemény kitartást igényel. Napi szinten kell sok döntést meghoznod. Csinálnod akkor is, amikor nem látszik. Stratégiákat kigondolnod, amiket működtetned kell.

Kipróbálsz egyvalamit, ami mellett ki kell tartanod. Nem lehet csapongani. Melyik lesz a te formátumod? A te hangod? Konzisztensnek kell maradnod, de időnként át kell nyergelned másra, hogy azt is kipróbáld. Ez lesz a stratégia része, hogy ezt hogyan tedd?

Csábító a sok-sok platform, ahol megmutathatod magad. Melyiket válaszd? Nos, a mai trendek azt mutatják, hogy bárhova bele lehet “paszírozni” az üzenetedet. De jó ez neked? Hiteles vagy? Kell-e neked?

Gondold át, hogy melyik az, amit (az elején) egyedül, rendszeresen tudsz üzemeltetni? Meg tudod tanulni ezen keresztül, hogy mit szeretnél elmondani. Amikor ki kell szervezned (delegálni), akkor tudd, hogy miről beszélsz, mert érted.

Senki sem fog helyetted gondolkozni, cselekedni.

Neked kell a szerződéseid feltételeit kidolgozni. Nem elsőre, de a harmadik-ötödik-tizedik után már rá fogsz érezni.

Az ügyfelemet a saját üzlete érdekli

Az ügyfelemet természetes módon a saját üzlete érdekli. Nem szeretne mélységeiben pl. a technológiával foglalkozni. Ez rendjén van így. Nem azért választott engem, hogy még több feladatot és fókusz-elvonást kapjon cserébe. Helyette nekem együtt kell élnem az üzletével, a víziójával. Megpróbálom átérezni “helyette”, hogy mi a fontos neki. A biztonság.

Az, hogy ami már működik, az továbbra is működjön. Ha új igények jönnek a termékével kapcsolatban, az belátható időn belül elkészüljön. Ezzel aztán újabb, vagy a meglévők közül elégedettebb vevői lesznek. Ami további bevételt jelent neki. Tehát (áttételesen) én is részesülök belőle.

Az üzleti életben, ha fizetsz egy szolgáltatásért/termékért, és az pont csak annyit hoz, mint amennyit rászántál, akkor nullán vagy, nem történt semmi.

Érdemes volt kipróbálni! Ha egy kiadás újabb bevételeket generál, akkor megütötted a főnyereményt. Ennyire leegyszerűsíthető.

A bizalmadat veszik meg

Amikor végre megvan az ügyfél, próbáltok közösen dolgozni. Te pl. szoftvert fejlesztesz neki, ő pedig szerzi a vevőit.

Ebben az együttműködésben olyan belső “titkokat” is látsz, amit kívülálló nem. Látsz olyan, működésbeli hibákat, amiket a partner nem biztos, hogy lát, mert ő hajtja az üzletét. Ha van rá lehetőséged, segítsd azzal, hogy ezeket a tudtára hozod. Biztosan meg tudjátok közösen oldani, és te annál értékesebbé válsz ebben a kapcsolatban.

Légy olyan partner számára, akire számíthat a nehéz időkben (ilyenből kijut bőven egy vállalkozásban)! Rendezkedj be hosszú távra vele kapcsolatban.

Mi van akkor, ha már nem működik a kémia? Nos, előfordul. Csalódás van bármelyik oldalon. Ezt vállalni kell, és nyíltan megbeszélni. Nem házasságot kötöttetek, hanem üzletet. A megfelelő határidőket betartva, békében abba lehet hagyni a közös munkát.

Ettől emberileg még értékelhetitek egymást, hiszen a szakmai oldalon romlott el valami. Kicsi a (világ) piac, és nem tudhatod, hogy mikor fog neked segíteni újra, vagy éppen Te tudsz egy jó tippet adni neki.

Jó vállalkozást kívánok és kitartást hozzá!

iOS mobil fejlesztő Flutter keretrendszerrel
Mennyibe kerül egy iOS fejlesztő?

Az elmúlt közel 3 évben aktívan használtam a Google megoldását mobil fejlesztésre. Ez a Flutter. Azóta kiderült, hogy nem csak mobil appok írására kiváló. Weblapok, vagy akár asztali alkalmazásokban is bevethető. Vetődik fel a kérdés 2022-ben: lehet-e egy iOS mobil app fejlesztő helyettesítője egy Flutter mobil fejlesztő?

A cikkben azért választottam az iOS fejlesztő munkakört, mert nagy szükség van várjuk, de igencsak drágák. A bérekben akár másfél-kétszeres lehet a szorzó (Android fejlesztő, iOS fejlesztő). Van-e alternatív és jó megoldás?

Mennyibe kerül egy iOS fejlesztő?

Egy jó iOS fejlesztő kiváltható egy Flutter fejlesztővel?

Az igazság az, hogy: ATTÓL függ!
Ha a pénztől tesszük függővé, akkor IGEN a válasz. Ha csak a költségeket nézzük, és nagy szükségünk van egy iOS mobil appra, akkor a keresztplatform (crossplatform) irányába kell keresgélnünk.

Ha nagyon erősen mobilra optimalizált megoldás kell, akkor NEM (biztos)! Nagyon erős mobil megoldás lehet, a videó streamelés, videóvágás, hangfelismerés, 3D játékok, stb. Rögtön hozzáteszem, hogy ez sem teljesen van így. Rengeteg szolgáltatás, megoldás már a felhő erejét használja, és az iPhone-ról leveszi a terhet.

Minden másra ott van a Flutter keretrendszer.

iOS fejlesztő helyett Flutter fejlesztőt alkalmaznál?

Bizony, 2022-ben már kijelenthető, hogy 1-1,5-2 Flutter fejlesztő áráért egyből 5 fejlesztőt kapsz!

1-1,5-2 = 5x


Ez eléggé talányos mondat, belátom.

Az egyenlet megoldása az, hogy nemcsak iOS fejlesztő az, akit kapsz. Egy keresztplatformos fejlesztő révén Android (mobil), Web (FrontEnd), Windows, Linux, Mac OS (Desktop) is jár.
(Az persze érdekes kérdés, hogy ki fejleszt manapság desktopra? A Google Február 3-ai bejelentése pont erről szólt, hogy a Windows-ra kijött a stabil keretrendszer.)

Érdekes tény, hogy kevés az a mobil app, amihez az utolsó csepp erőforrást, az utolsó feature-ket is kellene sajtolni a telefonból.
Bizony! A fejlesztő ideje meg véges, tehát a rendelkezésre álló fejlesztők száma is véges.

Jó Startupoknak is?

Ma az van, hogy “hamar-gyorsan” kell 1-2 app validálásra, olcsón, aztán menjünk tovább! Többször, ismétlődően: új funkció -> tesztelés -> új funkció -> tesztelés …
A pedig nagy előny, ha a validálás után nem kell eldobni a prototípust. A felhasználói tesztek után onnan lehet folytatni (profin), ahol abbahagytuk.

Többször elmondtam, és most is leírom, hogy egy vállalkozásban egy mobil app csak az egyik elem. Ez egy szükséges kellék, de nem ettől fog működni. Viszont ha nincsen, a felhasználókat nehéz megszólítani.

Tehát kell a mobil app (Mobile-first megközelítés)!

Konklúzió

Körbejártuk a témát, ami ma az iOS fejlesztő kereslet-kínálati piacot súlyosan érinti. Közben lehet, hogy nem is natív fejlesztőt kell keresned, hanem egy megbízható, de nem kompromisszumos megoldást.

Ha IT vezető, CTO, CEO, stb. vagy, és még nem hallottál a Flutter-ről, akkor javasolom, hogy sürgősen szánj rá 2 percet! Kezd a cikkeimmel itt az oldalamon.

De számos helyen tájékozódhatsz, egyre többen szeretik használni. A Flutter népszerűsége töretlen 2022-ben is.

Ha mobil app fejlesztését fontolgatod, de nem tudod, hogyan kezdj bele, akkor keress fel bizalommal az elérhetőségeim egyikén. Egy egyórás, ingyenes tanácsadás keretében megnézzük, hogy mire lenne szükséged, és merre indulj el.

Egy beszélgetés nem jár semmiféle kötelezettséggel, viszont magabiztosan tudsz dönteni a több információ ismeretében.

Chrome böngésző bővítmény készítése Flutter UI kit segítségével
Flutter Web bővítmények fejlesztésére

A Flutter Web által készített böngésző bővítmény
példa My Activities bővítmény a Chrome-ban

Nem mindig van szükség mobil app-ra egy feladatnál. Sőt, ha valaki böngészőben dolgozik sokat, akkor a kis felületen matatni hosszú órákon át, idegesítő. Az egyértelműen látszik, hogy a web böngészők dominálnak az asztali alkalmazások felett. Az online szolgáltatások elképzelhetetlenek nélküle. Van egy másik kör, ami még ide tartozik, a beépülő bővítmények (extension).

Mi a böngésző bővítmény?

A böngésző bővítmények már régóta velünk vannak. Sokan használjuk őket hasznos kiegészítőként napi feladataink során. Ezek olyan részei a böngészőknek, amit lelkes fejlesztők, vagy éppen komoly cégek fejlesztettek, és tettek elérhetővé. Vannak ingyenes és fizetős változataik. Képesek egészen komplex működéseket megoldani, kiterjesztve az alap böngésző tudását.

Mivel a böngészőt fejlesztő cégek (Google, Apple, Microsoft, stb.) csak a keretet adják, bárki írhat bővítményt. A keret adott, a szabvány adott, csak ötlet kell, hogy milyen problémát oldhatna meg ez a hasznos eszköz. Mivel kéznél van mindig a böngészőben, ezért nem kell elhagyni az ablakot egy funkcióért, ezáltal javítja a felhasználói élményt (UX).

Mit fogunk készíteni?

A lenti videón bemutatom, hogy pár óra alatt, mit lehet elkészíteni a Flutter Web-bel. Nem kell hozzá FrontEnd-es ismeret, és JavaScript kódokat írni.

Chrome böngésző bővítmény működés közben

Így kell megírni egy böngésző bővítményt

A cikk megírásában segítségemre volt ez a post.

Ha gyorsan ki szeretnéd próbálni, akkor ugrás a végére, a Letölthető anyagok fejezethez!

Hozzunk létre egy alap Flutter alkalmazást a szokásos módon. Ezt megtehetjük parancssorból a “flutter create app-neve” paranccsal, vagy Android Studio-ból.

Ezután az index.html file-ban cseréljük le a <script> tag-ben lévő sorokat az alábbiakra.

<body>

<script src="main.dart.js" type="application/javascript"></script>

</body>

Következő lépésként a manifest.json file tartalmának ezt adjuk meg. A name és description szövegek tesztőlegesen megadhatóak. Ez a böngészőben megjelenő név, és a böngésző bővítmény leírása lesz.

Megadhatunk saját ikont is, de figyeljünk, hogy PNG kép formátumú legyen, különben a böngésző nem jeleníti meg!

{
  "name": "flutter_chrome_extension",
  "description": "flutter_chrome_extension",
  "version": "1.0.0",
  "content_security_policy": {
    "extension_pages": "script-src 'self' ; object-src 'self'"
  },
  "action": {
    "default_popup": "index.html",
    "default_icon": "/icons/Icon-192.png"
  },
  "manifest_version": 3
}

Ezután nincsen más hátra, mint készíteni egy build-et az egészből az alábbi parancsot kiadva egy terminál ablakban:

flutter build web --web-renderer html --csp

Ez létrehoz egy /build/web könyvtárat, amibe benne van az összes szükséges file.

Ennek a csomagnak a tartalmát tudja felolvasni a Chrome böngésző bővítmény kezelője. Adjuk is hozzá!

Megjegyzés: mivel ezt a kiegészítőt teszt jelleggel hoztam létre, és nem publikáltam, ezért fejlesztői módban kell elvégezni a betöltését. Lásd alább!

Chrome -> Beállítások -> Bővítmények -> váltsunk át fejlesztői módra -> Kicsomagolt elemek betöltése… gombra kattintsunk.

Itt keressük meg a könyvtárat, és máris települ az új kiegészítőnk. Ezt rögzíthetjük a böngészőben, hogy gyorsan elérjük:

Így tudjuk kitűzni a böngésző bővítményt
Böngésző bővítmény kitűzése

Letölthető anyagok

GitHub repo: https://github.com/vborbely/my_activities_chrome_extension

A telepíthető Chrome bővítmény (ZIP) és a leírást megosztottam.

Ha te is gondolkozol böngésző bővítmény fejlesztetésében, akkor keress fel bizalommal az elérhetőségeimen, hogy átbeszéljük. Ha csak tanácsot szeretnél kérni, vagy egy jót beszélgetni, arra is nyitott vagyok 🙂

Korábbi cikkeim is érdekelhetnek a témában. Jó tájékozódást!

2022-re versenyhátrány lesz a natív mobil alkalmazás fejlesztés módszer
Most még nem késő váltani

forrás: Pixabay / stevepb

Látszik a kiélezett harc a két nagy mobil platform óriás, a Google és Apple között. Mindegyik dominanciára törekszik, azonban más-más piacokon teljesítik túl egymást. A harc inkább a felszín alatt dúl, azonban cégtulajdonosként mindkettő piacnak meg kell felelni. Mégpedig gyorsan, ha felhasználókat akarunk szerezni. Tovább nehezíti a fejlesztési költségek kordában tartását, hogy a Huawei is kijött a saját platformjával. Ezáltal ismét sokszereplőssé válik a tér.

Hogyan áll a piac a mobil platformokkal?

Amióta 2007-ben az Apple előrukkolt az érintőképernyős mobilokkal, majd a következő évben a Google is követte, egy korszak indult útjára. Megszülettek a mobil app-ok. Ezután a Microsoft is beszállt harmadikként a nagyok közé, a Windows Phone-nal, de ez mára kihalt.

Ki merne ma beszállni a nagyok közé? A Huawei kényszerűségből felvállalta. Bár neki egy kellően nagy piaca van, de a siker még így sem garantált. A Huawei 2021-ben már hivatalosan is a Harmony OS-t jelentette meg, elsőként a Huawei P50 sorozaton.

Ez persze nem nevezhető trendnek, hogy várható további platform, de minden esetre érdemes időről időre felkészülni erre a ritka eseményre. Mobil fejlesztőként pedig adaptálódni a kívánalmakhoz.

Mi az új módszer a mobil alkalmazás fejlesztés területén?

A cross-platform, vagy más néven keresztplatformos fejlesztés nem idei találmány, de talán elmondható, hogy nagy lendületet kapott. Ennek oka, hogy a digitális termékek száma tovább nő, viszont nincsen elegendő számú szakember, aki ezeket elkészítse. Ma már 10-30 fős csapat kell egy jelentős alkalmazás előállításához: architekt, fejlesztő, tesztelő, UX/UI researcher, Business Analyst (BA), PO/PM, stb.

Belátható, hogy ha egy-egy területen lehet picit is költségeket vágni, akkor előnyre tesz szert a vállalkozás. A cross-platform mobil alkalmazás fejlesztés módszer pont ebben rejlik:

Írjuk megy egyszer, és használjuk fel többször.

Ne kelljen ugyan azon a megoldáson két különböző csapatnak dolgoznia, duplikálva ugyan azt a munkát. Márpedig a natív fejlesztésnek ez a hátránya. Ráadásul sokszor vita tárgya, hogy melyik csapat megoldása a jó. Melyik maradjon? Nem beszélve a fejlesztések közötti sebességről, ami az egyes kiadások határidejét tolja egyre távolabb.

A mobil fejlesztés ezen módszerét már korábban felismerték, és az utóbbi időben előtérbe kerültek a jó minőségű keretrendszerek. Ezek közül a React Native és a Flutter a kiemelkedők, amik uralják a fejlesztők piacát.

Mi az előnye és hátránya a cross-plaformnak?

Előnyök:

  • költséghatékony: egy új platformon való megjelenés nem jelent kétszer annyi időráfordítást
  • a tervezéstől kezdve közös megoldásban lehet gondolkozni, és csupán kevés helyen van szükség a platform eltéréseit figyelembe venni (ujjlenyomat olvasó vs arcfelismerés; GPS beállítások; egyéb engedélykérések; stb.)
  • hibatűrő: egy jó keretrendszer együtt fejlődik a Google vagy Apple operációs rendszerével, gyorsan reagálva rá
  • támogatás: élvezzük a hatalmas fejlesztői közösség nyújtotta előnyöket
  • egységes kinézet minden platformon
  • ugyan az a csapat készíti a kódot, és ezáltal nagyobb az összetartás

Hátrányok:

  • speciális, főként az eszköz hardver elemeire épülő technológiákat nem, vagy nem teljesen használja ki egy keretrendszer
  • a megszokott platform felhasználói felületei eltűnhetnek
  • új nyelvet kell megtanulni, ami időbe/költségbe kerül a cégnek

Látható, hogy a cross-platform módszer a mobil alkalmazás fejlesztésben egyértelműen előnnyel bír.

Van más megoldás is?

Mindezek mellett szót érdemel az egyre elterjedőben lévő low-code vagy no-code módszer. Itt arról van szó, hogy nem szükséges programozói fejlesztői tudás egy alkalmazás elkészítéséhez. A munka nehezét a keretrendszer támogatja, és “összekattintgatós” módszerrel bárki elvégezheti.

Ezeket a módszereket előszeretettel alkalmazzák a startup fázisban lévő, fiatal csapatok, akik gyorsan ki akarják próbálni a koncepciójukat egy mobile-first megoldással.

A programozói, vagy rendszerszervezői tudás ezeknél az eszközöknél nagy hasznát vehetik a “fejlesztők”, mert itt is igaz: a jó terv fél siker. Az absztrakt gondolkozásra szükség van, hogy a végtermék jó legyen.

Az idő meghozza, hogy mennyire érettek ezek a low-code eszközök.

Extra csavar, amit csak a Flutter tud

Természetesen a fejlesztők létszáma nem egyedül a mobil alkalmazás fejlesztés terén jelent gondot.

A Google a mobil platformok mellett a keresett FrontEnd-es szakmának is segít azzal, hogy a Flutter Web-et kifejlesztette. Aki eddig mobil fejlesztő, backend szerver oldali fejlesztő volt, ezáltal tud böngészőben futó web-alkalmazásokat (PWA) készíteni.

De a Flutter nem állt meg itt, hanem Linux-ra, Windows-ra, Mac OS-re is lehet vele natívan futtatható alkalmazásokat készíteni. Mindezt a megszokott tetszetős kinézettel, és a teljesítményre optimalizálva.

A fent bemutatott cross-platform módszert érdemes minél előbb alkalmazni a mobil app fejlesztési projektekben. Persze nem csak ott!

Ha még bizonytalan vagy, vannak kérdéseid, nem tudod, hogy hogyan vágjál bele, akkor keress meg az elérhetőségeim egyikén.

Szívesen átbeszélem veled a lehetőségeket, a szükségleteidet. Igény esetén beindítom a projektet, együtt dolgozva a meglévő csapatoddal.

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.