A MOBIL ALKALMAZÁSFEJLESZTÉS ALAPJAI SUMMARY OF THEOREM PPKE ITK, December 16, 2016
Written by
Komporday András
2016
Contents
1 Az OOP alapelvei 1.1
1.2
3
A valós világ modellezése . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1.1
OOP alapelvek . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.1.2
OOP működési elvárások . . . . . . . . . . . . . . . . . . . .
4
1.1.3
OOP alapfogalmak . . . . . . . . . . . . . . . . . . . . . . .
5
Az objektum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.1
Mezők és metódusok . . . . . . . . . . . . . . . . . . . . . .
6
1.2.2
A szerver-kliens modell . . . . . . . . . . . . . . . . . . . . .
6
2 Programozási minták 2.1
2.2
7
A minták fajtái . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.1
Létrehozási minták . . . . . . . . . . . . . . . . . . . . . . .
8
Programtervezési paradigmák . . . . . . . . . . . . . . . . . . . . .
9
2.2.1
Model-View-Controller . . . . . . . . . . . . . . . . . . . . .
9
2.2.2
Model-View-Presenter . . . . . . . . . . . . . . . . . . . . .
9
2.2.3
Model-View-ViewModel . . . . . . . . . . . . . . . . . . . .
9
3 Tesztelés és programtervezés 3.1
10
A tesztek fajtái . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1
Funkcionális tesztelés . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2
Struktúrateszt . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3
OOP teszt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1
3.1.4
Inspekció
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.5
Terhelési tesztek . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.6
Test Driven Development, Extreme Programming . . . . . .
11
3.1.7
Terminológia . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4 Mobil alkalmazások 4.1
12
A technológiák előnyei és hátrányai . . . . . . . . . . . . . . . . . . 12
5 Android
13
5.1
Az Android felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2
Az Android projectfolyamat . . . . . . . . . . . . . . . . . . . . . . 14
5.3
Az Android-fejlesztés eszközei . . . . . . . . . . . . . . . . . . . . . 15
5.4
5.3.1
Android Debug Bridge . . . . . . . . . . . . . . . . . . . . . 15
5.3.2
Az Android project szerkezete . . . . . . . . . . . . . . . . . 16
Az Actvity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4.1
5.5
Az Activity életciklusa . . . . . . . . . . . . . . . . . . . . . 17
Az Android GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.5.1
Az elrendezés . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5.2
Néhány GUI elem: . . . . . . . . . . . . . . . . . . . . . . . 19
5.6
Felhasználói interakció . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.7
Egyedi View, Toolbar, Fragment . . . . . . . . . . . . . . . . . . . . 20 5.7.1
Egyedi View definiálása . . . . . . . . . . . . . . . . . . . . 20
5.7.2
Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.7.3
Fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2
6 iOS programozás
21
6.1
Az iOS felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2
Objective-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7 Adattárolás 7.1
7.2
1
24
iOS módszer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1.1
Core Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1.2
Az Adatmodell . . . . . . . . . . . . . . . . . . . . . . . . . 25
Android módszer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2.1
Shared preferences . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.2
Internal Storage . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.3
External Storage . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.4
Adatbázis használata . . . . . . . . . . . . . . . . . . . . . . 25
7.2.5
Backup
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Az OOP alapelvei
1.1
A valós világ modellezése
Az OOP a valós világot kívánja modellezni a követező alapelvek alapján: • Absztrakció: a valós világ leegyszerűsítése, hogy csak a cél eléréséhez feltétlenül szükséges részletekre koncetrálunk. • Megkülönböztetés: az objektumok a valós világ egy-egy önálló egységét jelölik, és a számunra lényeges tulajdonságaik alapján különböztetjük meg őket. • Osztályozás: a hasonló tulajdonságokkal rendelkező objektumokat osztá3
lyokba soroljuk. Az objektum-osztályok hordozzák az objektumok tulajdonságait, az objektumok mintáinak tekinthetők. • Általánosítás, specializálás: az objektumok között állandóan különbségeket és hasonlóságokat keresünk, hogy bővebb, vagy szűkebb kategóriákba sorolhassuk őket. 1.1.1
OOP alapelvek
• Dinamikus kötés: egy objektum esetén futási időben dől el, hogy egy metódus melyik implementációja kerül futtatásra. OOP-ben: az a jelenség, melynek során futási időben dől el, hogy egy objektumon a statikus típus által definiált műveletet meghívva, a statikus vagy a dinamikus típus implementációja fog-e lefutni? Csak akkor jön létre, ha van felüldefiniált (nem túlterehelt) metódus az alosztályban. • Egységbe zárás: az adatok és a rajtuk végrehajtható műveletet egységet alkotnak (modern típusdefinícióval kozisztens). • Altípusos polimorfizmus: egy rögzített típusú változó a típus altípusainak példányaira is mutathat. – Statikus típus: a deklarációnál használt típus. – Dinamikus típus: a véltozó által mutatott objektum tényleges típusa. A dinamikus típus vagy megegyezik a statikussal, vagy annak egy leszármazottja. – A statikus típus állandó, dinamikus változhat a program futása során. • Öröklődés, delegáció: egy adott osztályból lehetőség van képezni egy másik osztályt: ez módosíthatja, bővítheti az eredetit. Az osztály adattagjait, metódusait felhasználva, új funkciókat vezet be. Tervezési szintű lépés. Is-A reláció. • Nyílt rekurzió: speciális változó, mely egy metódus esetén elérhetővé teszi az aktuális példányt (pl. this, self ) 1.1.2
OOP működési elvárások
• Egységbezárás
4
• Információ elrejtése: az objektum belső állapotát csak egy interjace-en keresztül lehet megközelíteni. • Kód újrafelhasználhatóság: példányok létrehozásával, vagy osztály továbbfejlesztésével. 1.1.3
OOP alapfogalmak
• Objektum: valós fogalmak, objektumok reprezentációja, modellje. • Objektumosztály: Hasonló objektumok csoportja, sablon, minta a létrehozásukhoz. • Metódus: egy objektum állapotát befolyásoló, manipuláló függvény, eljárás. • Mező: egy objektum tulajdonságát meghatározó változó. • Üzenetküldés: objektumok interakciója, definiált interface-eken keresztüli kommunikáció. • Absztrakció: osztályok csoportosítása hierarchiába, implementációs tervezési eszköz. Megvalósítása az absztrakt osztály: ezek a tervezés eszközei, generalizálást, általánosítást tesznek lehetővé.Hiányosan definiált osztály, vannak benne olyan funkciók, melyek nincsenek implementálva, azt a leszármazottakra bízzuk. • Túlterhelés (Overload): két azonos metódus, különböző szignatúrával. A különbség a (kimenő vagy bemenő) paraméterek száma vagy típusa. • Felüldefiniálás (Override): A leszármazott osztály azonos névvel és szignatúrával bevezet egy függvényt. A különbség az elfedéstől, hogy itt létrejön a dinamikus kötés (az alosztály és a szülőosztály között). Vannak nyelvek, ahol jelezni kell. • Elfedés: a leszármazott osztály azonos névvel és szignatúrával bevezet egy új függvényt. Csak akkor felüldefiniálás, ha dinamikus kötés nem jön létre. Mezők és változók is fedhetik egymást adott programblokkon belül, vagy leszármazott osztályokban.
5
1.2
Az objektum
Az objektum dfiniált, információt tartalmazó belső állapottal rendelkezik, mely állapotot saját metódusai megváltoztathatják. Feladatokat hajt végre, üzenetekkel kommunikál más objektumokkal. Egyértelműen azonosítható. Az objektumoknak életciklusa van: • Létrejön (konstrukció, inicializáció), ekkro beállítódnak a kezdő értékei, típusinvariánsa. Végrehajtódnak a működéséhez szükséges tevékenységek. • Működik • Megszűnik: ekkor felszabadulnak az erőforrások. 1.2.1
Mezők és metódusok
Az objektumok rendelkezhetnek mezpkkel és metódusokkal, melyek lehetnek objektum- és osztályszíntűek. Az objektumszintű metódusok az aktuális objektum állapotait tárolják, míg az osztályszíntűek az osztályhoz tartozú összes objektumra érvényesek. A metódusoknál ugyanígy az objektumszintűek az egyes példányokon dolgoznak, míg az osztályszíntűek az osztályokon. Az objektumok indíthatnak export és import műveleteket: az exportműveleteket más objektumok hívják (pl. getterek), az importműveletekkel pedig az objektum igényel az export szolgáltatásaihoz szükséges információt. Az objektumok műveletei emellett lehetnek létrehozó (konstruktor), állapotmegváltoztató, szelektor (kiemeli az objektum egy bizonyos részét), kiértékelő (getterek) és iterátor műveletek (bejárásokhoz). 1.2.2
A szerver-kliens modell
Kliens: aktív objektum, más objektumokon végez műveleteket, de nincs export felülete (gettere). Szerver: passzív objektum, csak exportműveletei vannak, nem módosít más objektumokat. Nincs import felülete. Ágens: általános objektum, van import és exportfelülete is.
6
2
Programozási minták
A tervezési minták egymással együttműködő objektumok és osztályok leírásai, amelyek testreszabott formában, valamilyen általános tervezési problémát oldanak meg. OOP programnyelvek (C++? Java, Smalltalk, stb.) esetén néhány a nyelvben alapértelmezetten implementálva van (Öröklődés, Egységbe foglalás, Polimorfizmus).
7
2.1 2.1.1
A minták fajtái Létrehozási minták
• Abstract Factory: Interface biztosítása konkrét osztályok megadása nélkül. • Builder • Factory Method: Alosztályra átruházni, hogy miként kerüljön létrehozásra az objektum. Pl. egy framework többféle dokumentumot tudjon megjeleníteni az alkalmazás fajtája szerint. Megvalósítás: létrehozó absztrakt osztály, létrehozó konkrét osztály, paraméterezett gyártófüggvény. • Prototype • Singleton: egy osztályból csak egy példány létrehozását megengedni, és ehhez globális hozzáférési pontot biztosítani. Szerkezeti minták az adott osztály • Adapter: interface-ét az ügyfelek által igényelt interface-szé alakítani. Tehát biztosítani két nem kompatibilis interface együttűködését. • Bridge • Composite: az objektumok faszerkezetbe rendezés, hogy az önálló objektumokat és az objektumösszetételeket egységesen tudjuk kezelni. Pl. grafikus alkalmazásban az alapelemek, illetve az alapelemek csoportosításával létrehozott összetett elemek kezelését 8 egységesíteni. • Decorator
• Facade • Flyweight • Proxy: egy adott objektumot egy "képviselőn" keresztül irányítani. Akkor használható, amikor egy egyszerű objektum mutatónál rugalmasabb, kifinomultabb hivatkozás szükséges. Fajtái: távoli, virtuális, védelmi, smart (pl. referenciaszámlálás). Viselkedési minták • Chain of Responsibility • Command • Delegate: egy adott objektum egy feladatát nem hajtja végre, hanem azt egy másik objektumnak (akár segédobjektumnak) adja tovább. Az objektum végrehajtási felelőssége is továbbadódik. • Interpreter • Iterator • Mediator • Memento • Observer: objektumok közötti 1:n függőségi kapcsolat. Amikor a megfigyelt objektum megváltozik, minden tőle függő objektum értesül erről és automatikusan frissül. • State • Strategy • Template Method • Visitor
2.2
Programtervezési paradigmák
Léteznek komplex szerkezeti programozási paradigmák, melyek a teljes program felépítését meghatározzák. 2.2.1
Model-View-Controller
Ebben a paradigmában a Model az információk megjelenítésért felelős: logikai jelentést ad az adatnak. Általában része az adatelérési réteg. A View (Nézet) megjeleníti a Modelt egy felhasználói interakcióra alkalmas felületen. Jellemzően GUI. Különböző célokra különböző View-k létezhetnek ugyanazon Modelhez. A Controller (Vezérlő) feldolgozza az eseményeket (pl. felhasználói műveleteket), válaszokat küld és módosíthatja a Modelt. A vezérlés menete kb. ilyen: a felhasználó csinál valamit a View-n, ezt a Controller feldolgozza, ha szükséges, frissíti a Modelt. A View a frissített Model alapján frissíti a felhasználói felületet is. A Model-View kapcsolat egyirányú, ahol csal a View létja a Modelt. 2.2.2
Model-View-Presenter
Ebben a típusban a Model ugyanazért felel, mint az MVC-ben, a View pedig a felhasználói interakció fogadása után tovébbítja azokat a Presenter felé. Két fajtája van: a Passive View, ami minden feladatot átad a Presenternek és a Suprevisor View, ami bizonyos feladatokat (amik a program szempontjából lényegtelenek) elvégez maga. A Presenter a két másik réteg között helyezkedik el, itt található a folyamatvezérlés. Feladata az adatok konverziója és továbbítása a Model és a View között. 2.2.3
Model-View-ViewModel
A Microsoft MVC-forkja. Eseményvezérelt működésre tervezték. A Model ugyanaz mint eddig, a nézet pedig ugyanaz, mint az MVC-ben. A ModelView lényegében a View Modelje, egy speciális Controller, ami közvetít és konvertál a Model és a View között. Nyilvános tulajdonságokat, parancsokat és absztrakt felületeket biztosít. Az adat koncepcionális állapotát reprezentálja a Modelben lévő valós adattal szemben.
9
3
Tesztelés és programtervezés
A szoftver verifikációjának és validációjának célja a rendszer hibáinak felfedése, meggyőződni arról, hogy a rendszer egy-egy konkrét szituációban a specifikáció szerint működik. Az a sikeres teszt, ami legalább egy hibát felfedez.
3.1 3.1.1
A tesztek fajtái Funkcionális tesztelés
A program fekete doboz, a tesztesetek a specifikáció alapján készülnek. Nem érdekel az implementáció, így már a fejlesztés korai szakaszában elkezdődhet. 3.1.2
Struktúrateszt
A tesztek a program struktúrájának és implementációjának ismeretében készülnek. Ezek ismeretében új ekvivalencia-osztályok definiálhatók. A tesztelő a tesztesetek készítésekor elemzi a kódot, hogy biztosítsa minden utasítás legalább egyszeri végrehatását. 3.1.3
OOP teszt
A komponens-és integrációs tesztelés OOP rendszereknél is alkalmazható. Különbségek: a tesztelendő objektumok komponensként gyakran nagyobbak, mint az egyszerű függvények. Az objektumok lazán kütődnek, a rendszernek nincs egyértelmű teteje. Az újrafelhasznált komponensek forráskódjához nem lehet mindig hozzájutni. 3.1.4
Inspekció
Célja a hiányosságok felderítése, a hibák kb 60%-a felfedhető a kód átvizsgálásával. Egy átvizsgálás során több hiba felfedezhető, míg egy teszt tobbnyire egy hibát fed fel. Nem helyettesíti a tesztelést, de sok költséges tesztet előzhet meg.
10
3.1.5
Terhelési tesztek
A rendszereket a tervezettnék nagyobb terhelésre is tesztelni kell. Addig kell növelni a terhelést, amíg a rendszer hibázik, vagy a teljesítménye elfogadhatatlanná válik. A terhelési tesztek feladata, hogy szélsőséges körülmények között tesztelje a rendszer viselkedését. A túlterhelés nem okozhat adatvesztést, vagy szolgáltatások teljes eltűnését. Olyan hiányosságokat fedhet fel, melyek normál esetben nem okoznak rendszerhibát. Különösen fontos az osztott rendszereknél, ahol a koordinációs adatokkal túlterheli a hálózatot. A teszteket a program tervezésévek párhuzamosan kell tervezni. A program minden komponensét egyenként, illetve az összeset egységben is le kell tesztelni. 3.1.6
Test Driven Development, Extreme Programming
Agilis módszer, manapság népszerű. Lényege, hogy először a teszteket írják meg, és úgy készítik a programot, hogy a fejlesztés minden szakaszában a teszteknek megfefelően működjön. Ha egy kódhoz nincs automatizált teszt, akkor hibásnak tekintük. Az XP egy TDD-t és más gyakorlatokat is magába foglaló módszertan, mely több praktika (code refactoring, inspeció, TDD, stb.) kombinálásával próbálja meg megalkotni a leghatékonyabb szoftverfejlesztési folyamatot. 3.1.7
Terminológia
• Test fixture: tartalmazza az adatokat, melyek a teszt végrehajtásához szükségesek. • Unit test: egyszerű osztályok halmaza. • Test case: teszteli egy függvényre adott válaszokat egy bizonyos, meghatározott bemenet eseté. • Test suite: Test case-ek gyűjteménye. • Test runner: egy szoftver, mely a teszteket futtatja, valamint az eredményekről összefoglalót hoz létre. • Integrációs teszt: ellenőrzi, hogy az egyek osztályok milyen módon dolgoznak együtt.
11
4
Mobil alkalmazások
A mobil alkalmazások fajtái átjárhatóság szerint: • Mobil weboldal • Webalkalmazás • Hibrid alkalmazás • Keresztplatform alkalmazás • Natív alkalmazás
Figure 1: A mobil alkalmazások áttekintése
4.1
A technológiák előnyei és hátrányai
• HTML5: több platformon azonnal elérhető eredmény, a felhasználó számára könnyebben hozzáférhető. Webes ismeretekkel fejleszthető. Egyszerűbb terjeszteni a frissítéseket. Alacsonyabb fejlesztési költség és nagyobb gyorsaság. Nem igényel platformonként különleges szaktudást. • Natív: Eszközspecifikus képességek kihasználhatók.Nagyobb teljesítmény és biztonság. Magasabb felhasználói élmény. Az alkalmazhatóság alkalmazástól függ: szükséges erőforrások, képességek, igények alapján. 12
5
Android Android Egy Google által kezelt szoftver csomag: Linux kernel + Android WM + Egyéb alkalmazások
Működési környezete: Sok gyártó sok hardverén fut: eltérő képességek, eltérhetnek a specifikációtól. ARM alapú, de van x86 és Intel port. Főbb jellemzők: • Teljesen moduláris • Multitasking, automatikus memóriakezelés, sok beépített programkönyvtár • GSM, LTE, stb. támogatás (mobilcomm rendszerek) • WiFi, Bloetooth, NFC • Szenzorok: GPS, Triax, gyorsulás, mágneses mező, hőmérő, fénymérő, stb. • Kamera, média (felvétel, lejátszás) • HDMI, 2D, 3D gyorsítás, párhuzamosítás
5.1
Az Android felépítése
Több szoftver együttesen: • Middleware • Core alkalmazások • OPrendszer
13
Rétegei: • System Apps: email-kliens, SMSkliens, Telefonkönyv, Calendar, stb • Java API Framework: nyílt platform fejlesztőknek. gyors, hatékony fejlesztés, nagy szabadság. Testreszabható. • Native c/C++ Libraries / Android Runtime: – Android Runtime: minden app külön folyamat az ART VMben. ART + Core Libraries (megmaradt Java csomagok) – App Frameworkön keresztül használható: Media Framework, Webkit, OpenGL, OpenAl, OpenMax, SQLite, NDK komponensek.
Figure 2: Az Android felépítése
Abstraction Layer • Hardware (HAL): hardverek feletti réteg, a fölötte levők számára elfedi a hardverkülönbségeket. Architektúra-és eszközfüggő kód. • Linux Kernel: Minden alapja, hardver és szoftver között. Memória, energia és hálózatkezelés. Driverek. 3.4-es Linux kernel alapon.
5.2
Az Android projectfolyamat
Általában Java nyelven fejlesztik (lehet mással is). Bájtkódra fordul, az Android VM (ART vagy Darvik) értelmezi. Felépítése: forráskód + resource-ok (pl. képek, XML-ek) + AndroidManifest (az alkalmazás összefoglalója) = .apk + digitális. Ezt az APK-t tudjuk futtatni.
14
Figure 3: Android projectfolyamat
5.3
Az Android-fejlesztés eszközei
• Android Studio • Android SDK • Android NDK 5.3.1
Android Debug Bridge
A fejlesztőgép és a mobileszköz kommunikációját biztosítja. Kliens-szerver megközelítés: a kliens egy parancssori alkalmazás, a fejlesztő gépen fut. Az IDE-k általában elfedik. A szerver a kommunikációt vezérli kliens és démon között. A démon az eszközön vagy az emulátorban fut a háttérben. A kommunikáció az 5555-5585 portokon megy, eszközönként két porttal: konzol és ADB kapcsolat. A szervez az 5037-es porton allgat. A fejlesztéshez szükséges továbbá egy valós vagy virtuális mobileszköz. Ha valósat használunk, be kell állítani a drivereket és az USB hibakeresést, míg virtuális eszköznél be kell állítani egy emulátort. Ezt az AVD Manager(Android Virtual Device Manager) segítségével tehetjük meg: minden testreszabható, az AVD (a virtuális eszköz) saját tárhellyel rendelkezik. Nem szimulál, hanem valóban bebootol az Android rendszer.
15
5.3.2
Az Android project szerkezete
• .idea: az IntelliJ beállítások • app: az alkalmazásmodul fájljai – build: a lefordított program Több API-szintnek megfelelő lehet. – libs: saját felhasznált programkönyvtárak – src: androidTest: a teszteket tartalmazza main/java: a Java küdok main/jni: az NDK/JNI kódok main/assets: eredetileg üres, a resource-okat (pl. képek) tartalmazza main/res: anim - animációk, drawable - képek, layout - elrendezés XML-ek, menu - a menü gombra megjelenő felületek definiálása, raw - minden nyersanyag (mp3, mp4, avi, stb), values: nyelvli (szöveg) fájlok ∗ main/AndroidManifest.xml: minden fontos infó az appról: részei, követelmények, kompatibilitás, jogosultságok, feladat. ∗ ∗ ∗ ∗ ∗
• gradle: a Gradle Wrapper helye • build.gradle: projectleíró a Gradle-nek • gradle.properties: Gradle paraméterek • gradlew: OS specifikus Gradle szkript • local.properties: számítógépfüggő beállítások • .iml: az IDEA modul információi • settings.gradle: a Gradle tool beállításai 5.4
Az Actvity
Az alkalmazás legfontosabb része, egy tevékenységet (képernyőt) ír le. Egy alkalmazás sok Activityből állhat. Az android.app.Activityből osztály leszármazottja. Feladatai: • Kapcsolattartás a felhsználóval 16
• GUI kezelése • Funkciók végrehajtása 5.4.1
Az Activity életciklusa
Az Activity életciklusának szakaszai különböző fügvényekben történnek, ezeket a függvényeket nekünk felül kell definiálni, de kötelező meghívni a szülőosztály implementációját (super.onValami()). Ezek a függvények automatikusan hívódnak meg a program futása során, egyébként kivétel dobódik. Az életciklus függvényei: • onCreate(): amikor először, vagy teljesen nullázott állapotból indul el az Activity. A GUI változók beállítása. • onStart(): amikor az Activity láthatóvá válik a felhasználónak. • onResume(): a felhasználó elkezdheti használni az appot. • onPause(): amikor az Activity részben látszik, vagy többablakos megjelenítésnél, amikor nincs fókuszban. Itt kell elmenteni az adatokaz, ez az utolsó, ami biztos lefut. Gyorsan le kell fusson, hogy a következő Activity felugorhasson. • onStop(): amikor már nem látszik. Pl. hívás, screen lock stb. esetén. • onDestroy(): finish() függvény meghívása esetén. Törli az Activityt. Ha gyorsan kell a rendszernek a memória, meghívódik. A szükséges változók null -ra állítása történjen meg itt.
Figure 4: Android Activity életciklusa 17
5.5 5.5.1
Az Android GUI Az elrendezés
A Layout (Elrendezés) határozza meg a GUI elemek elhelyezkedését a képernyőn. Minden layout a View osztályból származik. Kétféleképpen adható meg, statikus módon: a res/layout mappában az XML fájlok definiálásával, valamint dinamikus módon: a Java forrásfájlokban, programkóddal megadva. A GUI elemek attribútumai: • id: opcionális, de ezzel hivatkozhatunk az elemre. • layout_width, layout_height: kötelező megadni (egyébként kivétel dobódik), megvalósulását a többi megjelenő objektum befolyásolhatja. Lehet: wrap_content: ameddig a tartalom igényli, fill_parent: minden rendelkezésre álló helyet kitölt, és fix méretű: dp (felbontásfüggetlen pixel) megadásban. • gravity: mint a szövegszerkesztőkben az igazítás: left, right, bottom, center (vízszintesen és függőlegesen középre). • layout_weight: priority-t lehet megadni, a kisebb értkűek nagyobb helyet foglalhatnak el. • visibility: visible, illetve invisible - helyet foglal, de nem látható vagy gone helyet sem foglal. • padding: hézag az elemek között • background háttér: drawable vagy szín. • Vannak attribútumok, melyek a szülő ViewGroup osztályától függenek. A GUI elemei: A GUI widgetekből épül fel: View és ViewGroup elemek fába rendezve. A ViewGroup a View olyan leszármazottja, melynek gyermekei lehetnek (további elemeket tartalmazhat). Ezek hierarchiája adja az Activity felhasználói felületét. Van sok előre definiált, de írhatunk sajátot is (megfelelő osztályból leszármaztatva). A View hierarchiában egy gyökérelem van, a setContentView metódussal lehet beállítani (onCreate()-ben!). A kirajzolás a gyökértől indul, lefele gyűrűzik (a levelek rajzolódnak legfelülre) és minden ViewGroup felelős a gyermekei kirajzolásáért (Összetétel minta). ViewGrouphoz gyermeket az addView(View) metódussal adhatunk. 18
5.5.2
Néhány GUI elem:
Layoutok
View-k:
• LinearLayout
• MapView
• RelativeLayout
beépített böngésző, • WebView: webes tartalom megjelenítésére.
sorokból áll • TableLayout: (TableRow ), a sorok View elemeket tartalmaznak egyás mellett (azok az oszlopok). A leghosszabb sor határozza meg az oszlopok számát. Az oszlopszélességet is a leghosszabb határozza meg. • GridView: rácsos elrendezés, ListAdapter kell hozzá. Automatikusan végja a tartalmat. Adapteres megjelenítés: Adapter->getView() - optimális erőforráskihasználás miatt. Csak akkor jön létre, ha meg kell jeleníteni a View-t. • ListView: szekvenciális adatszerkezet megjelenítésére (ebben tárolja a list elemeit). Ahogy görgetjük, a kikerülő View-k a bekerülő oldalon újra felhasználódnak. • FrameLayout: alapvetően egyetlen elem megjelenítésére, de gravityvel és paddinggal le lehet helyezni többet is. Ezek alapértelmezetten egymásra pakolódnak. Adapter: interface, összekapcsolja az adatot a megjelenítéssel. Ahhoz, hogy a ListView-val tudjuk használni, implementálni kell a saját osztályunkat. SDK-ban sok alapértelmezett implementáció. Pl. BaseAdapter, ArrayAdapter
19
• TextView: egy szöveg megjelenítésére alkalmas. Attribútumai: text - statikusan megadható szöveg, textColor - a szöveg színe, textSize méret, typeFace - betűtípus • EditText: a TextView leszármazottja, beviteli mező. Ha fókuszt kap, feljön a billentyűzet. Attribútumok: inputType - szöveg típusa (email, szöveg szám, stb.), hint - default szöveg • AutoCompleteTextView • Button: TextView leszármazottja. Kb. csak a háttérben különböznek. • ImageVew: kép megjelenítésére. Attribútumok: scaleType: nyújtás módja ha a View és a képerány különböző, src: a megjeleníteni kívánt kép. • ScrollView • ViewPager
Inflation: A View hierarchiát XML-ben is lehet definiálni, ekkor az elemek a R.java fájlban generált azonosítójukkal hivatkozhatók. A rendszer az XML alapján felépíti a fát, majd meghívja a setContentView() függvényt.
5.6
Felhasználói interakció
Az interakció az Observer minta alapján történik. Egy interface-t kell implementálni, melynek dedikált metódusa hívódik meg az esemény lefutásakor (a mintába: notify()/update(), itt onClick(), onLongClick(), stb.). Az osztályt példányosítani is kell, átadni a View-nak: set metósussal. Activity is implementálhatja.
Figure 5: Android ListView működése
5.7 5.7.1
Egyedi View, Toolbar, Fragment Egyedi View definiálása
Definiálhatunk saját widgeteket: a szokásos View paramétereken túl is testreszabható. Ekkor explicite felügyeljük a View kirajzolását az onDraw() protected függvény felüldefiniálásával. A szükséges méreteket az onMeasure(Canvas) függvénnyel kell megadni: ha nem implementáljuk, nem jelenik meg semmi. Az onDraw()-nak átadott Canvas sok rajzoló függvénnyel rendelkezik, illetve lekérhetjük a méreteit. 20
5.7.2
Toolbar
Általánosított ActionBar, Material Design-t alkalmaz.Lehet nyitható-csukható 5.7.3
Fragment
Önálló Activity lifecycle-el rendelkező kirajzolási egyság. A felhasználói felület része, saját logikával. Az Activity újrafelhasználható alapegysége, mindig egy Activity része - futásidőben cserélhető, az Activity saját back stack-jében tárolódik. A lifecycle-je szinkronban van az Activity-ével, ugyanazok a függvények hívódnak meg. Az onAttach() függvénnyel csatlakoztatható az Activity-hez. Az Activitybe beágyazva lehet használni, nem feltétlen van UI-a. Beágyazható közvetlenül XML-be vagy dinamikusan a kódban.
Figure 6: Android Fragment
6
iOS programozás
Az Apple által kezel operációs rendszer Dawin alapokon. Egyetlen gyártó, jól specifikált, kevés számó hardwerére: ARM processzoron, verziók közötti áttérés támogatása. Csak Apple rendszeren fejleszthető Objective-C vagy Swift nyelven. Főbb fellemzők: • Multitask, számos beépített programkönyvtár 21
• Mobil kommunikációs rendszerek támogatása (GSM, LTS, stb.) • WiFi, Bluetooth • Szenzorok: GOS, Triax gyorsulás/mágneses • Kamera, médiafelvétel támogatás • HDMI kimenet, 2D+3D grafikai gyorsítás
6.1
Az iOS felépítése
Több szoftver (és szoftverszint) együttese OS/X (Darwin) alapokon.
Figure 7: iOS rendszer felépítése
22
Részei: CoreOS
Media
• Mac OS/X kernel (XNU)
• Core Audio
• TCP/IP
• OpenAL (Open Audio Library)
• Socketek
• Hangkeverő
• Energia kezelés
• Hangrögzítő
• Fájlrendszer (HFS+)
• Video lejátszás
• Biztonság
• Médiaformátumok támogatása
Core sevices • Hálózatkezelés
• 2D gyorsítás
• Collections
• OpenGL ES
• Core Animation
• Preferenciák
Cocoa Touch • Többpontos érintése és gesztusok támogatása
• URL-ek kezelése • Fájlok hozzáférése
• Kamera támogatás
• Névjegyek • Beágyazott SQL adatbáziskezelő az eszköz • Core Location: helyzetének meghatározása WiFi, cella vagy GPS alapon. • Szálkezelés • CoreMotion: gyorsulásmérő szenzorok kezelése
• Többnyelvűség • Nézetek (nézethierarchia) kezelése • Gyorsulásmérő támogatása • Web view • Map kit • Értesítések kezelése • Core Motion: mozgással kapcsolatos információk felhassnálása
23
6.2
Objective-C
A C nyelv teljesen objektumorientélt kiterjesztése, vékony réteg, amit preprocesszor dolgoz fel. Új szintaktikai elemeket vezetett be osztályok, metódusok létrehozására. A Cocoa könyvtárak Objective-C alapúak. Üzenetküldésekkel operál, amiket []-kel jelez.
Figure 8: Objective-C objektumok élettartama
7 7.1 7.1.1
Adattárolás iOS módszer Core Data
OOP adatbázisban (OODB) tárolódnak az adatok, amihez az iOS-nek hatékony keretrendszere van. Lényegében egy objektumgráfot állítunk elő, amely mögött DBMS áll. Ez leggyakrabban SQL, de lehet XML vagy memóriaalapú is. Vizuálisan kell létrehozni egy megfeleltetést az objektumok és az adatbázis között. Az OO API használatával az objektumok létrehozása és lekérdezése lehetséges. A téblák oszlopainak lekérdezése az objektumok mezőinek lekérése.
24
7.1.2
Az Adatmodell
Ez egy Map az osztályaink és az adatbázis egyedek között. XCode: File > New > File menüponttal hozható létre új fájl az adatmodellhez. A Data Model egy sablon ennek a Mapnek. Legfontosabb fogalmai az Egyedek, Attribútumok, Kapcsolatok mind az adatbázisokhoz hasonlóan működnek.
7.2
Android módszer
Az Android fájlrendszere hasonló a többi Linux fájlrendszerhez: a /boot, /system és /recovery rendszerpartíciók, ide kerül a kernel, a system image és a backup oprendszer. A /misc a drivereket, rendszerbeállításokat, stb. tárolja. A /data a felhasználó által használható terület, ide kerülnek a programok, ez az internal storage. Van még egy halom másik is (/cache, /sdcard, /radio, stb) 7.2.1
Shared preferences
Privát primitív (boolean, float, int, long, string) típusok tárolása kulcs-érték párok alapján. Az alkalmazás beállításainak kezelésére használható a PreferenceActivity. Szerkesztésnék a SharedPreferences.Editor egy példánya szükséges. 7.2.2
Internal Storage
Alapértelmezésből privát az alkalmazás számára, az alkalmazás törlése esetén törlődnek az itt tárolt adatok. Ide kerülnek a fordítási időben a res/raw/utvonal helyre mellékelt fájlok. 7.2.3
External Storage
Lehet SD kártya vagy belső, nem privát hely is. Nincs semmiféle biztonság, a tárhely csak mountolás után látszik. 7.2.4
Adatbázis használata
Az egyedeket név alapján érjük el és csak az alkalmazás fér hozzájuk.Érdemes leszármaztatni az SQLiteOpenHelper osztályt és felüldefiniálni az onCreate() metó25
dusát. Ezután hozzáférhatünk az adatbázishoz az SQLiteOpenHelper getReadableDatabase() és getWriteableDatabase() függvényei által. Mindkettő SQLiteDatabase objektumot ad vissza, amin használhatjuk a .query() függvényt (komplexebb lekérdezés esetén az SQLiteQueryBuilder osztállyak hozhatjuk létre a queryt). Érdemes készíteni egy statikus adatbáziskezelő osztályt, és eltrejteni az adatbázist a program többi része elől. 7.2.5
Backup
A Google felhőszolgáltatásába menti el a rendszer az applikáció adatait, ezzel később visszaállíthatóvá válnak. Szinkronizációra nem alkalmas. Az AndroidManifest.xml fájlban kell deklarálni. Az onBackup() függvényt kell felüldefiniálni. A rendszer maga kezeli az egészet.
26
