“Igen, ilyen problémám, már nekem is volt!”
A Pontén belül mi is számos alkalommal futottunk bele abba a problémába, hogy szükségünk volt ugyanarra a szövegre, képre, színre stb. webes, Android, illetve iOS oldalon is. A platformok között csupán az állomány formátuma jelentette a különbséget. A szöveges tartalmak, bár több helyen tárolódnak, felvitelük gyors és problémamentes, hiszen minden platform ún. „Plain text”-ként, tehát egyszerű szövegként tárolja ezeket.
Ám képek felvitelekor már nem beszélhetünk ilyen egyszerű felvitelről. Az első probléma, amit meg kell oldanunk, hogy a platformok által támogatott formátumban kezeljük a képeket. Eleinte a PNG vagy JPG kiterjesztésű fájlok közkedveltnek számítottak, hiszen megjelenítésüket mindegyik fentebb említett platform támogatta. Napjainkban ezen formátumok visszaszorulóban vannak, hiszen a kijelzők mérete és ezzel együtt felbontásuk is folyamatosan változik. Válaszlépésként a vektoros képek jelentek meg és válnak egyre népszerűbbé, hiszen egyetlen fájl beillesztése is elegendő a megfelelő méretű képek megjelenítéséhez. A vektoros világ azonban újabb lépcsőfokot jelent a fejlesztők és designerek életében, mivel a közös megoldások helyett inkább széthúzás tapasztalható a fejlesztői világban. Webes technológiák esetén a közkedvelt SVG, iOS rendszeren a PDF, Androidon pedig a Vector Drawable formátumok használatosak. Szembetűnő, hogy az első kettő (SVG és PDF) formátum esetében könnyen kezelhető vektoros formátumokat használnak, ám a Vector Drawable már nem sorolható ezen megoldások közé. A fejlesztő, szerencsés esetben, az Android Studio által SVG-ből generált vektoros képet azonnal tudja használni. De sajnos sok esetben a Studio képtelen a képek tökéletes, vagy akár megfelelő szintű konverzióját elvégezni, így maradnak a 3rd party megoldások, vagy legrosszabb esetben a fejlesztő kézzel történő megoldásai, amik rengeteg időt emészthetnek fel.
További problémát okozhat a megrendelő igényeinek változása vagy a fejlesztőcsapat változtatásai. Optimális esetben a változtatások minden platformon tökéletesen és ellenőrzötten történnek meg, így – a fejlesztők rosszalló pillantásai és esetleges keserű megjegyzései után – az elvártnak megfelelő állapot áll elő. Kevésbé szerencsés esetben, az egyik vagy több platformon, hibás vagy semmilyen változtatás nem lép életbe, ennek eredményeképpen eltérő állapotok keletkeznek, ami a későbbiekben a fejlesztők még több idő ráfordítását igényli.
Végül azon esetet is szeretném itt szerepeltetni, amikor a marketing vagy sales csoport valamely tagja változtatási igényt nyújt be egy forrás állománnyal kapcsolatosan, a rendszer megjelenésének vagy használati élményének fokozása érdekében. Ez az igény eljut a fejlesztőkig, akik elvégzik a szükséges változtatásokat, majd újabb változatot szolgáltatnak az érintett csoport felé. Ez az iteráció egészen addig tart, amíg minden csoport meg nem elégszik az elkészült szoftverrel. Hangsúlyozva, hogy a csoport kooperációja szükségtelen, hiszen a fejlesztői csoport nem fejlesztéseket végez, hanem forrás állományokat cserél, esetleg javít.
Út a Respresso felé
A Pontén belül mi is számos alkalommal küzdöttünk meg a fenti problémák valamelyikével. Ezek kiaknázása érdekében több megoldást is próbáltunk bevetni, melyeket a teljesség igénye nélkül mutatok be, hogy a kedves olvasó láthassa a Respresso fejlődésének motivációit.
A lokalizációs szövegek kezelésére vetített fejlesztési módszereink a következők voltak:
- Első lépéseként minden platform a saját maga formátumának megfelelő módon tárolta a szöveges tartalmakat, ami mondhatjuk, hogy a legrosszabb, hiszen ezek módosítása favágó munka a fejlesztőknek, illetve drága a megrendelőnek.
- Gyorsan felismertük az előző pontban említett módszer negatív oldalát, és következő lépésben, amennyi szöveges tartalmat csak tudtunk, mind kiszerveztük szerverre. Ez eleinte csak azon felületeknél jöhetett szóba, ahol ettől eltekintve is szükséges volt a szerver – kliens kommunikáció.
A problémánk méregfogát ezzel ki is húztuk, hiszen a nyelvnek megfelelő adatlekérés megoldódott, és nem terheltük sokkal jobban a kommunikációt a szükségesnél. Jogosan vetődik fel a kérdés, hogy akkor a többi szöveges tartalommal mi történik, ahol nincs kommunikáció? Nos, ezek kapcsán maradtunk a régi, jól bevált megoldásnál. - Szükségünk volt tehát egy közös megoldásra, amit a kommunikációs csatorna terhelése nélkül, illetve ettől függetlenül is tudunk alkalmazni. Létrehoztunk tehát egy JSON formátumú fájlt, amit a szerveren tároltunk, és amit minden alkalmazás indításkor vagy weboldal betöltésnél lekértünk a szervertől. A kapott lokalizációs szövegeket eltároltuk, és ebből szolgáltuk ki a szöveges tartalmat.
A megoldás egyfelől praktikus, hiszen egyszer töltjük le a fájlt, ráadásul a szöveges tartalmi változtatásokra azonnal reagál a kliens, ám a kommunikáció még mindig elengedhetetlen, és a változtatáshoz plusz egy fejlesztő bevonása szükséges. - Következő lépésben szerettünk volna egy olyan megoldást találni, ami a szerver kommunikációtól független, és mégis kielégíti minden platform követelményeit. A JSON formátumú fájl már jól teljesített az előzőekben, így maradtunk ennél a megoldásnál, ugyancsak egy bárhonnan elérhető szerveren tárolva. Ehhez készítettünk platformonként scripteket, amik letöltik a fájlt a szerverről, és elhelyezik a szükséges mappákba. Mivel kézzel nem kívántuk kikeresni a módosított értékeket, így a script feladata lett az is, hogy minden platform esetén a számára megfelelő fájlstruktúrát állítsa elő, és az előző fájlt cserélje az aktuálisra.
Mondhatnánk, hogy a negyedik megoldás már sok esetben elég is lehet, ám pár dolgot érdemes szem előtt tartanunk. Ezt a megoldást még mindig csak fejlesztő tudja eszközölni, fejlesztők közül is olyan, akinek tudomása van róla, hogy ez a megoldás született a projekt esetében. A közös megoldás egy statikus fájl módosítását jelenti, egy sokszor kényelmetlen eszköz használatával a szerveren. Ráadásul a verziózás nem megoldott, hiszen korábbi szövegezésű állapotra visszaállni nagyon kényelmetlen.
Kezeld egy helyen, használd mindhol!
A korábbi megoldásokból tanulva elkezdtük egy könnyedén, interneten keresztül elérhető rendszer megtervezését, amibe csokorba szedtük az összes forrásállományt, amely szóba jöhet a fejlesztés során. A cikk megírásának pillanatában a következő állományokat kezeli a Respresso:
- Lokalizációs szöveget (ideértve több nyelv támogatottságát is)
- Színek
- Fontok
- Képek (vektoros)
- Alkalmazás ikonok
Lokalizáció felvitelekor használhatjuk az import funkciót is, melynek során a rendszer felolvassa a feltöltött szöveges állományt, így nem szükséges kézzel, sorról sorra felvinni a lokalizációs szövegeket. Színek felvitelekor ugyancsak importálhatjuk az adatokat színpalettáról, és már egyszerű PNG fájl színeivel is feltölthetjük a rendszert. Fontoknál a TTF és OTF támogatott. Képek esetén a vektoros képeket fogadja el a rendszer. Mobilos projekteknél pedig az alkalmazás ikont tudjuk itt kezelni, ahol a vektoros, illetve raszteres kiterjesztések (PNG, JPG) egyaránt használhatók, akár vegyesen is.
Ezzel egy projektet le tudunk írni, ám fontos, hogy a projekthez csak azok a személyek férjenek hozzá, akik érintettek is azzal kapcsolatosan. A projekthez való hozzáférést tehát előzetes regisztrációhoz, valamint csoporttagsághoz kötöttük.
Team
Minden regisztrált felhasználónak legalább egy csoportba tartoznia kell, melyet akár Ő maga is létrehozhat. A csoportokban csoporttagok és projektek definiáltak, ám minden csoporttag nem szerkeszthet minden projektet, hiszen a gyakorlatban sem feltétlenül férhet hozzá minden fejlesztő minden projekt forráskódjához. Amennyiben a fejlesztő szeretne jogosultságot kapni a projekthez, azt meghívásos rendszerünkön keresztül bármikor igényelheti.
Csapaton belül értelmeztük a „Team history”, azaz a csapattagok által eszközölt módosítások megjelenítését. Ez több szempontból is hasznos, hiszen így egy helyen értesül a fejlesztő minden változtatásról, nem szükséges a projekteken egyesével végig lépkedni és mindent ellenőrizni, További előnye, hogy naprakészen tart mindenkit, azaz akár további kommunikáció nélkül is információhoz juttatja az adott személyeket.
Ki lehet tagja a team-nek?
Értelmezésünk szerint érintett személynek, ezzel együtt csoportba meghívott tagnak nemcsak a fejlesztő tekinthető, hanem a designer, a megrendelő vagy akár egy fordítást végző megbízott iroda is. A csoporttagok bármely módosítását követően minden platformon a már módosított állományok szerepelnek a későbbiekben. A fejlesztőknek nem szükséges a projektek megnyitása, így ők kizárólag a fejlesztésre koncentrálhatnak.
Projekt
A projekt a legfőbb eleme a Respressonak, hiszen e köré épül az egész rendszer. A projekt egyedi azonosítóval ún. Projekt token-nel ellátott egység, mely token klienseken történő felhasználásával minden kliens megkapja a számára igényelt forrásállomány konvertált változatát.
Projektek esetén ugyancsak megjelenítettük a történeti áttekintést, a jobb átláthatóság végett. Szemben a „Team szintű” áttekintéssel, itt csak az adott projektre vonatkozó információk kerültek megjelenítésre: ki, mikor, mit csinált a projekttel kapcsolatosan, mely akár Slack üzenet formájában is kiküldhető. Projekten belül lehetőségünk van továbbá token cserére, melyet csak erősen indokolt esetben érdemes megtennünk, hiszen egy cserét követően a klienseken a régi tokennel többé nem lesznek elérhetők a korábbi állományok. Továbbá archiválhatjuk is a projektet, mely nem jelent fizikai törlést, így a későbbiekben lehetőségünk lesz annak módosítására is.
Minden felhasználó könnyedén képes az állományokat bővíteni, módosítani vagy törölni. Az állományok konvertálása a rendszer feladata, nem szükséges semmilyen egyéb interakció a felhasználó felől. A konvertálás folyamatát a háttérben apró processzorok halmazával végeztetjük el. Minden processzor rendelkezik egy bemenettel és egy kimenttel, így egy processzor esetén fekete doboz működést érhetünk el. A processzoraink előre definiált feladatokat hajtanak végre, amik lehetnek komplexek, de akár olyan egyszerűek is, mint egy egyszerű szóköz eltávolítása a kapott szöveges állományból. A processzorok a működésüknek megfelelően sorba köthetők, hiszen mindegyiknek a bemenete lehet az őt megelőző processzor kimenete, így a processzorok újra felhasználhatók és könnyen átláthatók maradnak.
Saját processzor
Hamarosan elkészülő fejlesztésünk keretében arra is lesz lehetőség, hogy saját processzort helyezzünk el a Respresso végrehajtási rendszerében. Így további várakozás nélkül mindenki számára elérhetővé és futtathatóvá tesszük a saját megoldását, hiszen előfordulhat olyan eset, amire a Pontén belül még nincs kész megoldásunk. Ez fakadhat abból, hogy egy cég teljes mértékben egyedi megoldást használ, vagy egyszerűen abból, hogy mi magunk még nem jutottunk el azon konverter lefejlesztéséig, amire másoknak szüksége lenne. Ekkor dönthet úgy a másik fél, hogy lefejleszti a saját konverterét és azzal kibővítve kívánja futtatni a folyamatláncot.
Verziók kezelése
A Respresson belül minden forrástípust verziószámmal látunk el. Az egyes források egymástól teljes mértékben függetlenül kezelik a változtatásokat, éppen ezért előfordulhat, hogy például a Lokalizációink 1.0.0 verzióval, míg a Színeink 1.3.2 verzióval vannak ellátva. Ezen verziózást GIT szerűen képzeltük el (gondoljunk csak a tag-elés lehetőségére), ezért vezettük be a Finalize funkciót.
Alapértelmezetten tehát minden szekció addig változtatható, amíg azok nem kerülnek véglegesítésre. A véglegesítéssel olyan visszaállítási pontot hozunk létre, ahol garantált az aktuális kontextus megőrzése. Ezalatt azt értjük, hogy többé sem a bővítés, sem a szűkítés nem megengedett a szóban forgó verzióval kapcsolatban. Verziók esetén értelmezett még a Copy, azaz a másolás lehetősége. Másolatot bármely verzióból lehetőségünk van létrehozni. Ekkor minden addigi forrásfájl megtalálható lesz a másolt verzióban, és további forrásokkal is kiegészíthető lesz, egészen a véglegesítés pillanatáig.
Kliensek
Kliensnek tekintünk minden olyan platformot, mely a szerver által generált állományokat részben vagy egészben letölti és megjeleníti valamilyen formában. Célunk, hogy a platformok számát folyamatosan bővítsük, ezzel minél több fejlesztő számára megadva a Respresso használatának lehetőségét.
Jelen pillanatban Android oldalon a build folyamatba beépülve történik a forrásállományok frissítése, iOS oldalon egy parancssorban futtatható scripten keresztüli frissítés gondoskodik a beszerzésről, webes felületen pedig az npm-en keresztül van lehetőség az állományok napra készen tartására. Klienseken természetesen nem szükséges minden forrásfájl letöltése, lehet például, hogy külön fontot nem használ a rendszer, ekkor a fontok lekérése a szervertől felesleges.
A forrásállomány beszerzéséről, illetve a Respresso kliensekbe történő integrálásáról bővebb információ a github oldalunkon érhető el.
Manager vagyok, nekem is megéri?
A Respresso megoldást kíván adni minden egyéni, kis-, közép-, illetve nagyvállalti megoldásnak, akár egyetlen platformos támogatottság esetén is! A rendszer egy helyen tárolja az összes resource fájlt, illetve automatikusan végzi el a konvertálást, ezzel növelve a komfortérzetet. Továbbá idő és pénz takarítható meg a rendszer használatával, mert a színek, képek, lokalizációs szövegek stb. felvitelére csak egyszer van szükség, a továbbiakban minden érintett platform használhatja azokat. A saját és partner céggel végzett előzetes kalkulációink alapján a fejlesztési idő körülbelül 20 %-kal csökkenthető a Respresso használatával. Az időkalkulációt több szempontból vizsgáltuk:
- a designer már a projekt tervezési szakaszában hozzáadhatja a projekthez az összes, későbbiekben szükségessé váló képet, fontot, színt stb.,
- rugalmasan kezelhetők a megrendelő forrásállományokat érintő változtatási igényei,
- könnyebb bővíthetőséget garantál,
- fejlesztő „feltartása” nélkül cserélhetők szövegek, képek, színek, fontok stb. az alkalmazásban vagy portálon, majd CI segítségével új verzió publikálható belőle,
- leegyszerűsíti a folyamatokat, hiszen garantált az állomány módosulása.
Merre tovább?
A Respresso tekintetében rengeteg ötletünk van nekünk is, ám a célközönség ötleteire, javaslataira még nagyobb szükségünk van. Ennek okán egy Polly felmérést hoztunk létre, ahol javaslattal, illetve korábbi ötletekre szavazással a közösség is előre mozdíthatja a Respresso fejlődését, melyet az oldalunkon (app.respresso.io) teszünk közzé.