1 / 55

Symbian alapú szoftverfejlesztés

Symbian alapú szoftverfejlesztés. ELTE PSZT – 2008. november. Symbian operációs rendszer. SIBO – Psion Computers (1980) EPOC - irodai kisszámítógép (1980-1998) Symbian OS – (alapítva 1998 : Nokia, Motorola, Psion, Ericsson, 2002: Sony-Ericssson , Siemens)

winter-owens
Download Presentation

Symbian alapú szoftverfejlesztés

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Symbian alapú szoftverfejlesztés ELTE PSZT – 2008. november

  2. Symbian operációs rendszer • SIBO – Psion Computers (1980) • EPOC - irodai kisszámítógép (1980-1998) • Symbian OS – (alapítva 1998 : Nokia, Motorola, Psion, Ericsson, 2002: Sony-Ericssson, Siemens) • Mérföldkő: 2000-ben megjelent 6.0-ás verzió

  3. Segédanyagok • www.symbian.com/books • www.symbian.com/developer • www.symbian.developer/public/index.html • http://forum.nokia.com/main.html • SDK online dokumentáció:C:\S60\devices\S60_3rd_FP2_SDK_v1.1\docs\eclipse.exe

  4. Online dokumentáció

  5. Okos telefonok • erős processzor • nagyméretű kijelző • viszonylag nagy memória • információ kezelő programok • egyéni alkalmazások • egyszerű kezelhetőség • megbízhatóság • erőforrásaival nem pazarló (memória, szolgáltatások, energia fogyasztás) • gyors reakcióidő • folyamatos üzemmód

  6. Elvárosok • megbízható • nincs adatvesztés • nem dobja el a vonalat • optimális a memória felhasználás • nincs memória szivárgás • minden hibát „értelmesen” kezel • nyitott a külső fejlesztések irányába

  7. Symbian OS felépítése Felhasználói interfész szinkronizáció UI alkalmazás keretrendszer UI eszköz-készlet MIDP CLDC JVM Alkalmazás szintű szolgáltatások PIM Üzenet-kezelés Böngészés Adat- szinkron Java Operációs rendszer szolgáltatásai Általános szolgáltatások Kommunikációs szolgáltatások Grafikai szolgáltatások PC-s kapcsolat szolgáltatásai Alap-szolgáltatások Alacsonyszintű szolgáltatások Fájlszerver Kernel és hardware integráció Kernel szolgáltatások Eszközmeghajtók

  8. A fejlesztés alapelemei • Symbian C++ sajátosságok • Elnevezési konvenciók • Kivétel- és memóriakezelés • Alaptípusok, sztringek, tömbök • ThinTemplate minta • Hibakezelés módja • Aszinkron kezelés (ActiveObject)

  9. Symbian C++ sajátosságok • Nincs kivétel. Helyette: TRAP és User::Leave • Nincs RTTI (dinamikus castolás nem megengedett) • Kódolási minták a memóriaszivárgás kiszűrésére: kétfázisú konstrukció, CleanUpStack • Saját elnevezési konvenciók:nem a változó típusa, hanem szerepe szerint történik az elnevezés (T,C,R,M) • memóriakezelés segítése függvénynevekkel: prefixek, postfixek

  10. Symbian C++ sajátosságok • Nincs STL, helyette saját generikus adatszerkezeteket használ • String helyett deszkriptorok • Többszálúság kezelése: ActiveObject, Thread • Template-ek használata: ThinTemplate

  11. Elnevezési konvenciók • Általános szabályok • Osztályok (T,C,M,R) • Egyéb típusok • Változók • Metódusok • Osztálydeklarációk elhelyezkedése

  12. Általános szabályokTípusok, változók, metódusok • Angol név, amerikai angol írásmód (Color, Colour) • Szavakat egybe írjuk, minden szót nagybetűvel kezdünk • Osztálynevek: főnevek; metódusnevek: igék • Név végén konvenció szerinti záróbetű (L, LC, LD)

  13. T osztályok (Type) • Egyszerű típusok • Nem tárolnak heapen objektumokat • Nincs szükségük destruktorra (az alapértelmezett jó) • Másoló konstruktort és értékadó operátort is ritkán használ • Legtöbbször a stack-en foglal helyet Nem igényelnek destruktort, ezért nem probléma, ha nem kerül végrehajtásra (leavelés).

  14. T osztályok - példa

  15. C osztályok (Class) • Bonyolultabb funkcionalitású osztályok • Ősosztálya a CBase • Virtuális destruktorral KELL rendelkeznie (memória felszabadítás) • Tagváltozók automatikusan kinullázódnak • Birtokolnak heapen tárolt objektumokat (memóriakezelés!) • Függvényhívásnál referenciaként, vagy pointerként adjuk át (nem igényelmásoló konstruktort vagy értékadó operátort)A destruktor hívását minden esetben biztosítani kell.

  16. R osztályok (Resource) • Valamilyen szerves szerű program által biztosított erőforrásra tartalmaznak azonosítót. (Pl. az RFile osztály az RFS osztály erőforrását használja ) • „Azonosító” miatt helyet foglalhatnak a stack-en is • A felszabadítás az erőforrást birtokló objektum (szerver) dolga • Szál befejeződésekor automatikusan felszabadul • Foglalás: Open, Create, Allocate • Elengedés: Close, Destroy, Free

  17. R osztályok - példa

  18. M osztályok (Mixin) • Interfész, absztrakt protokoll • C++: absztrakt osztályok • Csak virtuális metódusuk van, legtöbbször implementáció nélkül • Szigorú többszörös öröklődés: egy C osztály csak egy másik C osztályból és több M osztályból örökölhet (ugyanabból az M osztályból csak egyszer)

  19. Osztálytípusok - összefoglalás • T: egyszerű típus; nincs destruktora; csak T-ből, vagy M-ből öröklődhet; értékként átadható; stack-en tárolható • C: csak a heapen foglalható; van destruktora; pontosan egy C és tetszőleges M osztályból származhat; nem adható át értékként • M: interfész; csak virtuális metódusok; nincsenek tagváltozók; nem példányosítható • R: erőforrás, melyet meg kell nyitni és be kell zárni

  20. Kivételek, egyéb típusok • S: tagfüggvény nélküli struktúrák • Statikus osztályok: User, Math, Mem • H:HBufC • D: Kernel oldali osztályok • E:felorolások(enum) • K: Konstansok • i: tagváltozók (pl. iNum) • a: argumentumok (pl.: voidSetNumber (TIntaNumber);)

  21. Metódusok • Lekérdező és beállító metódusok • iNum tagváltozóhoz Num() lekérdező SetNum() beállító metódus • Bonyolultabb lekérdezéshez GetNum(); • „Kilépő” metódusok („Leavelő”) • Azok a metódusok, amelyek közvetlenül vagy közvetve User::Leave hívást eredményezhetnek • Lehetséges végződések: L, LC, LD

  22. Osztálydeklarációk - egyezmények • public, protected, private: mindig ki kell írni • Sorrend: tagfüggvények, tagváltozók • Metódusok argumentumait a deklarációban is ki kell írni • Az ősosztály virtuális metódusait külön csoportosítjuk, megjelölve, honnan öröklődtek • Ha sok inline függvény van, külön fájlba kell helyezni

  23. KivételkezelésMemóriakezelésHibakezelés

  24. Dinamikus objektumok - heap • Minden szál rendelkezik saját heap területtel • Symbian OS alatt a CBase osztályok példányait a heap-en helyezzük el • Az osztály adattagjai létrejöttükkor kinullázódnak • A virtuális destruktor biztosítja, hogy a felszabadítás helyesen megtörténjen

  25. Kivételkezelés, memóriakezelés • Kivételkezelési konvenciók • CleanupStack • Kétfázisú konstruktor

  26. Kivételkezelés • A Symbian elődjének fejlesztésekor a C++ fordítók nem ismerték a kivételkezelést • A C++ kivételek többlet memóriát és több számítást igényelnek • Symbian: egy-két konvenció  kisebb erőforrás igény

  27. Objektum automatikus létrehozása a stack-en

  28. Objektum létrehozása a heapen – példa Hiba esetén abbahagyja a végrehajtást.

  29. TrapHarrness és Leave

  30. Kivételkezelési konvenciók C++ Symbian • Throw • Catch • Függvénydeklaráció: Throw • new operátor: 0-t ad vissza • User::Leave • TRAP, TRAPD • záró L • new (ELeave): kivételt dob, ha nincs memória

  31. Kivételkezelés C++-ban Ha kivételkezelés történik • A program stack visszafejtésre kerül a catch szintjéig • Az objektumok destruktorai meghívódnak • A mutatók „elvesznek” (esetleg smart pointert lehet használni)

  32. Kivételkezelés C++-ban Ha kivételkezelés történik • A program stack visszafejtésre kerül a catch szintjéig • Az objektumok destruktorai meghívódnak • A mutatók „elvesznek” (esetleg smart pointert lehet használni)

  33. Kivételkezelés C++-ban Ha kivételkezelés történik • A program stack visszafejtésre kerül a catch szintjéig • Az objektumok destruktorai meghívódnak • A mutatók „elvesznek” (esetleg smart pointert lehet használni)

  34. Kivételkezelés C++-ban Ha kivételkezelés történik • A program stack visszafejtésre kerül a catch szintjéig • Az objektumok destruktorai meghívódnak • A mutatók „elvesznek” (esetleg smart pointert lehet használni)

  35. Kivételkezelés C++-ban Ha kivételkezelés történik • A program stack visszafejtésre kerül a catch szintjéig • Az objektumok destruktorai meghívódnak • A mutatók „elvesznek” (esetleg smart pointert lehet használni)

  36. Kivételkezelés C++-ban Ha kivételkezelés történik • A program stack visszafejtésre kerül a catch szintjéig • Az objektumok destruktorai meghívódnak • A mutatók „elvesznek” (esetleg smart pointert lehet használni) sizeof(Object) + sizeof(int) méretű memóriaszivárgás.

  37. Symbian C++ hibakezelés Nincs C++ kivétel • Nincs veremvisszafejtés • Destruktorokat nem hívja meg • Egész számot lehet eldobni és elkapni

  38. Hibakezelés - Leave • A Symbianbana hiba kezelésére a User könyvtár Leave metódusa szolgál. • Az olyan függvényeket, amelyek a User::Leave metódust hívják leave-elő függvényeknek nevezzük. • Minden leave-elő függvény neve L betűre végződik. • Mikor leave-elhet egy függvény? • Ha közvetlenül meghívja a User::Leave() függvényt • Heapen foglal helyet new (ELeave) metódussal • Más leave-elő függvényt hív.

  39. Hibakezelés + Leave Leave kezelése TRAP segítségével. Több függvényhívás esetén mindegyiket bele kellene tenni egy TRAP konstrukcióba. A CleanupStack használata „egyszerűsíti” ezeket a függvényhívásokat.

  40. CleanupStack Az x automatikus változó a heap-re mutat. Ha UseL() leave-el, akkor a delete nem hajtódik végre, a CX által lefoglalt terület „árván” marad. A UseL() függvény memóriát foglal és leave-elhet. A CX helyfoglalása után a rá mutató pointert elhelyezzük a CleannupStack-en Ha UseL() nem leave-el, akkor MI szedjük le a címet a stackről. Ha UseL() leave-el, akkor a Laeve kezelő eljárás.

  41. CleanupStack alkalmazása Egyszerre több elemet is leemelhetünk a stackről. Tilos!! Pointert tartalmazó adattagot ne tegyünk a CleanupStack-re. Az általa mutatott terület felszabadítása az adattagot tartalmazó osztály feladata, nem a Leave-elő mechanizmusé. A PushL() nem leave-el (előrefoglalás miatt)

  42. Kétfázisú konstrukció

  43. Kétfázisú konstrukció Probléma: A CY példányosításakor a CY konstruktora leave-el!

  44. Kétfázisú konstrukció

  45. Kétfázisú konstrukció • A konstruktort két részre bontjuk: • 1. rész: Biztonságos, nem leave-elő a példányra mutató pointer biztosan felkerül a CleanupStack-re • 2. rész: A „veszélyesebb” leave-elő rész. De ekkor már jó helyen van a pointer.

  46. Kétfázisú konstrukció A „két fázist” a NewL, NewLC függvényekbe „becsomagolják”.

  47. Kétfázisú konstrukció - összefoglalás • Az osztály standard konstruktorában nem hívunk leave-elő kódot • A leave-elő hívásokat egy külön „második fázisú konstruktorba” tesszük. (ConstructL) • Az osztály példányosításakor: • Meghívjuk a standard konstruktort (new) • A „félig létrejött” objektumot feltesszük a CleanupStack-re • Meghívjuk a második fázisú konstruktort (ConstructL) • (Levesszük a CleanupStack-ről) A „két fázist” a NewL, NewLC függvényekbe „becsomagolják”.

  48. Tagváltozók • Amikor egy osztály tagváltozót hozunk létre a heapen, akkor azt nem szabad feltenni a CleanupStack-re!! • Leave esetén meghívódik a gazda osztály destruktora és az törli a tagváltozót • Ha emellett a CleanupStack-en is fenn lenne a tagváltozó, akkor kétszer próbálná törölni, ami HIBA.

  49. Kódhatékonyság. ThinTemplate

  50. Hibák elleni védekezés • _ASSERT_ALWAYS • _ASSERT_DEBUG • User::Panic • _TEST_INVARIANT • _UHEAP_MARK, _UHEAP_MARKEND

More Related