Ez történt 2021-ben a mobil fejlesztési iparágban
Sűrű év volt a mobilok háza táján

2021 is over, let's see the summary of the year!
A kép forrása: Freepik / image

Az elmúlt év tovább erősítette a távolságtartásunkat egymástól, ami tovább növelte a digitális mobil termékek használatát. Új módszerek, szokások alakultak ki. A cikkben a több éve tartó megfigyeléseimet gyűjtöttem össze a mobil appok fejlesztési területén. Hozzátéve a saját meglátásaimat és előrejelzéseimet.

Mi új az Android 12-ben?

  1. Dinamikus téma színváltás a háttérképnek megfelelően: az Android 12 rácfelvarrást kapott a Material You kinézettel. Az újítás lényege, hogy a háttérként beállított kép alapján a színeket hozzáigazítja az egyéb felületeken. Továbbá, ha egy adott app fel van készítve rá, akkor az appon belül is megjelenik a témázás. Így sosem válnak unalmassá a felületek.
  2. Egykezes mód: megirigyelve a Samsung és a Xiaomi korábbi megoldásait, a Google beépítette ezt a beállítást az új, Android 12 változatába. Ezentúl a beállítások menüben könnyedén elérhető bárkinek.
  3. Gyorsindítás (Quick tap): az iOS 14-től lopva az ötletek, az Android 12-be is megérkezett a funkció. A beállításokban megadhatjuk, hogy mi történjen, ha a telefon hátuljára kétszer koppintunk. Egy általunk választott alkalmazás indul el.
  4. Személyes biztonság ellenőrzése (Privacy Dashboard): az idei évben a Google tovább erősítette azt a szándékát, hogy a személyes adataink a miénk, és nekünk van jogunk eldönteni, hogy kivel osztjuk meg. A felületen ellenőrizhető, hogy melyik alkalmazás, mikor, mihez fért hozzá a telefonunkon.
  5. Beszélgetés widget-ek (Conversation Widget): bármely chat alkalmazásunkhoz elhelyezhetünk kis felületeket a kezdőképernyőn, hogy lássuk a beszélgetéseinket.

Ezek csak pár az újítások közül, amiket az Android 12 verziója hozott nekünk.

Mit tudott hozzátenni az iOS 15?

  1. FaceTime és SharePlay: a megszokott FaceTime funkcionalitás tovább bővült, és a felhasználó került a középpontba. A háttér elmosódva látszik, ezáltal élesebb a résztvevő, valamint a hangzás is jobban kiemeli az aktuálisan beszélőt. A grid nézet pedig a több résztvevős beszélgetésekben segít egyszerre láttatni a partnereinket. A SharePlay tovább ment még ezen is, és a közös élmény megosztásra helyezi a hangsúlyt. Olyan, mintha a család (akik lehetnek több ezek km-re egymástól) ugyan azt a műsor néznék. Bárki beletekerhet a zenébe vagy filmbe. Együtt működik az Apple TV-vel, és könnyedén bevonhatóak az Androidos vagy Windowsos társaink is.
  2. Pici újítás a Safari böngészőben: nem tűnik nagy újításnak, de annál hasznosabb, hogy a böngésző címsora lekerült ujjközelbe. Az Apple felismerte, hogy ennek ott a helye, hiszen a böngésző elsődleges funkciója, hogy oldalakat nyisson meg. Ez pedig jó, ha kézre áll.
  3. Kocsikulcs, fizetés, személyi igazolvány minden egy helyen: az Apple Wallet-ben. A BMW volt az első autógyártó, aki az indítókulcsot elhelyezte a wallet-ben. Elő sem kell venni a telefont, hogy indítsunk. További megoldások várhatóak, hogy személyi azonosításra is alkalmas legyen, vagy akár reptéri azonosításra.
  4. Apple Maps, térkép: van még hova fejleszteni a navigációt. Részletesebb adatokkal látta el az Apple Maps-et. A navigáció hasznos infókkal látja el az utazót. A navigáció pedig az Apple Watch óráján folytatódik tovább. A telefon képernyőjén pedig nagyon pontos AR (Augmented Reality) élményt adó tájékoztatásokat jelenít meg.
Apple Maps street view with AR
A kép forrása: apple.com

Mindezek mellett számos újdonság, és haladó ötletek kerültek be az új iOS 15-be.

A Flutter új kiadása megcélozza a csillagokat

A tavaszi, márciusi 2.0-ás kiadás hatalmasat szólt, amikor a meglévő Android és iOS mobil platformok támogatása mellett a Google hivatalosan is “production ready”, vagyis stabil kiadássá nyilvánított még 4 platformot: Web, Windows, Linux, Mac OS operációs rendszerek.

Ezeket tovább tudta fokozni a 2.8-as verzió kiadásával. (Ami elhozta a Dart 2.15-ös kiadását is … mellékesen.)

Az új Flutter kiadás tovább fokozta a teljesítményt, még optimálisabbá téve a futtatást a mobil telefonokon, valamint a webböngészőben. A memóriafogyasztásból is sikerült lefaragni, amiről azt gondolhatnánk, hogy nem fontos a mai memória bővében lévő telefonokon. Nagyon tetszik, hogy a Google ezekre folyamatosan nagy hangsúlyt fektet, és nem lazít.

Az appok telepítőjének letöltési méretét kiadásról kiadásra csökkenti. Ez azért fontos, mert a natív Android vagy iOS applikációkkal szemben van egy 4-7 Mb-os többlete a Flutter app-oknak, amit úgy néz ki, a minimálisra akarja csökkenteni a Google. Ennek persze stratégiai okai is vannak véleményem szerint, hiszen ne felejtsük, hogy nem csak mobilokba szánja az alkalmazásokat a Google, hanem IoT eszközökbe. Itt már igen is van jelentősége pár Mb megspórolt kódterületnek.

A fent említett teljesítménybeli javulásnak van még egy nagyon pozitív üzenete. Mindezt ingyen! Nem nekünk kell ezzel törődni, hanem alapból jár, ha a legújabb Flutter SDK-t (Software Development Kit) használjuk. Melyik az a cég, ami manapság ingyen ad ilyet?

Egyre jelentősebb partnerek

Decemberben lett hivatalos, hogy a Samsung a Fuchsia OS-t (az Android lecserélésére szánt operációs rendszer) kívánja telepíteni a telefonjaira. Erre persze még néhány évet várnunk kell.

Nem ez volt az első, példa nélküli együttműködés, hiszen az év első felében a Microsofttal közösen fejlesztették, hogy a Flutter keretrendszerben megírt appok futtathatóak legyenek Windows rendszereken. Sőt, egy kezdetleges marketplace-t is kialakítottak, ahova további appok érkezhetnek. Ez, elnézve az Apple “side-load” (az, amikor nem csak a Store-ből lehet appot telepíteni, hanem más partnerektől letöltve) elleni kommunikációját tekintve egy másik szegmenst céloz. A Google mindazonáltal sosem próbálta beszűkíteni a partnereit. Minél inkább egy nyílt platformot hozott létre az évek alatt. Lásd a változatos mobil telefon és kijelzők felhozatalát.

A cikkben igyekeztem belesűríteni ezt a tartalmas évet. Nem minden fért bele, de a lényeg talán igen.

Lássuk mit hoz 2022!

A Fuchsia OS az Androidot válthatja a Google-nél
Új korszak kezdődik a mobilok világában

A Samsung és a Fuchsia OS - Samsung Community
A Google és a Samsung házassága. A kép forrása: Community.Samsung

Hozzászoktunk, hogy ha mobil telefonról van szó, akkor két nagy táborról beszélhetünk: Android vagy iOS. Bár nem csak ez a két platform létezik, piaci elterjedésük mellett eltörpülnek az egyéb megoldások. Az elmúlt időszak mobilos operációs rendszerek változatlanságát a Huawei Harmony OS bejelentése törte meg. Pár hónappal később pedig megérkezett a bejelentés: a Fuchsia OS hivatalos lett, és nem kisebb szereplővel karöltve, mint a Samsung.

Mi az a Fuchsia OS?

A codemagic.io egy posztban szedte össze, hogy mik az új Fuchsia OS várományos előnyei. Hogyan épül fel? Ezekből szemezgettem.

A Fuchsia OS egy olyan új operációs rendszer, ami szakít a Linux kernellel, és helyette a Zincorn mikrokernelt használja. A mikrokernelek általában a minimalitás elvét követik, és bár a Zircon alkalmazza a mikrokernelek által népszerűsített koncepciók közül sokat, nem törekszik a minimálisra. A Fuchsia mikrokernel architektúrája segít csökkenteni a rendszer futásához szükséges, megbízható kód mennyiségét.

A Fuchsia OS négy alapelve: biztonságos (secure), frissíthető (updatable), befogadó (inclusive) és gyakorlatias (pragmatic). A dokumentumok a következőképpen írják le ezeket az elveket:

  • Biztonságos (Secure): csak a legszükségesebb jogosultságokat kapja meg egy alkalmazás
  • Frissíthető (Updatable): akárcsak a webes tartalmak, az appok is jönnek-mennek egy eszközön. Ennek megfelelően a biztonsági frissítések bármikor megérkezhetnek a különböző eszközökre. Saját meglátásom: nem csak jogosultságokat fogunk ezután engedélyezni az appoknak (pl. saját GPS helyzetünk megadása), hanem ha kell, akkor egy biztonsági frissítés megléte is szükséges lesz, vagy egy biztonsági hardver komponens (chip) megléte is.
  • Befogadó (Inclusive): sok nyelvet támogat, úgymint C++, Web, Rust, Go, Flutter és Dart.
  • Gyakorlatias (Pragmatic): nem csak egy tudományos koncepció, hanem éles környezetre szánt rendszer, aminek meg kell felelnie az olyan alapvetéseknek, mint a teljesítmény.

Látható, hogy magában hordozza mindazokat a követelményeket, amiket az elmúlt 13 (14) évben a Google tapasztalatot összegyűjtött a mobil appok piacán.

Támogatja a Flutter-t?

Ahogyan a fenti cikk is írja, a Flutter-t alapból támogatni fogja. Mindamellett a meglévő Androidos applikációkat is.

A Fuchsia OS F4-es kódnevű release bejegyzése (2021. december 9.) pedig kifejezetten megemlít egy Flutter-es optimalizálást.

Release notes for Flutter on Fuchsia OS
Az F4 release bejegyzése

Mi lesz a Flutter jövője?

A Huawei korábban az Android rendszerre fejlesztett mobil appokat képes volt futtatni. Valamint a Harmony OS leírásokat átnézve látható, hogy gondolatvilágában nagyon sokat köszönhet a Google-nek. A Flutter fejlesztőknek szánt csomagkezelő oldalán sorra jelennek meg a GMS (Google Mobile Service) átiratai, HMS (Huawei Mobile Services) néven. Tehát a jövőben a Flutter app-ok futtathatóak lesznek a Harmony OS-en.

A fenti összeborulás pedig tovább erősíti a Google dominanciáját egy olyan piacon, ahol képes volt 13 év után megújulni a platform. Kinőtte a gyerekbetegségeit (teljesítménybeli lemaradás; sokfél kijelző támogatásának kényszere), sokat tanulva az elmúlt évekből. Az, hogy a Google hagyta (bizonyos licenszelési feltételek betartása mellett) ezt a sokszínűséget, mára nagy előnyévé vált.

Kétségtelen, hogy nem mindenkinek tetszik (a mostanában Apple által kirobbantott marketing kampánya a side-loading ellen) a biztonság oltárán feláldozott terjeszkedés, de az átlag felhasználónak nem mindig ez számít. Ugyanakkor mellé téve, hogy a Google az idei nyári Google IO konferenciáján minden megnyilvánulásában elszántan lépett fel a személyes adatok védelme mellett.

Minden esetre a Samsung Fuchsia OS rendszerre való áttérése még várat magára (néhány év), de a példán kapva elképzelhető, hogy több telefongyártó is követni fogja a példáját. Nem figyelmen kívül hagyva azt a tényt, hogy a Fuchsia OS az IOT eszközöket is be akarja venni (csakúgy, mint a Harmony OS nyilatkozataiban).

Személy szerint, amint én látok a Flutter-rel az az, hogy minden eszközt, aminek képernyője van, el akar foglalni. Aminek pedig nincsen kijelzője, oda a beágyazott (embedded) változatára készült Dart kódokat szánja.

Izgalmas időszak következik, és még van idő felkészülni rá.

Ha te is értékálló megoldásokat szeretnél létrehozni, de nem tudod, hogy hogyan indulj el, akkor keress bizalommal. Beszéljük át, hogy a te üzletedbe hogyan illeszkedik egy “Mobile-first” terv.

Tippek: Védd meg a tulajdonaidat
Egy mobil app tulajdonos erre figyel, hogy ne károsítsák meg

forrás: Pixabay / SarahRichterArt

Összeszedtem azokat a fő pontokat, amikre egy mobil app, vagy más digitális termék fejleszttetőjeként mindenképpen figyelj oda. Nem elegendő egy terméket beindítani valahogyan, de azt tudni is kell üzemeltetni. Mivel egy termék hosszú életű, érdemes már az elején lefektetni olyan alapokat, ami később sok fejfájástól kímél meg.

Előljáróban annyit tennék hozzá a továbbiakhoz, a több ügyfelemnél látott hibás gyakorlatokat gyűjtöttem össze. Ezek tehát sajnos megtörtént esetek, és csak a szerencsének köszönhető, hogy nem lett nagyobb baj (még).

Érdemes eljátszani a gondolattal, hogy …

Mi történne, ha már nem működne olyan jól az együttműködés egy partnerrel, egy fejlesztővel vagy fejlesztő céggel?

Alkalmazás nevének kiválasztása

A mobil appok több millióan vannak a Store-okban. Nehéz ma már kitűnni. Komoly kampányt kell kifizetni érte, hogy felfigyeljenek rá a felhasználók. Ha megvan a név, ami ASO kompatíbilis (App Store Optimization), és ezt elkezdjük bejáratni, akkor nagy veszteség, ha ezt elveszik tőlünk.

Figyeljünk oda, hogy milyen kiadóként szerepel a mi pénzünkön kiadott app az adatlapján. Ezt az alkalmazás részleteinél láthatjuk. Ezen a részen vannak kitöltve a cégnév, kapcsolattartók, webhely, egyszóval a fejlesztő elérhetősége. Ha nincsen meg a technikai tudásunk, és ügynökséggel fejleszttetünk, akkor erre figyeljünk oda, hogy jól legyen kitöltve, és ránk mutasson.

Esetleg érdemes megállapodni, hogy meddig lehet kint az ügynökség neve, pl. a fejlesztési költségek X %-ának kifizetéséig. De ezután mindenképpen állítsuk be!

Ez a része könnyedén átírható az áruházak adatlapjain. Van azonban egy rész, ami nem. Ez pedig a package id Android-on és bundle Id iOS-en. Ezek olyan az egész (világon) áruházakra jellemző nevek, amikből csak egy szerepelhet. Pl. com.facebook.app nevű alkalmazás csak egy létezhet. Sőt, az Apple-nél még az is megadható, hogy a com.facebook.* előtag után is foglalt legyen általunk. A lényeg, hogy lehetőleg ez a rész is minket azonosítson.

Jogosultságok beállítása

Ha már fent esett szól az app illetőségéről, akkor egy alapvető dolog, hogy ki az app tulajdonosa az áruházban? A Google Play-en Owner, az Apple Store-ban pedig Account Holder a neve ennek a szerepnek. Ezeket soha ne adjuk át másnak!

Minden alkalmazásáruház tudja, hogy többeknek, sokféle hozzáférést kell kiosztani. Beállításukhoz megfelelő jogosultságra van szükség. Csak a legszűkebb jogokat adjuk oda pl. egy fejlesztőnek, egy ügyféltámogatást végzőnek, vagy aki az apphoz érkező megjegyzéseket kezeli.

Ne csak a store-okra korlátozódjon ez az előrelátás. A GitHub-on, GitLab-en, Bitbucket-en, AWS, Azure, Google Cloud Platform-ban (GCP), Firebase-ben, Expo.dev-en (React Native CD/CD) stb. ezek a beállítások ugyan úgy megtalálhatóak. Nézzük át őket!

Ha kell, kérjük be a felhasználónevet, vagy hozzunk létre mi magunk egy újat, aminek a minimális jogokat kiosztjuk.

Korlátozd a külső szolgáltatókat

A fenti listából kitűnik, hogy egy tech projekt nagyon sokféle külső eszközre támaszkodik. Ez jól is van így, hiszen mi főként terméket szeretnénk fejleszteni és értékesíteni. Az üzemeltetésről azonban ugyancsak gondoskodnunk kell!

Ellenőrizzük, hogy egy új szolgáltató bevezetésével mennyire zárjuk be magunkat (vendor locking)? Ha már nem megfelelő, tudunk-e költözni? Mennyire szabványos a megoldásuk, és esetleg máshol is tudjuk használni és újra felépíteni?

Minél kevesebb a külső függőség, valamint minél kevesebb a szolgáltatás, annál könnyebb kézben (észben) tartani a dolgainkat. Nem mellesleg mindig olcsóbban jövünk ki.

Legyen egy checklistád!

A fentiek alapján a saját ellenőrző listámat osztom meg, hogy mint cégvezető, mindig tudd, hogy mi történik a házad táján.

  • Szerverek nevei, IP címei, felhasználók jelszavakkal
  • A fontos és fő felhasználók nevei, e-mail címei jelszavakkal
  • Helyreállítási e-mail címek, telefonszámok
  • Hol van hosztolva a szerver? Külföldön – miért? Szükséges?
  • Az adatbázisok hozzáférése védett? Nem a “gyári” jelszavakkal megy?
  • Van teszt és éles, esetleg egyéb szerver, amit üzemeltetsz? Hol – hogyan érhető el?
  • A Push Üzeneteket ki és honnan küldi?
  • A szolgáltatásokhoz a Service key, Api key-ek hol vannak beállítva, tárolva?

Mit tegyünk, ha már baj van?

Előfordul az életben, hogy meggondolja magát egy partner, vagy te nem vagy már elégedett a munkájával és elbúcsúznátok egymástól.

Feltételezhetően a partner is békésen szeretné zárni az együttműködést, és nem gördít akadályt eléd. Ekkor sorra kell venni a checklistát, és közösen kellő időt szánni az elválásra. Aktív közreműködést kell kérni, hogy mielőbb lezárható legyen. Fontos, hogy jogilag a köztetek fennálló szerződés még köti, illetve később a jog is a segítségedre lesz, ha valami akadály felmerülne.

A fent említett eszközökben a beállítások egyszerűen megtehetőek. Saját magunk elvégezhetjük, és végezzük is el! Ha már nem dolgozunk együtt, akkor semmi szüksége nincsen a mi szervereinken, alkalmazásainkban tárolt adatainkra.

Az appok átköltöztetése, pont a fenti egyedi név miatt, már nehezebb, de nem lehetetlen. Az Apple-nél ez nehezebb, de van erre kidolgozott procedúra és az app transzferálható másik Account Holderhez. A Google-nél pedig a tulajdonost kell átállítani (és átírni az áruházi adatokat).

Remélem hasznosnak találod a gondolataimat a témában. A fentiekben szereztem tapasztalatot, láttam különféle megoldásokat. Amennyiben segítségre van szükséged, keress meg az elérhetőségeim egyikén.

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.

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.

Mobil app vagy Mobil website? Melyik a jobb választás?
A 2020-as év fellendítette a mobilozást

Melyiket válasszam? Mobil app vagy mobil website?
Néha nehéz választani a jó közül. forrás: pixabay.com

Elérkezett a mobilozás ideje – a mobilt használók már többen vannak, mint az asztali gépet használók. Ennek következményeként az üzleti élet felismerte, hogy a mobil kommunikációt hatékonyabban kell használnia, hogy új ügyfeleket vonzanak. Bár ez önmagában még nem elegendő! A mobil app-okat vagy az website-jainkat optimalizálni kell a jó felhasználói élmény érdekében. Melyikre fektessük a hangsúlyt, ha a költségeket szinten kell tartani?

A 2020-as év eseményei tovább erősítették azt a tendenciát, hogy az emberek már inkább mobil eszközökről interneteznek, érik el a digitális tartalmakat.

Mobile App-ok

A natív mobil app-ok meghatározott platformra készülnek, úgymint iOS vagy Android operációs rendszerre. A felhasználók letöltik és telepítik az eszközeikre, és általánosan elmondható, hogy a natív app-ok gyorsabb és érzékenyebb felhasználói élményt nyújtanak a mobil website társaiknál.

A felhasználói élmény

Többféle, interaktív módon lehet a felhasználókat elkötelezni

A mobil app lehetővé teszi, hogy a meglévő felhasználóidnak egy új csatornán keresztül tudsz értéket adni. Ahelyett, hogy ugyan azt a szöveget és képeket kellene néznie, mint egy website-on, az app-ok olyan funkciókat tartalmaznak, amik az app speciális részeivel is kapcsolatba kerülnek. Például, az Instagram felhasználók megnézhetik a képeket egy website-on, de nem tudnak feltölteni az app nélkül.

Személyre szabhatóság

A mobil app-ok lehetővé teszik, hogy amint letöltötték a felhasználók az app-ot, egyből személyre is szabhassák a saját ízlésük szerint. Az app-ok tudják követni a felhasználói használatot, ez arra használható fel, hogy egyéni ajánlatokat, frissítéseket javasoljanak. Ezáltal még értékesebb lesz a használója számára. Az app-ok az üzleti élet számára fontos, egyénre szabott kommunikációt tudnak folytatni a felhasználó érdeklődési körei, földrajzi helyzete, használati szokásai, stb. alapján. A Business of Apps felmérése alapján, a személyre szóló vagy un. dinamikus értesítések pozitív hatással voltak az elköteleződésre, a megnyitási hajlandóságra, és a konverzióra. Az egyedi beállítások lehetősége jó a felhasználónak is, mert így a legtöbbet hozhatja ki az app-ból.

Működik offline módban is

A mobil app-ok internet kapcsolat nélkül is használhatóak. Bár sok app-nak szüksége van internet hozzáférésre, hogy a feladataik legtöbbjét elvégezzék, még így is tudnak biztosítani bizonyos funkciókat vagy tartalmat, kapcsolat hiányában. Ezzel az előnnyel a felhasználóink hozzáférhetnek az információhoz bárhol, bármikor.

Intuitív felületek

A mobil app-ok általánosságban véve intuitívabb kezelőfelületet nyújtanak, ezáltal a feladataink is könnyebben elvégezhetőek. Az egyedien kialakított felület lehetőséget ad, hogy a felhasználók jobban elmerüljenek a mobilozásban. Egy adott operációs rendszert használók már hozzászoktak annak működéséhez, és ha egy app egy bizonyos platformra készül, akkor a felhasználók ott is azt kapják, amit megszoktak. Egy reszponzív website nem tudja ezt minden esetben megadni.

Használjuk ki az eszköz képességeit!

A mobil app-ok hozzáférnek az eszköz beépített funkcióihoz, úgymint a kamera, GPS, helymeghatározás. Ezeknek a kihasználása egy fejlettebb, kényelmesebb élményt nyújt.

Például a GPS adatok automatikus használata a személyszállító társaságoknak nagyban segíti az utazásra váró személy megtalálását. Ezzel lerövidítve a várakozási időt, és növelve az elégedettséget.

Reszponzív mobil website-ok

A Reszponzív mobil website-ok olyan website-ok, amik a különböző képernyőméretekhez igazodnak. Alapvetően, egy reszponzív website ugyan annak az általános website-nak egy különlegesen beállított változata, de ezáltal a mobil-on is jól használható.

A felhasználói élmény

Mindenki számára elérhető

A mobil app-okkal ellentétben, amik csak bizonyos platformokon működnek (iOS vagy Android), egy reszponzív website bármely mobil eszközön elérhető, függetlenül az operációs rendszerétől, feltéve, hogy van internet kapcsolat. Bár ne feledjük, hogy az internet elérés, annak minősége és a sebessége mind olyan tényező, ami befolyásolja a web-es élményt.

A reszponzív website-okat nem kell letölteni és telepíteni, valamint teljesen ingyenesek, nem úgy, mint néhány fizetős app az áruházakban.

Nem a felhasználónak kell frissítenie

Még egyszer, a mobil app-okkal ellentétben, a felhasználóiknak nem kell bajlódni az új verziókkal és azok frissítgetésével, ha a website-ból egy új javítás jön ki. Mivel a website-ok könnyen frissíthetőek, könnyű hibákat javítani rajtuk, ezért feltételezhetően a felhasználók nem fognak az egészből semmit észrevenni, és egyből élvezhetik az új, fejlettebb élményt.

Költséghatékony

A költséghatékonyság inkább üzleti szempontból előnyös, mint a felhasználók szemszögéből. A bonyolultságtól függően azonban egy reszponzív mobil website költséghatékonyabb lehet, mint a mobilalkalmazások fejlesztése. A költségek egy alapvető tényező, amit számításba kell venni, különösképpen, ha egy app-pal több platformon is jelen szeretnénk lenni.

A költségek csökkentésére ma már nagyon jó megoldások léteznek, amik lehetővé teszik, hogy a mobil app-unk mindkét platformra (iOS és Android) elérhető legyen, de nagyjából a teljes ár kb. 65-75%-árért. Ilyen keretrendszer a Flutter, ami most a legjobb választásnak számít.

Konklúzió: melyik a jobb?

Tisztán statisztikailag nézve a számok azt mutatják, hogy a mobil app-ok érik meg. Egy nem túl régi jelentés a Sensor Tower-től kiderítette, hogy a fogyasztás és a telepítések száma a mobil app használók körében jelentősen növekedett 2020 első felében, elérve az 50.1 Milliárd dollárt az App Store és Google Play áruházakban, összesítve. Míg ez a növekedés a COVID-19-nek és annak felhasználókra gyakorolt hatásainak tudható be, ez 23.4%-os növekedést mutat 2019 első feléhez képest és folyamatosan növekszik.

Ugyan ez a jelentés azt becsüli, hogy 71.5 Milliárd új app telepítés történt 2020 első felében. Ez 26.1%-os növekedést jelent az előző évhez képest (YoY), ami további ösztönzést adott a vállalatoknak, hogy app szolgáltatást fejlesszenek.

A megfelelő választás függ az üzleti céljainktól. Ha a célunk az, hogy mobilbarát tartalmat szolgáltassunk a széles közönségnek, akkor feltételezhetően egy mobil website elegendő számunkra. Amennyiben a nagyobb elköteleződés, a szorosabb kapcsolattartás és kommunikáció ami növeli a lojalitást, a mobil app jobb választásnak tűnik.

Sok esetben úgy dönthetünk, hogy mindkettőre szükségünk van, egy mobil app-ra és egy website-ra. Ha jól van kivitelezve a stratégia, mindkettő értéket adhat vállalkozásunkhoz. Tehát amikor a branded mobil stratégiáján dolgozol, a kérdés nem az lesz, hogy mobil app vagy website legyen, hanem inkább egy kétirányú megközelítés.

Létezik egy köztes megoldás is, ötvözve a két irány előnyeit és hátrányait, ez a PWA. Vagyis Progressive Web App. Erről bővebben írtam egy bejegyzésemben.

Ha mobil app fejlesztését fontolgatod, akkor keress fel bizalommal az elérhetőségeim egyikén, ahol egy ingyenes beszélgetés alkalmával meg tudjuk beszélni, hogy mire app-ra, vagy website-ra van szükséged?

FlutterFlow: egy új Low-code eszköz, ami mobil app kódot generál
Muszáj megoldani a növekvő szakemberhiányt

A FlutterFlow low-code igérete
forrás: www.flutterflow.io

Idén visszatért a Google nagyszabású éves eseménye, a Google I/O. Május 18 és 20-a között rendezték, ezúttal az online térben. Ezt azonban már megszoktuk. Újdonságokból nem volt hiány, debütált a FlutterFlow nevű online eszköz, ami egy low-code (kevés kódolást igénylő) eszköz. Kipróbáltam, ennek osztom meg a tapasztalatait.

A low-code eszközöket nyomon követem, és kipróbálom, mert ezek már most is pótolják az IT-ban jelen lévő szakemberhiányt. Írtam már a UICode megoldásáról, ami a Figma designerek és az app fejlesztők táborát közelíti egymáshoz.

Ide fogok eljutni a FlutterFlow példával

Egy egyszerű példán keresztül néztem meg, hogy mit tud. Ez a végeredmény. Jelen esetben a Chrome böngészőben indítottam el, mert a Flutter Web-es támogatása első osztályú. Mobilon ugyan így nézne ki.

A végeredmény elkészült.

Előkészületek a FlutterFlow kipróbálásához

Az online eszköz a www.flutterflow.io oldalán érhető el, ahova egy Google accounttal regisztrálva máris hozzáfértem a felülethez.

Egyből végigvezet egy projekt beállításán, ami egy név megadásából áll. Adjunk neki egy nevet, és már kezdhetjük is a felületek kialakítását. Előtte még felajánlja, hogy már egy meglévő sablon alapján készítsen elő egy megoldást, vagy teljesen szabad kezet kapva, egy üressel kezdjünk.

Én a példában egy üres projekttel kezdtem, mert kíváncsi voltam, hogy mennyire bonyolult a játszadozás vele. Természetesen elérhetőek a tanuló videók, amik nagyban segítenek, ha elakadnánk.

A bal oldali menüben láthatjuk a választható widget-ek (kis grafikai komponensek) listáját. Van belőlük bőven, kedvemre válogathattam.

Csak fogd-és-vidd technikával be kell húzni a komponenst az előre elkészített Home screen-re. Ide én egy olyan listát adtam meg, aminek minden eleme egy termék képe és a neve.

A kezdőképernyő a listával.
Képernyőkép szerkesztése nagyon egyszerűen.

Ezután létrehoztam egy másik képernyőképet, hasonlóan egyszerűen, ahova akkor navigál az app, amikor rákattintunk egy sorra.

Ez lett a Részletek képernyő. A tetején van egy nagy kép, alatta különböző formázásokkal a neve, leírása, származási ország, ára. A formázások a megszokott kényelmes beállításokkal működik: betűméret, vastagítás, döntés, színe, igazítás. Egyszerű.

A termék részletek képernyő
A termék részletek képernyője.

Amiben nagyot tud az FlutterFlow low-code

Eddig mondhatnánk, hogy nem rossz, de azért mutasson valami igazán menőt!

Ez nem más, mint az, hogy a meglévő szerverünket (BackEnd) hozzá tudjuk kapcsolni. Lehet ez saját, meglévő interfész, vagy akár a Google Firebase cloud megoldása. A példában a Firebase integrációt próbáltam ki, ami ugyan igényel némi hozzáértést, de nem lehetetlen küldetés. Tulajdonképpen a szokásos beállításokat kell végigcsinálni, és nekem elsőre működött.

Nem írom le a lépéseket, de a lényeg, hogy meg tudjuk adni, hogy az adatok milyen szerkezetben érkeznek a szerverünkről. Ehhez egy adattípust készítünk el, és a későbbiekben ezt használjuk mindenhol.

A kezdő képernyőn a listát feltöltjük a szerverről jövő adatokkal. A termék kép címét, és nevét már ebből az adattípusból vesszük. Ha kiválasztunk egy elemet, akkor megjegyezzük, hogy melyik volt az, és a részletező képernyőn pedig bővebb infókat jelenítünk meg róla. Ennyire egyszerű. Mindezt úgy, hogy ugyan nem árt, ha láttunk már kódot, de nem kell kódot írnunk. Inkább csak táblázatokat töltünk ki hozzá.

Nagyon sok minden van a FlutterFlow alap eszköztárában, pl. hogy előnézetben egy kattintható drótvázat (wireframe) kapunk, ami arra jó, hogy legyen egy érzetünk a végtermékről. Sokszor már ez is elegendő a felhasználóknak, hogy kiderüljön, hogy mit csinál az app.

A gyorsan növekvő IT szakember hiány számos területen nehezíti a projektek indulását vagy befejezését. A low-code, no-code, vagy a kereszt-platformos (cross-platform) megoldások ezeket a terheket enyhíthetik. Ezekkel pótolhatóak fejlesztői pozíciók, amikre esetleg éveket kellene várnia egy cégvezetőnek.

Ingyenes vagy fizetős?

Kezdtem az ingyenes részével, ahol kipróbálhattam a fő funkcióját, hogy elkészíthettem a képernyőket. Ezután le akartam tölteni a kódot, hogy kipróbáljam.

Havi 30 USD-ért megkapjuk a kódot, ami azt jelenti, hogy sok órányi kódolástól mentesülünk.

A Pro-ban már havi 70 USD-t kell fizetnünk érte, ami jól jöhet egy mobil app fejlesztő stúdiónak.

Minden esetre az első 14 nap ingyenes, így el tudjuk dönteni, hogy áldoznánk-e rá?

Egyelőre még egy friss, első verzióról van szó, tehát sok hiba lehet benne.

Konklúzió

Összegzésként a FlutterFlow low-code webalkalmazásról elmondható, hogy érdemes volt kipróbálnom. Sok funkciót tud már most is, ami várhatóan hamarosan még tovább bővülnek.

Ennek, és számos, a közelmúltban útjára indult az eszköznek a megjelenése egyértelműen bizonyítja, hogy nagy jövő előtt áll a Flutter UI keretrendszer. Nem csupán mobil, de a web és asztali platformokat is meghódítja.

Ha további kérdésed lenne erről az eszközről, vagy magáról a mobil app fejlesztésről, a kapcsolati oldalamon vagy LinkedIN-en elérhető vagyok.

(PWA) 2021-ben hódítanak a Progresszív Web Alkalmazások

PWA jól működik a természetben is, offline.
forrás: Unsplash.com / Nature Mobile

A Progresszív Web Alkalmazás, röviden PWA, olyan megoldás, ami a weblap és a mobil app között helyezkedik el. Részben tartalmazza azokat a funkciókat, amiket egy mobil app tud, de kényelmesebb egy weblapnál. Ebben a cikkben ennek részleteit gyűjtöttem össze.

Mi egy PWA pontosan?

A PWA nem más, mint egy weboldal (HTML, CSS) technológiájára épülő mobil alkalmazás. Ennél persze többről van szó!

Az előző gondolat egy leegyszerűsített értelmezés, de kétség kívül ez az alapja. Alex Russell és Frances Berriman fogalmazták meg azt a 9 ismérvet, amit egy PWA -nak tudnia kell.

  1. Reszponzív: bármelyik kijelzőn jól mutat
  2. Kapcsolat független: internet kapcsolat nélkül is használható
  3. App-szerű használat: a mobil app-okban megszokott módon navigálhatunk benne
  4. Naprakész: egy un. Service Worker automatikusan figyeli, hogy mindig a legfrissebb verziót használjuk
  5. Biztonságos: TLS kapcsolatot használ, ami gondoskodik róla, hogy a forgalmat ne lehessen lehallgatni
  6. Könnyen megtalálható: egy megfelelően kitöltött un. Manifest írja le a tartalmat, amit a keresők gyorsan megtalálhatnak és indexelhetnek
  7. Elköteleződés: hozzáfér az operációs rendszer újbóli elköteleződést (re-engagement) segítő beállításaihoz, pl. Push Notification
  8. Telepíthető: Kitűzhető a mobilunk kezdőképernyőjére, hogy kézre essen a következő használatkor
  9. Linkelhető: egy linken érhető el az első használathoz, ezért könnyedén elérhető, megosztható másokkal

Hol lehet hasznos egy PWA?

A 2020-as évben beköltöztünk az online térbe egycsapásra. Naponta nyíltak (először csak kényszerből) a webshop-ok. Akinek addig nem létezett üzlete vagy vállalkozása, azok is felismerték az online vásárlás erejét. Ez felerősítette, hogy tovább bővüljenek az online vásárlások.

Nem minden webshop volt felkészülve a mobilra optimalizált megoldásokkal, ami gyors oldal elhagyást jelent a konkurencia javára. Ebből látszott, hogy a fizikai boltok szinte teljesen megszűntek, akinek nem volt online megoldása, az komoly gondba került (nagyon sokan bezártak végleg).

Egy mobilos felhasználói élményt javíthat a PWA:

  • Push Notification-k és értesítések küldése
  • Gyorsan lehet bejelentkezni a Facebook vagy Google felhasználónkkal
  • Internet nélkül is lehet vásárolni, gyűjtögetni a kosárba
  • Egyedi analitika nyomonkövetése
  • Könnyített mobil fizetési módok

Egy PWA jó belépő lehet akkor, ha nem akarjuk a felhasználót rákényszeríteni egy újabb app telepítésére, viszont a vállalkozásunkat pörgetni akarjuk.

Egy fodrászat, műkörmös időpontfoglalása egyszerűsödik. Mindenki magának intézheti, kényelmesen. A fodrásznak sem kell a hajas kezével, az ügyfelét késlekedve telefonokat bonyolítania. Ehelyett egy naptárat lát, aki szeretne menni, megadhatja a frizura típusát, így ez alapján becsülhető az idő. Elegendő az időpontra érkezni, ami csökkenti a sorbanállást.

A turisztikai app-ok töretlen sikernek örvendenek. A korlátozott utazások miatt egyéb, eddig nem ismert megoldásokat igényelnek a kirándulók.

A webshop-okról már volt szó, előnyük egyértelmű.

Meg kell jelenni az online térben, különben nem létezik az a vállalkozás, amelyik nem így tesz. Az egyszerű, tájékoztató jellegű, céges honlapok ideje lejárt.

A cégek berendezkedve a hibrid munkavégzésre, a munkaerőnek új szolgáltatásokat szeretne biztosítani. A Home Office elterjedésével már jóval túlmutat ez az egyszerű munkaidő regisztrálásán. Egy feladatkezelő könnyedén naprakészen tartja, hogy ki-mikor-mit végez? Céges eseményekről lehet értesíteni a dolgozókat. Visszajelzéseket kérni a felhasználóktól, hogy csak egy pár példát említsek.

A fentiek inkább a mobiltelefonos felhasználását hangsúlyozták, azonban van egy fontos terület még: az asztali számítógépen való használat. Egy ügyviteli rendszer, egy webshop adminisztrációs felület ugyan olyan jól kialakítható vele, mint egy mobil app. Véd a váratlan internet kapcsolat megszakadása ellen, és tovább tudunk dolgozni a programmal.

A PWA hátrányai

Azáltal, hogy nem az alkalmazás áruházakból (Google Play vagy App Store) telepítjük őket a telefonjainkra, elveszítjük annak a mérésnek a lehetőségét, hogy feltárjuk a célközönségünket. Ezek némileg kiküszöbölhetőek más analitikai megoldásokkal. Lényegében nem biztos, hogy az fontos számunkra, hogy mikor telepítették, és kik, hanem hogy valóban hozott-e forgalom növekedést. Minden esetre ez egy olyan tényező, amit SEO szempontjából érdemes figyelembe venni.

Bár egy PWA jobban kihasználja egy mobil képességeit, bizonyos funkciókhoz nem biztos, hogy hozzáférünk. Ilyen lehet a Bluetooth kapcsolat, vagy a GPS adatok. Főleg az Apple az iPhone-okon korlátozza ezek telepítését. Mérlegelni kell, hogy a fenti funkciókra valóban szükségünk van-e, és ha tényleg elengedhetetlen, akkor választani egy natív megoldást, ami ezt megoldja.

Alapvetően a telefonunkon lévő böngésző szab gátat a telefonon elérhető funkcionalitások kihasználásához, de néhány trükkel ezek bizonyos mértékig tágíthatóak. Azonban fontolóra kell venni, hogyha egy speciális képesség kell a telefonunkról, akkor a PWA szűk lesz egy idő után, és a natív irányba kell elmozdulnunk.

Mit kapunk a pénzünkért?

Azok a jó megoldások, amik belátható beruházások mellett a megtérülést szem előtt tartva valósulnak meg. Jó szempont az, ha kicsiben indulunk, és az igények növekedésével tudjuk fejleszteni a terméket.

Ma már van rá lehetőség, hogy a prototípustól (Figma), egy PWA-n keresztül el tudunk jutni egy natív app-ig. Közben nem kell mindig az elejéről kezdeni a fejlesztést. Ha ugyan az a csapat, a későbbiekben onnan tudja folytatni, ahol abbamaradt a fejlesztés, azzal sok idő és pénz takarítható meg.

Megoldások

A Flutter Web-es megoldása kínál olyan PWA megoldást, ami a későbbiekben natív Android vagy iOS applikációkká bővíthető. Ennek tetejében a két platformra egyszerre készül el a program. A Flutter keretrendszerről írtam korábban, ami nagyon jó megoldást kínál egy PWA vagy SPA (Single-Page Application) kiadásához.

Amennyiben nem vagy biztos benne, hogy merre indulj el, keress meg bizalommal, hogy beszéljünk a személyre szabott megoldásodról!

További Flutter-ről szóló cikkjeimet érdemes elolvasni.

A cikk megírásához a www.coredna.com hasonló posztjából szemezgettem.