Platform lehetőségek kutatása: ios A Mobil multimédiás kliens fejlesztői eszközkészlet létrehozása című kutatás-fejlesztési projekthez
Tartalomjegyzék 1 Bevezetés... 3 2 Objective-C... 3 2.1 ARC... 4 2.2 Konstruktorok... 4 2.3 Metódusok, üzenetek... 5 2.4 Interfészek és implementációk... 5 2.4.1 Interfészek... 5 2.4.2 Implementációk... 6 2.5 Példányosítás... 6 2.6 Kategóriák és kiterjesztések (categories, extensions)... 7 2.6.1 Kategóriák... 7 2.6.2 Extensions... 8 2.7 Protokollok... 9 2.8 SEL és @selector... 9 2.9 Delegált fejlesztési minta (delegate design pattern)... 10 3 ios... 11 3.1 Gyári alkalmazások... 12 3.2 Liszensz politika... 12 3.3 Apple elvárások AppStore-ba töltéshez... 12 4 Bevezetés az ios platform programozásába... 13 4.1 XCode tippek... 13 4.1.1 #pragma mark... 13 4.1.2 Analyze... 14 4.1.3 Hivatkozások (included by)... 14 4.1.4 Outlet-ek, action-ök... 15 4.2 iphone emulátor... 15 4.3 Compile, link és beállításaik... 16 4.4 Felhasználói felület... 16 4.5 Webszervizek... 17 4.6 Alkalmazás logika... 17 4.7 Képernyők, hogyanok és miértek... 18 4.7.1 Navigation Controller... 18 4.7.2 Induló képernyő... 18 4.7.3 Az UIApplicationDelegate... 18 4.7.4 Storyboard... 20 4.7.5 Splash screen... 21 4.7.6 Táblázatok, ScrollView elem... 22 4.7.7 Touch Event kezelése... 28 5 Források... 30
1 Bevezetés A dokumentum célja az ios alkalmazások fejlesztési módszereinek, lehetőségeinek kiderítése, felkutatása, vizsgálat. ios rendszerbe Objective-C nyelven lehet alkalmazásokat fejleszteni. 2 Objective-C Az Objective-C egy teljesen objektum-orientált kibővített változata a C programozási nyelvnek. A tervezők a C nyelvhez társították a Smalltalk stílusú üzenetközvetítést az objektumok között. Az 1980-as években a strukturált programozás volt a legelterjedtebb programozási modell. Előnye az volt, hogy a programokat kisebb modulokra lehetett bontani, így olvashatóbbak voltak. Nagy hátránya az volt, hogy a kód újrafelhasználása szinte nem létezett, valamint a nagy programok megint csak olvashatatlanok voltak. Hogy ezt kiküszöböljék, a XEROX Palo Alto-i kutatóközpontjában kifejlesztették a Smalltalk nyelvet, amely objektum-orientált volt. A Smalltalk nagy hátránya, hogy a programot egy Virtuális gép (VM) futtatja, emiatt nagyon nagy a memóriafelhasználása és sokkal lassúbb is, mint egy natívan futó program. Az Objective-C nyelvet Brad Cox és Tom Love fejlesztette ki az 1980-as évek elején. Mikor Steve Jobs elhagyta az Apple-t és megalapította a NeXT céget, megvásárolta az Objective-C licencét, ami lehetővé tette, hogy a NeXTstep operációs rendszert és minden fejlesztői alkalmazást Objective-C-ben írjanak meg. A NeXTstep ezáltal a kor legelőrehaladottabb operációs rendszere volt. A GNU projekt 1992-ben megjelentette a NeXTstep ingyenes klónját, az OpenStep operációs rendszert, amely már tartalmazott egy Objective-C fordítót és könyvtárakat, az gnuc-obj-t. Mikor az Apple 1996-ban megvásárolta a NeXT-et, a Mac OS X alapjául az OpenStep-et vették. Az OS tartalmazta az Objective-C-t és a NeXT fejlesztői rendszerét, a Project Buildert (amelyből később az Xcode lett), valamint az Interface Builder-t. Ezek a programok a mai napig a Mac OS X legfontosabb fejlesztői eszközei. A Cocoa API az Objective-C osztályokra támaszkodik és a legelterjedtebb Objective-C környezet a mai napig. A nyelv egy nagyon vékony réteg a C nyelv fölött (csakis C és nem C++ kiterjesztés). Bármilyen C program lefordítható Objective-C fordítóval. Az Objective-C szintaxisa a Smalltalkból ered. Minden nem objektum-orientált művelet (változók, preprocesszálás, függvény deklarációk, függvényhívások) egyezik a C-ben használtakkal, míg az objektum-orientált része a Smalltalk üzenetküldő mechanizmusának egyik változata. Az Objective-C objektum-orientált modellje az objektumpéldányok közti üzenetküldésen alapul. Ez teljesen eltér a C++ stílusú programozási nyelvektől: itt nem az objektum egyik metódusát hívjuk meg, hanem egy üzenetet küldünk az objektumnak és itt van a lényeges
eltérés. A Simula stílusú nyelvekben a metódus neve a fordító által pontosan meg van határozva a kódszegmensben, de a Smalltalkban és Objective-C-ben az üzenet csak egy név és futásidő alatt lesz meghatározva a tárbeli címe: a fogadó objektum kell feldolgozza a kapott üzenetet. Ebből következik, hogy az üzenet küldésekor nincs típusellenőrzés, és nincs rá garancia, hogy az objektum válaszolni is fog az üzenetre. Ha nem tudja feldolgozni, akkor egyszerűen egy nil pointert ad vissza. C++ kód egy objektum metódusának meghívására: foo->bar (parameter); Ugyanez Objective-C nyelvben: [foo bar:parameter]; Mindkét stílusnak megvan az előnye és hátránya. A Simula OOP-ben többszörös öröklődés és kisebb futásidő lehetséges, de alapértelmezetten nincs dinamikus kötés. A Smalltalk OOP lehetővé teszi, hogy az üzenetek ne legyenek implementálva. A Cocoa platform ezt kihasználja maximálisan: minden objektumnak a platform inicializáláskor elküldi az 'awakefromnib:' üzenetet amint a program elindul, és erre az objektumok inicializálódhatnak. Ugyanakkor nem kötelező definiálni egy objektumot az üzenet küldésekor a kódban, dinamikus kötéssel a függőségeket a runtime oldja meg. Egy Objective-C üzenet feldolgozása legalább háromszor annyi időbe telik, mint egy virtuális C++ metódushívás. Objective-c kódok készíteni majd futtatni Mac OSX operációs rendszeren az XCode nevű fejlesztőeszközzel szoktak. Az Xcode egy iphone/ipad szimulátor is tartalmaz, ami nagyjából mindent tud emulálni, tehát az iphone alkalmazás fejlesztése a szimulátoron végrehajtható, de azért a teszteléshez szükséges egy iphone. A következő kis fejezetekben azokat a tulajdonságokat vesszük sorra melyek egyediek, eltérnek más nyelvektől. 2.1 ARC A cím az automatic reference counting rövidítése. C nyelvben minden memória foglalás felszabadításáról a programozónak kell gondoskodnia. Java-ban a JVM garbage collector folyamata gondoskodik erről. Amikor egy új objective-c projektet hozunk létre XCode-ban nyilatkoznunk kell, hogy ARC-s vagy ARC nélküli a projekt. ARC nélküli esetben minden alloc-ot valahol követnie kell egy dealloc-nak. ARC-s projektben nem tudunk dealloc hívást írni mert az XCode hibának jelzi. Tehát az ARC-s Objective-c közel olyan kényelmes memória használat szempontjából, mint a java. 2.2 Konstruktorok A szokásos objektum orientált paradigmát ismerők első kérdései között szerepel, hogy miként lehet konstruktort készíteni. A válasz egyszerű, minden olyan metódus, mely az adott osztály egy példányára mutató mutatót adja vissza az konstruktor, a következő példában a WSLogin osztály konstruktora ki van emelve: @interface WSLogin : NSObject -(WSLogin*) initwithdelegate: (id<wslogindelegate>) _del;
-(void) login; @property (weak) id<wslogindelegate> delegate; Az, hogy mutató, onnan látszik, hogy van utána egy csillag. Ha ezt lehagyjuk, az XCode jelzi is. Az ios gyári osztályai általában id típust adnak vissza a konstruktorok. Az id az tulajdonképpen egy olyan mutató mely bármilyen más osztály mutatóját tartalmazhatja. Tehát az id után nem kell csillag, mert az eleve mutató. 2.3 Metódusok, üzenetek Az Objectiv-C egyik furcsasága például a java-val szemben, hogy míg java esetén már fordítási időben kiderülnek a metódus eltérések, hiányok, típus eltérések, addig Objective-C esetén még futásidőben sem. Mivel az Objective-C nem metódusokban gondolkodik, hanem üzenetekben, ezért ha egy objektumnak küldött üzenettel az objektum nem tud mit kezdeni (vagyis nincs olyan metódusa), egyszerűen egy szó nélkül nil-t ad vissza és a program futása tovább folytatódik. 2.4 Interfészek és implementációk Az Objective-C nyelvben egy osztály interfésze és implementációja különálló kód-tömbökben kell legyen. Megegyezés szerint az interfészt egy header fájlban (általában.h kiterjesztéssel) míg az implementációt egy kód fájlban helyezzük el (általában.m kiterjesztéssel). A "h" fájlban vannak azok az információk, hogy a külvilág mit lát az osztályból, ez az interfész definíció. Az "m" fájlban pedig az interfészt megvalósító kód van, és persze lehetnek a külvilág számára láthatatlan metódusok is. 2.4.1 Interfészek Az interfész általában a header fájlban van leírva. Szokványos, hogy a fájl neve az osztály neve is egyúttal. Ha van egy Foo osztályunk, akkor ezt általában a Foo.h fájlba tesszük. Példa egy interfész leírásra: @interface osztálynév : ősosztálynév { // változók -(típus)példánymetódus1:(típus)paraméter1_neve :(típus)paraméter2_neve; -(típus)példánymetódus2paraméter1:(típus)paraméter1_neve andparaméter2:(típus)paraméter2_neve; +(típus)osztálymetódus1; +(típus)osztálymetódus2; +(típus)osztálymetódus3:(típus)paraméter_neve; A '+' azt jelenti, hogy osztálymetódus, a '-' hogy példány metódusa. Az osztálymetódusok olyanok mint a static metódusok java-ban. Megfigyelhetjük, hogy a példánymetódus2paraméter1 mutatja az Objective-C egyik különlegességét, hogy a paramétereket nevesíteni lehet a függvény nevében (ilyet még csak
Oracle PL/SQL-ben láttam). És szokványos az is, hogy a második paramétertől kezdve "and" szócskával kezdődnek a paraméterek nevei, mintha egy kis mondat lenne az egész metódus hívós sor. Tehát a második paraméter így néz ki: andparaméter2:(típus)paraméter2_neve A metódus hívásakor ezt írjuk: andparaméter2:var2 Ahol var2 az ott helyben létező típus típusú változó. Tehát a metódust hívó az andparaméter2-vel hivatkozik, a metódus megvalósító kód pedig a paraméter2_neve változóban éri el a kapott paramétert. A visszatérési típusok lehetnek bármilyen standard C típusok, egy pointer egy Objective-C objektumra, vagy egy specifikus objektumra mutató pointer (NSArray *, NSImage *, NSString *). A metódusok paraméterei kettősponttal kezdődnek, utána következik a típus majd a neve. Sok esetben érdemes megnevezni a paramétereket: -(void) setrange:(int)start :(int)end; -(void) importdocumentwithname:(nsstring *)name withspecifiedpreferences:(preferences *)prefs beforepage:(int)insertpage 2.4.2 Implementációk Az interfész csak a metódusok és változók neveit deklarálja; maga a kód az implementációban létezik. Általában.m kiterjesztésű fájlokba tesszük. @implementation classname +(típus)osztálymetódus { // implementáció -(típus)példánymetódus { // implementáció Itt egy példa a paraméterek nevesítésére és használatára: -(int)changecolortored:(float)red green:(float)green blue:(float)blue; [mycolor changecolortored:5.0 green:2.0 blue:6.0]; 2.5 Példányosítás Az Objective-C osztályokat két lépésben példányosítjuk: először lefoglaljuk a memóriát az új objektum számára majd inicializáljuk. Egy objektum addig nem működőképes, amíg mindkét lépést nem végeztük el. Ezeket általában egyetlen sorban meg lehet oldani: MyObject *o = [[MyObject alloc] init]; Az alloc hívás elegendő memóriát foglal le, felülírásra még nem láttam példát, nem is szokás, az init hívás felülírható, hogy a változókat inicializálhassuk:
-(id) init { self = [super init]; if (self) { ivar1 = value1; ivar2 = value2; return self; Objective-C nyelvben a self az ugyanaz mint a java-ban a this. Az if (self) azt vizsgálja, hogy az objektum létrejött-e, vagyis hogy az self!= nil. A nil a java null megfelelője. Figyeljük meg, hogy a metódus self-el tér vissza ezért azonnal hívható egy másik metódusa az osztálynak, például feltételezve, hogy van egy loginwithuser metódusa is a MyObject osztálynak: MyObject *o = [[[MyObject alloc] init] loginwithuser:user andpassword:password]; 2.6 Kategóriák és kiterjesztések (categories, extensions) A kategória lehetővé teszi, hogy metódusokat adjunk hozzá egy meglévő osztályhoz, még akkor is ha az eredeti osztály forráskódja nem áll rendelkezésre. A kategóriák kitűnő lehetőséget biztosítanak a meglévő osztályok kibővítésére leszármazott osztály készítése nélkül. Az extensions hasonló, de megengedi más APIk deklarációját. 2.6.1 Kategóriák Új metódust az interfész fájlban egy új kategória névvel adhatjuk meg és az implementációs fájlban is ezzel a kategória névvel kell hivatkozni. A kategóriából tudható hogy a metódus utólag lett az osztályhoz adva nem pedig leszármazott osztály. Viszont új példány változót nem lehet a kategóriával az osztályhoz adni. A kategóriában lévő metódusok az osztály részévé válnak. Például, ha metódust adunk az NSArray osztályhoz egy kategóriában, akkor a fordító feltételezi, hogy minden NSArray példányban benne lesz ez a metódus. Ha származtatott osztályt készítenénk a kategória helyett, akkor az eredeti NSArray példányokban nem lenne benne a leszármazottban lévő metódus, természetesen. A kategória metódusok mindent megtehetnek amit az osztály normál metódusai is. Futásidőben nincs különbség. A kategóriában definiált metódusok az kiterjesztett osztályból származtatott osztályban is használhatók lesznek. A kategória deklaráció nagyon hasonlít az osztály interfész definícióra kivéve, hogy a kategória név zárójelek között szerepel az osztály neve után és ősosztály nem szerepel. Ha ezek a metódusok használnak példány változókat, akkor szerepelnie kell a kiterjesztendő osztály interfész importjának: #import "ClassName.h"
@interface ClassName ( CategoryName ) // method declarations A kategória nem deklarálhat újabb példány változókat csakis kizárólag metódusokat. A kiterjesztendő osztály minden példány változója ugyanúgy elérhető a kategóriában mint a kiterjesztendő osztályban még a @private részben definiáltak is. Nincs limitálva az egy osztályhoz létrehozható kategóriák száma, csak annyi a megkötés, hogy mindegyik nevének el kell térnie. 2.6.2 Extensions Az extensions olyan kb. mint egy névtelen kategória, kivéve hogy a metódusok melyeket deklarál a fő @implementation blokkban kell megvalósítani. Felül lehet definiálni példány változók láthatóságát is akár. Az extensions többnyire az implementációs fájlban kerül megvalósításra. Az interfész fájlban (.h): @interface MyClass : NSObject @property (retain, readonly) float value; Az implementációs fájlban (.m): @interface MyClass () @property (retain, readwrite) float value; A kategóriákkal ellentétben itt nincs név a zárójelek között. Osztály extensions lehetővé teszi, hogy deklaráljunk kötelezően megvalósítandó metódusokat, az interfész fájlban (.h): @interface MyClass : NSObject - (float)value; Az implementációs fájlban (.m): @interface MyClass () { float value; - (void)setvalue:(float)newvalue; @implementation MyClass - (float)value { return value; - (void)setvalue:(float)newvalue { value = newvalue;
A setvalue metódus megvalósításának a fő @implementation blokkban kell lennie, nem lehet úgy implementálni mintha kategóriában lenne. 2.7 Protokollok A protokollok lehetővé teszik a többszörös öröklődést. Kétféle protokoll van: ad-hoc vagy informális és fordító által szabályozott, vagy formális protokollok. Egy informális protokoll egyszerűen egy metódus lista, amit az osztály implementálhat. A dokumentációban létezik, mivel a nyelvben nem jelenik meg. Ilyenek például az opcionális metódusok, ahol a metódus implementálása az osztály teljes működését befolyásolja. A formális protokoll hasonló a Java interface típusaihoz. Ez egy metódus lista amelyet az osztály felsorol implementálás céljából. A 2.0 Objective-C változatok előtt minden felsorolt metódust implementálni kellett, máskülönben a fordító hibát jelzett, ha az osztály nem implementálta minden metódusát a felsorolt protokollokban. Ez már nem kötelezö a 2.0 változattól kezdődően. A leglényegesebb különbség a Java nyelvvel szemben, hogy egy osztály implementálhatja a protokollt anélkül, hogy deklarálta volna. A különbség a kódon kívül nem látható. Szintaxis: @protocol Locking - (void)lock; - (void)unlock; Ez a protokoll a lock műveletet implementálja, amelyet a következő osztály felhasznál: @interface Osztaly : OsOsztaly <Locking> Ez azt jelenti, hogy az Osztaly implementálni fogja a két metódust a Locking protokollból, ahogyan akarja. Lehetőség van arra, hogy kötelezővé tegyük a protokollt implementálni szándékozó osztályok részére bizonyos metódusok megvalósítását. Erre a @required módosító ad lehetőséget: @protocol Locking @required - (void)lock; - (void)unlock; 2.8 SEL és @selector Minden metódus azonosítható egy selector-ral. A metódus nevével lehet selector-t létrehozni, C logikával a selector tulajdonképpen egy metódusra mutató mutató. Egy ilyen mutatóra az Objective-C nyelvben van egy speciális típus: SEL: SEL setwidthheight; Egy ilyen változónak a speciális @selector hívással adhatunk értéket:
setwidthheight = @selector(setwidth:height:); Vagy akár string-et is megadhatunk az NSSelectorFromString metódusnak: NSString *abuffer = @'metodusnev'; setwidthheight = NSSelectorFromString(aBuffer); Vagy meg is hívhatunk egy metódust: [obj1 performselector:@selector(gossipabout:) withobject:objx]; Ami teljesen megegyezik a következő hívással: [obj1 gossipabout:objx]; Sőt, ellenőrizni is tudjuk, hogy létezik-e egy metódus: if ( [obj1 respondstoselector:@selector(gossipabout:)] )... 2.9 Delegált fejlesztési minta (delegate design pattern) Más programozási környezetből érkezőknek (java, c, c++, delphi) ez a legfurcsább dolog az ios fejlesztésben. A lényegét a következők írják le: szeretnénk egy osztálynak meghívni egy metódusát (üzenetet küldünk az osztálynak), de a meghívott metódus eredményét nem a visszatérési értékében kapjuk meg, hanem a hívó osztály egy metódusát visszahívja a meghívott a hívó osztálynak tehát lesz egy metódusa amit a hívott osztály meghív, ezt hívják úgy, hogy adott protokollt implementál a hívó a hívott osztálynak kell ismernie azt a példányt (a hívót), aki az adott protokollt implementálja, hogy vissza tudja hívni Nézzünk egy példát, mert így talán túl elméleti. Van egy osztály mely webszervizen keresztül képes bejelentkezni, legyen például WSLogin a neve. Ennek az interfész fájljában(h) van az a protokoll definiálva melyet a hívónak kell megvalósítania: @protocol WSLoginDelegate @required -(void) logincompleted: (Session*) session; @interface WSLogin : NSObject -(WSLogin*) initwithdelegate: (id<wslogindelegate>) _del; -(void) login; @property (weak) id<wslogindelegate> delegate; Tehát, a WSLogin osztály konstruktora vár egy paramétert melynek a neve _del, a típusa pedig id<wslogindelegate>, vagyis bármilyen osztály mely megvalósítja ezt a protokollt. A következő interfész példában látjuk, hogyan is lehet ezt megadni Objective-c-ben. @interface PGAppDelegate : UIResponder <UIApplicationDelegate, WSLoginDelegate> -(void) logincompleted: (Session*) session;
Tehát a PGAppDelegate osztály megvalósítja a WSLoginDelegate protokollt, ezért implementálja a logincompleted metódust. Még egy darabka szükséges, melyben a PGAppDelegate osztály meghívja a WSLogin osztály login metódusát, ezt a PGAppDelegate osztály valamelyik metódusába helyezzük el: [[[WSLogin alloc] initwithdelegate:self] login]; A folyamat a következő: 1. a PGAppDelegate létrehoz egy WSLogin példányt, a konstruktorban átadja saját magát (self) és egyben meg is hívja a login metódusát 2. a login metódus elindít egy háttérfolyamatot és azonnal a login metódus hívás utána soron folytatódik a végrehajtás 3. a háttérben futó folyamat amikor végez, meghívja a PGAppDelegate példány logincompleted metódusát 3 ios Az iphone OS, OS X iphone vagy ios annak az operációs rendszernek a neve, amelyet az Apple Inc. fejlesztett ki az iphone, ipod Touch és ipad készülékekre. Mint ahogyan a Mac OS X (amelyből származtatták), a Darwin alapokat használja. Az iphone OS négy fő rétegből tevődik össze: Core OS, Core Services, Media és Cocoa Touch. A teljes operációs rendszer alig 240 MB helyet foglal a készülék adathordozóján. Az operációs rendszernek nem volt neve, amíg az első iphone SDK meg nem jelent 2008. márciusában. Korábban az Apple csak annyit árult el, hogy az iphone OS X-et használ. 2009. június 6-án már több, mint 50 000 alkalmazás volt elérhető az iphone-ra. Az AppStore letöltések száma meghaladta az 1 milliárdot. Az iphone OS felhasználói felülete a multi-touch technológiára alapuló direkt manipulációra alapul. Ez azt jelenti, hogy minden objektumot, mint a valós világban, kézzel mozgatunk, manipulálunk. A felhasználói felületben kapcsolók, gombok, csúszkák vannak. A felhasználó mozdulatai egy természetes interfészt biztosítanak. A készüléknek egy belső gravitációs gyorsulásmérője van, amely az X, Y és Z koordináták irányában eső gravitációs gyorsulást méri. Mikor a készüléket bekapcsolják, egy induló képernyő jelentkezik be ikonokkal és egy "dock" a képernyő alján. A képernyő felső részén a fontosabb információk láthatók: pontos idő, akkumulátor töltöttsége, jelerősség (telefonhálózat és Wi-Fi térerő). A képernyő többi része szabadon használható az alkalmazások által. Nincs meg a kilépés koncepciója, ehelyett vagy megvárjuk, hogy az alkalmazás magától befejeződjön, vagy megnyomjuk a "home" gombot, ami befejezi az alkalmazást. Multitask csak az iphone belső processzeinek megengedett, a felhasználók alkalmazásai nem futhatnak a háttérben. Azonban több szálas alkalmazások futhatnak.
Az iphone és ipod Touch fő processzora egy ARM processzor, ellentétben a Macintosh Intel vagy PowerPC architektúrájával. 3D grafikához OpenGL ES-t használ amelyet a Power VR videokártya biztosít. A Mac OS X alkalmazások nem másolhatóak rá egyenesen az iphone-ra (még akkor sem, ha Cocoa alapúak), hanem specifikusan iphone-ra kell őket átírni és lefordítani (ehhez az Xcode fejlesztőcsomagot használjuk). Az iphone-on futó Safari böngésző webalkalmazások futtatására is alkalmas. Független fejlesztők az AppStore-on keresztül értékesíthetik az alkalmazásaikat. 3.1 Gyári alkalmazások A 4.0-ás verzióban a következő szoftverek vannak telepítve: Messages (SMS küldés-fogadás), Calendar, Photos, Camera, YouTube, FaceTime, Stocks, Maps, Weather, Clock, Calculator, Voice Memos, Notes, Settings, itunes, App Store, Contacts, Game Center. Négy másik alkalmazás a lényegi funkcionalitását adja a készüléknek: Safari böngésző, Mail, Telefon funkció és az ipod. Az iphone és ipod Touch közti különbség csak annyi, hogy hiányzik a telefon, SMS/MMS funkcionalitás. Az iphone "ipod" alkalmazása zenét és videót is le tud játszani. 2007-ben az Apple a WWDC-n bejelentette, hogy az iphone és ipod touch a Safari böngészőben webalkalmazások futtatását is lehetővé teszi, mint például az AJAX hívások. 3.2 Liszensz politika Az SDK ingyenesen letölthető, de ahhoz, hogy valaki közvetlenül az eszközön tudjon tesztelni, és szoftvert adjon ki, az iphone Developer Program tagja kell legyen, amihez az Apple engedélye is szükséges. Minden programhoz egy kulcs is tartozik, amit csakis az Apple webapplikációin keresztül lehet generálni. Három módja van az alkalmazások feltöltésének: az App Store révén belső terjesztés a fejlesztő cégen belül és egy Ad-hoc alapon, ami maximum 100 iphone készülékre engedi feltölteni. Ez a terjesztési modell lehetetlenné teszi a GPL licenccel gyártott alkalmazások terjesztését, mivel a kulcsokat nem terjesztheti tovább (ez az Apple tulajdona), így az esetleges változtatásokat nem lehet továbbvinni. 3.3 Apple elvárások AppStore-ba töltéshez Az AppStore "ellenőrök" sok mindent vizsgálnak egy programon mielőtt azt az AppStore-ban elérhetővé tehetjük. Például olyasmiket is kifogásolhatnak, hogy túl keveset tud a program, elüt az Apple minőségfilozófiájától. Ezek után el lehet képzelni, hogy milyen alapos az AppStore ellenőrző rendszer. Ha gördülékennyé akarjuk tenni az AppStore-ban történő megjelenést, akkor ezen oldalon található információkat tanulmányozzuk alaposan: https://developer.apple.com/appstore/guidelines.html
Például az XCode programban van egy Product/Analyze menüpont melynek lefuttatásakor nem lenne szabad semmilyen üzenet kapni, az AppStore ellenőrzés első lépései között van ennek vizsgálata. 4 Bevezetés az ios platform programozásába Mindenképp érdemes először 2 tutorialt végigcsinálni, az egyik a First ios application a másik a Second ios application, és XCode-ban az Organizer Documentation részében keressünk rá. A fejlesztőeszköz az XCode nevű program, melyet az AppStore-ból tudunk telepíteni. 4.1 XCode tippek Az XCode használata közben van néhány dolog mely eléggé el van dugva az interneten. És amíg nem találunk rá okozhat némi fejtörést. 4.1.1 #pragma mark Az összes példaprogramban amit az XCode help rendszerből töltünk be találunk ilyen sorokat a forráskódokban. Az érdekessége az, hogy nem az ios-nek, nem a fordítónak szól, hanem az XCode-nak, a következő képen látszik, hogy a lenyíló metódus lista menüt tudjuk szekciókra osztani ezekkel a #pragma mark sorokkal: Azért érdemes tudnunk, hogy a #pragma másra is használatos Objective-C nyelveben, de nekünk nagy valószínűséggel nem lesz rá szükségünk. Részletesebb információk:
https://developer.apple.com/library/mac/#documentation/developertools/conceptual/cpprunt imeenv/articles/symbolvisibility.html 4.1.2 Analyze Az AppStore-ba alkalmazást bejuttatni nem egyszerű művelet, ez a menüpont nyújt némi támogatást azzal, hogy a program teljes kódját egy alaposabb vizsgálatnak veti alá és forduló és jól működő részekben is képes problémákra felhívni a figyelmet: A képen látszik, hogy igen látványosan próbál megmutatni egy Logic Error néven illetett problémát. Az esetek többségében ezek javítása nem kis ráfordítást igényel. 4.1.3 Hivatkozások (included by) Eclipse-t használó fejlesztőként nagyon hamar felmerül a kérdés, hogy a jól megszokott Referenced by funkció hol található vagyis honnan tudom, hogy az osztályomat hol használják a kódban. Erre a program szerkesztő ablak bal felső sarkában található ikonra kattintáskor megjelenő menüben találunk 2 menüpontot az Includes és Included By utána zárójelben számok, hogy hányat talált az XCode. Az Includes azt mutatja meg, hogy az adott fájl milyen #include-okat tartalmaz. Az Included By pedig azt mutatja meg, hogy melyik másik fájlok includjában szerepel az adott fájl. Tehát a h és az m fájlon állva más és más lehet a menü tartalma.
4.1.4 Outlet-ek, action-ök Ahhoz hogy a kódból elérjünk egy GUI elemet IBOutlet típusú hivatkozást kell készítenünk a h fájlba. Erre több módszert is nyújt a Storyboard editor. Az egyik lehetőség, hogy a GUI elemet kiválasztva, jobb oldalt utolsó ikon (Connections inspector) panelen a kapcsolatokat láthatjuk, és innen a megfelelő sorból a kis jobb oldali kört drag&drop módszerrel dobjuk bele a forráskódba. Ekkor egy kis feljövő ablakban megadhatjuk a főbb paramétereit az IBOutletnek vagy az IBAcion-nek, majd a Connect gombra kattintás után a képen látható állapotba jutunk. A képen figyeljük meg, hogy a fában a Button - Guide van kiválasztva a program kódban az IBOutlet UIButton *butguide és jobb oldalt a Connections inspector-ban alul a butguide - Grid Controller kapcsolat látható Az interneten nagyon sok videót és tutoriált találni a témában, a következő linken egy nagyon jó leírás van az outletek kezeléséről: http://klanguedoc.hubpages.com/hub/ios-5-a-beginners-guide-to-storyboard-connection 4.2 iphone emulátor Az XCode telepítésével kapunk egy nagyon jó emulátort iphone és ipad fejlesztéshez. Pár eltérést biztosan tapasztalunk majd de összességében gyors és hiteles az emulátor. Egy érdekességet tapasztaltunk a fejlesztés során. Ha egy programot fektetett módban indítunk az emulátorban, akkor nem hívódik meg a willanimaterotationtointerfaceorientation viszont egy valós iphone ios-e meghívja ezt.
4.3 C o m p i l e, k és beállításaik Az XCode linker részén általában semmit sem kell állítani, csak ha valami extra dolgot használunk. Esetünkben a webszerviz hívások miatt egy XML feldolgozót használunk melyet linkelni kell a programhoz. l i n 4.4 F e l h a sználói felület Leírásokban szokták emlegetni az IB eszközt, ami az Interface Builder, vagyis az a komponens, amivel a felhasználói felületeket lehet készíteni. Régebbi verziókban ez (és még pár másik alkalmazásfejlesztői eszköz is) külön program volt. Mára integrálódtak az XCodeba. Az IB-vel készített fájlok kiterjesztése xib, ezek xml-ben tartalmazzák a képernyő leírását, más helyeken nib-nek is hívják. Az Apple legújabb fejlesztése a storyboard megjelenése volt. A storyboard editor is az XCode 4-ben található. Az Apple készített egy dokumentumot melynek címe ios Human Interface Guidelines. Ebben a dokumentumban az alkalmazás dizájn stratégiától a megfelelő képek elkészítésének elméletéig mindenről van szó. Ez és az ilyen dokumentumok elolvasása nemcsak hasznos, hanem egyben előrevetíti az AppStore-ba feltölteni szándékozott alkalmazásokkal szemben támasztott követelményeket is. Például - hogy a dizájnnál maradjunk - az Apple szerint az iphone-on jól megérinthető könnyen "eltalálható" grafikai elemek (gombok) minimális mérete 44 pixel a 320 széles, 480 pixel magas képernyőn.
A képernyő rajzoló eszközökkel készített fájlok feldolgozása futásidőben történik, tehát a storyboard fájl átmásolódik az iphone-ra az alkalmazás csomagjában (ipk). Majd amikor a programot elindítjuk az ios felolvassa, értelmezi, végrehajtja a gui megjelenítését, osztályok példányosítását. Viszont látszólag triviálisnak látszó dolgok sem biztos, hogy megtörténnek ilyenkor. Például ha mindent jól beállítunk a storyboard-ban, hogy képernyő elforgatáskor minden a megfelelő módon méreteződjön át, de ez mégsem történik meg, akkor a storyboardban látható view hierarchiát az osztályunkban is fel kell építeni. Vagyis ha egy view benne van a másikban (child view), akkor a tartalmazó view-hoz az addsubview metódussal hozzá kell adni az általa tartalmazott view-kat: [parent addsubview:childview]. 4.5 Webszervizek Java környezetben könnyen lehet webszerviz klienst generálni, erre több megoldás, több keretrendszer is létezik. ios környezetben ezt a http://sudzc.com/ weboldalon tehetjük meg, ahova egy wsdl-t lehet feltölteni, majd be kell állítani a generált kód típusát (Objective-C with ARC). A végeredmény egy zip fájlban töltődik le. Minden generált zip fájlban van Soap és TouchXML könyvtár, ezt elég egyszer a projektünkbe építeni. 4.6 Alkalmazás logika Minden alkalmazásban kell lennie egyetlen osztálynak melynek interfésze kb így néz ki: @interface OsztályNeve : UIResponder <UIApplicationDelegate> Ha az alkalmazás fejlesztés kezdetekor az XCode-dal hozzuk létre a projektet, akkor egy ilyen osztályt automatikusan létre is hoz. Ez lesz az ugynevezett application delegate osztály vagy röviden AppDelegate. Ebből az alkalmazásban egy példány jön létre (singleton). Az operációs rendszer, az ios, ezzel az osztállyal tudatja, hogyha például az alkalmazás futását meg kell szakítani (background), mert épp van egy bejövő hívás a telefonra. Vagy például azt is, hogy most az előtérbe került az alkalmazás (foreground). Az ios rendszer egy másik érdekessége, hogy konzekvensen minden metódusnak teljes neve van, nincsenek rövidítések a rendszerben. Például az előző bekezdésben említett 2 esemény bekövetkezésekor az ios az application delegate osztály következő metódusait hívja meg: applicationdidenterbackground applicationwillenterforeground A metódusok nevében szinte mindig szerepel a will vagy a did szócska, ezzel jelezve, hogy az esemény előtt vagy az esemény után hívódik meg a metódus. Egy képernyő megjelenése közben 12-16 metódus is meg tud hívódni. Persze nem mindet kell implementálni, csak amik esetében mást szeretnénk futtatni mint az alapértelmezett. A dokumentáció minden metódus esetében megadja, hogy az ősosztály (super) metódusát meg kell-e hívni vagy sem, ezt mindenképp be kell tartanunk a helyes működés érdekében. Az általában igaz, hogyha valami megvalósítása csak nagyon nehezen megy, akkor azt az ios tervezői nagy valószínűséggel máshogy képzelték el, és a program ezen az erőltetett módon megvalósított része lassú és/vagy instabil lesz.