Android alapok (1) ~ Primusz Péter

Senki nem születik úgy, hogy mindent tud, így ez az írás azokon az alapvető fogalmakon kíván végigmenni amelyek megismerése nélkül nehezen képzelhető el az Android fejlesztés. Én magam sem vagyok Android Guru, sőt! Mégis úgy gondolom, hogy hasznos lehet másokkal is megosztanom mindazt a tudást amit innen-onnan már összeszedtem. Ha Te Android Guru vagy akkor inkább ezt a részt hagyd ki, vagy írj jobbat... :)

Az Android platform szerkezete

Távolról tekintve a platform felépítése egyszerű és világos. A vörös színnel jelölt rész a Linux kernel, amely tartalmazza: a hardver által kezelendő eszközök meghajtó programjait. Ezeket azon cégek készítik el, amelyek az Android platformot saját készülékükön használni kívánják, hiszen a gyártónál jobban más nem ismerheti a mobil eszközbe integrált perifériákat. A kernel adja a memória kezelését, a folyamatok ütemezését és az alacsony fogyasztást elősegítő teljesítmény-kezelést is. Főként C és Assembly nyelven íródott.

Az Android platform szerkezete.

A Linux kernelen futnak a zöld részben található programkönyvtárak/szolgáltatások, mint például: libc, SSL, SQLite, stb … ezek C/C++ nyelven vannak megvalósítva. Ezekre épül a Dalvik virtuális gép, amely nem kompatibilis a Sun virtuális gépével, teljesen más az utasítás készlete, és más bináris programot futtat. A Java programok egy ún. Dalvik Executable formátumba fordítódnak, amelynek kiterjesztése .dex. Ennek a mérete kisebb mint a forrásul szolgáló .class állományok mérete, mert a több Java fájlban megtalálható konstansokat csak egyszer fordítja bele a Dalvik fordító.

A kék színnel jelölt részekben már csak Java forrást találunk (Application Framework). Java forrást a virtuális gép futtat, ez adja az Android lényegét. Ez maga az Android OS. Ez biztosítja a különféle funkciók megvalósítását: ablakkezelő, erőforrás kezelő, stb. A virtuális gép akár teljesen elrejti a Linux által használt fájlrendszert, és csak az Android Runtime által biztosított fájlrendszert láthatjuk. Majd legfelül helyezkednek el a felhasználó számára látható programok: home screen, böngésző, telefon alkalmazás, névjegyalbum, minden ami a telefonra feltelepítve érkezik vagy mi töltünk le a Market-ből.

Felügyelt kód

Az Android platformon alkalmazások fejlesztéséhez általánosan a Java nyelvet használhatjuk (SDK - Standard Development Kit), azonban alacsonyabb szintű funkciók eléréséhez lehetőségünk van natív kódot is készíteni (NDK - Native Development Kit). A natív kód hívásához használhatjuk a JNI-t (Java Native Interface), azonban a rendszer támogatja az osztott könyvtárak (shared libraries) használatát is. A fejlesztés megkönnyítésére lehetőségünk van arra, hogy egy projekten belül elhelyezzük a Java és C++ kódrészeket. A továbbiakban a natív irányt nem emeljük ki, hiszen érvényesek rá a Standard C++ szabályok.

Az Android alkalmazások az ún. „Dalvik” virtuális gépen futnak, mely tulajdonképpen egy átdolgozott, optimalizált Java virtuális gép. A virtuális gép előnye, hogy biztonságossá teszi az alkalmazások futtatását mivel egy alkalmazás összeomlása nem tudja tönkretenni az egész rendszert. Az Android a Java 5 szintaxissal kompatibilis, így használhatunk magasabb szintű nyelvi elemeket is, ellentétben például a Java ME-vel, ahol csak a 3-as nyelvi eszköztár támogatott. A Java nyelv és a Java alkalmazások felügyeltek, így a memóriakezelésért a futtatókörnyezet és a virtuális gép felelős. A memória felszabadításért a GC (Garbage Collector) felelős, azonban ez nem jelenti azt, hogy felelőtlenül bánhatunk az objektumok létrehozásával. Törekedni kell azok folyamatos felszabadítására, hiszen a GC csak a már nem hivatkozott és nem használt objektumok memóriaterületét tudja felszabadítani.

Android alkalmazás felépítése

Egy Android alkalmazás egy vagy több alkalmazás komponensből épül fel:

Activity (a program egy "ablaka")
Service (háttérben futó szolgáltatás)
Content Provider (adatok kezelése)
Broadcast Receiver (rendszerszintű eseményekre reagál)

Minden komponensnek különböző szerepe van az alkalmazáson belül. Bármelyik komponens önállóan aktiválódhat. Akár egy másik alkalmazás is aktiválhatja az egyes komponenseket.

Android alkalmazás komponensek.

Activity: egy-egy Activity leszármazott egy-egy képernyő a mobil eszköz kijelzőjén. Egyszerre mindig csak egy Activity látható, de egy alkalmazáshoz több képernyőkép tartozhat, amelyeket futás közben - események hatására - szabadon cserélhetünk. Minden programnak kell legyen egy belépési pontja, amely az az Activity leszármazott, amelyet először mutat meg a felhasználónak. Minden Activity az android.app.Activity osztályból származik le.

Service: sok alkalmazás igényli, hogy bezárt ablakkal is képes legyen futni a háttérben, ezt szolgáltatásként megteheti, egyszerűen kell egy Service osztályból leszármazott példány, így marad a programunknak olyan része, amely a felfüggesztett Activity esetén is fut (gondoljunk például egy média lejátszóra). Minden szolgáltatást addig futtat a platform, amíg azok be nem fejeződnek, s a futó alkalmazások képesek hozzákapcsolódni a szolgáltatásokhoz, így képesek vagyunk vezérelni a háttérben futó szolgáltatást. Az android.app.Service osztályból kell öröklődnie.

Content Provider: általában minden alkalmazás tárol adatokat két futás között, hiszen ha felfüggesztés helyett bezárnánk az alkalmazást, akkor elvesznének az addig összegyűjtött adatok. A Content provider (tartalom szolgáltató) komponens feladata egy megosztott adatforrás kezelése. A platformon lehetőségünk van állományokba vagy SQLite adatbázisba menteni adatokat, és ezt segíti a Content Provider, illetve lehetővé teszi, hogy két alkalmazás adatokat cseréljen egymással. A Content provider-en keresztül más alkalmazások hozzáférhetnek az adatokhoz, vagy akár módosíthatják is azokat pl.: CallLog alkalmazás, ami egy Content provider-t biztosít, és így elérhető a tartalom. Az android.content.ContentProvider osztályból származik le és kötelezően felül kell definiálni a szükséges API hívásokat.

Broadcast Receiver: a Broadcast receiver komponens a rendszer szintű eseményekre (broadcast) reagál. Például: kikapcsolt a képernyő, alacsony az akkumulátor töltöttsége, elkészült egy fotó, bejövő hívás, stb. Az alkalmazás is indíthat saját „broadcast”-ot, például ha jelezni akarja, hogy valamilyen művelettel végzett (pl. letöltődött a torrent). Nem rendelkeznek saját felülettel, inkább valamilyen figyelmeztetést írnak ki például a status bar-ra, vagy elindítanak egy másik komponenst (jeleznek például egy service-nek). Az android.content.BroadcastReceiver osztályból származik le; az esemény egy Intent (lásd. később) formájában érhető el.

Komponensek indíthatósága

Az Android rendszer sajátossága, hogy egy alkalmazás el tudja indítani egy másik alkalmazás komponensét is, mellyel magas fokú rugalmasságot tud biztosítani a fejlesztők számára. Vegyünk egy példát. Egy fénykép készítéséhez nem kell új Activity-t készíteni, hanem elegendő a kamera alkalmazás kép készítő Activity-jét meghívni. Hívás után a képet megkapja a hívó alkalmazás és a felhasználónak úgy tűnik, mintha a kamera funkció az alkalmazás része lenne. Hoppá!

Amikor a rendszer egy új komponenst indít, először megnézi, hogy fut-e a komponenset tartalmazó alkalmazás Process-e, ha nem, akkor elindítja. Ezt követően példányosítja a szükséges osztályokat. Például az előző kamera esetén, az egész kamera alkalmazást fel kell éleszteni, ha még nem futott. Androidban tehát egy alkalmazásnak több belépési pontja lehet (nincs egy egyszerű main() függvény).

Egy komponens indításához a rendszer felé egy üzenetet/szándékot (Intent) kell intéznünk, melynek hatására végrehajtódik a kérés. A kérésre válasz is érkezhet, mely eljut az indító félhez. Na de mi is ez az Intent? Egy Intent feladata a külső események kezelése. Minden alkalmazás fel tud iratkozni egy-egy - akár a platform által nyújtott, akár magunk által definiált - külső eseményre, mint a bejövő hívás vagy egy időpont bekövetkezte. Le kell származtatnunk egy saját példányt a BroadcastReceiver osztályból, és meg kell mondanunk, hogy milyen eseményre figyeljen. Ezt megtehetjük az AndroidManifest.xml állományban, vagy akár a program futása közben is. Ha az alkalmazásunk nem fut, a figyelt események bekövetkeztekor a platform gondoskodik az elindításról.

Egy androidos projekt felépítése

Egy Android projekt nagyjából úgy épül fel, mint egy átlagos Java projekt, a Java osztályok a megszokott java kiterjesztésű fájlokban vannak, a megszokott csomagstruktúrában, s a megszokott módon kell fordítani ezeket a forrásfájlokat.

Az Android projekt létrehozása után a forráskód az src könyvtárban, míg a felhasználói felület leírására szolgáló XML állományok a res könyvtárban találhatók. Az erőforrás állományokat egy R állomány köti össze a forráskóddal, így könnyedén elérhetjük Java oldalról az XML-ben definiált felületi elemeket. Az Android projekt fordításának eredménye egy APK állomány, melyet közvetlenül telepíthetünk mobil eszközre.

Szerencsére az Android fejlesztés esetén a forráskód és a felhasználói felület különválik, a felhasználói felület definiálására XML állományokat használhatunk (AXML - Android XML ;-] ), így lehetőségünk van a felület deklaratív módon való megadására. Ez jó hír, főleg annak aki már kiképezte magát WPF-ből. Ez azonban nem teszi kizárttá, hogy forráskód szintjén is létrehozzuk, elérjük és manipuláljuk a felhasználói felületet. Ökölszabályként elfogadott, hogy a felhasználói felület minél inkább különöljön el a forráskódtól (ÁMEN!). A projektleíró állomány szintén XML formátumban érhető el (Android Manifest).

Manifest állomány

A manifest állomány az alkalmazás (lelke) leírója, definiálja az alkalmazás komponenseit. Az állománynak deklarálnia kell a következőket:

Alkalmazás komponensek listája.
Szükséges minimális Android verzió.
Szükséges hardware konfiguráció.

Komponens indítás előtt a rendszer a manifest állományt ellenőrzi, hogy definiálva van-e benne a kért komponens. Ezen felül további feladatokat is ellát pl. mik az alkalmazás futtatásának minimális követelményei. A manifest állományban meg kell adni továbbá a támogatni kívánt Android verziót, mely felfele kompatibilis az újabb verziókkal, régebbi verzióra azonban már nem telepíthető. Meg kell adni az engedélyeket, amelyekre az alkalmazásnak szüksége van (pl. Internet elérés, névjegyzék elérés, stb.) Az alkalmazás telepítésekor ellenőrzi a rendszer ezen követelmények meglétét. A legfontosabb manifest attribútumok és tag-ek:

android:icon az alkalmazás ikonja
android:name az activity teljes neve package-al együtt
android:label a készülék felületén, a felhasználók által látható név

A manifest-ben nem szereplő Activity-k, Service-k és Content provider-ek nem láthatók a rendszer számára. Ezzel szemben Broadcast receiver-ek dinamikusan is ki/be regisztrálhatóak kódból (registerReceiver()).

A bűvös R.java állomány

Amikor először kezdünk fejleszteni Android platformra a legfurcsább állomány a forrásban az R.java lesz. Én legalábbis csak pislogtam amikor először megpillantottam. A nevét a RESOURCE szóból kapta. Ez a ronda állomány a felelős azért, hogy az erőforrásokat kódból is elérjük. Az erőforrások elérhetőségét a rendszer automatikusan frissíti és karbantartja, így csak azt jegyezzük meg, hogy ezt az állományt kézzel nem piszkáljuk. Ezt a Java fájlt használhatjuk arra, hogy az ikonokat, képeket, elrendezéseket vagy szövegeket nem a programba írunk közvetlenül, hanem felhasználjuk az R osztályt, amely mutat az adott erőforrásra. Gondoljunk csak az Xml-ben leírt UI-ra, itt tudunk pl. az ott leírt gombra hivatkozni az id segítségével. A gyakorlatban minden világos lesz.

A fordítás menete

A fejlesztő elkészíti a Java forráskódot, valamint az XML alapú felhasználói felületleírást a szükséges erőforrás állományokkal.
A fejlesztőkörnyezet az erőforrás állományokból folyamatosan naprakészen tartja az „R.java” erőforrás fájlt a fejlesztéshez és a fordításhoz.
A fejlesztő a Manifest állományban beállítja az alkalmazás hozzáférési jogosultságait (pl. Internet elérés, szenzorok használata, stb.).
A fordító a forráskódból, az erőforrásokból és a külső könyvtárakból előállítja a Dalvik virtuális gép gépi kódját.
A gépi kódból és az erőforrásokból előáll a nem aláírt APK állomány.
Végül a rendszer végrehajtja az aláírást és előáll a készülékekre telepíthető aláírt APK.

A fordítás menete.

A teljes folyamat a fejlesztői gépen megy végbe, a készülékekre már csak bináris állomány jut el. Szemben a Silverlight világgal ahol a fordításnak csak egy része megy végbe a fejlesztők gépén, a második lépcsőfok a felhasználó gépén történik. Ez a folyamat garantálja számunkra, hogy a végén a gépi kód teljes mértékben az adott processzora legyen optimalizálva. Az .apk-n belüli tartalom tekinthető egy alkalmazásnak, amely Android készülékekre telepíthető.

És itt a vége...

Itt és most véget vetünk ennek a bejegyzésnek. Még sok minden van amiről érdemes lenne írni de majd később. Remélem ez a rövid és sok szempontból nem alapos bevezető hozzájárul ahhoz, hogy a kezdő fejlesztők is magabiztosan tegyék meg az első lépéseket az Android varászlatos világában. A bejegyzés megírásához felhasználtam mindent amit értem, így egy jó kis turmix lett belőle. Alapvetően Dr. Ekler Péter előadásfóliáiból, valamint az AndroidWiki és Java Fórum cikkeiből ollóztam. Remélem nem lesz harag belőle. Ha szakmailag valami hibás akkor a kedves olvasókat kérem, hogy ne tartsák magukba kritikájukat. Kommentálni nem szégyen.