magyar | english | deutsch

A mobil fejlesztő eszközökről

Nézzünk meg, hasonlítsunk össze a jelenlegi mobil platformokhoz kapcsolódó fejlesztői eszközök közül hármat.

Az elmúlt 1-1.5 évben sikerült megismerkednünk a mobil platformok közül három “nagyobb” technológiával: iPhone, Android és Windows Mobile 7. Ezen írásunk a fejlesztő eszközökről fog szólni, megpróbálja azokat egy kicsit összehasonlítani – elsősorban fejlesztői szemszögből.

Android fejlesztés
Az Android operációs rendszerre történő fejlesztés – a platform nyitott voltából adódóan – több operációs rendszer (Windows, Linux és Mac OS X) alatt végezhető, ingyenesen hozzáférhető eszközökkel. A fejlesztés kezdeti szakaszában még androidos készülékre sincs szükség, az SDK tartalmaz egy emulátort, melynek segítségével az elkészített kód kipróbálható.

A fejlesztéshez szükséges eszközök a következőek:
- Java Development Kit (a Java runtime és fordító)
- Eclipse IDE (integrált fejlesztői környezet)
- Android SDK (az androidos fejlesztéshez szükséges eszközök, állományok)
- Android Development Tools (ADT) (plugin az Eclipse-hez)

Az Android operációs rendszernek számos változata létezik különféle eszközökre (különböző kijelzőméretekkel és egyéb hardverelemekkel), a fejlesztés során el kell dönteni, mi lesz az a minimum, amit az elkészült alkalmazás támogatni fog. Természetszerűleg a magasabb verziószámú változatok több lehetőséget tartalmaznak, ugyanakkor kevésbé elterjedtek, mint az alacsonyabbak – ésszerű kompromisszumra van szükség. Jelenleg (2010 vége) még számos, forgalomban lévő készüléken fut az 1.6-os változat.

Egy Android alkalmazás gyakorlatilag egy speciális .ZIP formátumú állomány (.APK, Android Package), amely – hasonlóan a Java által használt .JAR formátumhoz – tartalmazza a lefordított bájtkódot, az alkalmazás által használt erőforrásokat és egy leíró állományt, amely egyebek mellett a futtató készülék szolgáltatásaihoz való engedélyeket határozza meg.

Ezen engedélyek köre pontosan meghatározható – ilyen például az internetelérés, a kamera vagy a GPS használata. Az alkalmazás telepítésekor az operációs rendszer felsorolja azon szolgáltatásokat, melyeket az alkalmazás futása során használni fog – a felhasználó ezek ismeretében szabadon dönthet a telepítés folytatása vagy megszakítása mellett.

Az Android alkalmazások ritkán implementálnak olyan funkciót, amely az alkalmazás leállását eredményezi, a mögöttes filozófia szerint egy elindított alkalmazás mindaddig a memóriában marad, amíg az operációs rendszer úgy nem dönt, hogy szükség van az általa elfoglalt memóriaterületre. Egy alkalmazás lehet aktív állapotban, amikor éppen előtérben van, lehet felfüggesztett vagy inaktív. A fejlesztés során ezen állapotokat, állapotváltozásokat külön szükséges lekezelni – például egy játék esetén kézenfekvő az aktuális folyamatok szüneteltetése háttérbe kerüléskor.

Egy Android alkalmazás alapvetően egy vagy több activity-ből áll – egy activity lehet például egy vizuális felület vagy egy olyan elem, amely a kamera kezeléséért felelős. Az operációs rendszer tartalmaz néhány előre definiált activity-t, például olyat, aminek a segítségével a készülék névjegyzékéből lehet kiválasztani egy vagy több nevet. Az egyes activity-k szabványos felületeken keresztül tudnak egymással adatokat cserélni.

Az egyes activity-k egy vagy több view-t tartalmazhatnak. Egy view létrehozható teljes egészében a kódból, vagy használható a beépített vizuális szerkesztő, amely egy .XML formátumú állományt készít – az .XML természetesen a vizuális szerkesztőtől függően is elkészíthető, módosítható. A vizuális, XML alapú módszer előnye az áttekinthetőség, a könnyebb kezelhetőség. Tisztán kódból létrehozott felületet akkor érdemes használni, ha az egyes elemek egymáshoz viszonyított helyzete, elrendezésre, láthatósága széles skálán mozoghat a felhasználó akcióitól függően.

A kód, a mögöttes logika megírása során figyelmet kell fordítani az alkalmazások számára biztosított memóriára is, jelenleg egy alkalmazás 16 MB (heap) memória felett rendelkezhet szabadon (néhány újabb készülék már 24 MB memóriát biztosít). Az alkalmazás által használt erőforrások esetében törekedni kell a minél kisebb méretekre (képek, hangok), az objektumok újrafelhasználására illetve arra, hogy a szükséges memóriaterület lefoglalása akkor és csak akkor történjen meg, amikor szükség van rá.
A többnyelvűség támogatott, érdemes erőforrás (resource) állományokba helyezni minden egyes, a felhasználói felületen megjelenő szöveges értéket. A fent már említett korlátozások miatt, amennyiben az alkalmazás sok ilyen adatot használ, érdemes megfontolni a különböző nyelvek szerinti bontásban fordított külön változatokat.

Az Eclipse támogatja az Android Test Project projekt sémát is, ez arra szolgál, hogy az elkészült alkalmazás bizonyos aspektusai rendszerezett formában, automatikusan tesztelhetőek legyenek. Érdemes rá időt fordítani, mivel nagyban megkönnyíti az esetleges refaktorálási vagy optimalizálási műveleteket, vagy éppen – összetett felhasználói felület esetén – csökkenti a tesztelésre fordított időt.

iPhone fejlesztés
Az iPhone mobil fejlesztőeszköze – hasonlóan az Apple többi operációs rendszeréhez – a jól ismert Xcode, melyben Objective-C nyelven fejleszthetünk. A nyelv a C++ “módosított” változata. Az Apple oldaláról letölthető iPhone SDK segítségével a fejlesztőkörnyezet kiegészül az iPhone fejlesztés specifikus elemeivel, mely tartalmazza az általánosan használt osztályokat, valamint iPhone / iPad szimulátort is. Így a fejlesztés – korlátozott módon – hardver elem nélkül is végezhető. Természetesen a szimulátor nem képes néhány dologra, amit az eszköz tud, pl: push notification, kamera használat, stb…
A telefon rendelkezik külön grafikus chip-el, mely OpenGL -ben írt 3D-s alkalmazásokat is szépen megjelenít.

Az iPhone-on iOS operációs rendszer fut, melynek több verziója használatos. A manapság használt device-okon (iPad, iPhone 3G, iPhone 3GS, iPhone 4, iPad) lehet az iOS akármelyik verziója, így a fejlesztés során ügyelni kell a minimum operációs rendszer verziójának kiválasztására. Jelen pillanatban a 4.2.1 -es iOS a legújabb elérhető verzió.

Fejlesztőknek a teszt telefon operációs rendszerének frissítésénél vigyázni kell, mert a fejlesztőeszköz (SDK) általában később jön ki, mint maga az operációs rendszer, így egy elhamarkodott frissítéssel a fejlesztés bonyodalmakba ütközhet, ha nem sikerül az új rendszerre lefordítani az alkalmazást.
A telefonra csak az Apple által engedélyezett alkalmazások telepíthetőek. Ezt speciális aláírásokkal ellenőrzik. Annak érdekében, hogy a fejlesztő ki tudja próbálni az alkalmazását a telefonon, egy ún. Provisioning fájlt kell kérni az Apple oldalán (megfelelő regisztráció után), melyet a telefonra kell másolni, így az Xcode képes rátölteni az alkalmazást. Ezen műveletek elvégzésére az Apple részletes útmutatást nyújt.

Az iOS a 4-es verziótól kezdve támogat bizonyos szintű multitasking-ot. Amennyiben be kívánunk zárni egy alkalmazást, annak a futása megáll, de nem záródik be maga a program. Az állapotokat le kell menteni ha szükség van rá, majd az alkalmazás felélesztésekor visszatölteni azokat.
Amennyiben zenelejátszó, VOIP, vagy folyamatos helyzetmeghatározó alkalmazást fejlesztünk, lehetőségünk van ezen folyamatok folyamatos háttérben való futtatására, melyek nem állnak le ha az alkalmazást a háttérbe rakják.

A fejlesztés menetét igyekeztek úgy kialakítani, hogy a kinézet, és a kód elkülönülve legyenek egymástól. Ezt nem sikerült teljes mértékben megvalósítani, igen gyakran van szükség kódból formázni, rajzolni, létrehozni, pozicionálni a különböző UI elemeket. Tipikus példa, hogy a táblázatot nem a beépített UI elemekkel (UILabel, UIImageView) hozzák létre, hanem kódból rajzolják ki. Így sokkal gyorsabb a táblázat görgetése, mert nem a processzor, hanem a grafikus chip rajzolja ki a szöveget, képet, így levéve jelentős terhelést a processzorról.
A “view”-k kialakítása miatt az utólagos módosítás meglehetősen nehézkes. Ha például egy Tab Bar-t szeretnénk pár pixellel magasabbra megnövelni, akkor az összes view-n meg kell növelnünk azt – egyenként.

A fejlesztés során különös figyelmet kell fordítani a memória kezelésre. A C-ből ismert, hasonló módon a létrehozott objektumokat minden esetben fel kel szabadítani. Ellenkező esetben memória szivárgás (leak) lép fel, melyet nem néz jó szemmel az Apple tesztelő bizottsága. Egy objektum csak akkor szabadul fel ténylegesen, ha arra nem hivatkozik tovább egyetlen mutató (pointer) sem.
Ezen szivárgások felderítésére hasznos segédprogramot kapunk az Instruments program személyében, mely az Xcode -al karöltve segít a leak-ek megtalálásában, és kijavításában. Számos esetben elég nehéz ezeket felderíteni, így érdemes már a fejlesztés során odafigyelni a mutatók felszabadítására, így jelentős időt takaríthatunk meg egy-egy eldugott mutató keresgélése helyett.

Sajnos az elmúlt időben az Apple is követi bizonyos értelemben az Androidot: egyre több különböző készülékkel és eltérő operációs rendszer verzióval vannak jelen a piacon és ezek vegyítésével egyre “nő” a lehetséges tesztelendő verziók száma. Persze az Apple szeretné, ha mindenki megvenné a legújabb telefonját a legújabb iOS verzióval, de ez nem mindig-mindenhol fog működni. Ha az egyszeri felhasználó 3-as iPhone-jára rárakja a legfrissebb iOS verziót, akkor persze szidni fogja a programot, hogy lassú, rosszul működik, holott a hiba az ő készülékében van: kevés memóriával, régi hardverrel nem fog működni rajta semmi sem normálisan.

Win Mobile 7 fejlesztés
A “legfiatalabb” mobil eszköz a társaihoz képest, ellenben a fejlesztőeszköz, amivel fejleszteni lehet rá, már öregnek számít. A fejlesztést C# nyelven .NET keretrendszer segítségével végezhetjük a telefonra, a felületek kialakításában a SilverLight segít.

Bár ezen eszközzel foglalkoztunk a legkevesebbet – de szakmai tapasztalatunk alapján – ezzel ismerkedtünk meg a leggyorsabban. Nagyon gyorsan és könnyen kezelhető a fejlesztő környezet (természetesen aki nem találkozott még a C# nyelvvel, annak meg kell ismernie: egy kicsit olyan, mintha a Java-t, a Delphi-t és a C++-t összekeverték volna).
Nagy segítségünkre lehet a jól ismert Expression Blend, melynek segítségével a felületek tervezése és a fejlesztés összekapcsolható.

A Mindmegette alkamazásunkat teszteltük vele, s egy képernyő elkészítése – az iPhone fejlesztőeszközhöz viszonyítva – nagyjából 30-40%-al kevesebb időt vett igénybe. Ezen felül a fejlesztői élményről ne is beszéljünk – ebben a tekintetben a Microsoft nagyon odatette magát, véleményünk szerint mindkét, korábban említett fejlesztői eszköznél egyszerűbb a kezelése.

Sajnos egyelőre Magyarországon még nem lehet alkalmazást feltenni a Market-be, ehhez külföldi céget (vagy ismerőst) kell segítségül hívnunk. Az alkalmazás elbírálása is barátságosabb (hasonlóan, mint az Android esetén), összevetve az Apple körüli “hercehurcával”.
A Microsoft mobil megoldása – bár elég lassan reagált a mobil piac ténykedéseire – erős konkurenciája lehet a piac meglévő szereplőinek.

Eszköz Hardver
diverzitás
Fejlesztő
eszköz
Fejlesztő
segédeszközök
Utólagos
módosítás
Össz.
pont
Helyezés
iPhone (iOS) 4 3 3 3 13 3.
Android 3 4 4 5 16 2.
Windows Mobile 7 5 5 5 5 20 1.



Megjegyzések a táblázathoz: a pontszámok 1-5 lehetségesek.
Hardver diverzitás: Minél több fajta hardver van a piacon és azokon minél több fajta operációs rendszer van, annál nehézkesebb a fejlesztés. 5: kevés ilyen van, 1: nagyon sok ilyen van.
Fejlesztőeszköz: A fejlesztőeszköz kezelhetősége.
Fejlesztői segédeszközök: A fejlesztés segítő egyéb alkalmazások.
Utólagos módosítás: Képernyők utólagos módosításának az értékelése: 1: nagyon nehéz, 5:könnyű

pwd by wp