A MOBIL ALKALMAZÁSFEJLESZTÉS ALAPJAI

Átírás

1 A MOBIL ALKALMAZÁSFEJLESZTÉS ALAPJAI SUMMARY OF THEOREM PPKE ITK, December 16, 2016 Written by Komporday András 2016

2 Contents 1 Az OOP alapelvei A valós világ modellezése OOP alapelvek OOP működési elvárások OOP alapfogalmak Az objektum Mezők és metódusok A szerver-kliens modell Programozási minták A minták fajtái Létrehozási minták Programtervezési paradigmák Model-View-Controller Model-View-Presenter Model-View-ViewModel Tesztelés és programtervezés A tesztek fajtái Funkcionális tesztelés Struktúrateszt OOP teszt

3 3.1.4 Inspekció Terhelési tesztek Test Driven Development, Extreme Programming Terminológia Mobil alkalmazások A technológiák előnyei és hátrányai Android Az Android felépítése Az Android projectfolyamat Az Android-fejlesztés eszközei Android Debug Bridge Az Android project szerkezete Az Actvity Az Activity életciklusa Az Android GUI Az elrendezés Néhány GUI elem: Felhasználói interakció Egyedi View, Toolbar, Fragment Egyedi View definiálása Toolbar Fragment

4 6 ios programozás Az ios felépítése Objective-C Adattárolás ios módszer Core Data Az Adatmodell Android módszer Shared preferences Internal Storage External Storage Adatbázis használata Backup 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

5 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 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 ) OOP működési elvárások Egységbezárás 4

6 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 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

7 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 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) 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

8 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

9 2.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 Adapter: az adott osztály 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 egységesíteni. 8 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

10 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 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 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 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

11 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 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 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 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 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

12 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 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 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

13 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

14 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

15 Rétegei: System Apps: -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. Hardware Abstraction Layer (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. Figure 2: Az Android felépítése 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

16 Figure 3: Android projectfolyamat 5.3 Az Android-fejlesztés eszközei Android Studio Android SDK Android NDK 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 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

17 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

18 GUI kezelése Funkciók végrehajtása 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

19 5.5 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 View- Group 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

20 5.5.2 Néhány GUI elem: Layoutok LinearLayout View-k: MapView RelativeLayout TableLayout: sorokból áll (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. WebView: beépített böngésző, webes tartalom megjelenítésére. 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 ( , 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 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<T> 19

21 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<listenername> metósussal. Activity is implementálhatja. Figure 5: Android ListView működése 5.7 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

22 5.7.2 Toolbar Általánosított ActionBar, Material Design-t alkalmaz.lehet nyitható-csukható 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

23 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

24 Részei: CoreOS Mac OS/X kernel (XNU) TCP/IP Socketek Energia kezelés Fájlrendszer (HFS+) Biztonság Core sevices Hálózatkezelés Collections Preferenciák URL-ek kezelése Fájlok hozzáférése Névjegyek Beágyazott SQL adatbáziskezelő Core Location: az eszköz helyzetének meghatározása WiFi, cella vagy GPS alapon. Szálkezelés CoreMotion: gyorsulásmérő szenzorok kezelése Media Core Audio OpenAL (Open Audio Library) Hangkeverő Hangrögzítő Video lejátszás Médiaformátumok támogatása 2D gyorsítás Core Animation OpenGL ES Cocoa Touch Többpontos érintése és gesztusok támogatása Kamera támogatás 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

25 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 Adattárolás 7.1 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

26 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) 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 Preference- Activity. Szerkesztésnék a SharedPreferences.Editor egy példánya szükséges 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 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 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

27 dusát. Ezután hozzáférhatünk az adatbázishoz az SQLiteOpenHelper getreadable- Database() é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 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