Android alapú szoftverfejlesztés kezdőknek

Átírás

1 oktatási segédanyag, mely a Társadalmi Megújulás Operatív Program Határon átnyúló együttműködés a szakképzés és a felnőttképzés területén c. pályázati felhívás keretében megvalósított Mobil alkalmazásfejlesztés az informatikai tudás innovatív alkalmazásával című, TÁMOP / kódszámú projekt keretében valósult meg

2 1 Tartalomjegyzék 1. Bevezetés Az Android operációs rendszer Egy kis történelem Az Android platform felépítése Fejlesztés, fordítás és futtatás Fejlesztői környezet Fejlesztői környezet telepítése Eclipse fejlesztői környezet Az alkalmazások felépítése Az alkalmazások futtatási környezete Az Android alkalmazások építőkövei, a komponensek Activity Service Content provider Broadcast receiver Intent Manifest állomány Erőforrások Az Activity életciklusa, környezete Activity Az Activity életciklusa Felhasználói felületek Az alapok Layoutok használata Interaktív vezérlő elemek és eseménykezelésük Stílusok és témák alkalmazása Lokalizáció Animációk Menük Komponensek közötti kommunikáció Az intent objektumok Activity indítása Alkalmazás felkészítése kérések kiszolgálására Intent Filter Broadcast események hívása Állománykezelés Kulcs-érték párok tárolása Az Internal Storage használata...56

3 7.3. Az External Storage használata Alkalmazások közzététele Nyílt közzétételi lehetőségek Az APK fájlok közzététele Webes közzététel, QR kód Közzététel ben Közzététel valamely piactér alkalmazásban Google Play Fizetős tartalmak közzététele Közzététel a Google Play esetében Előkészületek Alkalmazás közzététele

4 1. Bevezetés 3 Az Android operációs rendszer egy ingyenesen elérhető nyílt forráskódú operációs rendszer, mely mögött a Google és számos más nagyvállalat összefogása áll. Ennek ismeretében talán nem meglepő, hogy napjainkra az Android operáció rendszer vált a legnépszerűbbé platformmá az okostelefonok piacán. Ezt bizonyítja az is, hogy ma már több, mint 900 millió eszközön aktiválták 1 az Android operációs rendszert több, mint 190 országban, és naponta több mint 1 millió új Androidos készüléket aktiválnak világszerte 2. Jelen jegyzetünkben nem másra vállalkozunk, mint hogy - a teljesség igénye nélkül - bemutassuk az Android operációs rendszer főbb jellemzőit, és azokat az alapvető ismereteket, amelyek az Androidos alkalmazások készítéséhez létfontosságúak. Alapul tekintjük, hogy a kedves olvasó rendelkezik már programozási ismeretekkel, és ismeri az objektum orientált programozás főbb jellemzőit, illetve elsajátította már a Java nyelv használatát. Jegyzetünkben a bevezetés után az Android platform rövid bemutatására kerül sor, majd a fejlesztői környezet telepítéséről és felépítéséről. Ezt követően megismertetjük az olvasót az alkalmazások felépítésével, az Activity-k fogalomkörével és ezek környezetével. A továbbiakban betekintést nyújtunk a felhasználói felületek kialakításához szükséges legalapvetőbb elemek kezelésébe, és a különböző komponensek közötti kommunikációba. Végezetül bemutatjuk az egyszerű állománykezelés alapjait és azt, hogy alkalmazásunkat mások számára miképpen tehetjük elérhetővé a Google Play-en keresztül. A jegyzetünkben szereplő példaprogramokat több platformon is igyekeztünk tesztelni. Alapnak a 4.1-es verziót tekintettük, melyet Samsung Galaxy S III-as telefonokon és Samsung Galaxy Tab 2-esen futtattunk, továbbá ahol lehetséges volt, ott programjainkat teszteltük még a 2.3as verzión is. 1 Salvador Rodriguez - Google: 900 million Android devices activated to date, Los Angeles Times Android -

5 2. Az Android operációs rendszer Egy kis történelem Az Android operációs rendszert eredetileg a Palo Alto-i székhellyel rendelkező Android Inc. vállalat kezdte el kifejleszteni, amit a Google 2005-ben vásárolt fel. Ez után, két éves fejlesztői munkát követően a Google 2007-ben jelentette be készülő mobil-operációs rendszerét, melyet az ugyanakkor megalakult Open Handset Alliance (OHA) 3 üzleti szövetséggel közösen fejlesztettek és fejlesztenek napjainkban is. Az OHA szövetség tagja a Google-ön kívül a HTC, a Dell, a Motorola, a Samsung, az LG, a Qualcomm, az NVIDIA, a T-Mobile és még sok más vállalat. A teljesség igénye nélkül nézzük meg az operációs rendszer fejlődésének fő időrendi lépéseit! Az első Android mobil-operációs rendszerrel felszerelt okostelefon a HTC G1-es telefonja (HTC Dream) volt, mely 2008 vége felé került a piacra, és amelyet a T-Mobile forgalmazott. Ezen az Android 1.0-ás verziója futott. Innentől fogva az operációs rendszer fejlesztése rendkívül gyors léptékben zajlott, szinte havonta jelentek meg az újabbnál újabb verziók. Az 1.0-ás javítása 2009 februárjában látott napvilágot 1.1-es verziószámmal, azonban az igazi áttörést a év áprilisában megjelent 1.5-ös (Cupcake) verzió jelentette, amely rengeteg újdonságot tartalmazott elődjeihez képest. A fejlődés gyorsaságát is mutatja, hogy a 2.0-ás (Eclair) verzió még ugyanannak az évnek októberében forgalomba került. Ezt követte 2010 januárjában a 2.1- es, 2010 májusában pedig a 2.2-es (Froyo) verzió. A 2010-es év decembere pedig elhozta a 2.3-es (Gingerbread) verziót, mely erőteljes optimalizáláson esett túl elődeihez képest, bár nagyobb változást nem hozott. Új kihívást jelentett az Android számára a tablet Pc-k piacának beindulása is. Bár a Samsung Galaxy Tab sikeres eladási mutatókkal indult, azonban hamar kiderült, hogy az akkori Androidos verziók nem igazán tudták teljes egészében kiszolgálni a tabletekkel kapcsolatos igényeket. Ennek megoldására jelent meg 2011 januárjában a 3.0-ás (Honeycomb) verzió, amely már lényegi változásokat hozott az operációs rendszer életében, hiszen szinte teljesen átírták az egészet. Itt rövid időre kettévált az okostelefonok és a táblagépek operációs rendszere, hiszen míg az előbbieket a 2-es verzió szolgálta ki, addig az utóbbiakat a 3-as. A 4.0-ás (Ice Cream Sandwich) verziója teremtette meg újra az egységet az Android platformon belül, hiszen ez már mind a táblagépeket, mind pedig a telefonokat támogatta egyben, illetve 3 Open Handset Alliance -

6 számos új funkcióval bővült az operációs rendszer palettája. Ez a verzió 2011 októberében látta meg a napvilágot. A jegyzet írásának kezdeti időpontjában (2012. november) még a 2012 júniusában bemutatott 4.1-es (Jelly Bean) verziót volt a legfrissebb, azonban a közeli napokban jelenik majd meg a 4.2-es verzió is, amely várhatóan a 4.1-es frissített kiadásának tekinthető majd. Valószínűsíthető, hogy a jelentősebb változásokat azonban csak a jövőre megjelenő 5-ös verzió hoz majd, de addig is további 4-es verziók megjelenése várható. A fent említett verziók szinte mindegyike alkalmazásban van még ma is a készülékeken, amit jól jellemez a következő táblázat, mely az utóbbi 14 napban a Google Play oldalára feljelentkezett telefonok verzióinak eloszlási adatait tartalmazza. 4 5 Verzió Kódnév API Eloszlás 1.6 Donut 4 0.2% 2.1 Eclair 7 1.9% 2.2 Froyo 8 7.5% % Gingerbread % % Honeycomb % Ice Cream Sandwich % % Jelly Bean % 1. Táblázat Android verziók és eloszlási arányuk 2.2. Az Android platform felépítése 5 Az Android operációs rendszer négy fő komponensből épül fel, mint ahogy azt az ábrán is láthatjuk (1. ábra). Legalul helyezkedik el a Linux kernel. Ennek fő feladatai a memória és a hardver eszközök kezelése, az alkalmazások felügyelete, a feladatok ütemezése, valamint ez felel a biztonságért rendszer és alkalmazás szinten is. E fölött találhatjuk a rendszer számos komponense által használt programkönyvtárakat, melyek C/C++ nyelven íródtak. Szintén itt 4 A március 4. adatok alapján Android Developers -

7 találjuk az Android futtatókörnyezetet, mely a Java alap könyvtárait és a Dalvik virtuális gépet (DVM) tartalmazza. Ez utóbbi feladata a Java alkalmazások futtatása a Java-nál megszokott JVM-mel analóg módon ábra Az Android operációs rendszer felépítése Minden Android alkalmazás egy különálló DVM-ban fut, melyet a párhuzamos futási képességre és a minimális memória felhasználásra optimalizáltak. Akár csak a Java, a Dalvik VM is garbage collector-ral dolgozik, azonban a korlátozott memória miatt érdemes erős hangsúlyt fektetni a programon belül a hatékony memória kihasználásra. A felső két szint már teljesen Java-alapú alkalmazásokat kínál számunkra, melyek a virtuális gép segítségével lényegében elrejtik előlünk az alsóbb szinteket. A harmadik szint az alkalmazás-keretrendszer, mely az erőforrásokhoz való hozzáférést biztosítja, és mely lényegében kiszolgálja a legfelső rétegben alkalmazás rétegben található, a felhasználók számára elérhető alkalmazásokat Fejlesztés, fordítás és futtatás Az Android alapú alkalmazások fejlesztésénél két eltérő részről beszélhetünk. Alapvetően az alkalmazások fejlesztése Java nyelven folyik, azonban az alacsonyabb szintű funkciók hatékonyabb felhasználásához lehetőségünk van natív kódot is készíteni. A Java alkalmazások készítéséhez szükséges Software Development Kit fejlesztői csomagot a Google biztosítja számunkra. A natív kódok

8 készítése már nem Java, hanem C++ programozási nyelven történik, melyhez szintén rendelkezésünkre áll egy Native Development Kit fejlesztői csomag. Természetesen ez a két rész nem különül el teljesen, hiszen egy projekten belül mind Java, mind natív kódrészeket is elhelyezhetünk. Az Android alkalmazások esetében a felhasználói felület és a program forráskódja teljesen elkülönül. A felhasználói felület kialakítására XML állományokat használunk, és bár lehetséges a felhasználói felületek definiálása a forráskódon belül is, azonban célszerűbb ezt kerülni. A felhasználó felület elemei erőforrásként fognak megjelenni a programunkban. Mint azt később részletesebben is látni fogjuk, a forráskódok az src, míg az erőforrások a res alkönyvtárban lesznek elérhetőek. A kettő közötti kapcsolatot az R.java állomány fogja megteremteni, azaz ennek a segítségével tudjuk majd a forráskódunkból elérni a rendelkezésre álló erőforrásainkat. Miután a programozó elkészítette a forráskódot a hozzá tartozó XML erőforrás állományokkal, valamint a manifest állományban beállította az alkalmazás hozzáférési jogosultságait, azaz megadta, hogy milyen elemeket érhet el az alkalmazás (pl. internet elérés, szenzorok, stb.), ezután megtörténhet a fordítás. A fordítás során először a Java állományok kerülnek lefordításra. Ezt követően a fordító, a Dalvik által értelmezhető bájtkódot alakítja ki az elkészült class állományok és a külső könyvtárak felhasználásával. A bájtkódból, valamint a nem lefordított (pl. képek) és a lefordított erőforrásokból a fordító létrehoz egy aláírás nélküli apk állományt. 6 Ahhoz, hogy ezt az alkalmazást feltelepíthessük bármilyen eszközre, vagy közzé tehessük a Google Play-en, ahhoz szükséges, hogy a fejlesztő digitális aláírással lássa el a programot. Erre a célra a fejlesztő egy saját maga által létrehozott aláírást hozhat létre a Keytool utility segítségével. Erre az egyedi aláírásra csak a közzététel esetében kell odafigyelnünk, mivel a fejlesztés során a fordításkor automatikusan egy debug kulcs kerül elkészítésre. 7 A kulcs felhasználásával a fordító végül létrehozza az aláírt, és így most már telepíthető apk állományunkat. Az apk állomány - akár csak a Java-ból már jól ismert jar egy tömörített állomány, amely a lefordított forráskódot és metainformációkat tartalmazza. Általában a következő elemeket tartalmazza az apk állomány: 7 6 Android - Building and Running Android - Signing Your Applications -

9 META-INF alkönyvtár: Android alapú szoftverfejlesztés kezdőknek o CERT.RSA: alkalmazástanúsítvány, o MANIFEST.MF: metainformációk kulcs-érték párokba rendezve, o CERT.SF: erőforrások listája az SHA-1 hash értékükkel res alkönyvtár: az alkalmazásnál felhasznált erőforrásokat tartalmazza, AndroidManifest.xml: az alkalmazásra vonatkozó nevet, verziószámot valamint a jogosultságokat tartalmazza classes.dex: itt találhatóak a lefordított osztályok resources.arsc: erőforrásadatok találhatóak benne A fordítás végeredménye tehát egy apk állomány, melynek futtatásához már nincs más teendőnk, csak hogy ezt az állományt felmásoljuk a céleszközre. Ennek elindítása pedig telepíteni fogja az alkalmazásunkat a céleszközön Fejlesztői környezet Fejlesztői környezet telepítése A fejlesztői környezet telepítésének részletes leírása megtalálható az Android fejlesztői weboldalon 8, de nagy vonalakban tekintsük át itt is, hogy milyen lépések szükségesek a fejlesztői környezet kialakításához Window-os környezetben 9. Első lépésben célszerű feltelepíteni a Java SE Development Kit (JDK) 10 csomagot. Amennyiben elmulasztanánk, az sem probléma, ugyanis a következő lépésben az Android Software Development Kit (SDK) 11 telepítése következik, amely ha nem találja JDK-t a gépen, akkor telepíti azt. Fontos itt megjegyezni, hogy a problémamentes működés érdekében célszerű, ha az Android SDK-t a C: meghajtóra telepítjük szóközmentes elérési úttal, és a felhasználói nevünk sem tartalmaz szóközt. A telepített Android SDK a fejlesztői csomagon túlmenően számos egyéb részt is tartalmaz, mint például emulátort, dokumentációt vagy példaprogramokat, és ezen túl még sok hasznos elemet. 8 8 Android Installing the SDK Más platformokra történő telepítés nagyon hasonló ezért azokkal most nem foglalkozunk. 10 Oracle Technlogy Network Java Java SE Downloads Android SDK Download -

10 Az Android SDK telepítése után elérhetővé válik az SDK Manager program, amely segítségével letölthetjük a számunkra szükséges Android verziókat, valamint frissíthetjük azokat. Ügyeljünk arra, hogy minimum egy platformot itt telepítenünk kell ábra Az SDK Manager program a telepítés után Az Android SDK telepítése után szintén elérhetővé válik az AVD Manager, amely segítségével a kiválasztott verziónak megfelelő emulátort lehet létrehozni. Ez létrehozható már most is, de később is beállítható a programok fordítása és futtatása előtt. Az így létrehozott emulátor képes a teljes Android rendszert szimulálni. 3. ábra A szimulátor működés közben

11 Az emulátor segítségével különböző események bekövetkezését is tudjuk szimulálni az által, ha az emulátor bal felső sarkában található portszámra az ábrán ez betelnetelünk. A telnet localhost <portszám> paranccsal megnyithatjuk az emulátorhoz tartozó Android konzolt, ahol különböző eseményeket tudunk előidézni. Ilyen esemény lehet például egy beérkező telefonhívás is, amit a gsm call <telefonszám> paranccsal tudunk szimulálni. A következő lépés az integrált fejlesztői környezet telepítése. A fejlesztésekhez a legteljesebb támogatást az Eclipse 12 nyújtja, ezért mi is ezt fogjuk bemutatni, de egyéb fejlesztői környezeten is folyhat a fejlesztés 13 Az Eclipse telepítése után össze kell kapcsolnunk az Android SDk-t az Eclipse-el. Ezt az Eclipse plugin telepítésével tehetjük meg a következőképpen: 1. Nyissuk meg a Help>Install New Software almenüt 2. Klikkeljünk az Add gombra, majd adjuk meg a felbukkanó ablakban az Android nevet és a következő URL-t: 3. Jelöljük ki a Developer Tools-t, majd a Next gomb lenyomása után fogadjuk el a licenszt és a Finish gombbal telepítsük a plugint. 4. Indítsuk újra az Eclipse-t. 5. Ezután még meg kell adnunk az Android SDK helyét Ne felejtsük el, hogy ha frissítettük az Android SDK-t, akkor az Eclipse beépülő moduljait is frissítenünk kell, de erre a rendszer automatikusan figyelmeztet is majd minket Eclipse fejlesztői környezet Az Eclipse egy integrált fejlesztői környezet, amely minden platformon elérhető, és amely számos programozási nyelvhez nyújt fejlesztői környezetet (pl. Java, C++, stb.). Sajnos terjedelem hiányában nincs lehetőségünk az Eclipse részletes bemutatására, ennek felfedezését a kedves olvasóra bízzuk, itt csak pár részletre térünk ki. Az Eclipse az Android plugin telepítése után nagyon hasznos elemekkel segíti alkalmazásaink fejlesztését. Egyrészt képes a futtatás során az emulátor elindítására, másrészt, ha az eszközünket USB-n csatlakoztattuk a számítógéphez, akkor képes közvetlenül az eszközünkön futtatni az alkalmazásunkat. Alap beállítás esetén, mint ahogy az a mellékelt ábrán is látszik (4. ábra), az Eclipse felülete egy szokványos fejlesztői felületet ad Eclipse Netbeans is használható fejlesztésre, azonban ennek támogatása még jelenleg nem a legteljesebb. Lásd -

12 számunkra. Felül találhatóak a menük és az eszközsorok, bal oldalt a Project Explorer, ahol az aktuális projektjeink alkönyvtárai között barangolhatunk. Középen található a szerkesztő rész, ahová a kódjainkat írhatjuk, míg alatta a Consol és a LogCat elemek helyezkednek el. Természetesen ezek a részek a felhasználó igényei szerint áthelyezhetőek, módosíthatóak. A jobb felső sarokban található gombokkal az Eclipse perspektívái között váltogathatunk. Itt találjuk többek között azon elemeket, amelyek az Androidos alkalmazásfejlesztést igazán kényelmessé teszik. Ilyen perspektíva a Debug, ahol a hibakeresést tudjuk profi módon végezni, vagy a DDMS, ahol képesek vagyunk az emulátor, vagy a mobil készülék beállításait elérni ábra Az Eclipse felhasználói felülete A fejlesztő kényelmét szolgálja az is, hogy az XML erőforrások - mint például a AndroidManifest.xml állomány tartalmát az egyszerű szöveges bevitel mellett, grafikus felületen is elvégezhetjük. Új Androidos alkalmazás létrehozásához válasszuk a File>New>Project almenüt, majd válasszuk ki az Android Application Project-et. Ennek hatására az Eclipse létrehozza a Hello world alapértelmezett alkalmazásunkat a szükséges alkönyvtárakkal és állományokkal egyetemben. Az alkalmazásunk futtatása a Run>Run parancs segítségével történik, ami elindítja az emulátorunkat. Ha nem állítottunk be korábban semmilyen AVD eszközt, akkor most van lehetőségünk a virtuális eszköz létrehozására, amelyen az alkalmazásunk majd fut.

13 3. Az alkalmazások felépítése 12 Ebben a fejezetben az Android alkalmazások szerkezetével, azok általános felépítésével foglalkozunk. Az eredményesebb munka érdekében azonban ehhez ismerkedjünk meg előtte a platform olyan jellemzőivel, amelyek hatással lesznek erre is! 3.1. Az alkalmazások futtatási környezete A közkeletű vélekedés alapján egy mobilalkalmazás olyan program, amit egy ikon (csempe, stb.) képvisel egy indítófelületen, és ha rákattintunk, betöltődik. Ez azonban csak a valóság egy igaz, talán a legnagyobb szelete. Alkalmazásnak tekinthetjük azokat a háttérben futó szolgáltatásokat is, amelyek nem feltétlenül rendelkeznek látványos felhasználói felülettel. Ezek végezhetnek szolgáltatásokat, kommunikálhatnak a hálózatban, és nem okvetlen gombnyomásra indulnak, hanem aktiválhatja őket egy tetszőleges esemény, mint például a hálózati töltöttség alacsony szintje. A platform a nyitottság mellett néha ennek ellenére igyekszik biztonságos körülményeket is teremteni a felhasználók számára. Ez megnyilvánul abban, hogy az alkalmazások csak olyan rendszerszolgáltatáshoz férhetnek hozzá, amelyre engedélyt kaptak. A program telepítésekor ezek listázódnak, azokat a felhasználónak jóvá kell hagynia. Ilyen jogok lehetnek a felhasználó személyes adataihoz való hozzáférés (telefonszámok, címek), különböző hálózati erőforrások használata, vagy akár csupán az eszköz ébren tartása. A jogosultságok - hasonlóan a most következő fejezetben tárgyalt komponensekhez az alkalmazás manifest állományában kerülnek rögzítésre. A platform biztonsági törekvései abban is tetten érhetők, hogy minden alkalmazás szeparált környezetben fut (virtual sandbox), függetlenül az általuk használt technológiától. Mindegy tehát, hogy Java, natív, vagy hibrid megoldást választunk, a programjaink ugyanúgy elkülönülnek egymástól, és ugyanazon biztonsági fokozatok lesznek érvényesek rájuk. Alapesetben az alkalmazások különböző rendszerazonosítók (Linux user ID és group ID) alatt futnak. Ez a rendszerazonosító az Android által ismert, az alkalmazásnak nem is kell róla tudnia. Az alkalmazások ilyenkor saját Linux processben, folyamatban futnak. Az Android akkor indítja el a folyamatot, ha az alkalmazás valamely komponense elindul. Bezárásra akkor kerül, ha már nincs rá szükség, illetve ha a rendszernek szüksége van az általa lekötött erőforrásokra, memóriára. Minden alkalmazás olyan tanúsítvánnyal van aláírva, amelynek a privát kulcsa az alkalmazás fejlesztőjénél található. A tanúsítvány

14 önaláírt, ez megkönnyíti a fejlesztők dolgát, amennyiben nem szükséges hivatalos kibocsátónál hitelesíttetni azokat. Amennyiben két alkalmazás ugyanazon a Linux user ID-n osztozik, hozzáférhetnek egymás fájljaihoz. Ily módon takarékoskodhatnak a rendszer erőforrásaival, hiszen ugyanazt a virtuális gépet használják a futtatáskor. Ennek feltétele az is, hogy ugyanazzal a tanúsítvánnyal legyen a két alkalmazás aláírva Az Android alkalmazások építőkövei, a komponensek 13 Minden Android alkalmazás egy, vagy több komponensből épül fel. Az alkalmazás ugyanabból a komponensből is tartalmazhat többet. A komponensek különböző belépési pontokat biztosítanak a programunk felé a rendszer számára. Nem minden komponens biztosít azonban a felhasználó számára belépést a programba. Az Android programokban négy komponens létezik, amelyek mindegyike különböző célt szolgál. Életciklusuk is eltér egymástól, amelyek létrehozzák, vagy megsemmisítik őket. Egy egyszerű C++ programhoz képest itt tehát nem feltétlen egyetlen, jól meghatározott belépési pontja lehet a programnak (mint a main() metódus). Egy új komponens indítása előtt a rendszer megnézi, fut-e már a komponenst tartalmazó alkalmazás egy processze. Ha igen, alapesetben ehhez a processzhez rendeli a létrehozandó komponenst. Ha nem, akkor elindítja az alkalmazást, majd példányosítja a komponenshez szükséges osztályokat Activity Az Activity talán a legismertebb komponens. Ez egy felhasználói felülettel rendelkező képe a programnak. Egy alkalmazás több Activityt is tartalmazhat, amelyek együtt biztosítják a program valamennyi szolgáltatását. Egy naptáralkalmazás például tartalmazhat olyan Activityt, amely havi bontásban mutatja a napokat, egy másikat, ami heti, vagy napi listát valósít meg. Ugyanakkor egy harmadik Activity szolgálhat új naptári események rögzítésére. Az Android rendszer megengedi, hogy olyan Activityt is meghívhassunk (megfelelő jogosultsággal a birtokunkban), ami másik alkalmazáshoz tartozik. Ily módon bizonyos tevékenységeket (például az előző naptáralkalmazásban egy találkozóhoz az ismerősünk kiválasztását) a felhasználó akár minden programból ugyanazzal az Activityvel, a megtanult módon végezheti, továbbá ezt az alkalmazás fejlesztőjének sem szükséges megírnia. Az Activity ablaka leggyakrabban teljes képernyő méretű, de más módokon is megjelenhet a felhasználó számára: van lehetőség úszó ablakban, vagy az ActivityGroup segítségével beágyazott ablakban

15 megjeleníteni Activityt. A 3.0-s Honeycomb verziótól kezdve Fragmenteket is használhatunk az Activityn belül. Ezek az Activity moduláris részeként akár saját életciklussal is rendelkezhetnek Service A Service ezzel szemben nem rendelkezik önálló felülettel. Általában egy háttérfolyamat, vagy elhúzódó tevékenység kiszolgálására alkalmas. Ily módon nem zavarja meg mondjuk egy fájl letöltése közben, vagy a háttérben hallgatott zene lejátszása esetén a felhasználót más tevékenységében. Ennek ellenére természetesen a Service behívhat Activity-ket a futása közben szükség esetén. A Service, hasonlóan az alkalmazás többi objektumához, alapesetben az őt kiszolgáló folyamat fő szálán fut. Ez teljesítményigényes feladatnál, vagy lassú, esetleg hozzáférhetetlen hálózati erőforrások esetében negatívan hathat a válaszkészségre. Maga az operációs rendszer is több Servicet igényel a normál működéséhez. Ezek megtekinthetők, vagy akár menedzselhetők is a Settings/Applications/Running services, illetve az új változatokban a Settings/Applications manager/running/show services in use menüpontok alatt ábra Futó folyamatok és szolgáltatások

16 Content provider 15 A Content provider egy adatforrás kezelését megvalósító tartalomszolgáltató komponens. A tartalmat jelentő adatforrás lehet egy file a filerendszerben, elhelyezkedhet egy SQLite adatbázisban, a weben, vagy bárhol, ahol az alkalmazás hozzáférhet. A tartalomszolgáltató engedélyével bármilyen más alkalmazás hozzáférhet ezekhez az adatokhoz, akár azok lekérdezése, akár azok megváltoztatása a cél. Természetesen a komponens alkalmazható akkor is, ha az alkalmazásunk saját, privát adataihoz szeretne hozzáférni, de nem szükséges saját content providert készítenünk, ha az alkalmazásunk nem oszt meg semmilyen adatot másokkal. Az Android rendszer tartalmaz beépített providereket, többek között képek, hanganyag, videók, vagy névjegyzék-adatok megosztása érdekében. Ezek kötöttségekkel ugyan, de bármilyen alkalmazásból felhasználhatók Broadcast receiver Eme komponens segítségével iratkozhatunk fel az operációs rendszer alacsony szintű eseményeire. Az Android számos eseményt jelez broadcast formájában, amelyekre az alkalmazásunk is jelentkezhet ennek segítsével. Ilyen broadcast esemény lehet a képernyő kikapcsolódása, az akkumulátor alacsony töltöttségi szintje, vagy egy bejövő GSM hívás. Amikor egy ilyen esemény bekövetkezik, az Android megvizsgálja, mely alkalmazásoknak van olyan broadcast receiver komponense, ami az adott eseményben érintett. Ha ilyeneket talál, elindítja őket. Innentől viszont már az alkalmazáskomponens fejlesztője határozhatja meg, hogy mi történik. Önmagában a komponens ugyan nem rendelkezik saját felhasználói felülettel, de természetesen elindíthat más komponenseket, vagy megjeleníthet úgynevezett notification-öket, amik a status bar részeként látszik. A kapott broadcastek alapvetően kétfélék lehetnek: Normál broadcast Rendszerezett (ordered) broadcast A normál broadcasteket a Context.sendBroadcast() metódus küldi, ezek aszinkron módon működnek. A receiverek rendezetlenül, gyakran egyszerre kapják meg őket. A rendszerezett broadcastek a Context.sendOrderedBroadcast() által érkeznek. Ilyenkor a receiverek egy megadott sorrendben kapják meg a broadcast-et, és adhatják tovább egymásnak annak eredményét, vagy akár fel is függeszthetik a továbbadást. A továbbadás sorrendjét a megfelelő intent filter

17 android:priority attribútuma határozhatja meg. Az azonos prioritással kezelt receiverek között önkényesen dől el a sorrend. Mivel az operációs rendszer alapesetben a különböző alkalmazásokat különböző folyamatokban indítja el, ezek nem hívhatják egymás komponenseit közvetlenül. A komponensek indítását általában (az Activity, a Service és a Broadcast receiver esetében) egy Intent kézbesítésével kezdeményezhetjük. A negyedik komponenstípus esetében nem Intent, hanem egy ContentResolver-től érkező kérés aktiválja a content providert Intent A platformon az alkalmazások komponensei közötti adatcsere eszköze, egy-egy esemény egzakt leírására szolgál. Különlegessége, hogy nemcsak egyazon alkalmazás komponensei, de különböző programok komponensei között is megvalósíthat kommunikációt. Sosem közvetlenül, hanem az operációs rendszeren keresztül történik a kézbesítése. Activity és Service komponensek esetében az Intent leír egy eseményt, mint például megnézni, vagy küldeni valamit. Ehhez meghatározhatja a kapcsolódó adatok elérését is (URI). Broadcast üzenetek esetében is Intent objektumok formájában jut el az üzenet az arra feliratkozott komponensekhez. Tehát nemcsak az elvárt, hanem a bekövetkezett események attribútumait is tartalmazhatja az eszköz. Bármilyen komponensből is adták fel, a megcélzott komponensek fajtája metódusfüggő, a következők szerint: startactivity(), vagy startactivityforresult() metódusok esetében egy Activityt tudunk indítani. startservice(), vagy bindservice() metódusok segítségével Service komponenst indíthatunk, vagy kapcsolódhatunk hozzá. Különféle Broadcastek kezdeményezhetők egy Intent átadásával a következő metódusok valamelyikének: o sendbroadcast() o sendorderedbroadcast() o sendstickybroadcast() Az Intentek alapvetően kétfélék lehetnek működési mechanizmusuk alapján: Explicit Intentek Implicit Intentek Az explicit Intent pontosan meghatározza a kívánt komponenst a setcomponent(), vagy a setclass() metódusok segítségével. 16

18 Implicit Intent esetében azonban nem nevezzük meg a kérés kiszolgálására legalkalmasabb komponenst, hanem az operációs rendszerre bízzuk a döntést, azaz ő dönti el, melyik fog futni ekkor. Ilyenkor egy Intent filter (szűrő) segítségével jelezheti egy komponens, hogy lehetősége van bizonyos adatokat fogadni, valamilyen eseményt vagy egy kérést kiszolgálni. Ezek a szűrők a manifest fájlban jelennek meg Manifest állomány A manifest állomány egy az alkalmazást leíró XML formátumú fájl, a projekt gyökérmappájában. Főbb feladatai: Elsődleges feladata, hogy tájékoztatja a rendszert az alkalmazás részeiről, leírja az alkalmazás komponenseit. Rögzíti a futtatáshoz szükséges követelményeket és jogosultságokat, mint amilyen például a névjegyzék olvasása, vagy az írás a memóriakártyára. Meghatározza az alkalmazás szükségleteit, úgymint a kijelző mérete és képpont-sűrűsége, stb. Meghatározza az alkalmazás futtatásához szükséges (nem az Android frameworkhöz tartozó) API könyvtárakat. Ilyen lehet a Google Maps könyvtárai. Egy egyszerű példa egy alkalmazás manifest állományára: <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android=" package="hu.nyf.file_teszt" android:versioncode="1" android:versionname="1.0" > <uses-permission android:name="android.permission.write_external_storage" /> <uses-sdk android:minsdkversion="8" android:targetsdkversion="17" /> <application android:allowbackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/apptheme" > 17

19 <activity android:name="hu.nyf.file_teszt.mainactivity" > <intent-filter> <action android:name="android.intent.action.main" /> 18 <category android:name="android.intent.category.launcher" /> </intent-filter> </activity> </application> </manifest> A manifest elemen belül található a csomag neve és verziója. Minden alkalmazás egyedi csomagnevet igényel, ezért javasolt ehhez a saját fordított DNS tartományunk nevét használni. Ilyen például a hu.nyf.file_teszt. Az opcionális uses-permission elem a szükséges jogosultságot tartalmazza, ebben az esetben írási jogot külső tárolóra, memóriakártyára. A uses-sdk szakasz tartalmazza az alkalmazás kompatibilitására vonatkozó leírásokat. A minsdkversion a futtatáshoz szükséges abszolút minimális API verziószámát jelenti. Ha elhagyjuk, akkor feltételezett, hogy valamennyi Androiddal kompatibilis a program! A targetsdkversion az ajánlott API verziót jelöli, ahol az alkalmazás valamennyi funkciója hiba nélkül elérhető, amire a fejlesztő szánta az alkalmazást. Az application szakasz határozza meg az alkalmazás komponenseit és azok tulajdonságait. Az allowbackup tulajdonság megadja, hogy az alkalmazás el lesz-e mentve a rendszer mentésekor, vagy nem. Alapértelmezett az igen válasz. Az icon, label és theme tulajdonságok az alkalmazás indításához használt ikont, nevet, és megjelenési sémát határozzák meg. Az alkalmazáshoz tartozó komponensek következnek az application elemen belül. Ezek a komponens típusától függően értelemszerűen a következők lehetnek: <activity> <service> <provider> <receiver>

20 Az egyes komponensek name attribútuma adja a megvalósított komponens osztályának a nevét, a label elemben található a komponens látható neve. Az adott komponensen belüli intent-filter definiálja a korábban már említett szűrőket, például azt, hogy milyen események hatására éledjen a komponens. Ebben az esetben az intent-filter action tagja jelzi, hogy az Activity az alkalmazás belépési pontja. A category tagja a szűrőnek pedig azt jelzi, hogy ezen komponens által az alkalmazás indítható, az jelenjen meg ikonjával és címkéjével az alkalmazások listájában Erőforrások Az Android alkalmazások természetesen nemcsak program kódot tartalmaznak. Az egyes alkalmazások által használt erőforrások jól különválnak az őket kezelő forráskódoktól, ily módon az üzleti logikát megvalósító kód és a felhasználói felület jól körülírt és egymástól elválasztott maradhat. Erőforrás lehetnek típusuk alapján: Képek Hanganyagok Animációk Menük Stílusok Színek Szöveges tartalmak A felhasználói felületet leíró layout xml állományok Az erőforrások segítségével a kód változtatása nélkül készülhetünk fel az alkalmazásunk különböző környezetben való futtatására, legyen az akár más nyelvi környezet, vagy eltérő méretű kijelző. Valamennyi erőforrás hivatkozhatóvá válik forráskódból az SDK által (aapt program) kezelt R.java nevű állományon keresztül. Mivel ezt a fejlesztőkörnyezet kezeli, ezért ne módosítsuk kézzel a tartalmát! Egy példa az erőforrások leírására az aapt segítségével: package com.example.file_teszt; public final class R { public static final class attr { } public static final class drawable { public static final int ic_launcher=0x7f020000; } public static final class id { 19

21 } public static final int menu_settings=0x7f070005; public static final int okbutton=0x7f070002; public static final int text1=0x7f070000; } public static final class layout { public static final int activity_main=0x7f030000; } public static final class menu { public static final int activity_main=0x7f060000; } public static final class string { public static final int app_name=0x7f040000; public static final int menu_settings=0x7f040002; public static final int okbutton=0x7f040003; public static final int text1=0x7f040004; } public static final class style { public static final int AppBaseTheme=0x7f050000; public static final int AppTheme=0x7f050001; } 20 Mint látható, gyakorlatilag statikus int típusú változókkal leírható valamennyi erőforráselem. Legyen az a layoutra vagy az egyes UI elemekre vonatkozó azonosító, esetleg az elemek által használt felirat, forrásszöveg. A fájl frissítése az erőforrások mentésekor történik. Hivatkozni a forráskódból az elemekre standard módon lehet. Az okbuttonra, mint gombra például az R.id.okButton úton lehetséges. A forráskódban létrehozott, és rá hivatkozó objektum tehát: Button okbutton = (Button) findviewbyid(r.id.okbutton); Maguk a tényleges erőforráselemek a projekt gyökérmappájában, a res mappában helyezkednek el, típusuk alapján külön mappákba helyezve, mint például a következők: drawable mappák: a képek, bitmap-ek, ikonok számára layout: a felhasználói felületek, activityk leírására menu: menük leírására values: témák, szöveges erőforrások tárolására animator: animációk leírására color: színek megadásához A mappák elnevezése egy, vagy több qualifier (minősítő) segítségével módosítható. Ez azért bír jelentőséggel, mert ezek segítségével

22 biztosítható, hogy bármely erőforrásra különböző változatokat írhassunk elő a felhasználó eszközén lévő Android eszköz nyelve, képernyőmérete, orientációja, vagy API verziója alapján. Például a values-hu mappa segítségével a magyar nyelvű lokalizáció esetén külön, magyar nyelven is megadhatjuk a program által használt feliratokat. Egyéb eszközök az alapértelmezett mappát (values) fogják használni. A minősítők használatának szabályai: Kötőjellel választjuk el őket az eredeti névtől, vagy egymástól, ha több is van. Például: values-hu-v11 jelentése magyar lokalizációjú, API 11-es verziójú eszközök számára használható values mappa. A különböző típusú minősítők csak előre meghatározott, kötött sorrendben használhatók. Nem használható az előző példa values-v11-hu sorrendben. A minősítők teljes leírása, és alkalmazásuk sorrendje a következő táblázatban található: -resources.html#table2 A minősítővel ellátott mappát ne ágyazzuk az eredetibe be! Tehát ne használjuk a values/values-hu mappaszerkezetet! Noha a használható értékek nem érzékenyek a kis-nagybetű eltérésekre, az ilyen eltérést figyelembe vevő fájlrendszerekkel való kompatibilitás érdekében a fordító kisbetűs változatra fordítja az elnevezéseket. Minden minősítőfajtából egyszerre csak egy érték használható az erőforrásmappa elnevezésében. Ne használjunk pl. valuesen-hu elnevezést! Ha nem szeretnénk az azonos tartalmak miatt erőforrásokat duplikálni, használjunk aliast a mappák esetében! Az Activity életciklusa, környezete 4.1. Activity Az Activity (tevékenység) az alkalmazásnak egy olyan fontos része, amivel a program felhasználója interakcióba léphet: így például megnézhet egy térképet, megtekintheti a levelezését, vagy tárcsázhat egy telefonszámot. Minden Activity egy ablakot biztosít a számunkra, amely meg tudja jeleníteni az ehhez szükséges felhasználói interfészt. Az ablak általában kitölti a képernyőt, de lehetőség van kisebb ablak létrehozására is, vagy ráúszhat más ablakok tetejére. Egy alkalmazás általában több Activityből áll, amelyek kapcsolódhatnak egymáshoz, vagy akár más alkalmazáshoz is. Van tehát lehetőség arra, hogy például egy fényképet készítő program a kép megosztása érdekében meghívjon egy levelezőklienst. Ehhez természetesen a levelezőkliens alkalmazás engedélyére van szükség.

23 Így tehát a fénykép alkotója megoszthatja másokkal is alkotását, például levél mellékleteként is. Jellemzően az alkalmazás egy ilyen tevékenysége ki van jelölve, mint Main Activity (elsődleges tevékenység). Ez fog megjelenni először a felhasználó számára az alkalmazás első futtatása alkalmával. Minden Activity elindíthat más Activityket valamilyen tevékenység előidézése érdekében. Valahányszor egy Activity elindul, az előző Activity leáll, de a rendszer megőrzi ennek az előző tevékenységnek az állapotát a háttér veremben (back stack). Az új Activity indulásakor bekerül a stack tetejére, majd a rendszer elkezdi futtatni. A verem LIFO elvű működéséből következik, hogy amikor a felhasználó megnyomja a Back (Vissza) gombot, akkor az ezt megelőző tevékenység kerül elő a veremből és annak futása folytatódik. Az Activity megvalósítása az Activity osztály egy alosztályaként deklarálva lehetséges. Amikor egy tevékenység egy másik tevékenység indulása miatt leállításra kerül, értesítést kap erről úgynevezett callback metódusok segítségével. Számos callback metódust kaphat egy tevékenység az állapotváltozás jellegétől függően: kaphat ilyet az operációs rendszertől létrehozásakor, leállításakor, folytatása, vagy törlése esetén. Minden ilyen esetben lehetőség van arra, hogy az esedékes állapotváltozásra egy megfelelő eseménnyel reagáljon a tevékenység (Activity). Az Activity leállításakor például felszabadíthat olyan nagyméretű objektumokat, mint amilyen egy adatbázis-, vagy egy hálózati kapcsolat kezeléséhez szükséges. A tevékenység folytatásakor a félbeszakított tevékenységek folytathatók, a szükséges erőforrások újra lefoglalhatók. Ezek az állapotváltások részei a tevékenység életciklusának Az Activity életciklusa 22 Az Activity alapvetően négy állapot valamelyikében lehet. Ezek a következők: 1. Running Ha az Activity az előtérben fut (a stack tetején helyezkedik el), ez az aktív, vagy futó állapot (running). Ilyenkor az Activity fókuszban van. 2. Paused Ha az Activity elvesztette a fókuszt, de még látható, akár részben is (mert például egy új, nem teljes képernyőt lefoglaló Activity jelent meg fölötte), akkor az Activity szünetel, az állapota paused. Egy ilyen szüneteltetett tevékenység teljes mértékben élő maradhat, abban az értelemben, hogy az összes állapot- és taginformációját megőrizheti és csatlakoztatva marad az ablakkezelőhöz. Ám ha az operációs rendszer extrém

24 alacsony memóriaállapotot érzékel (ennek értéke beállításfüggő), akkor törölheti az Activityt. 3. Stopped Ha az Activityt egy másik tevékenység teljes egészében letakarja, akkor leállítódik (stopped). Minden állapot- és taginformációja megőrződik ugyan, de nem lesz látható a felhasználó számára az ablaka és gyakran törlésre kerülhet az operációs rendszer által, ha az általa lefoglalt memóriaterületre más Activitynek szüksége lehet. 4. Finished, vagy killed Szünetelő, vagy leállított állapotú Activity esetén tehát az operációs rendszer bármikor kérheti az Activity befejezését (finished), vagy egyszerűen kitörölheti azt (killed). Az Activity újbóli megnyitásához ilyenkor újra teljes egészében létre kell hozni azt. A következő ábra az Activity legfontosabb állapotváltozásainak menetét mutatja. A téglalapok jelképezik a callback hívásokat az állapotváltozások között. Ezekben megvalósíthatjuk a tevékenységhez tartozó utasításokat, az egyes állapotváltozások alkalmával. A színes ellipszisekben pedig a főbb állapotok láthatók. 23

25 24 Elindított Activity A felhasználó kiválasztja az Activity-t Folyamat törölve Futó Activity Magasabb prioritású alkalmazások memóriát igényelnek Másik Activity kerül előtérbe A felhasználó visszatér az Activityhez Az Activity már nem látható A felhasználó kiválasztja az Activity-t Az Activity leáll, vagy a rendszer kezdeményezte a leállítását Activity leállítva 6. ábra Az Activity életciklusa 14 Az Activity élettartamai (lifetime) közül a következő hármat érdemes megkülönböztetni egymástól: 1. Teljes élettartam (entire lifetime) Az Activity azon életciklusa, amely az oncreate() metódus első hívása és az ondestroy() utolsó hívása között zajlik. Egy Activitynek minden globális beállítást el kell végezni az oncreate() híváskor és minden esetleg megmaradt erőforrást el kell engedjen az ondestroy() esetében. Ha például egy 14 Activity LifeCycle -

26 Activity a háttérben egy szálat futtatva adatokat tölt le a hálózatról, az oncreate()-et használhatja a szál létrehozásához és az ondestroy() metódust a szál leállításához. 2. Látható élettartam (visible lifetime) Az Activity látható életciklusa az onstart() és az onstop() metódusok meghívása között zajlik. Ilyenkor a felhasználó láthatja az Activityt és kapcsolatba léphet vele. Az operációs rendszer többször is meghívhatja ezeket a metódusokat az Activity teljes élettartama során, hiszen az Activity láthatósága változhat, ahogy változnak a tevékenységek. 3. Előtérben töltött élettartam (foreground lifetime) Az Activity ezen életciklusa az onresume() és onpause() metódusok hívása között telik el. Ebben az esetben az Activity nemcsak látható, de előtérben van, birtokolja a fókuszt is. Egy tevékenység gyakran váltogathat a paused és a resumed állapot között, ha például az eszköz sleep módba kerül, ha új Intent kézbesítése történik. Mivel ilyen váltás gyakran előfordulhat, ezért ajánlott, hogy az ehhez tartozó kód kicsi, gyorsan lefutó legyen, elkerülendő a felhasználói élmény csorbulását. Az Activity életciklusaihoz tartozó mozgásokat a következő táblázat szemlélteti: 25 Metódus Leírás Törölhető? oncreate() Az Activity létrehozásakor nem hívódik. Ekkor kell az összes statikus beállítást elvégezni nézetek létrehozása, adatok kötése listákhoz, stb. A metódus egy Bundle objektumot kap, ami tartalmazza az Activity korábbi állapotát, ha volt ilyen. onrestart() A leállított Activity újra elindítása nem előtt közvetlenül hí- vódik meg. Mindig az onstart() metódus követi. Következő metódus onstart() onstart()

27 onstart() Az Activity felhasználója előtt láthatóvá válása előtt kerül meghívásra. Ha az Activity előtérbe kerül, az onresume() követi, ha rejtetté válik, akkor az onstop() hívódik meg. onresume() Akkor hívódik meg, amikor egy tevékenység interaktívvá válik a felhasználó számára. Ekkor az Activity a stack tetején van, készen áll a felhasználói interakcióra. Mindig az onpause() metódus követi őt. onpause() Akkor hívódik, amikor az operációs rendszer egy másik Activityt készül folytatni, vagy újraindítani. Általában a mentetlen adatok rögzítésekor, animációk leállításakor, és más processzor igényes tevékenységekhez köthető. A megvalósításnak nagyon gyorsnak kell lennie, mivel a következő Activity nem folytatódik addig, amíg ez be nem fejeződik. Vagy az onstop() onresume() metódus követi, ha az Activity az előtérbe tér vissza, vagy az onstop(), ha láthatatlanná válik a felhasználó számára. Akkor hívódik meg, amikor az Activity nem látható már a felhasználó számára. Ez fakadhat abból, hogy az Activity megszűnt, de abból is, hogy egy másik új, vagy már létező Activity (újra)indítódott és eltakarja emezt a képernyőn. Az onrestart() metódus követi, ha a tevékenység a felhasználó nem igen 3.0 verzió előtt igen onresume() onpause() 26 onresume(), vagy onstop() onrestart(), vagy ondestroy()

28 számára interaktív állapotba kerül vissza, vagy az ondestroy(), ha az Activity végleg meg fog szűnni. ondestroy() Az utolsó metódus az Activity megszűnése előtt. Bekövetkezhet a finish() metódus hívása okán (be akarjuk fejezni az Activityt), vagy azért, mert az operációs rendszer hely megtakarítása végett ideiglenesen megszünteti. Az isfinishing() metódussal lehet különbséget tenni a kettő között (true, vagy false). igen nincs ilyen 27 A Törölhető? oszlop jelzi, hogy az operációs rendszer törölheti-e bármikor az Activityt kiszolgáló folyamatot az adott callback metódus lefutása után egyetlen további sor futtatása nélkül. Az onpause(), az onstop() és az ondestroy() metódusok ilyenek s, Honeycomb rendszerek előtt kritikusan helyzetben előfordulhatott, hogy az onstop() és az ondestroy() metódusok meg sem hívódtak, ha a rendszernek memóriát kellett felszabadítania. Ekkor csak az onpause() metódusra lehetett számítani, amely garantáltan meghívásra kerül az Activity megszüntetése előtt. Ebben kellett tehát elhelyezni az érzékeny felhasználói adatok mentésére szolgáló kódot. A Honeycomb verziótól kezdődően azonban az alkalmazás nem kerül megszüntethető állapotba addig, amíg az onstop() metódus le nem fut. Így biztonságosan alkalmazható ez a megoldás is a fontos adatok mentésére.

29 28 5. Felhasználói felületek 5.1. Az alapok A felhasználó felületek kialakítása az egyik legfontosabb lépés az Android alkalmazásunk fejlesztése során. A vonzó, jól áttekinthető és jól kialakított felület teszi alkalmazásunkat a felhasználó számára igazán felhasználó baráttá. Egy kiváló ötletet megvalósító alkalmazás is kieshet a felhasználók kegyeiből, ha a rosszul megtervezett felhasználói felületek miatt nehézkes a kezelése, vagy nem áttekinthető a felülete. Arról nem is beszélve, hogy a felhasználók a Google Play-en is először csak a felhasználói felülettel találkoznak, ez alapján döntik el, hogy letöltik-e az alkalmazást vagy nem. Jelenleg a világban számos gyártó készít olyan termékeket, melyeken az Android operációs rendszer fut. Ezek a termékek sok mindenben eltérnek egymástól, például nem egységesek a képernyőméreteik, más és más a képernyő felbontásuk, különböző méretű memóriával és háttértárral rendelkeznek, de sokszor még az érintőképernyőjük is eltérő. Ehhez a sokszínű hardveres palettához alkalmazkodva kell nekünk úgy elkészíteni Android alkalmazásunkat, hogy a sok eltérő képernyőméret és felbontás ellenére mindegyik eszközön ugyanúgy jelenjen meg alkalmazásunk. Ez első olvasásra szinte lehetetlennek tűnik, de szerencsére nem így van. Az Android az 1.6-os verziótól támogatást nyújt az eltérő képernyőméret és felbontás kezelésére, ami azt jelenti, hogy nekünk elegendő elkészítenünk a megfelelő felületeket és grafikákat a megfelelő méretekben, és a rendszer a felületi elemeket az adott eszköz kijelző tulajdonságai szerint képes skálázni. Mint azt korábban már említettük, a felhasználói felületet mind forrásprogramból, mind XML erőforrás állományból is fel lehet építeni. Azonban, hogy maradéktalanul kihasználhassuk az Android által nyújtott felület kezelői mechanizmust, ahhoz célszerű az utóbbit eszközzel élni. A felhasználói felületek elkészítéséhez szükséges pár alapvető fogalom, melyeket tekintsünk is át röviden: 15 Képernyő méret A tényleges fizikai mérete képátlóban megadva. Az Android négy csoportba sorolja e szerint a képernyő méreteket: small, normal, large, extra large Képernyősűrűség Egy fizikai területen található pixelek sűrűsége, amit általában dot per inch-ben (dpi) szoktak 15 Android - Supporting Multiple Screens -

30 megadni. Az android ngy csoportba sorolja e szerint a képernyősűrűséget: low, medium, high, extra high Orientáció Ez lehet álló (portrait), vagy fekvő (landscape). Az orientáció előírható fixen, vagy futási időben megváltoztatható. Felbontás Az összes pixel száma a fizikai képernyőn. Az alkalmazások nem dolgoznak ezzel az értékkel, hanem helyette a képernyő méret és a képernyősűrűség értékeivel számolnak. Sűrűségfüggetlen pixel (dp) Ez egy virtuális pixel egység, amit a felület tervezésekor használunk. Egy 160dpi-s képernyőn egy fizikai pixellel egyezik meg. A rendszer futási időben gondoskodik a dp egységek mértezéséről az aktuális képsűrűség függvényében. Az átváltás a dp egység és a pixel között a következő képlettel írható le: px=dp*(dpi/160). Például egy 200 dpi-s képernyőn a képlet alapján azt kapjuk, hogy 1 dp 1,25 fizikai pixelnek felel meg. A 7. ábra jól szemlélteti, hogy az Android hogyan kategorizálja a különböző képernyőméreteket és a képernyősűrűségeket csoportokba ábra képernyőméretek és sűrűségek csoportjai 16 Minden általánosított mérethez tartozik egy minimum méret, amit érdemes figyelembe venni a felhasználó felületek készítésénél. Ezeket a minimum érétkeket dp mértékegységben adják meg, és a következőek: xlarge : 960dp x 720dp large: 640dp x 480dp normal: 470dp x 320dp small: 426dp 320dp Az Android két módon is segít számunkra, hogy minden eszközön a megfelelő méretben jeleníthesse meg a felhasználói felület elemeit. Egyfelől a rendszer az aktuális képernyősűrűségnek megfelelően a dp kiszámítása alapján skálázza a felhasználói felületet, másrészt a 16 Android - Supporting Multiple Screens -

31 képernyősűrűség felhasználásával automatikusan átméretezi a képerőforrásokat. A grafikus erőforrásokkal kapcsolatosan azonban meg kell jegyeznünk, hogy nem célszerű a rendszerre hagyatkozni ezek átméretezésénél. Ehelyett inkább célszerű elkészíteni a különböző méretű képernyőfelületekhez a különböző méretű grafikus erőforrásokat. A négyfajta képernyőmérethez igazodva célszerű a grafikus elemeket is négyfajta méretben elkészíteni, melyek méretei 3:4:6:8 arányban viszonyulnak egymáshoz. Az Androidban minden erőforrást a res alkönyvtárban kell elhelyezni, míg a képeket ezen belül a drawable alkönyvtárba helyezhetjük el. Az alkönyvtárak neveit minősítőkkel láthatjuk el, amelyek megszabják, hogy az adott alkönyvtárban lévő erőforrások milyen rendszertulajdonság esetén használjuk fel. A minősítőket általánosan a következőképpen adhatjuk meg: <erőforrás_azonosító> - <módosító> 30 Például ha small képernyőmérethez szeretnénk képerőforrásokat megadni, akkor azokat a drawable-small alkönyvtárban kell elhelyeznünk. Egy erőforrás azonosítóhoz akár több módosító is kapcsolható, például drawable-large-mdpi. A legfontosabb képernyő konfigurációkhoz kapcsolódó minősítők a következők: Képernyőméret: small, normal, large, xlarge Sűrűség: ldpi, mdpi, hdpi, xhdpi, nodpi (sűrűség független), tvdpi (megközelítőleg 213dpi) Orientáció: land, port Képarány: long, notlong Amikor futtatunk egy alkalmazást, akkor az Android először az eszköz paramétereinek megfelelő módosítókkal ellátott erőforrásokat próbálja használni. Ha nem talál ilyet, akkor az alapértelmezett erőforrást használja, és az adott képernyő mérethez és sűrűséghez igazodva nagyítja, vagy kicsinyíti az adott elemet. A legjobb megjelenés elérése érdekében azonban a rendszer néha eltér ettől a szabálytól és az alapértelmezett erőforrás helyett egy másik felbontás specifikus erőforrást használ. Például az Android ha nem talál kis felbontású elemet, de az alapértelmezett elemnél nagyobb felbontású elem létezik az alkalmazásban, akkor a rendszer előnyben fogja részesíteni a nagy felbontású képet, mert annak kicsinyítése sokkal szebb megjelenést tesz majd lehetővé. A képernyőmérettel kapcsolatosan megadhatunk pár előírást a manifest állományban. Ha az eszközünk nem felel meg ezeknek az előírásoknak, akkor az alkalmazás vagy kompatibilis módban kezd el

32 futni, vagy legrosszabb esetben fel sem települ az adott eszközre. Ilyen előírások lehetnek a következők: android:requiressmallestwidthdp Az alkalmazás futtatásához szükséges legkisebb szélességet írja elő. android:compatiblewidthlimitdp Ha az itt megadott értéknél nagyobb a képernyő szélessége, akkor a rendszer felajánlja, hogy az alkalmazás kompatibilis megjelenési módban fusson. Ez a kompatibilitási mód kikapcsolható a rendszer menüből bármikor. android:largestwidthlimitdp AZ előzővel egyezik meg, azaz az alkalmazás itt is kompatibilis módban fog futni, azonban ebben az esetben ez a mód nem kapcoslható ki. A manifest állományban ez a következőképpen néz ki: 31 <manifest... > <supports-screens android:requiressmallestwidthdp="400" />... </manifest> Alkalmazásunk felhasználói felületének tervezésekor a legfőbb cél, hogy minden képernyőméret és sűrűség beállítás mellett ugyanolyan jól használható és szép megjelenésű felületet biztosítsunk a felhasználók számára. Ennek megvalósítása érdekében lehetőleg kerüljük a pixel (px) mértékegység használatát, használjunk helyette inkább density-independent pixelt (dp), a wrap_content, fill_parent jellemzőkkel. Szövegek esetében a scale-independent pixel (sp) mértékegység használata a javasolt. Kerüljük az AbsoluteLayout használatát, mert ennek fix pozíció megadásai különböző képernyőméretek estén hibás megjelenést okozhatnak. Végül, de nem utolsó sorban használjunk képernyőméret és sűrűség specifikus erőforrásokat. A rendszer ugyan képes az erőforrások átméretezésére az aktuális eszköz igényeinek megfelelően, azonban a helyes megjelenés érdekében mégis inkább célszerű elkészíteni a különböző képernyőméreteknek megfelelő erőforrásokat. A felhasználói felületek kialakításában nagy segítségünkre lehet az Eclipse-ben található felülettervező rész 17, mely segítségével gyorsan könnyen elvégezhetjük a felületünk alap kialakítását. Ezt követheti a finomhangolás, amikor is az egyes elemek tulajdonságait állítjuk be pontosan. Ezt megtehetjük az Eclipse Properties ablakában, illetve magában az XML kódban is. 17 Más felület tervező programokat is használhatunk, melyek képesek az elkészített felületek XML kódját legenerálni. Ilyen például a DroidDraw alkalmazás -

33 32 8. ábra Az Eclipse felülettervező modulja Az elkészített felhasználói felületeket minden esetben célszerű tesztelni a támogatott képernyőméreteken. Ehhez nagy segítséget nyújt az Android fejlesztői környezete az által, hogy az emulátora képes különböző képernyőméretű és sűrűségű eszközök emulálására. Ezek segítségével valós eszközök nélkül is tesztelhetjük a különböző méretekhez igazított felhasználói felületünket Layoutok használata A layoutok definiálják a felhasználói felület struktúráját. A felhasználói felület elemeit megadhatjuk XML erőforrás állományban, valamint a program forráskódjában is. Javasolt az erőforrás állományok használata, hiszen így a felhasználói felület elkülönül a program szövegétől, aminek nagy előnye, hogy a program forráskódjának megváltoztatása nélkül hajthatók végre módosítások a felületen. Minden layout erőforrás állomány tartalmaz egy gyökér elemet, amely egy View, vagy ViewGroup osztálybeli elem. A View osztály tartalmazza a felhasználói felület alap építőelemeit. A View osztály elemei egy négyszögletes felületet foglalnak el a képernyőn, és felelősek ezen felület rajzolásáért, illetve a rajta bekövetkező események kezeléséért. A ViewGroup osztály a View osztály leszármazottja, és legfőbb tulajdonsága, hogy tartalmazhat további View osztály beli elemeket, akár további ViewGroup elemeket is. A ViewGroup felelős a közvetlen gyermek elemeinek kirajzolásáért, és elrendezéséért. Ezek lehetővé teszik, hogy a felhasználói felület elemeivel komplex hierarchikus struktúrát alakíthassunk ki, amely egy fa struktúrában reprezentálható a legjobban.

34 Amikor egy Activity-re kerül a végrehajtás, akkor a rendszer az Activity-hez tartozó felhasználói felület gyökér elemét utasítja, hogy végezze el a megjelenéshez szükséges méretezést és rajzolást. A gyökérelem rekurzívan utasítja saját gyermek elemeit ugyanezen tevékenységek végrehajtására, amely eredménye képen fog megjelenni a kívánt felület. Az egyik leggyakrabban használt layout a LinearLayout 18. Ebben a nézetben az elemek más néven View elemek - horizontálisan, vagy vertikálisan kerülnek egymás után elhelyezésre, attól függően, hogy az android:orientation tulajdonság horizontal, vagy vertical értéket vesz föl. Az adott nézeten beleül az elemeket az android:gravity 19 tulajdonsággal tudjuk igazítani. Megemlíthetjük itt még az android:layout_weight tulajdonságot, amivel egy fontossági értéket adhatunk meg az egyes elemeknek. Ennek hatására a nagyobb súllyal rendelkező elem fogja kitölteni a szülő elem maradék részeit. Például, ha van két szöveges mezőnk, és a másodiknak nagyobb a layout_weight értéke, mint az elsőnek, akkor míg az első csak olyan hosszú lesz, mint az abban található szöveg, addig a második teljesen ki fogja tölteni a szülő elem fennmaradó helyét is, túlnyúlva a benne található tartalom hosszán. A layout_weight tulajdonság alapértelmezett értéke <LinearLayout xmlns:android=" xmlns:tools=" android:id="@+id/linearlayout1" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:paddingbottom="@dimen/activity_vertical_margin" android:paddingleft="@dimen/activity_horizontal_margin" android:paddingright="@dimen/activity_horizontal_margin" android:paddingtop="@dimen/activity_vertical_margin" tools:context=".segedactivity" > <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center" android:text="@string/liner_layout_szoveg" android:textsize="22sp" /> 18 Android LinearLayout Android androd:gravity - gravity

35 34 <EditText android:layout_width="match_parent" android:layout_height="wrap_content" android:ems="10" > <requestfocus /> </EditText> <LinearLayout android:layout_width="match_parent" android:layout_height="wrap_content" android:gravity="center_horizontal" > <CheckBox android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_marginright="20dp" /> <CheckBox android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_marginleft="20dp" /> </LinearLayout> <LinearLayout android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_gravity="right" android:gravity="right" > <Button android:layout_width="100dp" android:layout_height="wrap_content" android:layout_gravity="left" android:layout_marginright="20dp" /> <Button android:layout_width="100dp" android:layout_height="wrap_content" android:layout_gravity="right" android:gravity="center_vertical center_horizontal" /> </LinearLayout> </LinearLayout>

36 35 9. ábra LienearLayout példa megjelenése Másik gyakran használt nézet a RelativeLayout 20. Ebben a nézetben az elemeket elhelyezkedését az egymáshoz viszonyított helyzetükkel lehet meghatározni. Helyes használatával ki lehet küszöbölni az összetett nézetek készítését, ami által egyszerűsödik a layout, és nő a teljesítmény. Például, ha azt szeretnénk, hogy egy elem egy másik alatt jelenjen meg, akkor használjuk a android:layout_below tulajdonságot, amely értékéül annak az elemnek az azonosítóját kell megadni, amelyik alá szeretnének az új elemünket elhelyezni. Ebben a nézetben tehát azoknak az elemeknek, amihez viszonyítani szeretnénk más elemeket, azoknak azonosítót kell adnunk. Több, mint 20 különböző RelativeLayout paraméter áll rendelkezésünkre az elemek relatív elhelyezkedésének megadására 21. <?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android=" android:layout_width="match_parent" 20 Android RelativeLayout Android RelativeLayout.LayoutParams - ml

37 android:layout_height="match_parent" > <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentleft="false" android:layout_alignparenttop="false" android:layout_centerhorizontal="true" android:layout_marginbottom="2dp" android:layout_margintop="2dp" android:textsize="22sp" /> <EditText android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_marginleft="5dp" android:layout_marginright="5dp" android:ems="10" > <requestfocus /> </EditText> <CheckBox android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_marginright="22dp" /> <CheckBox android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_marginright="20dp" /> <Button android:layout_width="100dp" android:layout_height="wrap_content" android:gravity="center_vertical center_horizontal" /> <Button 36

38 android:layout_width="100dp" android:layout_height="wrap_content" /> </RelativeLayout> ábra Ugyanaz a felület RelativeLayottal Az Android a fent említetteken kívül még több mint húsz elrendezést foglal magában, melyek bemutatására itt most nem térünk ki részletesen, csak felsoroljuk ezek közül a leggyakrabban használtakat: AbsoluteLayout: az elemeket abszolút pozíciójuk alapján helyezhetjük el benne, GridView: két dimenziós gördíthető elrendezést ad, ListView: listanézetben jelennek meg az elemek, MapView: térképnézeteket helyezhetünk el vele, TableLayout: táblázatos elrendezést biztosít, WebView: weboldalak megjelenítésére alkalmas.

39 5.3. Interaktív vezérlő elemek és eseménykezelésük 38 Az Android számos olyan grafikus vezérlő elemet tartalmaz, amely segítségével interaktívvá tehetjük az alkalmazásunkat. A vezérlő elemek ősosztálya a View osztály. A leggyakrabban használt elemek a következőek 22 : Button (Button osztály) A grafikus felhasználói felületeken már megszokott tulajdonsággal rendelkező nyomógomb. Checkbox (CheckBox osztály) Kijelölő négyzet, melynek állása lehet be, illetve kikapcsolt. Pickers (DatePicker és TimePicker osztályok) Segítségével a felhasználó valós dátumot és időpontot tud beállítani le-föl gombok segítségével, a beállított nyelvi környezetnek megfelelően. Radio button (RadioButton és RadioGroup osztályok) A kijelölő négyzethez hasonlít, azonban itt az egy csoportba tartozó választási lehetőségek közül csak egy jelölhető ki. Spinner (Spinner osztály) A felhasználó egy legördülő lista elemeiből választhat ki egyet ezáltal. Textfield (EditText osztály) Szerkeszthető szöveges beviteli mező. Az AutoCompleteTextView osztály segítségével olyan beviteli mező készíthető, mely a begépelt betűk alapján egy listát ajánl fel a lehetséges értékekről. Toggle button (ToggleButton és Switch osztály) Egy ki- és bekapcsolható gomb, mely a bekapcsolt állapotát az On feliraton kívül egy kis fénycsíkkal is jelzi. Az Android 4.0 verziótól rendelkezésünkre áll egy másik csúsztatható fajtája is. 11. ábra Vezérlő elemek 22 Android Input controls -

40 Tekintsük át az elemek pár alaptulajdonságát: Android alapú szoftverfejlesztés kezdőknek android:layout_height és android:layout_width mindkettő a ViewGroup osztály tulajdonságai, és az adott elem magasságát és szélességét állíthatjuk be velük. Értéke lehet valamilyen konkrét érték, vagy a követező konstansok egyike: o o o fill_parent Az elem olyan nagy lesz, mint a szülő eleme. Ezt váltotta fel a 8-as API feletti verziókban a match_parent. match_parent Lásd az előző wrap_content Csak olyan nagy lesz az elem, hogy elférjen benne a tartalma. android:textsize A szöveg mérete állítható be vele, amit célszerű "sp", azaz scaled-pixels mértékegységben megadni. android:textstyle A szöveg stílusa adható meg vele, amely lehet normal, bold vagy italic. Ha egyszerre szeretnék félkövér és dőlt betűt, akkor a két konstanst a (bitenkénti vagy) művelettel kell összekötni. android:autolink Meghatározhatjuk, hogy a szövegünkben előforduló url címek, vagy címek automatikusan átkonvertálódjanak-e klikkelhető linkké. Konstansai lehetnek a következők: none 0x00 Match no patterns (default). o o o o web webcímeket illeszt. - címeket illeszt. phone telefonszámokat illeszt. map térkép címeket illeszt. o all mindent illeszt. Megegyezik a web phone map megadással. Természetesen ezeken kívül még rengeteg tulajdonság létezik, amelyek elemenként eltérőek lehetnek, és amelyeket itt nincs lehetőségünk felsorolni. Mint ahogy a fenti példánkban is látható volt, sok helyen konkrét értékeket adtunk meg egy-egy tulajdonságnak. Ezek mindegyikét valamilyen mértékegységben lehet megadni az Android számára. A következő mértékegységeket használhatjuk az XML erőforrás állományainkban: dp (Density-independent Pixels) a már korábban is bemutatott sűrűség független pixel. sp (Scale-independent Pixels) Hasonló elven működik, mint a dp, csak ezt a betűk méretének megadására használhatjuk. pt A szövegszerkesztő programokból már jól ismert nyomdászati pont, ami a méter 2660-ad része (1/72 inch). 39

41 px Pixel. mm Milliméter. in Hüvelyk. Android alapú szoftverfejlesztés kezdőknek Az utolsó négy mértékegység használata kevésbé ajánlott, mivel ezek az aktuális képernyő fizikai tulajdonságaitól függnek, és ezért nem garantálják a megfelelő megjelenést a különböző méretű és tulajdonságú kijelzőkön. Alkalmazásainkban gyakran előfordul, hogy valamilyen információt kell megjelenítenünk felugró ablakban, vagy további adatokat bekérnünk a felhasználótól. Erre az Android többféle megoldást is biztosít a számunkra. Megjeleníthetünk egy teljes Activityt felugró ablakban, definiálhatunk felugró ablakokat (PopUpWindows osztály), dialógus ablakokat készíthetünk (Dialog osztály), vagy használhatjuk a Toast elemeket (Toast osztály). Nézzünk ez utóbbira egy egyszerű példát. 40 Button okgomb = (Button) this.findviewbyid(r.id.tl_gomb_ok); //az ok gomb lenyomásának eseménykezelése okgomb.setonclicklistener(new View.OnClickListener() public void onclick(view v) { Context con=getapplicationcontext(); Toast uzenet = Toast.makeText(con, R.string.rendben, Toast.LENGTH_LONG); uzenet.show(); } }); 12. ábra Példa Toast elem megjelenésére

42 41 A vezérlő elemek fő tulajdonsága, hogy segítségével a felhasználók interaktívan befolyásolhatják az alkalmazás működését. A UI felületen lévő elemeken a felhasználó eseményeket tud generálni, melyek bekövetkezésének figyelését a különböző eseményfigyelő (event listenet) interfészek végzik. Ezek tartalmazzák azon függvényeket, melyek az adott elemen az adott esemény bekövetkezésekor végre fognak hajtódni. Tekintsük át röviden párat a View osztályhoz kapcsolódó eseményfigyelő interfészek legfontosabb callback metódisaból: onclick() (View.OnClickListener interfész) akkor hívódik meg, ha a felhasználó megérinti az adott elemet onlongclick() (View.OnLongClickListener interfész) akkor hívódik meg, ha a felhasználó megérinti az adott elemet, és továbbra is nyomva tartja azt. onfocuschange() (View.OnFocusChangeListener interfész) akkor hívódik meg, ha a felhasználó az adott elemre, vagy arról elnavigál. onkey() (View.OnKeyListener interfész) - akkor hívódik meg, ha a fókusz az adott elemen van, és a felhasználó megnyom, vagy felenged egy hardveres gombot ontouch() (View.OnTouchListener) akkor hívódik meg, ha a felhasználó végrahajt eg yérintési eseményt, ami lehet lenyomás, felengedés, vagy egyéb mozgatással járó kézmozdulat Az előbbi példában jól nyomon követhető a gombnyomás eseménykezelése az onclick() eseménykezelő függvénnyel Stílusok és témák alkalmazása A stílusok és a témák használata az Android platformokon ugyanazt a filozófiát követi, mint amit a CSS stíluslapok alkalmazása a weboldalak létrehozásánál. A segítségükkel a megjelenés megtervezése és a tartalom szerkesztése külön választható. Bár létrehozásuk módja azonos, mégis meg kell különböztetnünk a stílus és a téma fogalmát. Stílusról akkor beszélünk, ha a létrehozott stílus a felhasználói felület egyetlen View elemére vonatkozik csak. Témának akkor nevezzük az elkészített stílust, hogy az már nem egyetlen elemre, hanem egy Activity-re, vagy akár a teljes alkalmazásra vonatkozik. A stílusokat leíró állományokat a res/values alkönyvtárba kell elhelyeznünk. Minden stílus állomány gyökérelemének a <resources> elemnek kell lennie. Ebben helyezkednek el a stílust definiáló elemek, melyeket a <style> tagok jelölnek, és amelyek kötelező attribútuma a

43 name, amivel egy egyedi azonosító rendelhető hozzájuk. Ezzel hivatkozhatunk majd rájuk a forráskódban, vagy más erőforrás állományokban. A <style> tagokon belül adhatjuk meg <item> elemeket a name tulajdonsággal, ami meghatározza, hogy melyik stílus tulajdonságot írjuk le éppen. Az <item> elem pedig tartalmazza a stílus tulajdonság értékét. Ez az érték sokféleképpen megadható. Lehet ez kulcsszó, hexadecimális formában meghatározott szín, hivatkozás egy másik erőforrás típusra, attól függően, hogy mi volt a stílus tulajdonság 23. Az elkészített stílusokat az erőforrás állományokban található elemekhez a style tulajdonság beállításával rendelhetjük hozzá. 42 <resources xmlns:android=" <!-- Base application theme for API 14+. This theme completely replaces AppBaseTheme from BOTH res/values/styles.xml and res/values-v11/styles.xml on API 14+ devices. --> <style name="appbasetheme" > <!-- API 14 theme customizations can go here. --> <item name="android:textcolor">#00ff00</item> <item name="android:textsize">22sp</item> <item name="android:textstyle">italic</item> </style> <style name="beviteli"> <item name="android:textcolor">@color/feher</item> </style> <style name="radiogroup"> <item name="android:background">@color/bezs</item> </style> <style name="radiogomb" > <item name="android:textcolor">#00ff00</item> <item name="android:paddingleft">50dp</item> </style> <style name="gombok"> <item name="android:background">#d8e9cb</item> <item name="android:textstyle">bold</item> <item name="android:textcolor">#00ff00</item> <item name="android:paddingleft">10dp</item> <item name="android:paddingright">10dp</item> </style> </resources> 23 Android Styles and Themes -

44 43 Kellemes tulajdonsága a stílusoknak, hogy a programozó által létrehozott stílusok öröklődhetnek. Öröklődés esetén az összes tulajdonság átöröklődik a szülő stílusból a gyerek stílusba. Az öröklődés megadása a <style> elem name attribútumában történhet, a következő módon: szülőstílus_azonosítója.gyermekstílus_ azonosítója. A témák elkészítése teljesen azonos módon történik, mint a stílusoké, csak ezeket teljes Activity-kre, vagy alkalmazásokra tudjuk alkalmazni. Az Android rendszer tartalmaz pár előre elkészített témát is, melyeket alkalmazásainkban mi magunk is szabadon felhasználhatunk. A felhasználandó témát az AndroidManifest.xml állományban állíthatjuk be az android:theme tulajdonságnál megadva a téma azonosítóját. Ha az android:theme tulajdonság az <activity> elemen belül szerepel, akkor az adott Activity-re fog vonatkozni a téma, míg ha az <application> elemen belü szerepel, akkor a teljes alkalmazásra. Természetesen az alkalmazott téma beállítható forráskódból is. Ekkor a settheme() metódust kell meghívnunk az oncreate() metódusban, ügyelve arra, hogy a hívás még a felhasználói felület elemeinek létrehozása előtt megtörténjen Lokalizáció Alkalmazásunkat akkor tudjuk eljuttatni sok emberhez, ha több nyelven is elérhetővé tesszük azt. Erre, a nem is túl egyszerű feladat megoldására az Android egy igen jó megoldást nyújt rendelkezésünkre, éspedig a korábban már említett minősítők használatával. Minden, az alkalmazásunkban található szöveges elemet alapértelmezetten a res/values/strings.xml állományba kell elhelyezni. Az Android azonban lehetővé teszi, hogy ezen felül a values könyvtárhoz minősítőket tegyünk, és így ott az adott nyelvnek megfelelő változatban hozzuk létre a strings.xml állomány tartalmát. Így ha angol verziót szeretnénk, akkor létre kell hoznunk a values-en, míg ha magyar verziót, akkor a values-hu alkönyvtárt és ebben tárolni el a nyelv specifikus strings.xml erőforrás állományt. Fontos itt megjegyezni, hogy a values alkönyvtárban lévő strings.xml állomány az alapértelmezett, így annak hiánya hibát okozhat, ha olyan nyelven szeretné megnézni valaki az alkalmazásunkat, melyhez nem hoztunk létre nyelv specifikus részt Animációk Alkalmazásinkat még érdekesebbé tehetjük a grafikus elemeink animálásával. Ezt az Android két beépített eszközzel is támogatja. Az első az úgynevezett tweened animáció, melyben megadhatjuk az adott elemhez, hogy milyen animáció hajtódjon végre rajta, mint

45 például halványítás vagy mozgatás. A második a frame by frame animáció, ami a filmeknél alkalmazott megoldást jelenti, azaz egy képsorozat egyes képeit tudjuk vele automatikusan lecserélni bizonyos időközönként. Akár csak a felhasználói felület kialakításakor, itt is célszerű az animációkat erőforrás állományokban megadni, melyeket a /res/anim alkönyvtárba kell elhelyeznünk. A tweened 24 animáció esetén a következő négy plusz egy animációs forma közül választhatunk: alpha az átlátszóság állítható vele scale a méretezés beállítására szolgál translate a mozgatás megvalósítását végzi rotate a forgatás beállítása valósítható meg vele A plusz egyedik elem a set elem, amely segítségével csoportba foghatjuk az animációs elemeket, így lehetőségünk van összetett animációk készítésére. Ilyen animációk esetén az eltérő alap animációs formák egyszerre hajtódnak végre, például az elem elforog miközben elhalványul. Mindegyik animáció típusnak megvannak a saját beállítási lehetőségei, melyekkel az animációk kezdő és végértékeit lehet beállítani. Ezen felül pedig léteznek olyan tulajdonságok is, amelyekkel az animáció lefolyását befolyásolhatjuk. Ilyenek például a következők: android:duration az animáció időtartama adható meg vele miliszekundumban android:fillafter ha értéke igaz, akkor az animáció befejeződése után alkalmazza a módosításokat android:fillbefore ha értéke igaz, akkor az animáció elindítása előtt alkalmazza a módosításokat android:interpolator az animáció sebességét változtatja meg. Ezáltal egy animáció lehet gyorsuló, lassuló, ismétlődő stb. android:repeatcount az animáció ismétlődésének számát adja meg. android:startoffset az animáció indításának késleltetése adható meg vele miliszekundumban Következzen itt egy példa összetettebb animációs példa a hozzá tartozó XML erőforrással - textanimation.xml - és az animáció forráskódban való alkalmazásával Android View Animation -

46 <?xml version="1.0" encoding="utf-8"?> <set xmlns:android=" <rotate xmlns:android=" android:fromdegrees="0" android:todegrees="360" android:toyscale="0.0" android:pivotx="40%" android:pivoty="30%" android:duration="2000" /> <alpha android:fromalpha="1.0" android:toalpha="0.0" android:duration="4000" /> <scale android:fromxscale="1.0" android:toxscale="0.0" android:fromyscale="1.0" android:toyscale="0.0" android:pivotx="0" android:pivoty="0" android:duration="2000" /> </set> 45 final Animation a = AnimationUtils.loadAnimation(this, R.anim.textanimation); a.reset(); final TextView animtext = (TextView) findviewbyid(r.id.animszoveg); animtext.setonclicklistener(new View.OnClickListener() public void onclick(view v) { animtext.startanimation(a); } }); A frame by frame 25 vagy más néven drawable -animáció esetén is XML erőforrás állományban adjuk meg az elemeket. Ebben az esetben nem kell mást tennünk, mint egy animation-list elemben fel kell sorolnunk az egymás után megjelenítendő képeket a hozzájuk tartozó időtartammal. 25 Android Drawable Animation -

47 46 <?xml version="1.0" encoding="utf-8"?> <animation-list xmlns:android=" android:oneshot="true"> <item android:duration="200"/> <item android:duration="200"/> <item android:duration="200"/> <item android:duration="200"/> <item android:duration="200"/> <item android:duration="200"/> </animation-list> //Az animáció beállítása a forráskódban ImageView kep=(imageview) this.findviewbyid(r.id.imageview_kocka); kep.setimageresource(r.drawable.kocka_animation); final AnimationDrawable kockaanim=(animationdrawable) kep.getdrawable(); kep.setonclicklistener(new View.OnClickListener() public void onclick(view v) { kockaanim.start(); } }); 5.7. Menük Alkalmazásaink fejlesztésekor gyakran szükségünk lehet egyszerű, vagy öszetett menük kialakítására és használatára. A menüket legegyszerűbben erőforrások felhasználásával hozhatjuk létre. Nincs más dolgunk, mint létrehozni egy erőforrás XML állományt a /res/menu alkönyvtárba. Az állományban a <menu> elemen belül kell felsorolnunk a menüpontokat <item> elemekben. A <menu> elemek egymásba ágyazhatóak, így több szintű menü is létrehozható. <menu xmlns:android=" <item android:id="@+id/menu1"

48 <item <menu> <item <item </menu> </item> <item </menu> Android alapú szoftverfejlesztés kezdőknek A menüt az oncreateoptionsmenu() metódus felüldefiniálásával tölthetjük be a programunkba, míg a menüpontok kiválasztását az onoptionsitemselected() metódussal kezelhetjük le. public boolean oncreateoptionsmenu(menu menu) { getmenuinflater().inflate(r.menu.menuk, menu); return true; public boolean onoptionsitemselected(menuitem item) { switch(item.getitemid()){ case R.id.menu1: Toast.makeText(MenukActivity.this, "Az első menüpontott választottad", Toast.LENGTH_LONG).show(); return true; case R.id.almenu1: Toast.makeText(MenukActivity.this, "Az első almenüt választottad", Toast.LENGTH_LONG).show(); return true; case R.id.almenu2: Toast.makeText(MenukActivity.this, "A második almenüt választottad", Toast.LENGTH_LONG).show(); return true; case R.id.menu3 Toast.makeText(MenukActivity.this, "A harmadik menüpontot választottad", Toast.LENGTH_LONG).show(); return true; default: return super.onoptionsitemselected(item); } }

49 6. Komponensek közötti kommunikáció 48 Mint azt már korábban említettük minden Androidos alkalmazás a saját Dalvik virtuális gépén fut. Így az alkalmazások elkülönülnek egymástól, biztosítva ezzel az adatok és processzek védelmét. Az alkalmazásainknak azonban valamilyen módon kommunikálniuk kell egymással, amit az Android elsődlegesen az intent elemek alkalmazásával old meg. Az alkalmazások fő komponenseit az activity-ket, service-eket és broadcast reciver-eket üzeneteken keresztül lehet aktiválni. Ezeket az üzeneteket intent-eknek nevezzük, melyek az Intent osztály példányai. Az intent tulajdonképpen egy passzív adatstruktúra, amely események vagy műveletek absztrakt leírását tartalmazza. Vagy olyan műveletét, amelyet végre szeretnénk hajtatni, vagy olyan bekövetkezett eseményét, amely már máshol bekövetkezett. Az intent közvetítése mindig az operációs rendszeren keresztül történik. Az intent-ek szigorú előírásoknak megfelelően juthatnak csak el a megfelelő komponensekhez: 26 A Context.startActivity() vagy Activity.startActivityForResult() metódusokkal elindított intent-eket csak Activity-k fogadhatják. Ezek segítségével indíthatunk el egy egy activityt, vagy mondhatjuk meg egy activity-nek, hogy hajtson végre valamit. A Context.startService() vagy Context.bindService() metódusokkal elindított intent-eket csak Service-ek fogadhatják. Ezek segítségével indíthatunk el egy service-t, vagy adhatunk új parancsokat már futó szolgáltatásoknak. A Context.sendBroadcast(), Context.sendOrderedBroadcast(), vagy Context.sendStickyBroadcast()metódusokkal elindított intent-eket csak broadcast reciever-ek fogadhatják. Az Android rendszer az, amely megkeresi az adott típusú intent-hez a fogadására képes komponenst, szükség esetén példányosítja és elindítja a komponenst, és átadja neki az információkat. A meghívott komponens nem csak az adott alkalmazás eleme lehet, hanem bármilyen más alkalmazás modulja is. Ebből következik, hogy saját alkalmazásainkat is fel tudjuk készíteni más alkalmazásokból küldött intent-ek fogadására. 26 Android - Intents and Intent Filters -

50 6.1. Az intent objektumok 49 Az intent objektum tehát nem más, mint egy információs csomag, amely a következő részekből épül fel 27 : Komponens név Annak a komponensnek a neve, amelynek kezelnie kell az intent-et. Ez tulajdonképpen egy ComponentName osztály béli objektum, ami a célkomponens minősített osztálynevének (pl.: hu.nyf.pelda.app.peldaactivity) és a komponenst tartalmazó alkalmazás csomagnevének az együttese. Akció A bekövetkezett eseményt, vagy az általunk kiváltandó eseményt azonosítja. A rendszer számos ilyen előre definiált akciót tartalmaz, de akár mi is létrehozhatunk ilyet. Az intent ezen része határozza meg, hogy milyen egyéb adat és extra mezők kapcsolódnak majd az intent-hez. Példaképen nézzünk meg párat a leggyakoribb akciók közül: o o ACTION_CALL (célkomponens: activity) Egy hívást kezdeményez az adatmezőben átadott telefonszám irányába. ACTION_MAIN (célkomponens: activity) Elindítja a kezdő activity-t. Nincs se bemenő, se kimenő adata. o ACTION_BATTERY_LOW (célkomponens: broadcast receiver) Az alacsony töltöttségi szintre figyelmeztet. o ACTION_SCREEN_ON (célkomponens: broadcast receiver) A képernyőt bekapcsolták. Adat Az eseményhez tartozó adat URI-jét és MIME 28 típusát tartalmazza. Különböző eseményekhez különböző típusú adatok tartoznak. Például egy ACTION_EDIT eseménynél az adat mező a szerkesztendő dokumentum URI-jét tartalmazza majd. Bár sok esetben az URI-ből egyértelműen következik az adat típusa, mégis sok esetben nem csak az adat URI-jét, de az adat típusát is ismernünk kell, hogy helyesen kezeljük az intentet. Az adat típusát a MIME típussal adhatjuk meg. Az adatokra vonatkozó információkat mi magunk is beállíthatjuk és lekérdezhetjük a következő metódusokkal: o o o o setdata() az adat URI-jét adhatjuk meg vele settype() a MIME típus adható meg vele setdataandtype() az URI és MIME típus együtt adható meg vele getdata() az adat URI-je kérdezhető le vele 27 Android Intent A MIME típusok az Internet Assigned Numbers Authority oldalán találhatóak meg -

51 o Android alapú szoftverfejlesztés kezdőknek gettype() az adat MIME típusa kérdezhető le vele Kategória További információkat tartalmaz az intent-et feldolgozó komponens típusáról. Kategóriából egyszerre több is megadható. A kategóriák leírásai az intent osztályban lettek elhelyezve 29. Álljon itt két példa a kategóriára: o CATEGORY_HOME Ez az első activity, amely a rendszer indítása után végrehajtódik. o CATEGORY_BROWSABLE Azoknak az alkalmazásoknak, melyek biztonságosan meghívhatóak a webböngészőkből, azoknak támogatniuk kell ezt. Például egy böngészőben címre való kattintást csak olyan alkalmazás tud majd lekezelni, amely támogatja ezt a kategóriát. Extrák Olyan további kulcs-érték párokat tartalmaz, amelyeket az intent kezelő komponenshez kell eljuttatni. Ezekből akár több is lehet. A kulcs-érték párokat beállíthatjuk és visszaolvashatjuk a put () és get () metódusok sorozatával, de úgy is, mint egy Bundle objektumot, felhasználva a putextras() és getextras() metódusokat. Jelölők (Flags) Számos fajtája létezik. Némelyik megadja, hogy indítsunk el egy activity-t, másik fajtájukkal azt állíthatjuk be, hogy mit tegyünk az activity-vel az elindulás után. A jelölők az Intent osztály setflags() metódusával állíthatók be, és leírásuk az Intent osztálynál találhatóak meg Activity indítása A startactivity() metódust használhatjuk egy új activity elindítására, ami ezzel az activity verem legtetejére kerül. A metódus bemenő paramétere egy intent, amely alapján a rendszer meghatározza, meghatározza, hogy melyik activity-t kell elindítani. Az indításhoz az Intent-et megadhatjuk implicit vagy explicit módon is. Explicit Intent-et akkor tudunk alkalmazni, ha pontosan tudjuk, hogy melyik activity-t akarjuk elindítani. Ha a saját alkalmazásunk egy másik activity-jét szeretnénk meghívni, akkor célszerű az intent konstruktorában átadni az alkalmazás környezetet a getapplicationcontext() metódussal, valamint az indítandó activity osztály nevét a class kiterjesztéssel. Ha más alkalmazásból való activity-t szeretnénk elindítani, akkor a külső alkalmazás pontos csomagnevét kell megadnunk az alkalmazás környezet attribútumaként. 29 Android Developers Intent class -

52 51 Intent relative_hivas=new Intent(getApplicationContext(), RelativeActivity.class); startactivity(relative_hivas); Button gomb_animextra = (Button) this.findviewbyid(r.id.button_animextra); gomb_animextra.setonclicklistener(new View.OnClickListener() public void onclick(view v) { Intent hivasextra=new Intent(); hivasextra.setaction(intent.action_send); hivasextra.setclassname("nyf.hu.animaciok", "nyf.hu.animaciok.animacioactivity"); hivasextra.putextra(intent.extra_text, "Ez az elküldött szöveg"); hivasextra.settype("text/plain"); startactivity(hivasextra); }); } Implicit Intent-et esetén nem kell pontosan tudnunk, hogy melyik alkalmazást akarjuk meghívni, csak azt, hogy milyen akciót szeretnénk végrehajtatni alkalmazásunkkal. Ilyenkor nem a komponens nevét kell megadnunk, hanem az elvárt akciót, melyet sok esetben ki kell egészíteni a hozzá tartozó adatokkal. A plusz információt vagy az Intent adat mezőjével, vagy az Intent Extra Bundle-jének feltöltésével adhatjuk meg. Ezek ismeretében az operációs rendszer fogja megkeresni számunkra a kérés kiszolgálásához legmegfelelőbb alkalmazást. Az Android operációs rendszer egyik legnagyobb előnye is ebben rejlik, hiszen ha már létezik alkalmazás egy adott probléma megoldására, és az fel van készítve implicit intentek fogadására, akkor a programozónak csak az adott alkalmazást kell meghívnia, ahelyett, hogy újra írná azt. Ha az operációs rendszer egyetlen megfelelő alkalmazást sem talál a kérésre, akkor az ActivityNotFoundException kivételt eredményez. Ha viszont több lehetséges alkalmazás is a rendelkezésünkre áll, akkor a felhasználónak kell döntenie, hogy melyiket alkalmazza. Az előző példában a lévő startactivityforresult() hívásra visszaérkező adatok fogadása a következőképpen történik: Button gomb_kamera= (Button) this.findviewbyid(r.id.button_explicit); gomb_kamera.setonclicklistener(new View.OnClickListener() {

53 @Override public void onclick(view v) { Intent fotokeszites=new Intent(MediaStore.ACTION_IMAGE_CAPTURE); startactivityforresult(fotokeszites, 1); } }); 52 A startactivity() metódus legnagyobb hibája, hogy semmilyen információt nem ad vissza a hívott activity-ről, és onnan semmilyen további adatot sem tudunk átvenni. Ha olyan activity-t szeretnénk meghívni, amelytől azt várjuk el, hogy adatot szolgáltasson vissza a hívónak, akkor ezt a startactivityforresult() metódussal kell meghívnunk. Ilyenkor a hívott activity befejeződésekor a hívó oldalon az onactivityresult() eseménykezelő fut le, amellyel lekezelhetjük a befejeződési módokat és feldolgozhatjuk a visszaadott adatokat. A startactivityforresult() metódus paramétere egy intent és egy egész szám, amely a kérést azonosítja. A meghívott activity-ben a setresult() metódussal állíthatjuk be a visszaadandó adatokat. Itt először a visszatérési kódot adhatjuk meg, amely általában az előre definiált RESULT_CANCELED, vagy a RESULT_OK ez utóbbi az alapértelmezett - konstans szokott lenni. Ezt követheti egy Intent objektum a visszaadandó adatokkal. A finish() metódus hívására az activity befejezi a működését és a hívó oldalon meghívódik az onactivityresult() eseménykezelő Alkalmazás felkészítése kérések kiszolgálására Intent Filter Ha olyan alkalmazást írtunk, melyet más alkalmazások is felhasználhatnak, akkor ezt elérhetővé kell tennünk a többi alkalmazás számára. Ezt úgy tehetjük meg, hogy az Intent Filter-ek segítségével regisztráljuk alkalmazásunkat az operációs rendszerben, megadva annak, hogy mely kérések kiszolgálására alkalmas az alkalmazásunk. Az Intent Filter-eket az AndroidManifest.xml állományban állíthatjuk be, ahol az adott komponenseknél kell megadni egy vagy akár több ilyen szűrőt. A szűrőket az <intentfilter> elemmel kell megadni, ahol beállíthatóak az <action>, <category> és a <data> elemek. <intent-filter> <action android:name="android.intetn.action.send"/> <category android:name="android.intent.category.default"/> <data android:mimetype="text/plain" /> </intent-filter>

54 Ha egy alkalmazásnál beállítottuk a komponensekhez tartozó Intent Filter-eket, akkor ezzel jeleztük az operációs rendszer felé, hogy alkalmazásunk milyen kéréseket képes kiszolgálni. Az operációs rendszer egy activity hívása esetén a hívás által átadott Intent-et hasonlítja az alkalmazások Intent Filter-eihez. Azon alkalmazások választódnak ki, amelyekre igazak a következők: Az Intent objektum action-je megegyezik az alkalmazás szűrőjében megjelenő valamelyik action-el, vagy ha a szűrőben üres action van beállítva. Az Intent objektumnál megadott összes category megtalálható a szűrőben is. Az Intent URI és MIME beállításai megfelelnek a data beállításaival, vagy ha a szűrő data tagja üres. Ha egyetlen komponenst se talál a rendszer, amely képes kiszolgálni a kérést, akkor ActivityNotFoundException váltódik ki. Ha csak egy komponenst talál, akkor azt azonnal el is indítja, míg ha többet, akkor kilistázza azokat és a felhasználóra bízza, hogy azok közül melyiket választja ki Broadcast események hívása Az Intentek segítségével nem csak alkalmazáskomponenseket indíthatunk el, de lehetőségünk van úgynevezett broadcast, vagy más néven rendszer üzenetek küldésére is. Ezeket olyan alkalmazások tudják kezelni, melyek feliratkoztak a broadcast események fogadására. Broadcast eseményt a sendbroadcast() metódussal küldhetünk, melynek paramétere egy Intent objektum. Egy broadcast eseményt csak a BroadcastReceiver komponens képes kezelni, ezért ha saját Reciever osztályt szeretnénk készíteni a broadcast üzenetek kezelésére, akkor azt a BroadcastReceiver osztályból kell származtatnunk. Az osztályunk onrecieve() metódusa fog végrehajtódni bármilyen broadcast esemény bekövetkeztekor, annyi megkötéssel, hogy ennek a programrésznek öt másodpercen belül be kell fejeződnie, különben Application Not Responding hibaüzenetet kapunk. A broadcast üzenetek feldolgozására felkészített alkalmazásunkat az Intent Filter-ek segítségével tudjuk regisztrálni a rendszerbe. Ezt megtehetjük futási időben, vagy előre az AndroidManifest.xml állományban. Ha futási időben regisztráljuk alkalmazásunkat, akkor az ott található broadcast kezelő csak akkor fut le, ha az alkalmazásunk éppen fut. Ha a manifest állományban regisztráljuk alkalmazásunkat, akkor alkalmazásunkat a rendszer el tudja indítani egy bejövő broadcast üzenet hatására.

55 //Broadcast fogadására regisztrálás Manifest állományban 54 <receiver android:name="broadcastfogadoreceiver"> <intent-filter> <action android:name="nyf.hu.broadcastkuldo.bcuzenet"/> </intent-filter> </receiver> //Broadcast fogadására regisztrálás futási időben IntentFilter szuro = new IntentFilter(Intent.ACTION_HEADSET_PLUG); FulhallgatoReceiver rec=new FulhallgatoReceiver(); this.registerreceiver(rec,szuro ); Az Android operációs rendszer számos broadcast Intent-et ismer 30. Ezek közül felsorolunk párat: ACTION_BATTERY_LOW - Az akkufeszültség alacsony. Ilyenkor érdemes minimalizálni az energiafelhasználást a processzorigényes műveletek leállításával. ACTION_CAMERA_BUTTON A kamera gomb meg lett nyomva. ACTION_HEADSET_PLUG A fülhallgató be lett dugva, vagy ki lett húzva. ACTION_POWER_CONNECTED - A készülék hálózati töltőre lett kapcsolva. Ilyenkor célszerű nagy CPU terheléssel járó, ütemezhető műveleteket elvégezni ACTION_BOOT_COMPLETED - A telefon bekapcsolása és az operációs rendszer elindulása megtörtént. Ilyenkor érdemes olyan alkalmazásokat elindítani, amelyek betöltődés után automatikusan el szeretnénk indítani. 30 Android Developers -

56 7. Állománykezelés 55 Az Android számos lehetőséget biztosít adataink biztonságos tárolására. A választás az alkalmazás igényeinek függvényében sokféle lehet, pl. a hozzáférése alapján privát, vagy publikus tárolás. Utóbbi esetben más alkalmazások és felhasználók is hozzáférhetnek az általunk rögzített információkhoz. Főbb tárolási lehetőségeink: Shared preferences: egyszerű kulcs-érték párral leírható adatok tárolására Internal Storage: az alkalmazásunk privát adatainak tárolására szolgáló megoldás External Storage: másokkal megosztható információk rögzítését oldhatjuk meg a segítségével SQLite adatbázis: strukturált adatok tárolása egy privát adatbázis által Hálózati kapcsolat: az adatok weben keresztüli rögzítése Ebben a fejezetben főleg az egyszerű fájlkezeléssel és adatmentési lehetőségekkel foglalkozunk. Mivel a fájlkezelő műveletek jellemzően nagyságrendekkel lassabbak, mint a memóriában tárolt adatok hozzáférése, ezért érdemes őket különválasztott módon, a felhasználói felülettől külön futtatni, hogy alkalmazásunk reakcióképes maradjon Kulcs-érték párok tárolása A SharedPreferences osztály segítségével az alkalmazás beállításainak tárolása vagy egyszerű adattípusok rögzítése lehetséges. Primitív adattípusok (int, float, boolean, String, stb.) adatokat tárolhatunk szöveges típusú kulcsok segítségével. Az Activityhez tartozó privát területen tárolódnak. Alapvető metódusai: getsharedpreferences(): nevesített állomány létrehozására, illetve megnyitására szolgáló függvény getpreferences(): ha az Activity csupán egyetlen preferencia fájlt kíván tárolni, név megadására nincs is szükség. Közvetlen írásra az állományokba nincs lehetőség, emiatt egy Editor objektumot kell használni.

57 Az értékek tárolásának lépései ennek alapján: Az edit() metódus meghívása a SharedPreferences.Editor segítségével. 2. A megfelelő metódus meghívásával adatrögzítés: putboolean(), putstring(), stb. 3. Véglegesítés a commit() metódus hívásával. A metódusok szintakszisa: put<típus>(string kulcs, <típus> érték) Az olvasás a SharedPreferences osztály get kezdetű metódusaival lehetséges (getstring(), getboolean()). Törölni egyetlen kulcs-értékpárt a remove(string kulcs) metódussal tudunk. Valamennyi törlését a clear() képes elvégezni. A jóváhagyás történhet a commit() mellett az apply(), aszinkron függvénnyel is. Példa String-String típusú kulcs-érték pár tárolására SharedPreferences sharedpref = getsharedpreferences( FileNeve, Context.MODE_PRIVATE); SharedPreferences.Editor editor = sharedpref.edit(); editor.putstring( Kulcs, Érték ); editor.commit(); Példa a kulcs-érték pár visszaolvasására egy TextView objektumba SharedPreferences sharedpref = getsharedpreferences( FileNeve,Context.MODE_PRIVATE); textview1.settext(sharedpref.getstring( Kulcs, "A preference nem található")); A sharedpref.getstring() metódus ha nem találja a fájlban a kulcsot, alapértelmezett értékkel tér vissza. Ez a jelen példában egy figyelmeztető szöveg. Amennyiben a preference fájl létezik, de rossz típusú metódussal próbálunk olvsani belőle, ClassCastException típusú kivételt dob Az Internal Storage használata Az adattároláshoz használt Internal Storage elnevezés itt nem az eszköz beépített tárolóját jelöli. Ennek a tárolónak a segítségével olyan adatrögzítésre nyílik lehetőség, ami jellemzően csak az alkalmazásunk számára érhető el.

58 Ilyenkor, ha az adott alkalmazást eltávolítjuk a készülékről, az ebben rögzített adatok is eltávolításra kerülhetnek. A fájl létrehozásának és írásának menete: 1. Az openfileoutput() függvény hívása a létrehozandó fájl nevével és a hozzáférés módjával. A függvény egy FileOutputStreamet ad, amelyet a továbbiakban írásra használhatunk. 2. Írás a write() függvény segítségével. 3. Lezárás a close() metódussal lehetséges. A létrehozandó fájl hozzáférésének módjai: MODE_PRIVATE: mindenki elől rejtett MODE_WORLD_READABLE: publikus olvasási lehetőség MODE_WORLD_WRITABLE: publikus írási opció MODE_APPEND: meglévő állomány bővítése hozzáfűzéssel 57 Az olvasás menete: 1. openfileinput() hívása, a visszaadott eredmény FileInputStream. 2. Olvasás a read() metódussal. 3. A stream lezárása a close() hívásával. Ha a file nem létezik, nyitáskor FileNotFoundExceptiont kapunk. További hasznos metódusok: getfilesdir(): visszaadja az adatokat tartalmazó könyvtár elérési útját egy File objektumba. getdir(): létrehozza, vagy megnyitja a már létező könyvtárat a könyvtárunkon belül. deletefile(): törli a kijelölt fájlt a tárolóból. Telepítéskor már elérhető adatfájlok létrehozása Amennyiben telepítéskor már rendelkezésre álló adathalmazt szeretnénk készíteni, ezeket a fejlesztés ideje alatt a következő módon hozhatjuk létre: A fájl(ok) mentése történjen a res/raw könyvtárba. A megnyitás az openrawresource() segítségével lehetséges, a megfelelő erőforrása azonosítójának megadásával. Ennek képzése: R.raw.<fájl neve> A fenti metódus InputStreammel tér vissza, ami képes olvasni a fájlt. Az eredeti állomány nem írható. Egyszerű szöveges állomány létrehozása a belső adattárolón:

59 String file_neve = "hello_vilag"; String szoveg = "Helló Világ!"; FileOutputStream fki; 58 try { fki = openfileoutput(file_neve, Context.MODE_PRIVATE); fki.write(string.getbytes()); } finally { fki.close(); } A fájl nevének kiterjesztést adni ebben az esetben nem lényeges, hiszen azt ismerjük és csak az alkalmazásunk látja Az External Storage használata Minden Android-kompatibilis eszköz támogat olyan külső adattárolóknak a használatát, amelyekre adatokat menthetünk. Ez a neve ellenére nem feltétlenül csak külső SD kártya lehet, hanem az eszközbe beépített, fix eszköz is elképzelhető. Jellemző a FAT fájlrendszerek használata, de több partíció is kialakítható rajtuk és támogatottak az ext típusú fájlrendszerek is. A nevüknek megfelelően az ide mentett adatok bárki számára elérhetőek, módosíthatóak, ha a felhasználó az USB mass storage funkcióját aktiválja, amivel a számítógéppel való adatátvitel hagyományosan megvalósítható. Mivel az eszköz akár fizikailag is eltávolítható, az itt található adatok az alkalmazásunk számára ideiglenesen, vagy tartósan is elérhetetlenné válhatnak. Ezért fontos az elérhetőség vizsgálata. A vizsgálat mindennemű művelet előtt a getexternalstoragestate() segítségével történhet. Az adott állapot a következő String típusú konstansok segítségével kapható meg: MEDIA_MOUNTED: a lemezterület felcsatolt MEDIA_MOUNTED_READ_ONLY: csak olvasható módon hozzáférhető a tároló. MEDIA_BAD_REMOVAL: szabálytalanul lett a tároló eltávolítva (lecsatolás nélkül) MEDIA_CHECKING: a tárolót érzékeltük, lemezellenőrzés zajlik MEDIA_NOFS: a tároló üres, vagy nem támogatott fájlrendszert tartalmaz. MEDIA_REMOVED: a tároló le van csatolva (eltávolított). MEDIA_SHARED: a tároló USB mass storage alatt megosztott.

60 MEDIA_UNMOUNTABLE: a tároló érzékelve, de nem felcsatolható. MEDIA_UNMOUNTED: a tároló érzékelve, de nincs felcsatolva. 59 A tároló menet közbeni, akár szabálytalan eltávolítása Intent Filterrel figyeltethető (Intent.ACTION_MEDIA_REMOVED). Ilyenkor a tároló eltávolításáról értesítést kaphatunk egy saját broadcast receiver segítségével. Az Android 2.2-es változata (API Level 8), vagy annál újabb Android esetén bizonyos fájltípusokat szervezetten, egy-egy dedikált mappában tárolhatunk. Külön mappákba gyűjthetjük a fotókat, képeket, a zenéket, videókat, vagy akár a csengőhangokat is. Ettől a verziótól használhatjuk a getexternalfilesdir() metódust arra, hogy a paraméteréül megadott String típus segítségével az visszaadjon egy javasolt teljes elérési útvonalat az adott fájltípus számára. Példák fájltípusokhoz tartozó Stringekre: DIRECTORY_PICTURES: képek tárolására szolgáló mappa DIRECTORY_MUSIC: zenék tárolásához. DIRECTORY_RINGTONES: csengőhangok számára kijelölt könyvtár. Ha a típus hiányzik, a tároló gyökérkönyvtárát adja vissza. A 2.2-nél korábbi Android esetében a fájlok szervezés esetleges volt, legfeljebb ajánlásokat követhetünk. Ilyen esetben használjuk a getexternalstoragedirectory() metódust, amellyel elérhetjük a gyökérkönyvárat. A javasolt könyvtárszerkezet a tároláshoz: /Android/data/<alkalmazás csomagneve>/files/ Az újabb Androidok az alkalmazás eltávolításakor ezeket a mappákat törlik! Példa egyszerű szöveges fájl létrehozására a külső tárolóban: //A tároló elérhető állapotban van felcsatlakoztatva? if (Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorage State())){ //Tároló gyökérkönyvtárának meghatározása File root =android.os.environment.getexternalstoragedirectory(); File dir = new File (root.getabsolutepath() + "/sajat_konyvtar");

61 //Saját könyvtár létrehozása a gyökérkönyvtárban. dir.mkdirs(); //Saját fájl létrehozása File file = new File(dir, "hello.txt"); FileOutputStream f; PrintWriter pw; try { f = new FileOutputStream(file); pw = new PrintWriter(f); pw.println("helló Világ!"); pw.flush(); } catch (FileNotFoundException e) { e.printstacktrace(); Log.e(getString(R.string.app_name), "A fájl nem található. Írási jogosultság?"); } finally { pw.close(); f.close(); } } 60 A programrészlet először leellenőrzi a tároló állapotát, majd a gyökérkönyvtárban létrehoz egy mappát, ott pedig egy fájlt. Hiba esetén az alkalmazás nevével naplóz. A fájl és a könyvtár létrehozásához szükséges a manifest állományban a következő bejegyzés: <uses-permission android:name="android.permission.write_external_storage" /> Jelenleg valamennyi alkalmazás olvashatja a külső tárolókat külön engedély nélkül is. Ez a jövőbeli Android változatoknál várhatóan változni fog 31. Ahhoz, hogy az alkalmazásunk olvashassa a külső tárolót (külön írási jog nélkül), a következő bejegyzés lesz szükséges a manifestben: <uses-permission android:name="android.permission.read_external_storage" /> Mindenesetre a meglévő írási jog egyúttal olvasási jogot is jelent. 31 Android Developers Saving Files -

62 8. Alkalmazások közzététele 61 Elkészült alkalmazásaink sikeres befejezéséhez természetes módon kapcsolódik az a kívánság, hogy azokat másoknak is megmutassuk, megoszthassuk barátainkkal, ismerőseinkkel művünket, vagy közzétegyük bárki számára legfrissebb alkotásunkat. Az Android platformnak kezdetektől erőssége volt a közzétételi lehetőségek sokszínűsége. Az alábbiakban erre kívánunk néhány közkeletű példát bemutatni Nyílt közzétételi lehetőségek Az Android eszközök számára fejlesztett programok esetében szemben a például jóval zártabb IOS megoldásával minden alkalmazás könnyedén megosztható másokkal. A nyitott platformnak köszönhetően a program készítője szabadon dönthet a közzététel módjáról. A fejlesztők számára időt takarít meg az a fontos tulajdonság, hogy az alkalmazás lefordítása és az alkalmazáscsomag elkészítése mindig ugyanúgy történhet, függetlenül a publikálás módszerétől. A következő példák ötleteket kívánnak adni a korlátozások nélküli megosztás módjaihoz Az APK fájlok közzététele A legegyszerűbb módszer alkalmazásaink terjesztésére az alkalmazás telepítőkészletének a megosztása. A megbízható alkalmazáspiacokról származó programokkal szemben egy ismeretlen eredetű alkalmazás azonban biztonsági kockázatot is hordoz. Ezért az Android eszközökön ez a terjesztési módszer alapesetben tiltott. Eléréséhez a Settings > Security > Unknown sources menüpontban (korábban a Settings > Applications menüpontban volt található) engedélyeznünk kell az ismeretlen eredetű alkalmazások telepítését, mielőtt az alkalmazást telepítenénk. Noha ez a legegyszerűbb módja a közzétételnek, mivel tetszőleges más, aláíratlan és ismeretlen alkalmazás is telepíthető így, érdemes a telepítést követően visszazárni ezt az opciót.

63 ábra Aláíratlan csomagok telepítéséhez szükséges opció Webes közzététel, QR kód Az alkalmazásaink közzétételének egyszerű és kézenfekvő módja annak megosztása egy akár intraneten, akár nyilvánosan elérhető webszerveren. Ehhez első körben az alkalmazásunk release módban történő kibocsátása szükséges. Ezután már csupán egy link segítségével megoszthatjuk az alkalmazás telepítőjét. Amikor egy Android eszközről böngésszük az oldalt, az alkalmazáshoz érve alapesetben felajánlja annak telepítését az operációs rendszer. Természetesen csak akkor lehetséges a program telepítése, ha a fentebb tárgyalt, ismeretlen alkalmazások telepítése opció engedélyezve van. A telepítéshez szükséges URL nemcsak hagyományos formában, hanem akár QR kódok segítségével is megosztható, amelyeket akár kép formájában egy plakáton, vagy egy tetszőleges tárgyon megtalálhatunk. Ezek számos erre a célra készült alkalmazással közvetlenül letölthetővé, telepíthetővé teszik a kódba rejtett URL-en keresztül az alkalmazást.

64 ábra QR kód generáló alkalmazás képernyőképe A módszerrel nemcsak alkalmazások, vagy weblapok URL-ei, hanem tetszőleges szövegek, telefonszámok, sms-ek, esetleg vcard alapú névjegyek is közzétehetők Közzététel ben Az ben elküldés az alkalmazás legegyszerűbb, leggyorsabb terjesztési módja lehet(ne). A levél Androidos levelezőkliensekben megnyitott csatolmánya általában egy kattintásra telepíthetővé teszi a továbbított programunkat (például a Gmail alkalmazásban). Az es terjesztést azonban lehetőség szerint kerüljük, ugyanis az feladója könnyedén hamisítható. Emiatt sokkal nagyobb a kockázat ilyenkor, mint egy ismeretlen weblapról töltött alkalmazás esetében. Hamarabb megbízunk egy (hamis) ismerős jében, mint egy kétes weblapban. Az alkalmazások fenti közzétételi módjai korlátozottan, vagy egyáltalán nem teszik lehetővé a fizetőssé tételt, vagy az alkalmazáson belüli vásárlást Közzététel valamely piactér alkalmazásban Szélesebb közönség számára tehetjük elérhetővé programjainkat, ha egy, vagy több piactéren (marketplace) meghirdetjük azt. Ekkor a piactér látogatóinak számától függően több ezer, vagy akár millió felhasználó értesülhet alkalmazásainkról. Az ezeken a piactereken való publikálás módja, bonyolultsága a konkrét helyszíntől függ. A piacterek biztonsága változó, azaz a rajtuk lévő alkalmazások megbízhatósága, hitelessége szintén különböző lehet.

65 Íme néhány a megbízhatóbb piactér alkalmazások közül: 32 Piactér neve Piactér linkje Földrajzi helye 64 Becsült kockázat Aproov Európa 2,1% Amazon Appstore USA 2,7% D.cn Kína 7,0% Handster Európa 7,3% Google Play play.google.com USA 8,4% A táblázat érdekessége, hogy a felmérést végző cég szerint a kisebb, vagy nem hagyományosan Androidra alapozott piacterek (pl. Amazon) megbízhatóbbak lehetnek, mint a Google saját piactere, annak ellenére, hogy ez utóbbi nem tartalmaz például az eszközök feltörésére használható root készleteket. Ennek oka a vizsgálat szerint az, hogy az Amazonon például kevesebb a mobilalkalmazás, és ezen belül is kevés a jellemzően kockázatot okozó ingyenes alkalmazások száma, továbbá a lassabb közzétételi periódus is kisebb rizikót jelent Google Play A legismertebb és legnagyobb piactér a Google Play, mely alkalmazásának segítségével, vagy weblapján keresztül érhető el. A korábban Android Market néven ismert felület 2008-ban indult. Körülbelül 400 millió eszközre gyárilag fel van telepítve, eddig nagyjából 25 milliárd letöltést generálva. 33 Mivel az eszközök többségén már eleve fent van, a Google-fiókunk megadásával azonnal használatba is vehető. Legfontosabb tulajdonságai és funkciói: 1. Felhasználói értékelések, vélemények írása 2. Kategóriák létrehozása 3. Fejlett keresési lehetőségek 4. Toplisták készítése 5. Ajánlott tartalmak közzététele 32 PCmag- The Safest Android App Markets Android Developers Visibilty for Your Apps -

66 Fizetős tartalmak közzététele 65 A Google Play támogatja fizetős alkalmazások készítését is, a következő feltételekkel: Az ingyenes alkalmazásoknak ingyenesnek kell maradniuk, a fizetősök ingyenessé tehetők. A fizetési lehetőségek: egy alkalommal történő fizetés, alkalmazáson belüli fizetés, vagy rendszeres, előfizetés jellegű mód. A választható fizetési módok, akárcsak a fizetős alkalmazások közzétételének helyszíne, országfüggő. Jelenleg kb. 130 országból érhető el világszerte. A Google Play lehetővé teszi a fejlesztők számára a földrajzi alapú célzást a közzétételhez. Meghatározható továbbá a támogatott készülékek listája is, elkerülendő az esetleges készülékfüggő inkompatibilitást. Egyéb technikai szűrések, pl. felbontás, szenzorok megléte, verziószám is beállíthatók. A letöltésekről a fentiek szerint bontott statisztikák is segítik az alkalmazás nyomon követését. 15. ábra Alkalmazásunk telepítéseinek nyomon követése Közzététel a Google Play esetében Előkészületek Ahhoz, hogy alkalmazásunkat ezen a piactéren is elérhetővé tegyük a következő lépésekre van szükség: Google Play publisher account készítése 34 Android Developers- Distribution Control -

67 Alkalmazások értékesítéséhez Google Checkout Merchant account regisztrálása (Magyarországról sajnos jelenleg nem elérhető opció.) A Google Play Developer Console segítségével az alkalmazásunk közzététele. Google Play publisher account regisztrálásának menete: 66 Regisztrálás a oldalon, a fejlesztő adatainak és elérhetőségének megadásával. Fejlesztői csoport létrehozása is támogatott, több fiók megadása mellett. Ekkor meghatározható, hogy az adott fiók mihez férjen hozzá: közzététel, alkalmazás konfigurálás, üzleti jelentések, statisztikák, stb. Jelenleg a regisztráció költsége 25 $, amelyet egy Google Checkout számla segítségével kell rendezni. 16. ábra Google Developer Console kezdőképe 35 Az alkalmazáson belüli fizetéshez Google Checkout Merchant számla is szükséges, ezért sajnos jelenleg Magyarországon nem támogatott a használata. A konzolon belül elérhető az alkalmazásainkra adott értékelés és szöveges vélemény is, amihez újabban már a véleményt író készülékének típusa, az alkalmazás verziószáma is automatikusan társul. Az alkalmazás debuggolását megkönnyíti az összeomlásról szóló jelentés automatikus továbbítása, ami kiegészül a stack trace-ről szóló információkkal is Alkalmazás közzététele 35 Android Developers Developer Console -