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.