Így Született Meg a Festy

• Thu, Feb 7, 2019
• 7 perces olvasmány

Az első saját Androidos alkalmazás megalkotásának ötlete onnan eredt, hogy sajnos 2017-ben még mindig léteztek olyan zenei fesztiválok hazánkban, amelyek nem biztosítottak látogatóik számára hivatalos, letisztult és könnyen használható mobilos alkalmazást a zenei kínálat gyors áttekintésére.

Rés a piaci kínálatban

Aki valaha is járt zenei fesztiválon, annak valószínűleg nem kell ecsetelnem, hogy mennyire frusztráló is tud lenni, amikor a fesztivál kezdetének napján már az első koncertek előtt elfogynak a nyomtatott programfüzetek. Emiatt a fesztiválozók jobb híján egyéb forrásokra vannak utalva, amennyiben szeretnék megismerni a fellépők névsorát, az aznapi programokat, vagy akár csak a fesztivál területét bemutató térképre vetnének egy pillantást.

Végső elkeseredésükben sokan próbálkoznak ilyenkor a fesztivál honlapjának megnyitásával, de ezek nem ritkán még a 90-es éveket idéző technológiai megoldások szintjén vannak megragadva, ezért reszponzív dizájnról, koncertek kezdetén (vagy annak elmaradása esetén) érkező értesítésekről nem is álmodhatunk.

Az 1997 óta létező Fehérvári Zenei Napok (közismertebb nevén FEZEN) kiváló példája volt annak, hogy milyen is az, amikor egy nagyszerű fesztivál szervezése során néhány kevésbé nagyszerű döntés következtében elsiklanak afelett, hogy a modern fesztiválozónak már nem csak tiszta TOI-TOI-ra és olcsó sörre, hanem egy digitális társra is szüksége lehet, ha sikerrel szeretne navigálni a fesztiválok forgatagában.

Az ideális platform kiválasztása

Mivel a felhasználók egyre nagyobb arányban töltik idejüket a hagyományos számítógépek és laptopok képernyői helyett a mobil eszközeik kijelzői előtt¹, ezért logikusnak tűnt, hogy előbb-utóbb a szoftverfejlesztői piac is ebbe az irányba fog eltolódni, és a hagyományos Windows-alapú fejlesztés mellett egyre nagyobb figyelmet kell fordítani a reszponzív weben, valamint a mobilfejlesztésben használatos technológiákra.

A webes technológiák kétségtelenül nagy ütemben fejlődtek az elmúlt években, amelynek folyományaként egyre könnyebb lett mindenféle dirty hack nélkül olyan weboldalt fejleszteni, ami funkcionalitásában megközelíti egy natív mobilos alkalmazás képességeit, de azért még mindig nem tartunk ott. Emellett a fejlődés szédületes sebessége következtében arra sincs biztosíték, hogy biztosan megérné egy adott webes technológia elsajátításába jelentősebb erőforrást fektetni, hiszen a mai környezetben már az az informatikus is idejét múltnak számít, aki a fél éve megjelent Javascript-es keretrendszer használatában még nem rendelkezik két év igazolható tapasztalattal.

A fentiek miatt tulajdonképpen nemigen maradt más választás, mint a mobilos alkalmazások felé venni az irányt. Szerencsére (vagy épp ellenkezőleg) napjainkra már csak két meghatározó mobilos platform maradt, az Alphabet-féle nyílt forráskódú alapokra helyezett Android és az Apple-féle iOS.

Mivel az egyetemi évek során egy keveset foglalkoztam Java-val is, ezért rögtön adódott az Android előnye az iOS-szel szemben, de a döntő érv mégis az volt, hogy a hétköznapokban Androidos telefont használok. Ez főleg a grafikus felület tervezése során jelent nagyon nagy előnyt, hiszen a tipikus Android-os app dizájnjának, menürendszerének ismerete, a jól tervezett appokban becsukott szemmel történő navigálás képessége egész egyszerűen nem volt meg az Apple termékeinek esetében, ami így végleg eldöntötte a kérdést.

A back-end technológia kiválasztásának dilemmáiról, a C# és a Java szintaktikai hasonlóságáról és úgy általában a rendszer architektúrájáról egy másik bejegyzésben fogok írni.

Követelmények

Megvolt tehát a célplatform, ideje volt kitalálni, hogy tulajdonképpen mire is használjam azt. A teljes mértékben hiányzó mobilalkalmazás-fejlesztői tapasztalatom arra mindenképp jó volt, hogy a követelmények megalkotásakor ne korlátozzam magam kizárólag megvalósítható dolgokra. Így tehát mertem nagyot álmodni.

A végül megvalósult követelmények listája nagyjából így festett:

• A dizájn érzésre legyen vérbeli Android, lehetőleg a Material dizájnelvek figyelembe vételével
• Az adatokat egy szabványos REST API szolgáltassa, hogy a jövőben várható iOS-es verzió fejlesztése során ne kelljen többet a back-enddel foglalkozni
• Legyen egy programfüzet, amely kilistázza, hogy melyik fellépő mikor és melyik színpadon lép fel
• A fenti lista többféle szempont szerint szűrhető és rendezhető legyen (pl. napok, színpadok és ABC szerint)
• A programfüzetben egy előadóra kattintva legyen elérhető néhány információ a fellépőről
• A fellépést lehessen kedvencnek jelölni, amire szintén lehet szűrni, illetve koncert előtt értesítést kérni a közelgő alkalomról
• A telefon (vagy tablet) GPS képességeit kiaknázva legyen lehetőség megkérdezni, hogy a felhasználó közelében lévő színpadon éppen ki játszik
• A fesztivál térképe legyen megnyitható és nagyítható
• Lokalizáció lehetőségének megteremtése, angol nyelv támogatása

A fentiek mellett volt néhány „őrült professzor” ötletem is, ami a jelenleg aktuális verzióban még nem lett implementálva:

• „Hol a sátram?” funkció: a sátor mellett állva rögzíthető az aktuális koordináta, amit később (amikor a fesztiválozó adott esetben már kevésbé tud magától tájékozódni) vissza lehet tölteni, az app pedig egy iránytűhöz hasonló grafikával mutatja az irányt légvonalban
• Spotify integráció: az előadó oldalán a Spotify linkre kattintva megnyílik az app, ahol bele lehet hallgatni az előadó életművébe
• Közösségimédia-funkció: a bejelölt kedvenc előadók alapján hasonló érdeklődésű emberek felkutatása, közös koncertlátogatás megszervezése
• Facebook-integráció: a profil összekapcsolása után a facebook-on lájkolt előadókat automatikusan felveszi kedvencnek, így jön értesítés koncert előtt

A követelmények rögzítése után nem volt más hátra, mint nekiállni a festy fejlesztésének.

Implementálás

A szoftver létrejöttének technikai részleteibe most nem mennék bele, helyette összefoglalom, hogy mi volt meglepő számomra a több, mint 10 év alatt gyűjtött asztaliszoftver-fejlesztési tapasztalat birtokában:

• Az Android elvárja a tiszta és explicit fejlesztést, gyakorlatilag nem ad lehetőséget arra, hogy az ember igénytelen legyen
• Szinte mindenhol ráerőlteti a fejlesztőre az aszinkron fejlesztést. Ennek kétségtelen előnye, hogy a grafikus felület szinte sosem akadozik, cserébe viszont rémálom debug-olni
• Az Android Studio (ami az Android hivatalos fejlesztői környezete) a JetBrains cég IDE-jére épül, ami egy nagyszerű IDE, azonban rengeteg erőforrást használ. Emiatt fejlesztői körökben elterjedt a nézet, hogy amikor az Android Studio a forráskódot fordítja, akkor valójában kriptovalutát bányászik a JetBrains-nek
• A fejlesztéshez rengeteg anyag érhető el online a StackExchange-en, fórumokon, a Google fejlesztői oldalain, stb
• Az Android SDK moduláris felépítése miatt még a legjelentéktelenebb komponens frissítése is sokszor azzal jár, hogy az egész build meghiúsul, és addig nem hajlandó fordítani, míg hosszas molyolás után fel nem oldjuk a konfliktust a Gradle fájlban

A fejlesztés végül kb. 3 hónapot vett igénybe. Az angolra fordításban és a back-end adatainak feltöltésében szerencsére volt némi segítségem, emellett több ismerősöm is részt vett az alfa- és bétatesztelésben, amit ezúton is köszönök.

A Play Store-ról és úgy általában egy mobilalkalmazás terjesztéséről, valamint a lehetséges monetizálásáról egy későbbi bejegyzésben fogok írni.

Az első fesztivál

Ahogy előbb-utóbb minden fióka elhagyja a fészkét, úgy a festy debütálásának ideje is egyre csak közeledett. Körülbelül egy héttel a 20. FEZEN kezdete előtt az alkalmazás készen állt arra, hogy bemutatkozzon a nyilvánosság előtt is.

Hogy miért pont a FEZEN lett az állatorvosi ló, az természetesen nem a véletlen műve. A fesztiválhoz hosszú évek során gyűjtött személyes élmények kötnek, ugyanis ez volt az első olyan fesztivál, amelyen elejétől-végéig végéig, kempingestül, hidegvizes-zuhanyostul, zsíros kenyérlángosostúl részt vettem. Ez a fesztivál tehet arról is, hogy a 2006-os első látogatás óta szinte minden évben legalább 3-4 napot töltök Székesfehérváron.

Érdekes módon annak ellenére, hogy az alkalmazásom megjelenése előtt évekig nem volt semmiféle FEZEN-es mobilalkalmazás elérhető, a publikálást követően szinte azonnal megjelent egy hasonló nevű app a Play Áruházban, amely az ott megjelent vélemények szerint sem dizájnjában, sem funkcionalitásában nem volt kifejezetten igényes.

Egy darabig tűnődtem azon, hogy pontosan mekkora az esélye annak, hogy több havi energiát befektetve pont abban az évben jelenjen meg először hivatalos fesztivál-alkalmazás, amikor a projekt kedvéért egy teljesen új platform megtanulásába vágok bele, azonban a felhasználói visszajelzések megnyugtattak, hogy nem volt hiába.

Az első fesztiválszezonban az alkalmazás fejlesztéséről még nem értesítettem a fesztivál szervezőit, nem is álltunk semmilyen kapcsolatban. Bár a platform már az első évben is mindenféle reklám nélkül szerzett több száz (többségében elégedett) felhasználót, a szervezők mégsem kerestek meg, amit akkor kissé furcsállottam.

A következő évben ez másképp alakult, de erről majd talán egy másik alkalommal mesélek bővebben.

Összegzés

Az projekt célja az volt, hogy találjak egy olyan alkalmazási területet, amiért tudok annyira lelkesedni, hogy ezt a motivációt meglovagolva meg- és kiismerjek egy olyan technológiát, ami minden jel szerint a szoftverfejlesztés jövőjének egyik fontos területét fogja majd képezni. Ez kétségtelenül sikerült is.

A fejlesztés során viszont nem csak egy újabb platformot ismertem meg, hanem hasznos dolgokat tanultam a virtuális fejlesztői csapatmunkáról és arról, hogy mennyire sokrétű (és türelmes) személyiség kell ahhoz, hogy az ember egyszerre legyen jó fejlesztő, jó csapatjátékos, jó motivátor és jó marketinges is.

Hogy mi lesz a festy sorsa, az egyelőre kérdéses, de a fejlesztés során szerzett tapasztalatok miatt már most bizto vagyok abban, hogy a megvalósítás érdekében tett erőfeszítések nem voltak hiába.