Játékélmény segítése Androidon képfeldolgozással

Átírás

1 Miskolci Egyetem Gépészmérnöki és Informatikai Kar Általános Informatikai Tanszék Játékélmény segítése Androidon Diplomamunka Miskolci Egyetem Gergely Ádám C8OK6Q Mérnök Informatikus MSc Alkalmazásfejlesztő

2 Köszönetnyilvánítás Ezúton megragadom az alkalmat arra, hogy megköszönjem témavezetőmnek, dr. habil Kovács Lászlónak a diplomamunka készítése során nyújtott útmutatását és segítségét.

3 Tartalomjegyzék 1 Bevezetés Célkitűzések, feladatok Kapcsolódó technológiák Digitális Képfeldolgozás Digitális Képfeldolgozás alapok Digitális kép fogalma Szegmentálás Hasonlóság keresése képeknél Hisztogram összehasonlítás Average Hash algoritmus Difference Hash algoritmus Perceptual Hash algoritmus Android alapok Az Android története Az Andorid bemutatása Fő Android komponensek Android Native Development Kit Kamerakezelés Androidon Rendszerterv Követelmény specifikáció Tervezés Kamerakomponens Képfeldolgozás megtervezése Működés megtervezése Osztályok meghatározása Implementáció Segédeszközök az elkészítésbe Alkalmazás Tesztelés Továbblépés Összefoglalás Summary IRODALOMJEGYZÉK DVD melléklet

4 1 Bevezetés Napjainkban egyre fontosabb szerep jut az informatikának az élet minden területén. Szinte nincs olyan feladat vagy munka, ami közvetve, vagy közvetlenül ne hívná segítségül az informatika valamely ágát. Ma az egyik legnagyobb figyelmet kapó informatikai terület a mobilipar. Az okostelefonok megjelenése és rohamos terjedése óta a mindennapi élet szerves részét képezik. Használatuk megszokottá, elfogadottá vált. Elterjedésük alapvetően változtatta meg a társadalom addigi szokásait. Ellentétben elődeivel ( buta telefonok ) nem csak egyetlen jól körül határolt területen lehetnek a használóik segítségére, mint például telefonhívás, üzenetküldés, hanem szinte a mindennapi élet bármely területén. Az okostelefonok által biztosított szolgáltatásoknak köszönhetően ma már szinte ugyanazokat a dolgokat el tudjuk végezni a telefonunkkal, mint egy asztali számítógéppel (szórakozás, vásárlás, ügyintézés, közösségi kapcsolattartás, stb.).bizonyos téren felül is múlja azt, mint például a kamerát igénylő alkalmazások. Mára sokak számára olyannyira természetessé vált az okostelefonok használata, hogy ha valamit nem tudnak megoldani, akkor először a telefonjukat hívják segítségül. Akár triviális dolgok esetében is (például szótár helyett fordító alkalmazás, moziműsor nézegető applikáció). A problémára megoldást jó eséllyel meg is találhatják a két legnagyobb mobilplatform (Android, ios) hivatalos alkalmazásboltjának valamelyikében. A mobilipar mellett szintén kiemelt terület az informatika foglalkozó ága. Jelentősége régóta ismert, eredményei sok különböző területen kerülnek felhasználásra. A tejesség igénye nélkül ezek a következőek: egészségügy, játékipar, QR kódok felismerése, arcfelismerés. Az mobilipar változásakor már sejthető volt a képfeldolgozás által nyújtott lehetőségek az okostelefonok által biztosított szolgáltatások egyik fontos részét fogja 2

5 képezni. A sejtés beigazolódott, hiszen sorra jelennek meg a különböző mobil alkalmazásboltokban a képfeldolgozást valamilyen formában felhasználó alkalmazások. 3

6 2 Célkitűzések, feladatok A diplomamunka célja megmutatni az okostelefonok kapcsolatos lehetőségeit, mindezt egy konkrét alkalmazás elkészítésén keresztül. Az applikáció az egyre népszerűbbé váló online kártyajátékhoz, a Heartstone-hoz készült, mint segédalkalmazás. A Hearthstone-ban a felhasználó többféle játékmód közül választhatnak. A mobilalkalmazás ezek közül is az egyik legnépszerűbbhez, az Arena játékmódhoz nyújt segítséget annak korai szakaszában, a pakli összerakása során. Egy pakli harminc lapból áll. Mindenegyes pakliban szereplő lapot a játékosnak kell kiválasztania három lap közül. Az alkalmazás lehetővé teszi, hogy az elkészített paklit rögzíthessük a mobilunkon. Mindezt a lehető legegyszerűbben, vagyis, hogy a felhasználónak ne kelljen kikeresnie a választott kártyát a több száz lehetséges közül, hanem elég legyen lefényképeznie a képernyőt, amin mindhárom választható kártya látható. Ehhez az applikáció a képfeldolgozást használ. Miután az alkalmazás felismerte a kártyákat, a felhasználó egy érintéssel hozzáadhatja a választott kártyát a paklijához. Az alkalmazás először Android platformon kerül megvalósításra, melynek fő okai annak nyíltsága, nagyfokú támogatottsága és nem utolsó sorban, hogy ez legelterjedtebb mobil operációsrendszer. Megoldandó problémák A Hearthstone teljes kártyacsomagja jelenleg is rengeteg több száz kártyát tartalmaz, és újabb kártyacsomagok érkeznek a jövőben is a játékhoz. Ezt figyelembe véve a feladat során a következő megoldandó problémák jelentik a főbb kihívást: 4

7 olyan módszert kell alkalmazni, ami nagyszámú felismerendő objektumra is megbízhatóan működik; fontos a válaszidő, hogy az alkalmazás gyorsan felismerje az okostelefon kamerája által lefényképezett kártyákat; számításba kell venni, hogy rengeteg különböző hardverrel (pl: kamera) rendelkező eszköz futtat Androidot, ami szükségessé teszi a kép egyfajta előfeldolgozását, hogy gyengébb kamerával rendelkező eszközök esetén is megbízható legyen a kártyafelismerés; az alkalmazást fel kell készíteni, hogy különböző fényviszonyok esetén is megbízhatóan működjön. 5

8 3 Kapcsolódó technológiák 3.1 Digitális Képfeldolgozás Digitális Képfeldolgozás alapok A képfeldolgozás kezdete az 1960-as évek végére vezethető vissza, ekkor álltak először rendelkezésre a kép kezeléséhez megfelelő hardverrel rendelkező számítógépek. Számos más tudományterület hasznos tulajdonságait vette át, mint például fizika, matematika, informatika, elektronika, fotográfia. Amíg kezdetben csak a nagy tőkével rendelkező vállalatok számára volt megfizethető a képfeldolgozáshoz szükséges hardver, addig ma már akár otthon is lehetőség van képfeldolgozó eljárásokat alkalmazó programok írására. A képfeldolgozás által elért eredményeket több különböző területen is hasznosítják a teljesség igénye nélkül, ezek a következőek: orvostudomány, csillagászat, ipari alkalmazások (robotika, stb.), hadászat, játékipar. A digitális képfeldolgozás alapvetően három szintre bontható[1]: alacsonyszintű digitális képfeldolgozás, digitális képelemzés, digitális képértelmezés. Az alacsonyszintű digitális képfeldolgozás során alacsonyszintű algoritmusok által (például küszöbölés) képből kép keletkezik. 6

9 Digitális képelemzés esetén az input a már elő feldolgozott kép, eredményeként pedig a képen látható objektumok tulajdonságai (például a kontúrok) kerülnek meghatározásra. Digitális képértelmezéskor pedig olyan algoritmusok kerülnek használatra, amelyek segítségével absztrakt információk nyerhetőek a képen található objektumokról (objektum felismerés) Digitális kép fogalma A digitális képfeldolgozás során a cél általában valamilyen módosítás (például képjavítás) végrehajtása a forrásképen vagy pedig az általa hordozott tartalomból a lényeges információk kinyerése. Gyakran az első lépést magának a digitális képnek a létrehozása jelenti. Ennek során a valós világ egy meghatározott részét képezzük le a számítógép számára értelmezhető, kezelhető adatokra. Ezt az átalakítást digitalizálásnak nevezik. A fő lépések az alábbi ábrán láthatóak[1]: 1. ábra Digitalizálás lépései 7

10 A folyamat során létrejött digitális kép egy kétdimenziós tömb, azaz egy mátrix. A mátrixban található adatok fényerősség függvényeként határozhatóak meg, ahol f(x,y) az adott koordinátájú képpont, azaz a pixel fényessége. Minden digitális kép rendelkezik az alábbi tulajdonságokkal: felbontás, bitmélység, komponensek száma. A felbontás a digitális kép pixeleit tartalmazó mátrix méretétől függ, vagyis ha a képet tartalmazó mátrix sorainak a száma m, az oszlopainak száma pedig n, akkor a kép felbontása m x n. A digitális kép bitmélysége meghatározza az egyes pixelértékek reprezentálásához szükséges méretet bitekben, vagyis megmondja, hogy egy pixel hány különböző értéket vehet fel. Ha a kép bitmélysége n, akkor a kép minden egyes pixelének pontosan 2ˆn különböző értéke lehet. A komponensek megmutatják a képet felépítő pixelmátrixok számát. Színes képek esetén általában három komponensről lehet beszélni. Például RGB szintér használata esetén a kép vörös, zöld és kék komponensekből fog felépülni. Szürkeárnyalatos képek esetén csak egyetlen komponens található. N komponensből álló kép esetén minden egyes pixel egy egydimenziós vektor Szegmentálás A képelemzés egyik alapvető része a szegmentálás. Szegmentálás során az eredeti kép hasonló tulajdonságokkal rendelkező képrészleteinek a meghatározása, homogén csoportokba szervezése a cél. A szegmentálás pontossága kulcsfontosságú, gyakran ezen múlik a teljes folyamat sikere, hiszen utána csak az általa meghatározott képrészletetek kerülnek kiértékelésre. Alak, alakzat felismerésnél elengedhetetlen a használata. A különböző szegmentálásos eljárások alapvetően két különböző csoportba sorolhatók: globális szegmentálási eljárások, 8

11 lokális szegmentálási eljárások. Amíg a globális szegmentálási eljárások hasonlóság alapján (például festő algoritmusok), addig a lokális alapú szegmentálási eljárások az intenzitás ugrások és megszakítások alapján dolgoznak. Hisztogram Olyan grafikon[2], amely minden lehetséges szürkeárnyalathoz megadja a képen az adott árnyalatú pixelek számát. Ezt felhasználva meghatározható az egyes pixelértékek elfordulási valószínűségének értéke normalizálás által, vagyis minden értéket elosztunk a kép méretével. Intenzitás Minden szürkeárnyalatos kép[2] fényintenzitást rögzít. A rögzített fényintenzitás egy (x,y) pontban lényegében két összetevő szorzata: f(x,y) = r(x,y)*i(x,y), ahol r(x,y) a felület visszaverődési tulajdonsága. i(x,y) a megvilágítás erőssége. Egyenletes megvilágítás esetén f(x,y) jól tükrözi a szegmentálandó terület visszaverődési tulajdonságát, azaz a hisztogram megbízható. Azonban nem egyenletes megvilágítás esetén torzítottan reprezentálja a felület visszaverődési tulajdonságát, tehát a hisztogramból származó információ félrevezető lehet. Küszöbölés (Thresholding) A legegyszerűbb szegmentálási módszer. Az eljárás alapfeltevése, hogy a keresett objektum színe különbözik a kép háttérszínétől. Vagyis az objektum pixeleinek intenzitása nagyban eltér a háttér pixeleinek intenzitásától. Meghatározásra kerül egy T küszöbszám, amivel az egyes pixelek intenzitását összehasonlítjuk, ezáltal kiválasztva az objektum pixeleit. 9

12 Legyen egy sötét színű objektum világos háttéren, ahol f(x,y) az input kép. t(x,y) a szegmentált kép. T a küszöbszám. Ezen paraméterek esetén, ha f(x,y) <= T t(x,y) = 1. f(x,y) > T t(x,y) = 0. Eredeti Transzformáció utáni A küszöbérték meghatározása történhet manuálisan, azaz a bemeneti képtől függetlenül, vagy adaptívan, tehát a bemeneti kép függvényében. Ismert küszöbölési algoritmusok: Otsu algoritmus, Isodata algoritmus, Niblack algoritmus. Hisztogram kiegyenlítés A képminőségének javítását valósítja meg az intenzitás intervallumok elnyújtása által. Ajánlott kontrasztszegény képek esetén. A módszer lényege, hogy meg kell keresni a kép legsötétebb, illetve legvilágosabb pontját. A legsötétebb pontot el kell tolni az abszolút 10

13 fekete pontba, míg a legvilágosabbat az abszolút fehér pontba. Végül az összes köztes pont intenzitását ezzel arányosan kell megváltozatni. Eredeti Transzformáció utáni Éldetektálás Canny éldetektor Az éldetektálás alapja digitális képek esetében a hirtelen intenzitásváltozás felismerése a kétdimenziós térben. A hirtelen intenzitásváltozást kiválthatják többek között a színek változása, mélységi változások, objektumhatárok, felület megtörése. Az élekkel szemben elvárás, hogy összefüggőek legyenek. Három különböző típusú éldetektáló algoritmus különböztethető meg: derivált alapú, második derivált alapúm fázis alapú. A derivált alapú éldetektáló algoritmusok tipikus lépései a következőek: 1. Véges differenciaszámítás, azaz a derivált közelítése. 2. A keletkezett kép küszöbölése. 3. A kialakuló élek vékonyítása. A Canny éldetektor[3], ami az egyik legrégebbi, leghatékonyabb és egyben leggyakrabban használt éldetektáló algoritmus is a derivált alapú éldetektáló algoritmusok közé tartozik. Algoritmusa matematikailag jól meghatározott, optimális éldetektálást tesz lehetővé, vagyis csak valódi éleket detektál, minden élt csakis egyszer jelenít meg, 11

14 pontosan meghatározza az élek lokalitását, a hibarátája alacsony. A matematikailag optimalizált változatát ritkán használják, helyette egy gyorsabb azt közelítő megoldást alkalmaznak, amelynek lépései a következőek. 1. Gauss simítás végrehajtása a képen. 2. Iránymenti derivált közelítése. 3. Gradiens vektor nagyságnak meghatározása az iránymenti deriváltból. Az így kapott kép nagy intenzitású nyergein lesznek az élek. Élek ott vannak, ahol a gradiensnek maximuma van, a többi pontot el kell hagyni. 4. Hiszterézises küszöbölés. Eredeti Transzformáció utáni Hasonlóság keresése képeknél A digitális képértelmezés fázisában objektum felismerés során használják. Hasonlóság keresésnél a cél meghatározni azon összetartozó képeket, amelyeken ugyanaz a vizuális tartalom, információ látható. Legegyszerűbb esetben ez egy adott kép egyszerű duplikációját jelenti, vagyis olyan képeket, amelyek bitről bitre egyeznek. Azonban általában nem ilyen egyszerű a helyzet. A következő eseteket is tudnia kell kezelni: exponálás vagy a fényviszonyok miatt az elkészült kép sötétebb vagy világosabb, mint az eredeti; kicsit más nézőpontból készült a fotó, mint az eredeti; 12

15 különböző képarányok miatt adódó különbségek; átméretezés okozta eltérések. A fentebbi eseteket figyelembe véve kell kiválasztani az adott feladatnak legjobban megfelelő módszert Hisztogram összehasonlítás A hisztogram összehasonlítás a legegyszerűbb hasonlóság keresést megvalósító technika. Az összehasonlítandó képeknek meghatározza a hisztogramjait, majd normalizálja azokat. Ezzel előállt összes szürkeárnyalat előfordulásának a valószínűsége. Majd képek normalizált hisztogramjait hasonlítja össze a módszer. Hátránya, hogy nehéz a megfelelő küszöbszám kiválasztása és nagyon érzékeny a megvilágításra Average Hash algoritmus Az Average Hash[4] (ahash)-nél az alapötlet az volt, hogy kiszűrjék egy adott képen a magas frekvenciákat és csak az alacsonyakat tartsák meg. Képek esetében amíg a magas frekvenciák a részleteket, addig az alacsony frekvenciák a felépítést mutatják. A módszer előnye, hogy gyors, illetve, a generált hash értékét nem változtatja meg drasztikusan a színek, a fényesség vagy a képarány változása sem. Hátránya, hogy nem elég pontos. Az algoritmus: 1. Legegyszerűbb módja a magas frekvenciák kiszűrésének a kép méretének csökkentése. Ennek megfelelően a képet 8x8 pixel méretűvé kell zsugorítani. A kép arány változása miatt nem kell aggódni. 2. Az előző lépés eredményét konvertáljuk szürkeárnyalatos képpé. 3. A megmaradt 64 színnek ki kell számítani az átlagát. 4. A 64 szín konvertálása 64 bitté (1, 0), aszerint, hogy az aktuális szín értéke nagyobb-e vagy sem, mint az átlagérték. 5. A 64 bitből hash előállítása. Az így előállt hasheket Hamming távolság számolásával lehet összehasonlítani. 13

16 Difference Hash algoritmus A Difference Hash[4] (dhash) algoritmus közel annyira megbízható, mint a phash, de attól jóval gyorsabb. Amíg az ahash az átlagszámításra, a phash pediga DCT-re helyezi a hangsúlyt, addig a dhash gradienseket követi. Az algoritmus: 1. Az ahash-hez hasonlóan a magas frekvenciák kiszűrése a kép méretének csökkentésével 8x9 pixel méretűvé. 2. Az előző lépés eredményét konvertáljuk szürkeárnyalatos képpé. 3. A szomszédos pixelek különbségének kiszámítása, a dhash algoritmus ezen alapszik, ugyanis ez megfeleltethető a gradiens relatív irányának. 4. Hash előállítása aszerint, hogy a baloldali pixel intenzitása nagyobb-e, mint a jobboldali Perceptual Hash algoritmus A Perceptive Hash[4] (phash) robosztus megbízható megoldás, az ahash algoritmust bővíti ki, azáltal, hogy diszkrét koszinusz transzformációt (DCT) használ az alacsonyabb frekvenciák kiválasztására, rendkívül pontos. Hátránya, hogy viszonylag lassú. Az algoritmus: 1. A kép méretének csökkentése 32x32 pixel méretűre. Jelenesetben ennek elsődleges haszna nem a magas frekvenciák kiszűrése, hanem a DCT fázis megkönnyítése. 2. Az előző lépés eredményét konvertáljuk szürkeárnyalatos képpé. 3. DCT kiszámítása, a kép felbontása frekvenciák és skalárok csoportjaira. 4. DCT csökkentése, vagyis legalacsonyabb frekvenciák kiválasztása. 32x32 méret esetén a legalacsonyabb frekvenciákat a bal felső sarok 8x8-ban található értékek jelentik. 14

17 5. A fent maradó 8x8-as mátrix átlagértékének kiszámítása. Fontos, hogy az átlagérték meghatározása során nem kell figyelemben venni [0][0] pozícióban található elem értékét, mert ennek értéke jelentősen eltérhet a többitől. 6. DCT értékek konvertálása bitekké (1, 0) aszerint, hogy nagyobbak-e vagy sem, mint az átlagérték. Nem az aktuális alacsony frekvenciákat kapjuk meg, hanem csak azt, hogy az egyes frekvenciák, hogyan viszonyulnak az átlaghoz. 7. A 64 bitből hash előállítása. 3.2 Android alapok Az Android története A 2000-res évek elején még egyáltalán nem beszélhetünk okostelefonokról. A mobilfejlesztők számára nagy kihívást jelent alkalmazásuk futtatása a különböző hardverű telefonokon. Többek között ezen problémát is orvosolni akarja Andy Rubin, az Android megalkotója, amikor belevág az új mobiloperációs-rendszer fejlesztésébe és létrehozza Android Incorporated nevű vállalkozást. Miután cég tőkéje elfogy Rubin támogatókat keres ötletének a megvalósításához. Többek között jár a Samsungnál is, végül azonban a projektet a Google vásárolja. Az Android operációsrendszert ingyenesnek és nyílt forráskódúnak határozzák meg. Bejegyzésre kerül az Open Handset Alliance nevű konzorcium, amely az Android platform fejlesztésért felel, és amelynek hivatalosan több mint 80 tagja van, vezetője pedig a Google. Az Android platformot 2007-ben jelentik be először, végül 2008-ban mutatják be a nyilvánosság számára is elérhető Android operációs rendszert futtató mobiltelefont. Az operációsrendszer ingyenessége miatt kiváló lehetőséget biztosított a kisebb cégeknek, hogy jó ár-érték arányú termékekkel jelenhessenek meg a mobilpiacon. Egyre több telefont gyártó cég kezdte el saját telefonjain az Android-ot futtatni, az operációsrendszer rohamos terjedéséhez vezetett. 15

18 Mára a legelterjedtebb mobil-operációsrendszerré vált. 2. ábra Android piaci részesedése Az Andorid bemutatása Az Android jelenleg a legnépszerűbb mobil-operációsrendszer. Ezt nagyban köszönheti ingyenességének és nyíltságának, habár a Google egyre jobban megköti a gyártók kezét. Az Android egy monolitikus Linux-kernel köré épül, az alkalmazások írásához az elsődleges nyelv a Java. A Java nyelven megírt alkalmazások futtatását jelenleg a Dalvik VM végzi, ami a Java virtuális géphez hasonló és hordozható eszközökre lett optimalizálva, azonban már elérhető a béta verziója az új futtatókörnyezetnek. Az ART (KitKat-tel együtt jelent meg), amely jelentős teljesítménybeli javulást fog eredményezni a Dalvik virtuális géphez képest, ami JIT fordítást alkalmaz, hiszen az ART ezzel szemben csak telepítéskor fogja lefordítani az applikációt, nem pedig minden futtatáskor. 16

19 A platform tulajdonságait figyelembe véve a következő megállapítások fogalmazhatóak meg. Előnyök: nagy támogatottság, szinte mindenen fut (Rendkívül sok mindent lefed.), egyszerű, jól használható felület, testre szabható, jó ár-érték arány. Hátrányok: szinte mindenen fut (Több odafigyelést igényel a fejlesztők részéről.), fragmentáció. A különböző mérettel és erőforrássokkal rendelkező eszközök miatt a fejlesztőktől fokozott figyelmet igényel, hogy az alkalmazás jól fusson, az összes különböző méretű és erejű készüléken. A platform története során számos új verzió jelent meg, azonban a gyártók gyakran csak rövid ideig vagy egyáltalán nem látják el telefonjaikat az operációsrendszer frissítéseivel, ami szintén nagy kihívás elé állítja fejlesztőket. Alább láthatók az eddig megjelent Android verziók, jellegzetességük, hogy az eddig trend szerint valamilyen közkedvelt édességről kapják a nevüket. Android verziók: Android október Android február Android 1.5 (Cupcake) április Android 1.6 (Donut) szeptember Android (Eclair) október Android 2.2 (Froyo) május Android 2.3 (Gingerbread) december Android (Honeycomb) január Android 4.0 (Ice Cream Sandwich) október Android (Jelly Bean) július 17

20 Android 4.4 (KitKat) október Android 5.0 (Lollipop) október Fontos megjegyezni, hogy a 3.0 előtti verziók csak mobiltelefonon, míg a 3.X verziójú Androidok csak tableten futnak. A 4.0 verziótól nyílik meg a lehetőség, hogy egyszerre fejlesszünk mindkettőre. A platform szegmentáltságát jól szemlélteti az alábbi kép. 3. ábra Android fragmentáció (2014. május) Fő Android komponensek Az Android platformra írt alkalmazások 4 fő komponensből[5] épülnek fel (Activity, Service, ContentProvider, BroadcastReceiver). Egy alkalmazáson belül egy komponens többször is előfordulhat, de akár csupán egyetlen komponensből is állhat. Az egyes komponensek eltérő feladatokkal rendelkeznek. Activity Az Activity[6] a leggyakrabban használt komponens típus. Saját felhasználói felülettel rendelkezik. Általában egy alkalmazás több Activity-ből épül fel. Az Android operációsrendszer lehetőséget biztosít más alkalmazások Activity-inek meghívására, 18

21 illetve, hogy elérhetővé tegyük saját Activity-nket más alkalmazások számára. Ennek köszönhetőn bizonyos funkciókat nem kell újra implementálni elég csupán meghívni az adott funkciót implementáló Activity-t (például pdf olvasó). Az Activity-k saját életciklussal rendelkeznek, amit az alábbi ábra szemléltet. 4. ábra Activity életciklus 19

22 Service A Service[7] nem rendelkezik saját felhasználói felülettel, azonban míg egy Activity csak előtérben képes futni, addig a Service egy háttérben futó feladatot jelképez. Habár nem rendelkezik saját felhasználói felülettel, de indíthat Activity-t vagy mutathat felületi elemeket (értesítések, felugró ablak). Tipikus alkalmazási területei: nagyobb adatforgalmú letöltések, zenelejátszás, pozíció nyomon követés, szinkronizálás. Különböző Servicek vannak, két fő típusuk: Started Service, Bound Service. ContentProvider A ContentProvider[8] egy tartalomszolgáltató komponens, feladata az adatforrás kezelése és az adatforrásra irányuló kérések kiszolgálása. Feladatának komplexitása abban rejlik, hogy maga az adatforrás bármi lehet. A ContentProvider feladata, hogy elfedje az adatforrás összetettségét, elhelyezkedését és megfelelő sebességű hozzáférést biztosítson hozzá. Minden ContentProvider egyedi azonosítóval rendelkezik, amin keresztül más alkalmazások is el tudják azt érni. BrodacastReceiver Az Android operációsrendszer sajátossága, hogy rengeteg eseményt, brodcast-ok (sugárzás) formájában jelez, azonban nem csak OS, hanem mi is kiválthatunk eseményeket. 20

23 BroadcastReceiver-rek[9] használatával lehetőség van feliratkozni a különböző eseményekre, az Android rugalmasságnak köszönhetően. Saját felhasználói felülettel nem rendelkezik, de indíthat más komponenseket Android Native Development Kit Az Android egy Linux alapú mobil-operációsrendszer[5], melynek elsődleges fejlesztői nyelve a Java, de nyíltságának köszönhetően lehetőség van C/C++-ban megírt natív kód futtatására is. Ennek nagy előnye, hogy az így megírt kódok közvetlenül az operációsrendszeren futnak. A memóriafoglalásokért a programozó felel, nincs Garbage Collector, így optimális esetben jelentős teljesítményjavulás érhető el. Lehetőség van natív programkód hívására Java kódból a JNI interfészen keresztül. Azonban használata csak speciális feladatok megoldása során javallott, mert egy JNI hívás nagyon drága, erőforrás igényes. Natív programkódok használata a következő esetekben javallott: nagyobb C/C++ kódok átemelése, nagyobb bonyolult algoritmusok, CPU-intenzív műveletek, kép/jel-feldolgozás. Az NDK beállításához információ oldalon található. JNI (Java Native Interface) A Java Native Interface lehetővé teszi Java és a natív programkód közötti kommunikációt. Az alább látható egyszerű mintapélda feltételezi, hogy az NDK környezet már megfelelően be van állítva. 1. Először is a projekten belül létre kell hozni egy jni mappát, ami tartalmazni fogja a natív fájlokat, illetve leíró állományt (Android.mk), amiben megadjuk forrásainkat a fordítónak. 21

24 5. ábra jni könyvátr szerkezete 2. Az Android.mk fájlban kell definiálni a forrásfájlokat a megfelelő paraméterekkel. 6. ábra JNI konfigurációs állomány LOCAL_PATH: A my-dir makró meghívásával visszakapjuk annak a jni könyvtárnak az elérési útját, ami tartalmazza magát az Android.mk-t is. include $(CLEAR_VARS): Mielőtt kiadásra kerülnének a konkrét utasítások, előtte törölni kell a LOCAL_XXX változókat a LOCAL_PATH kivételével. LOCAL_LDLIBS: Opcionális, segítségével rendszerkönyvtárak linkelhetőek a modulhoz. LOCAL_MODUL: Kötelezően meg kell adni a modul nevét, nem tartalmazhat szóközt és egyedinek kell lennie. LOCAL_SRC_FILES: A modulba tartozó fájlok felsorolása (a header fájlok kivételével). include (BUILD_SHARED_LIBRARY): A legutóbbi CLEAR_VARS óta definiált LOCAL_XXX változókat összegyűjti, meghatározza miket kell lefordítani és pontosan hogyan. 3. Következő lépés a natív kód (C/C++) megírása a JNI szabványnak megfelelően. A példában látható metódus egy egyszerű konstans String értékkel tér vissza. Fontos 22

25 megjegyezni, hogy a függvény elnevezése során kötelezően a Java_PackageName_ClassName_FunctionName konvenciót kell alkalmazni. A csomag és osztály neve helyére annak a Java osztálynak az elérési útja, illetve a neve kerül, amelyikkel kommunikálni a natív állománynak kommunikálnia kell a JNI interfészen keresztül. 4. Natív kód elérése Java kódból. Az osztály static blokkjában betöltjük a megfelelő modult, illetve natív kulcsszóval megjelöljük a natív állományban implementált metódust. Ez után a metódus meghívása a szokásos módon történik. 7. ábra Natív kód elérése Java osztályból Kamerakezelés Androidon Amennyiben olyan alkalmazást készítünk, amelynek szüksége van valamilyen formában a kamerához[5] való hozzáférésre, akkor két lehetőség közül lehet választani: beépített kameraalkalmazás meghívása, saját kamerafelület megvalósítása. Érdemes mérlegelni, hogy az applikációnak pontosan mik az igényei, mivel a beépített kameraalkalmazás meghívása jóval egyszerűbb, mint megvalósítani egy sajátot. A kamera alkalmazásból való hozzáféréséhez a manifest állományban be kell állítani az ezt engedélyező jogosultságokat. 23

26 8. ábra Kamera jogosultságok Amennyiben saját kamerafelület írására esik a választás, akkor szükség van egy felületre (előnézeti képre), amin a kamera kép meg fog jelenni, egy vezérlőre, ami kontrollálja a működést és természetesen magára a hardware, azaz a kamerára. A következőkben bemutatásra kerülnek a saját kamerafelület létrehozásának a lépései. A kamera előnézeti képének megjelenítésére lehet a modernebb API 14-ben megjelent TextureView-t is használni, azonban az Android platform fragmentációja miatt, a korábbi Android verzióval futó készülékek támogatásának érdekében a régebbi a SurfaceView kerül bemutatásra. Először a kameranézet kerül beállításra, illetve az annak a menedzseléséhez szükséges a SurfaceHolder objektum. 9. ábra Kamerafelület létrehozás 1. A kamera lefoglalása a következőképpen történik. 10. ábra Kamera lefoglalása 24

27 Lefoglaláskor fel kell készülni arra az esetre, hogy kivétel keletkezik, mivel előfordulhat, hogy más alkalmazás lefoglalta és nem szabadította fel a kamerát, illetve, ha nem volt ellenőrizve, akkor szélsőséges esetben az is előfordulhat, hogy nincs is kamera. A SurfaceHolder.Callback interfészét implementálva fel lehet iratkozni az előnézetet érintő változásokra és befolyásolhatjuk is azt. 11. ábra SurfaceHolder eseményfigyelői Értesülés szerezhető az előnézet létrehozásáról, módosulásáról, illetve az elpusztulásáról is. Amennyiben élő kameraképet kell megjeleníteni, akkor a teendők a következőek. Meg kell adni a kamerának, hogy melyik felületen kell a kamera képét megjeleníteni. Ezt azután lehet megtenni leghamarabb, miután a felület először létrejött. 12. ábra SurfaceView beállítása a kamerához A kamera képének kirajzolását a surfacechanged metódusban célszerű megtenni, mivel minden olyan esetben meghívódik, amikor felületen méretbeli vagy formai változás történik (például elforgatás). Ezenkívül, amennyiben nem csak a kamera kép megjelenítése, hanem az ahhoz való hozzáférés is szükséges, akkor a Camera osztály setpreviewcallback metódusának segítségével fel lehet iratkozni a kamera által megjelenített aktuális képre. 25

28 13. ábra Kamera képének megjelenítése a SurfaceView-ban Az aktuális kamera által látott kép a Camera.PreviewCallback interfész onpreviewframe metódusán keresztül érhető el. Azonban nem rögtön, ugyanis közvetlenül csak egy nyersformátumú képet szolgáltat, amit át kell konvertálni valamely képformátumba. Az alább látható ábrán.jpeg formátumba alakítás látható, majd ez átadásra kerül egy Bitmap objektumnak. 14. ábra Kamera képének kinyerése Utolsó lépésként nem szabad elfelejteni, hogy a kamera használat nagyon erőforrás igényes, ezért célszerű helyzettől függően az Activity vagy Fragment onresume() és onpause() metódusában gondoskodni annak lefoglalásáról és felszabadításáról. 26

29 15. ábra Kamera használat optimalizáció 27

30 4 Rendszerterv 4.1 Követelmény specifikáció Az alkalmazás a Hearthstone online kártyajáték Arena játékmódjához készült, mint segédalkalmazás. Annak korai szakaszában, a pakli összerakása során nyújt segítséget. Célja, hogy a felhasználó által a játék során a pakliba választott kártyák megőrzésre kerüljenek a telefonon. Az alkalmazás ehhez alkalmaz újszerű megközelítést azáltal, hogy nem megy egy az összes kártyát tartalmazó listából kell kikeresni a választott kártyát, hanem elég okostelefonnal készíteni egy a három választható kártyát tartalmazó fényképet, amit aztán az alkalmazás feldolgoz. A képelemezés során meghatározott három kártya közül a felhasználó már egy érintéssel kiválaszthatja azt a kártyát, amelyet a saját paklijához kíván adni. A kártyafelismeréshez először is egy a kártyákat tartalmazó képre van szükség. A kamera alkalmazás eléréséhez az Android nagyon kényelmes hozzáférést biztosít egy Intent-en keresztül. Azonban ennek használata mindig egy Activity váltással jár, ami gyakori használat esetén már zavaró lehet a felhasználó szempontjából. A pakli összerakása során pedig rövid időn belül harminc képet kell készíteni a felhasználónak, ezért szükséges, hogy az alkalmazás maga tartalmazzon egy beépített kamerakomponenst, hogy így tegye letisztultabbá, kifinomultabbá az applikáció használatát. A kamerakomponensnek két fő funkcióval kell rendelkeznie, egyrészt mutatnia kell az eszköz kamerája által látott képet a felhasználónak, valamint érintésre egy képet kell készíteni, amit aztán tovább ad feldolgozásra a képfeldolgozó komponensnek. 28

31 A képfeldolgozó komponens feladata, hogy eldöntse, hogy a kapott képen valóban három kártya található-e és ha igen, akkor határozza meg azokat. A mobilalkalmazásoknál a sebesség létfontosságú, ha valami lassú az a felhasználók szemében egyenlő a rosszal, ezért kritikus, hogy a komponens nemcsak megbízhatóan, hanem gyorsan is végezze a dolgát, ami több száz felismerendő objektum esetén nagy kihívás. Számolni kell azzal, hogy az alkalmazás rengeteg különböző hardverrel bíró telefonon fog futni, ami az Android platform jellegzetessége, illetve magát az alkalmazást is különböző fényviszonyok mellett fogja használni. Vagyis fontos a kártyafelismerés minél rugalmasabb legyen ne csak egy adott eszközön vagy fényviszony esetén legyen használható. A képfeldolgozó komponens a kártyák felismerését hasonlóság kereséssel végzi, vagyis nem csak a létrehozott paklik tárolásához van szükség adatbázisra, hanem tárolni kell minden Hearthstone-ban meglévő kártyához egy azt reprezentáló azonosítót is, amelyek felhasználásával eldönthető, hogy egy adott kártya melyikre hasonlít a leginkább. Ezen információk alapján az alkalmazás működési terve a következő: 16. ábra Működési terv 29

32 4.2 Tervezés Kamerakomponens A kamerakomponens feladata, hogy a kameraképét folyamatosan megjelenítse egy előnézeti képen, illetve, hogy érintésre egy fényképet készítsen az éppen látható tartalomról. Ehhez a komponensnek több dologról is gondoskodnia kell: kamera objektum kezelése, képernyőfelbontás, képernyőméret, orientáció. A konfiguráció során figyelembe kell venni a felbontás és a képernyőméret kapcsolatát. Nem lehet tetszés szerint összepárosítani bármelyik képernyőméretet akármelyik felbontással, különben a megjelenített kamera kép össze lesz nyomva vagy éppen el lesz nyújtva. Az Android operációsrendszeren egy metóduson keresztül lehet lekérdezni az adott készülék által támogatott felbontásokat és csakis ezek közül szabad választani. Fontos megjegyezni még, a kiválasztott felbontás mindig landscape módra vonatkozik. Ha portrait módban is szükséges a kamera futtatása, akkor annak képét 90 fokkal el kell forgatni, ami a setdisplayoirentation() metódus segítségével tehető meg, és ennek fényében kell a felbontást megválasztani. Fénykép készítésekor szintén el kell forgatni a képet, ha portrait nézetben kell a képet megjeleníteni. A fénykép elforgatása a setrotation() metódussal állítható be a kamera paraméterének. Érdekesség, hogy ez nem minden eszközgyártó esetében jelenti a fénykép adott fokkal történő elforgatását. Samsungos okostelefonoknál az elkészült kép exif információjába fog kerülni egy orientáció bejegyzés, ezt kiolvasva kell a programozónak adott szöggel elfordítania a kapott képet. 30

33 17. ábra Kamerakomponens működése Mivel a kameraerőforrás használata kifejezetten drága, valamint egy kamerát egy időben csak egy kliens használhat, ezért rendíkvül fontos, hogy, amint a kamera képet megjelenítő fragment háttérbe kerül, a kamera felszabításra kerüljön. Ez maga után vonja, hogy előtérbe kerülés esetén ismét le kell foglalni a kamera objektumot Képfeldolgozás megtervezése Az alkalmazás legfontosabb része a kártyafelismerés, ami képfeldolgozás által történik. A folyamat során egy nyers képből kártya objektumok előállítása megy végbe, amelyek közül a felhasználó később kiválaszthatja, hogy melyik kártyát kívánja hozzáadni az általa készített paklihoz. A folyamatot az alábbi ábra reprezentálja: 31

34 18. ábra Képfeldolgozás folyamata Ahogy az ábrán is jól látható, hogy maga a képfeldolgozási folyamat két fő fázisra bontható, melyek a következőek: szegmentálás, hasonlóság keresés. A szegmentálási fázis bemenete egy nyers kép, amelyet a kamera komponens szolgáltat. Feladatai közé tartoznak az alacsony képfeldolgozási műveletek is, mint például a kép konvertálása szürkeárnyalatos képpé. Azonban a fázis fő célja a kártya alakzatok keresése és ezek közül is a három ténylegesen látható kártya helyének detektálása a képen, illetve nem megfelelő input esetén a hiba jelzése. A kártyák helyének lokalizálásához azt a tényt lehet kiindulásként felhasználni, hogy a kártyák színe élesen elüt az azokat körülvevő háttértől, vagyis, a kamera képen küszöbölési eljárást végrehajtva, az így előállított képen az élek között megtalálhatóak lesznek a három kártya határvonalai is. Minden kártyára teljesül, hogy az azokat határoló élek zárt görbét alkotnak, vagy is el lehet hagyni minden 32

35 olyan görbét, amire ez a feltétel nem teljesül. A zárt görbék meghatározása után további szűrőfeltétel szükséges, hiszen ez még messze nem garancia a helyes eredményre. Ahhoz, hogy a zárt görbék közül meg lehessen határozni a három kártya helyét, további kártyatulajdonságoknak való megfelelést kell vizsgálni. A három megtalálni kívánt kártyára teljesülnie kell a következőeknek: Nem lehet közös pontjuk. elhelyezkedésük az y tengelyt tekintve nem metszheti egymást; a három kártyának megközelítőleg egy vonalban kell elhelyezkednie; a három kártya együttesen nem lehet kisebb, mint a kép magasságának a fele, illetve keskenyebb, mint a kép szélességének a fele; a három kártyának közel azonos méretűnek kell lennie; minden kártya szélesség/magasság aránya megközelítőleg 2:3. A szegmentálás alapvető működése az alábbi ábrán látható: 19. ábra Szegmentálás aktivitás diagramja A hasonlóság keresés fázis kezdeténél már rendelkezésre állnak a három meghatározni kártyát tartalmazó képek. A képek már nem tartalmaznak felesleges 33

36 információt, módosítás nélkül használhatóak az általuk reprezentált kártya azonosítására. Az összehasonlítás során nem képek kerülnek konkrétan összehasonlításra, mivel ez egyrészt túlságosan is memória igényes, ezenkívül lassú és megbízhatatlan is. Olyan megoldásra van szükség, ami gyors és jó hibatűréssel rendelkezik, s nem zavarja meg drámaian a megvilágítás vagy a kép méretének megváltozása sem. A kártya kép azonosításához egy már korábban említett módszer, a phash algoritmus kerül használatra. A módszer lényege, hogy egy adott képből az alacsony frekvenciáinak felhasználásával egy hash kerül generálásra, ami hűen tükrözi a kép struktúráját. Ez a következőképpen valósítható meg: 20. ábra phash előállítása 34

37 A phash merőben eltér a normál hashelési módszerektől, hiszen azokkal ellentétben itt az a cél, hogy hasonló képek esetén ne legyen nagy eltérés a generált a hash kódban. Annak érdekében, hogy a kártyák identitásának azonosítása minél hamarabb megtörténjen, valamint erőforrás-takarékossági szempontokat is figyelembe véve az összes kártyáról phash generálása az alkalmazás határain kívül történik. Így az applikációnak már csak az adatbázisból kell lekérdeznie, hogy melyik kártyához, milyen hash azonosító tartozik. Az alkalmazás futási idejében egyszerre mindig csak az éppen felismerni kívánt három kártya phash-ének előállítására van szükség. 21. ábra Kártyák azonosítása Miután rendelkezésre állnak a meghatározandó kártyák phash-jei és az összes lehetséges kártya, utána kezdődik meg az adott kártya mintához legjobban illeszkedő kártya megkeresése. Ez egyszerű Hamming-távolság vizsgálatot takar. A meghatározandó objektum az a kártya lesz, amire a legjobban hasonlít Működés megtervezése Az alkalmazás fő részei már meg vannak határozva, de még rendszerezni kell azokat. El kell dönteni, hogy a felhasználó az alkalmazás mely részén, mely szolgáltatáshoz férhet hozzá, illetve, hogy az egyes komponensek milyen sorrendben 35

38 követhetik egymást. Ezen kérdések tisztázásra első lépésnek hasznos egy használati eset diagram készítése, ami összegzi a felhasználó applikáción belüli lehetőségeit. 22. ábra Az alkalmazás használati eset diagramja Az ábra segítségével már egyértelműen látható, hogy az alkalmazás alapvetően három fő folyamatra osztható, új pakli létrehozása, meglévő paklik lekérése, illetve a témaváltás. A fő funkciókat érdemes az applikáció elejére helyezni, mivel ezek a folyamatok függetlenek egymástól, illetve semmilyen más folyamattól sem függenek, viszont belőlük további más funkciók érhetőek el. Közülük a legkisebb a témaváltás, amelynek segítségével a felhasználók kiválaszthatják a számukra legszimpatikusabb megjelenésű témát. Új pakli létrehozása esetén meg kell jeleníteni a meghasználónak az általa használt összes paklit, illetve egy paklit kiválasztva megnézheti annak részleteit, hogy milyen kártyák alkotják, valamint, hogy milyen eredményt sikerült vele elérni. A tervezés és a megvalósítás szempontjából a legösszetettebb az új pakli létrehozása. Ennek során a felhasználó első lépésben kiválaszt egy hőst, majd a választott hős képességeinek megfelelően összerakja a paklit. A pakli készítése során a felhasználónak lehetősége van új kártya hozzáadására képfeldolgozás által, illetve, ha meggondolná magát, akkor a pakliból törölheti is a kártyát és igény szerint hozzá is adhat. A kártyaválasztás során a felhasználó az úgy nevezetett mana curve segítségével tudja nyomon követni a felhasználó, hogy az eddig választott kártyák hány mana pontot 36

39 emésztenek fel. Ennek mutatása fontos, mivel minden játékosnak előre meghatározott mana pontból kell gazdálkodnia. A funkciók összegzése után már elkészíthető az alkalmazás nagyvonalú aktivitás diagramja, ami már mutatja, a folyamatok között fennálló sorrendiséget. 23. ábra Alkalmazás aktivitás diagramja Osztályok meghatározása A működés, a funkciók megtervezése után következhet az megfelelő osztályok meghatározása. A feladat osztályokra bontásakor fontos számításba venni, hogy az alkalmazásnak milyen követelményeknek kell megfelelnie. A diplomamunka során fejlesztett applikációval szemben a következő célkitűzések fogalmazódtak meg: átlátható programkód, robosztusság, legyen adaptív, könnyen módosítható, 37

40 legyen újrafelhasználható, ugyanazt az algoritmust ne kelljen többször is implementálni. Ezen követelmények tükrében az alkalmazás osztályainak meghatározásánál az MVC (Model View Control) tervezési minta került használatra. Modell csomag biztosítani. A modell csomagba kerülnek azok az osztályok, amelyek az alapadatokat fogják 24. ábra Modell csomag Az alkalmazásnak logikailag kétféle objektumot kell tudni kezelnie, paklikat és a hozzájuk tartozó kártyákat. Egy paklit el lehet nevezni, valamint kártyákat adni hozzá és kivenni azokat. A kártya objektum tartalmazza a Hearthstone-ból már ismert attribútumokat, valamint megtalálható benne a kártya azonosítóját képező phash, ami alapján fel lehet ismerni a kártyát. Mivel egy kártya több pakliban is szerepelhet és értelemszerűen egy pakli több kártyából áll, ezért közöttük lévő kapcsolat több-több kapcsolatnak feleltethető meg. 25. ábra Card - Deck kapcsolat adatbázis szinten 38

41 A Contour osztály szerepe, hogy megkönnyítse a szegmentálási folyamatot, egy zárt görbe pontjait tartalmazó listát tartalmaz, illetve az iscommonpointsbetween(contour c) metódusa segítségével megállapítani, hogy a két a Contour objektumnak van-e közös pontja. Üzleti logika Az alkalmazás fő üzleti logikáját a képfeldolgozás adja, ami a cardprocessing csomagban található. 26. ábra CardProcessing csomag Az alkalmazás által végrehajtott kártyafelismerés során két jól elkülöníthető folyamat zajlik: szegmentálás. hasonlóság keresés. 39

42 Amíg a szegmentálás során meghatározásra kerül a nyers képből a három kártyát tartalmazó képrész, addig a képelemzés során az dől el, hogy pontosan milyen kártyáról van szó. A kapcsolatos feladatokat a CardRecognizerManager osztály koordinálja. Annak az osztálynak, amelyik használni szeretne a cardprocessing csomagban megvalósított kártyafelismeréssel elég meghívnia a CardRecognizerManager osztályban található findcards() metódust. Maga a képfeldolgozás teljes folyamata egy külön szálon, aszinkron történik. A külön szálra azért van szükség, hogy a kártyafelismerés során se legyen blokkolva az alkalmazás UI-ja. A CardRecognizerManager működését az alábbi ábra szemlélteti: 27. ábra CardprocessingManager findcards() metódusa Egyedi komponensek Az alkalmazás fejlesztése során olyan követelmények jelentkeztek a felhasználói felülettel kapcsolatban, amelyre az alap gyári komponensek nem feleltek meg. Az okok különbözőek voltak, hol a gyári komponens megjelenése nem volt megfelelő, hol pedig a működése nem felelt meg a fejlesztendő alkalmazás elvárásainak. Az új komponensek a 40

43 views csomagban kaptak helyet. Az alábbi ábrán a csak a legfontosabb osztályok szerepelnek: 28. ábra Views csomag A CameraTextureView a TextureView osztályt terjeszti ki, illetve implementálja a SurfaceTextureListener interfészt. Az osztály célja, hogy egységbe zárja a kamerával kapcsolatos funkciókat, beleértve mind a megjelenéssel, mind a kamera erőforrás kezelésével kapcsolatos feladatokat. A ManCureView osztály egy oszlopdiagram megjelenítéséért felel. Az oszlopdiagram hivatott mutatni, hogy a felhasználó paklijában milyen mana költségű kártyák találhatóak. A CardSelectorView osztály használatára a képfeldolgozás végén kerül sor, miután a kártyák felismerése befejeződött. A komponens fogja kezelni a felismert kártyák megjelenítését, illetve egy eseményfigyelőn keresztül értesítést küld arról, ha a három felismert kártya közül valamelyik kiválasztásra kerül. Adatbázissal kapcsolatos osztályok A fejlesztett alkalmazásnak szüksége van adatbázis kapcsolatra, melyben tárolni tudja a Hearthstone-ban lévő összes kártyát, azok tulajdonságait, adott kártya azonosítására szolgáló phash-t, valamint a felhasználó által létrehozott paklikat. Az adatbázissal kapcsolatos műveletek a db csomagba kerültek. 41

44 29. ábra Db csomag A DbConstants osztályban található minden adatbázissal kapcsolatos fogalom, mint például a mező és osztálynevek konstansként kiemelve, hogy kizárható legyen az elírásból adódó hiba. A DatabaseHelper osztály az SQLiteOpenHelper osztályból származik, feladatai az adatbázis létrehozása, illetve annak frissítése. Az InitializerService osztály az IntentService absztrakt osztályból származik. Feladata, hogy háttérszálon a CardDbLoader segítségével feltöltse az összes kártyát, illetve annak tulajdonságait az adatbázisba. A CardDbLoader osztály a kártyákhoz kapcsolódó alap CRUD (CREATE, READ, UPDATE, DELETE) műveleteket valósítja meg. A felhasználói felülettel kapcsolatos osztályok Az alkalmazás felhasználói felületéről az Activity-k gondoskodnak. 42

45 30. ábra Az alkalmazás Activity-jei Az applikációban található Activity-k a BaseActivity osztályból származnak le, ami az általános, minden Activity-re érvényes beállításokat tartalmazza. A BaseActivity teszi lehetővé, hogy az alkalmazáson belül, futási időben is legyen lehetősége a felhasználónak témát váltani. Azért, hogy az alkalmazás minél dinamikusabb legyen és kielégítse a felhasználói igényeket Fragment-eket használ. A Fragment-eket Activity-khez lehet hozzácsatolni, előnye, hogy egy Activity több Fragment-et is tartalmazhat, így segítségével lehetőség van összetett, ugyanakkor jól strukturált kód írására. 43

46 5 Implementáció 5.1 Segédeszközök az elkészítésbe Eclipse Az Eclipse egy a Java programozási nyelven alapuló, rendkívül sokrétű integrált fejlesztői környezet. Gyors, hatékony fejlesztést tesz lehetővé az általa biztosított szolgáltatásoknak köszönhetően, mint például a kódkiegészítés, illetve szintaktikai és alapvető szemantikai hibák jelzése. Előfordulhatnak olyan helyzetek, amikor a programozó nem tudja pontosan a meghívandó metódus nevét, ilyenkor jól jön a fejlesztői környezet segítsége, egyébként az adott kódhoz tartozó teljes dokumentációban lehet böngészni, már ha van ilyen. Az Eclipse-ben ez a probléma szerencsére nem merül fel, hiszen vagy automatikusan, vagy a Ctrl+Space billentyűkombinációt követően előhozza a lehetséges parancsokat, az adott objektum meghívható metódusait. Ezek mellé a metódusok rövid leírásait is megjeleníti. Ha a kurzort egy osztály, metódus vagy adattag felé visszük, akkor láthatóvá válnak a hozzájuk tartozó dokumentációk, amennyiben van hozzá javadoc. Az Eclipse lehetővé teszi, hogy külső függvénykönyvtárakat könnyen hozzá lehessen adni a projekthez, valamint megkönnyíti a több modulos alkalmazások fejlesztését is. Komolyabb projektek fejlesztése során elengedhetetlen valamilyen verziókövető rendszer használata. Az Eclipse-hez elérhető számtalan plugin-nek köszönhetően könnyen integrálni lehet a megadott projeket a választott verziókövető rendszerrel, legyen az SVN, GIT vagy más verziókövető rendszer. Az Android alkalmazások fejlesztésére sokáig az Eclipse volt a hivatalos fejlesztői környezet az Android Studio megjelenéséig. A választás azért esett az Eclipse-re, mert teljes körű Android NDK(Native Development Kit) integrációt tartalmaz, amíg ez az Android Studio-ról nem volt elmondható a diplomamunka megkezdéséig. 44

47 Az Eclipse fejlesztői környezet segítségével történő androidos alkalmazások fejlesztéséhez először is szükség van pár alapbeállításra. Az Android SDK-n kívül szükség lesz az Android Development Tools (ADT) installására is, részletes leírás következő linken található: A plugin és Android SDK beállítását követően már meg is kezdődhet fejlesztés. Az Eclipse fejlesztés megkönnyítéséhez több eszközt is nyújt. Az egyik legalapvetőbb a Logcat, amely segítségével megkönnyíthető az alkalmazás debuggolása, mert így nyomon követhető, hogy pontosan hol mi történt az alkalmazás futása során. 31. ábra Logcat Amennyiben összetett alkalmazás fejlesztésére kerül sor, hasznos lehet tudni, hogy a rendszer az adott Activity-t mennyi idő alatt tudja felfújni, ennek nyomon követésére szolgál a Hierarchy Viewer[10]. A Hierarchy Viewer használata elősegíti az alkalmazás optimalizálását. 32. ábra Hierarchy Viewer 45

48 Használatával azonban nem csak az optimalizálást lehet mérni, hanem bármelyik View-ban lévő adatokhoz is hozzáférést lehet nyerni, ami biztonsági kockázatot jelent. A Google a Hierarchy Viewer használatát korlátozta, csak fejlesztői eszközökön, illetve szimulátoron lehet használni. OpenCV Az OpenCV[11] egy BSD licenc alatt álló programkönyvtár, amely ingyenesen használható mind oktatási, mind kereskedelmi célokra. Nagy hangsúlyt fektet a számítási hatékonyságra, ezért alkalmazható valósidejű alkalmazásoknál is. Az OpenCV C++ nyelven íródott, ami lehetővé teszi a több szálon történő feldolgozást is. Felhasználási területei a teljesség igénye nélkül: arcfelismerés, gesztus felismerés, kiterjesztett valóság, alakzat felismerés, 2D és 3D-s toolkit-eknél, objektum felismerés, mozgáskövetés, ember és gép közötti interakció esetén, robotika. Az OpenCV több platformon is elérhető, többek között: Windows, Linux, Android. Mac Os. ios. A továbbiakban az OpenCV Android platformon történő használata fog bemutatásra kerülni. A fejlesztők az OpenCV integrációja során két különböző lehetőség 46

49 közül választhatnak. Vagy a fejlesztendő alkalmazásnak kell tartalmaznia minden szükséges forrást, vagy Intent-eken keresztül kell kommunikálni az OpenCV Manager applikációval, ami biztosítja az OpenCV szolgáltatásokat. Az OpenCV az utóbbi módot preferálja, ezért az kerül bemutatásra. Az OpenCV-hez egy library projektet kell letölteni, ami a következő url-en keresztül érhető el: A letöltött forrásban az OpenCV SDK-ja értelemszerűen az sdk könyvtár alatt található, ezt kell importálni a workspace-be. 33. ábra OpenCV workspace import Amennyiben az alkalmazás, amibe integrálni kell az OpenCV-t nem tartalmaz C/C++ fájlokat, akkor csak meg kell adni a hivatkozást az OpenCV library projektre. 34. ábra ivatkozás az OpenCV projektre Az OpenCV által nyújtott natív függvénykönyvtárat nagyon kényelmesen lehet használni egyszerű Java osztályokon keresztül. A Java kódból történő JNI interfészen keresztül történő natív függvényhívásokról az OpenCV gondoskodik. Azonban az OpenCV használata előtt kötelezően inicializálni kell azt. Az inicializálás aszinkron módon történik, megkezdésének ajánlott időpontja az Activity onresume() metódusa. 47

50 35. ábra OpenCV initasync Az initasync() metódus paraméterében átadott BaseLoaderCallback-en keresztül fog az OpenCV jelezni, ha az inicializálás befejeződött, csak a visszajelzést követően lehet használni a OpenCV által nyújtott szolgáltatásokat. A visszajelzést a következőképpen lehet lekezelni: 36. ábra OpenCV loader callback Amennyiben az alkalmazás használja az OpenCV által implementált kamerakomponenst, akkor azt az mloadercallback-ben, sikeres lefutás után lehet engedélyezni. Az OpenCV által biztosított kamera komponens rendkívül megkönnyíti az interaktív kameraalkalmazások fejlesztését. Elég hozzá a CvCameraViewListener2 interfészt implementálni. 48

51 37. ábra OpenCV camera eseményfigyelő Az interfész segítségével az OpenCV által biztosított kamerakomponens életciklusát lehet végigkövetni. Legérdekesebb metódusa az oncameraframe(), amelynek visszatérési értéke fogja megmondani, hogy mi jelenjen meg a kamera előnézeti képén, tehát egyszerűen lehet módosítani a kamerától kapott képet. Minden jó tulajdonsága ellenére azonban az OpenCV kamerakomponens nem került használatra a diplomamunkában, ennek fő oka, hogy a kamerakomponens alapból nem támogatja a portrait módot, csak landscape-ben fut mindig teljes képernyőn. Ezen okok miatt és mivel a diplomamunka során fejlesztett alkalmazásnak nincs szüksége a kapott kamerakép módosítására, egy saját kamerakomponenst használ az alkalmazás, amelynek ugyan szerényebbek a képességei, viszont orientáció és méret szempontjából jobban testre szabható, mint az OpenCV kamera komponens. A diplomamunka keretein belül elsősorban az OpenCV által nyújtott jól használható, kapcsolatos függvénykönyvtár került felhasználásra. Az OpenCV-ben egy képet egy úgynevezett Mat objektum fog reprezentálni, két fő része van egy fix méretű header, benne a képre vonatkozó információkkal (például méret, objektum memóriacíme) és egy pointer, ami a kép pixeleit tároló mátrixra mutat. A képet tartalmazó mátrix felfogható egy olyan kétdimenziós vektornak, amelynek minden eleme egy vektor. A vektor hossza pedig függ a használt színtértől, például szürkeárnyalatos képek esetén csak egy elemű lesz a vektor. 49

52 Az egyik legalapvetőbb képfeldolgozási eljárásnak tekinthető a kép átméretezése, valamint szintér váltása. OpenCV-ben az előbbiek a következőképpen valósíthatóak meg: 38. ábra OpenCV alap műveletek Színtér váltás esetén első paraméter az átalakítani kívánt Mat objektum, második paraméter pedig az a Mat objektum, amelybe az eredménynek kell kerülnie, az utolsó paramtérben pedig megadható, hogy melyik színtérbe kell átkonvertálni a képet. Átméretezésnél az első két paraméter megegyezik a szintér váltáséval, viszont utána már eltérés, hogy az átméretezés mérete nem annak a Mat objektumnak a méretétől függ, amelyben az eredmény tárolásra kerül, hanem egy külön paraméterben kerül megadásra, utolsó paramétere pedig az interpolációs eljárás típusának a meghatározása. Ha a képen alakzat felismerést kell végezni, akkor célszerű azt a kép előfeldolgozásával kezdenie, erre jó módszer küszöbölés. Küszöbölés során egy szürkeárnyalatos kép a bemenet. Ha a bemeneti kép intenzitása az adott helyen kisebb, mint a küszöbérték, akkor 1-re állítja, egyébként 0-ra. Az eljárás gyengesége abban rejlik, hogy a kép intenzitása különböző lehet a kép egyes részein, vagyis nem egyenletes megvilágítás esetén információ veszteség fog bekövetkezni. A hiba abban rejlik, hogy a küszöbölés során a teljes képre ugyanaz az egy globálisan meghatározott küszöbérték kerül használatra. Azért, hogy a nem egyenletes megvilágításból adódó információveszteséget minimalizálni lehessen érdemes adaptívküszöbölést alkalmazni. Az adaptívküszöbölés erőssége abban rejlik, hogy nem globális, hanem lokális küszöbértékeket használ. A módszer a képet blokkokra osztja és minden blokkra egy küszöbérték kerül megválasztásra. A blokkméretet a programozó szabhatja meg. 39. ábra Adaptív küszöbölés Speciális esetekben, már az adaptívküszöbölés is eredményre vezethet, ám gyakran ezután még további szűrést kell alkalmazni a keresett objektum, vagy objektumok 50

53 helyének meghatározásához. Az OpenCV segítségével könnyen fel lehet deríteni a szürkeárnyalatos képen található körvonalakat a findcontours() metódus segítségével. 40. ábra FindContours A keresés során meg lehet adni annak módját, az ábrán látható Imgproc.RETR_LIST konstans jelentése, hogy az eredménybe kerüljön be minden körvonal, anélkül, hogy közöttük hierarchiai kapcsolat kerülne meghatározásra. A talált körvonalakat egy listában adja vissza. Picasso A mai mobilalkalmazásoknál többnyire elkerülhetetlen a képek használata. Az Android platformon alapból nincsen olyan egyszerű és jó könyvtárcsomag, amit lehetne használni képek betöltésére, pedig sok kép kezelése egyáltalán nem triviális feladat. Képkezelési feladatok: képek aszinkron betöltése, hogy ne blokkolódjon a UI szál; képek cache-elése, egy képet ne kelljen újra betölteni; gyorsítótár kezelése; képek több forrásból érkezhetnek. Szerencsére a Picasso[12] képletöltő és cache-elő függvénykönyvtár leveszi a terhet a fejlesztők válláról. A Picasso egységes kezelési felületet biztosít a képek letöltéséhez, érkezzenek azok akár hálózaton, erőforrások közül, vagy fájlból. mindössze egy a függvénykönyvtárt tartalmazó.jar állományt kell hozzáadni a projekthez és már lehet is használni a Picasso-t. 41. ábra Picasso képletöltés A Picasso alapvető használatához meg kell adni egy kontextust, hogy mit kell letölteni (a load() metódus túlterhelésének köszönhetően meg lehet adni URL-t, Erőforrás 51

54 azonosítót, vagy fájlt), illetve hogy hova kell letölteni a képet. Lehetőség van a képletöltés további testreszabására, leírás a következő URL-en található.. 52

55 5.2 Alkalmazás Az elkészült alkalmazás felhasználóknak a Hearthstone online kártyajáték aréna játékmódban nyújt segítséget. Az alkalmazás segítségével a következőkre van lehetőség: új pakli létrehozás, pakli törlés, pakli szerkesztése. Az alkalmazás felépítése Az alkalmazás belépési pontja a splash screen (az induló képernyő), ami az alkalmazás ikonját mutatja animálva, körbe-körbe forgatva. 42. ábra Induló képernyő 53