Anwendungsentwicklung für Symbian OS

Transkript

1 Anwendungsentwicklung für Symbian OS Eric Thomas & Jürgen Zeitz 23. Februar 2006 Zusammenfassung Symbian OS ist ein gängiges Betriebssystem für mobile Geräte. Endkunden, Hersteller und Software-Entwickler profitieren von der Architektur, welche für Symbian OS entwickelt wurde. Aber ohne gute Anwendungen für diese Plattform wäre Symbian für den Endkunden uninteressant. Damit eine Anwendung für Symbian OS geschrieben werden kann, ist es nötig, die Eigenheiten von Symbian OS zu verstehen und einen Blick auf den komplexen Build-Prozess zu werfen. Inhaltsverzeichnis 1 Mobile Geräte 3 2 Wozu Symbian OS? 3 3 Das Betriebssystem Oberflächen des Betriebssystem Dateisystem und Speichermedien Speichermanagement Entwicklung für Symbian OS Programmiersprachen Entwicklungsumgebungen Sichere Speicherverwaltung Erste Anwendungen Der Buildprozess Anhang 19 A Projekdefinitionsdatei 19 1

2 B Package-Datei 19 C Installationsdatei 20 D Ressourcen 21 2

3 1 Mobile Geräte Der Entwicklungsprozess von mobilen Geräten verläuft gerade im Bereich der Mobiltelefone sehr schnell. Sie werden PCs immer ähnlicher und erhalten mit jeder Generation weitere Funktionen. Natürlich steigt auch der Wunsch der Nutzer die Geräte durch eigene Anwendungen um beliebige Funktionen zu ergänzen. Wie auf Computern werden in diesem Bereich zunehmend Betriebssysteme eingesetzt, um die erweiterte Funktionalität zu nutzen und anzupassen. Mobiltelefone, die neben den üblichen Telefoniefunktionen weitere PCähnliche Funktionalitäten bereitstellen, werden als Smartphone bezeichnet. Zu den erweiterten Funktionalitäten zählt das versenden von oder Fax sowie das Surfen im Internet. Kontakte, Termine und Aufgaben können verwaltet werden und es ist möglich, Fotos oder Videos zu erstellen, welche auf dem vergleichsweise großen Farbdisplay in guter Qualität angezeigt werden. Smartphones können darüber hinaus untereinander oder mit Computern Daten austauschen. 2 Wozu Symbian OS? Das Betriebssystem eines mobilen Gerätes muss den hohen Ansprüchen mehrerer Parteien genügen. Der Benutzer verlangt von seinem Mobiltelefon, dass er jederzeit erreichbar ist. Daten, die er in dem Gerät speichert, dürfen auf keinen Fall verloren gehen und müssen problemlos zwischen ihm und anderen mobielen Geräten oder Desktop PCs ausgetauscht werden können. Die Betriebszeit des Mobiltelefons soll so lang wie möglich sein, wobei die Erinnerungs- bzw. Weckfunktion selbst in ausgeschaltetem Zustand funktionieren muss. Einfache Benutzung, hundertprozentige Verlässlichkeit und absolute Stabilität wird vom Benutzer ebenso vorrausgesetzt, wie die Möglichkeit sein Handy bzw. seinen PDA um neue Funktionen erweitern zu können. Damit dieses Bedürfnis befriedigt werden kann, ist ein Netzwerk von Entwicklern für das Betriebssystem eines solchen Gerätes nötig. Dies impliziert, dass die Lernkurve für die Entwicklung nicht zu steil ist, dass Objektorientierung unterstützt wird und ein einfach zu nutzendes Fehlerbehandlungssystem verfügbar ist. SDKs, Hilfsmittel, Dokumentationen, technische Unterstützung und Schulungen werden ebenso selbstverständlich vorrausgesetzt. Damit der Programmierer in seinen Möglichkeiten nicht eingeschränkt wird, muss er auf alle Systemressourcen zugreifen können. Hierzu zählen auch die eventuell einzigartigen Charakteristika spezieller Mobiltelefonmodelle. Hardwarehersteller stellen zusätzliche Anforderungen an ein entsprechendes Betriebssys- 3

4 tem, damit sie es auf ihren Geräten vorinstallieren. Das Betriebssystem muss z.b. auf verschiedenen, mitunter völlig unterschiedlich bedienbaren Geräten funktionieren, denn nur so ist es möglich, ein Betriebssystem günstig auf verschiedenen Geräteklassen einzusetzen. Unterschiedliche Hersteller verlangen Anpassbarkeit des Aussehens eines Betriebssystems, damit sie sich von der Konkurrenz abheben können. Das Betriebssystem muss zukünftige Entwicklungen entweder schon unterstützen oder eine einfache Möglichkeit vorsehen, diese zu integrieren. Symbian OS schafft den Spagat, auf der einen Seite kompakt zu sein und auf der anderen Seite all die genannten Anforderungen zu erfüllen. Das Benutzerinterface ist komplett vom Betriebssystemkern getrennt, welcher seinerseits so klein wie möglich gehalten wurde. Dies reduziert das Risiko, das System auf irgend eine Weise unsicher zu machen. Symbian OS unterstützt offene Standards, wie Java 1, Bluetooth 2, MMS 3, SyncML 4, IPv6 5, etc. und ist damit gewappnet für aktuelle und kommende Entwicklungen. Einfache Mechanismen zur Codewiederverwendung und zum Speichermangement garantieren sichere, effiziente und günstige Anwendungsentwicklung. Durch die Verwendung der verbreiteten Programmiersprache C++ kann nahezu jeder Programmierer sofort Software für Symbian OS entwickeln. Es ist dabei möglich, sowohl portable Programme zu schreiben, die auf jedem Symbian-Gerät funktionieren, als auch gerätespezifische Software zu entwickeln, die auf spezielle Systemressourcen einer Geräteklasse zugreift. Ein großes, meherere tausend Teilnehmer umfassendes Netzwerk an Entwicklern garantiert zudem, dass das Betriebssystem den Ansprüchen von Anwendungsentwicklern, Herstellern und Endkunden gerecht wird. Nicht umsonst ist Symbian OS 6 neben Microsofts angepasster Windows-Version Windows Mobile 7 das wohl am weitesten verbreitete Betriebssystem für mobile Geräte. War Symbian OS 2003 noch auf 8 Millionen Geräten installiert [SymbOS], stieg die Zahl bis 2005 auf 39 Millionen Geräte [Symbian] Multimedia Messaging Service 4 Synchronization Markup Language, 5 Internet Protocol, Version 6,

5 3 Das Betriebssystem 3.1 Oberflächen des Betriebssystem Der Kern des Symbian-Betriebssystems wird von Symbian Ltd. 8 entwickelt und ist bei allen Geräten gleich. Je nach Gerät und Geräteklasse werden allerdings verschiedene Betriebssystemoberflächen eingesetzt, die von anderen Anbietern bereitgestellt werden. Von Nokia 9 stammen hierbei die Series 60, 80 und 90. UIQ Technology 10 bietet zudem die selbst entwickelte UIQ- Plattform an. Die Unterschiede der verschiedenen Plattformen liegen lediglich in den Komponenten, die für Darstellung, Oberfläche und Eingabegeräte ausgelegt sind. Zum Einen haben die verschiedenen Geräteklassen deutliche Unterschiede in der Displaygröße und zum anderen gibt es eine Vielzahl unterschiedlicher Eingabegeräte. Hierbei reicht das Spektrum von normalen Telefontastaturen über Mini-Tastaturen, welche sich nur in ihrer Größe von einer Computertastatur unterscheiden, bis hin zu Touchscreens, die mit einem Stift bedient werden. Am weitesten verbreitet ist Symbian Series 60. Diese Variante des Betriebssystems findet vorallem auf sogenannten sprachzentrischen Geräten Verwendung. Zu dieser Klasse zählen die meisten Smartphones, da hier der Anwendungsschwerpunkt auf der Sprachkommunikation liegt. Die Eingabe erfolgt dabei über eine normale Telefontastatur mit Ziffernblock, 5-Wege- Navigationstaste und zwei Softbuttons, die frei mit Funktionen belegt werden können. Die Series 80 wird weitgehend auf Organizern eingesetzt. Diese gehören zur Klasse der informationszentrischen Geräte, wobei sie jedoch in der Regel auch über Telefoniefunktionen verfügen. Diese Geräte zeichnen sich durch eine computerähnliche Tastatur und ein größeres Display aus. Series 90 und UIQ sind sich sehr ähnlich. Beide werden auf PDA-ähnlichen Geräten eingesetzt, die zur Klasse der informationszentrischen Geräten mit Telefoniefunktion zählen. Das spezielle Merkmal dieser Geräteklasse ist der Touchscreen, über den alle Benutzereingaben erfolgen. Manche Geräte haben jedoch zusätzlich noch eine Tastatur. Der hauptsächliche Unterschied zwischen Series 90 und UIQ liegt darin, dass Series 90 das Anlegen benutzerdefinierter Skins unterstützt. So ist es möglich die Oberfläche des Bestriebssystems beliebig umzugestalten. 8 Symbian Ltd., 9 Nokia GmbH, 10 User Interface Quartz, 5

6 Oberfläche Anwendungsgebiet Hardware Series 60 sprachzentrisch, erweiterte Farbdisplay, Informationsfunktionen Telefontastatur Series 80 informationszentrisch, Telefoniefunktion Großes Farbdisplay, Mini-Tastatur Series 90 informationszentrisch, Telefoniefunktion Touchscreen unterstützt benutzerdefinierte Skins (PDA-ähnlich) UIQ informationszentrisch, Telefoniefunktion (PDA-ähnlich) Touchscreen Tabelle 1: Die verschiedenen Plattformen 3.2 Dateisystem und Speichermedien Das Dateisystem von Symbian OS ist stark an Microsoft Windows 11 orientiert. Unter Symbian werden den verschiendenen Speichermedien wie unter Windows Laufwerksbuchstaben zugeordnet. Über diese können die Medien angesprochen werden. Dabei gibt es auf jedem Gerät grundsätzlich mindestens zwei Laufwerke. Gerät optional ROM RAM Flash RAM Card Card Z: C: D: E:... Abbildung 1: Laufwerke Über das Laufwerk mit der Kennung Z: wird auf das ROM 12 eines Geräts zugegriffen. Hier ist wie der Name schon sagt kein Schreibzugriff möglich. Das ROM enthält die vorinstallierte Software eines Geräts. Hier sind Betriebssystem, Bibliotheken und gegebenenfalls weitere vom Hersteller vorinstallierte Anwendungen abgelegt Read Only Memory 6

7 Z: Abbildung 2: Speichermanagement nach [Task00] Auf das RAM 13 wird unter Symbian OS ebenfalls wie auf ein Laufwerk zugegriffen. Es ist über die Laufwerkskennung C: zu erreichen. Hier hat das Betriebssystem entsprechend Schreib-Lese-Zugriff und kann Nutzerdaten und Konfigurationen speichern. Auch vom Benutzter installierte Programme werden hier abgelegt. Das RAM wird in modernen Geräten durch RAM- und Flash-RAM-Bausteine realisiert. Flash-RAM-Bausteine haben den Vorteil, dass sie ohne eine ständige Stromversorgung auskommen, um Daten persistent zu speichern. Datenverlust durch mangelnde Stromversorgung ist somit ausgeschlossen während gleichzeitig der Akku geschont wird. Die Verwaltung des RAMs wird vom Betriebssystem übernommen. Nachinstallierte Software wird automatisch im Flash-RAM gespeichert, während das flüchtige RAM von Programmen während ihrer Ausführung genutzt wird. Die meisten mobilen Geräte unterstützen externe Speichermedien wie CompactFlash Cards 14 oder SD Memory Cards. Jedes zusätzliche Speichermedium wird dabei mit einer fortlaufenden Laufwerkskennung (D:, E:,...) in das Dateisystem von Symbian eingebunden. Da alle Daten auf Speicherkarten persistent gespeichert werden, sind diese sowohl zur Speicherung von Benutzerdaten als auch zur Installation weiterer Programme geeignet. 13 Random Access Memory

8 Lauferk Speicher Datenhaltung Speicherinhalt Z: ROM persistent Betriebssystemdaten, werkseitig installierte Anwendungen C: Flash-RAM persistent nachinstallierte Anwendungen, Anwendungs- und System- Dateien (.ini), Daten C: RAM flüchtig Ausführung der Anwendungen D:, E:,... Memory-Cards persistent Anwendungen, Daten 3.3 Speichermanagement Tabelle 2: Speicher Ein großer Unterschied zu anderen Betriebssystemen ist, dass Programme unter Symbian OS nicht zuerst ins RAM geladen müssen, um ausgeführt werden zu können. Sie werden direkt aus dem ROM gestartet. Im Vergleich zur Festplatte eines normalen PCs ist das ROM eines mobilen Geräts deutlich schneller und ermöglicht so das direkte Starten der Anwendung. Zur Laufzeit entstandene Daten werden in Symbian aber ebenfalls im RAM abgelegt. Ferner unterstützt Symbian ein Konzept, das es ermöglicht es den knappen Speicher eines Geräts optimal auszunutzen. Dabei werden Bibliotheken, die von mehreren Anwendungen benötigt werden, nur einmal in den Speicher geladen und von den Programmen gleichzeitig genutzt (Vergleiche [SymbOS, Seite 77]). Anders als bei Desktop-PCs gibt es bei Symbian keine Auslagerungsdatei. Wenn keine freien Speicherblöcke mehr vorhanden sind, tritt ein outof-memory- oder ein disk-full-fehler auf. Da der verfügbare Speicher auf mobilen Geräten ohnehin sehr begrenzt ist, muß verstärkt auf solche Fehler geachtet werden. Zur Vermeidung vom Memory Leaks 15 stellt Symbian daher diverse Mechanismen zur Verfügung(siehe Abschnitt 4.3). Speicher, der bei der Objekterzeugung oder durch explizite Allokierung reserviert wird, wird vom zugeteilten Speicher (Heap) des jeweiligen Threads geholt. Falls im Heap nicht genug freie Speicherblöcke zur Verfügung stehen, versucht der Heap-Manager den Heap um weitere Blöcke zu vergößern. Jeder Thread hat zusätzlich einen 12 kbyte großen Stack. Hier können entsprechend nur geringe Datenmengen (z.b. Variableninhalte von Grunddatentypen) abgelegt werden. 15 Speicherlöcher - nicht freigegebener Speicher 8

9 4 Entwicklung für Symbian OS Native Symbian-Programme werden in der Regel auf Computern mit Windows als Betriebssystem entwickelt. Um zu gewährleisten, das die entwickelten Programme auf einem Endgerät mit Symbian OS lauffähig sind, wird durch einen Emulator die API von Symbian OS bereitgestellt. Die so zur Verfügung gestellten Dienste werden auf der jeweiligen Hardware jeweils anders implementiert, wobei auf Quellcode-Ebene keine Unterschiede bestehen. Soll ein Dienst des Betriebssystems, wie etwa der Fileserver, aus einem Programm heraus angesprochen werden, so ist der Funktionsaufruf im Quellcode unabhängig von der genutzten Hardwareplattform. Im Emulator greift der Fileserver-Dienst auf ein Unterverzeichnis auf der Festplatte zu, während auf einem echten Gerät ein Zugriff auf die RAM-Disk erfolgt. Beim Übertragen einer Applikation auf ein Endgerät, muß die Anwendung mit einem Crosscompiler 16 übersetzt werden. Programmcode, der für dem Emulator übersetzt wurde ist auf echten Geräten nicht lauffähig, da hier andere Prozessoren benutzt werden, die einen anderen Befehlssatz unterstützen, als die Prozessoren der Entwicklungssysteme (vgl. Abschnitt 4.5.1). 4.1 Programmiersprachen Es gibt mehrere Möglichkeiten Programme für mobile Geräte zu schreiben. Die meisten mobilen Geräte unterstützen Java. Hierbei läuft auf dem Gerät eine KVM 17, welche Java-Midlets 18 ausführen kann. Der Vorteil hierbei ist, daß die Midlets auf jedem Java-fähigen Gerät laufen, auf dem die vom Midlet benutzten APIs implementiert sind. Auch Symbian-Geräte haben in der Regel eine KVM, um Java-Programme ausführen zu können. Der größte Vorteil, bei der direkten Entwicklung von Symbian-Software ist der uneingeschränkte Zugriff auf alle Systemressourcen. Da die Programme, genau wie das Betriebssystem in C++ implementiert werden, kann hier auf alle Betriebssystemfunktionen zugegriffen werden. Die Programme unterliegen nicht den Einschränkungen einer Laufzeitumgebung. Auf diese Weise kann auf Bluetooth-, Kamera-, Radio-, GPS-Komponenten oder das Dateissytem direkt zugegriffen werden. Dies ermöglicht das Schreiben von Treibern, Antivirensoftware und anderen Programmen, die tief in das System eingreifen. Auch der Einsatz von Skriptsprachen ist auf mobilen Geräten möglich. 16 Compiler, der ausführbaren Code für eine andere Computerplattform erzeugt 17 Kilobyte Virtual Machine, Java-Laufzeitumgebung 18 Java-Anwendung für mobile Geräte 9

10 Symbian OS bietet beispielsweise die Möglichkeit Python 19 einzusetzen. Der Vorteil von Python ist hierbei, dass die Sprache die Möglichkeit bietet C- Module zu integrieren. Auf diese Weise ist auch von Python aus der Zugriff auf Betriebssystemfunktionen möglich. Im Gegensatz zu reinen C++ Programmen ist hier jedoch mit einer schlechteren Performance zu rechnen. 4.2 Entwicklungsumgebungen Symbian SDKs 20 werden sowohl von Symbian direkt als auch von den Herstellern der Endgeräte, wie zum Beispiel Nokia, angeboten. Sie enthalten verschiedene Hilfsprogramme zum Erstellen von Symbian-Anwendungen sowie einen Emulator, um die Programme auf einem Desktop-PC zu testen. Die SDKs unterstützen direkt die Entwicklungsumgebungen Microsoft Visual C++ 21, Metrowerks CodeWarrior 22, sowie emphborland Mobile Studio 23. Sie bieten die bekannten Vorteile einer Entwicklungsumgebung wie Syntax- Highlighting, das Anzeigen von Klassen oder das Kompilieren auf Tastendruck. Allerdings existieren zum Teil große Unterschiede in der Art der Integration der SDKs in die jeweilige IDE 24. Während in Visual C++ lediglich ein Wizard integriert werden kann, der dabei hilft, das Grundgerüst einer Anwendung zu erstellen, bietet das Mobile Studio von Borland deutlich mehr Komfort. Neben der Verwaltung der Projektdateien (.mmp) besteht hier auch die Möglichkeit mit wenigen Handgriffen aus der IDE heraus verschiedene Build-Targets (siehe Abschnitt 4.5.1) auszuwählen, oder auch GUI-Elemente leicht mit einigen Mausklicks zu erstellen. Das Tool makmake, auf das in Abschnitt 4.5 näher eingegangen wird bietet die Möglichkeit MS-Visual-C++-Projektdateien zu erstellen, die mit der IDE geöffnet werden können. Zu diesem Zweck muß das Tool mit dem Auruf makmake programm.mmp vc6 gestartet werden. Wird ein Projekt über die so erstellte Datei geladen, sind in der IDE sämtliche Parameter gesetzt, um die Anwendung von dort aus zu kompilieren, zu starten oder zu debuggen. Allerdings müssen die Projektdateien jedesmal neu erstellt werden, wenn neue Quellcode-Dateien zum Projekt hinzugefügt werden. Diese müssen zunächst in die Projektdefinitionsdatei eingetragen werden, bevor daraus erneut eine Workspace-Datei erstellt werden kann Software Development Kit Integrated Development Environment: Entwicklungsumgebung 10

11 4.3 Sichere Speicherverwaltung C++ Programme für Symbian müssen hinsichtlich des Speichermanagements mit besonderer Sorgfalt programmiert werden. Besondere Makros, Funktionen und Klassen erleichtern es dem Programmierer, diese komplexe Anforderung umzusetzen ([SymbOS, Siehe S.52,88f.]). Mit Hilfe der Makros UHEAP_MARK und UHEAP_MARKEND, die das komplette Programm umschließen sollten, wird der allokierte Speicher bei Programmstart und -ende überprüft. Somit wird gewährleistet, daß der komplette von der Anwendung genutzte Speicher beim Verlassen des Programms wieder freigegeben wird. Die Klasse CleanupStack hilft ebenfalls dabei, Memory Leaks zu vermeiden. Auf dem Cleanupstack werden zusätzliche Referenzen auf Objekte abgelegt. Falls beim Verarbeiten eines Objekts ein Fehler auftritt, und die Referenz darauf verloren geht, existiert weiterhin die Objektreferenz auf dem Cleanupstack, die dazu genutzt werden kann, den vom Objekt belegten Speicher wieder freizugeben. Die statischen Funktionen PushL(), Pop() sowie PopAndDestroy() der Klasse CleanupStack dienen dazu, Objektereferenzen auf dem Cleanupstack zu speichern, sie wieder davon zu entfernen und gegebenenfalls das zugehörige Objekt zu zerstören. Symbian bietet darüber hinaus einen fehlertoleranten Konstruktor. Der Operator new (ELeave) erzeugt ein temporäres Objekt. Konnte das temporäre Objekt erfolgreich erstellt werden, wird es dem eigentlichen Objekt übergeben und die Objekterzeugung kann ohne weitere Speicherprobleme abgeschlossen werden. Tritt ein Fehler auf, so läuft die Routine in die vorgesehene Fehlerbehandlung. Eine typische Verwendung des fehlertoleranten Konstruktors sieht wie folgt aus: CFbsBitmap ibmp = new ( ELeave ) CFbsBitmap ; 4.4 Erste Anwendungen Konsolenanwendung Symbian bietet neben der von Smartphones gewohnten graphischen Oberfläche eine Konsole, wie man es von Betriebssystemen wie Linux oder Windows gewohnt ist. In der Praxis findet diese jedoch kaum Verwendung und wird für gewöhnlich von Entwicklern zum Debuggen genutzt. Am Beispiel einer Konsolenanwendung läßt sich jedoch gut der Aufbau eines simplen Programms erklären, ohne auf das komplexe GUI-Framework einzugehen. C++ Programme unter Symbian haben, wie in anderen Programmiersprachen auch, einen festen Einstiegspunkt in den Programmcode. Dies ist die Funktion E32Main(). 11

12 Sie wird beim Start der Anwendung gerufen. Als Rückgabewert wird ein Integer verlangt. Dieser stellt, wie in anderen C-Programmen üblich, einen Exit-Status dar. Ein einfaches Hello World! -Programm für die Konsole sieht folgendermassen aus: # include < e32base. h> # include < e32cons. h> LOCAL_D CConsoleBase c o n s o l e ; _LIT( t i t l e, " Hello Text" ) void consolemainl ( ) { c o n s o l e = Console : : NewL( t i t l e, TSize ( KConsFullScreen, KConsFullScreen ) ) ; CleanupStack : : PushL ( c o n s o l e ) ; console >P r i n t f (_L( " Hello World! \ n" ) ) ; console >P r i n t f (_L( " [ p r e s s any key ] " ) ) ; console >Getch ( ) ; } CleanupStack : : PopAndDestroy ( ) ; GLDEF_C TInt E32Main ( ) { UHEAP_MARK; CTrapCleanup cleanupstack=ctrapcleanup : : New ( ) ; TRAPD( error, consolemainl ( ) ) ; ASSERT_ALWAYS(! error, User : : Panic (_L( "PEP" ), e r r o r ) ) ; delete cleanupstack ; UHEAP_MARKEND; return 0 ; } Mit diesem Quellcode wird ein Programm erzeugt, welches Hello World! auf der Konsole ausgibt, eine beliebige Eingabe vom Benutzer abwartet und sich daraufhin beendet. Der Zweck des Cleanupstacks und der verwendeten Makros UHEAP_MARK und UHEAP_MARKEND wurden bereits in Abschnitt 3.3 erläutert. 12

13 Das Makro TRAP bzw. TRAPD stellt einen Mechanismus zur Verfügung, der mit dem Exception-Handling in anderen Programmiersprachen vergleichbar ist. Der erste Parameter ist dabei eine Variable, in der ein Fehlercode gespeichert wird. Der zweite Parameter ist die auszuführende Funktion. Eine Funktion kann mittels USER::LEAVE() die normale Ausführung beenden und die Exception-Behandlung anstoßen. Als Programmierkonvention gilt es Funktionen, die solche Fehler auslösen können, mit einem L am Ende des Funktionsnamens zu kennzeichnen. Das ASSERT_ALWAYS-Makro überprüft anschließend, ob die in TRAPD ausgeführte Funktion einen Fehler zurückgeliefert hat und reagiert entsprechend. Durch den Aufruf von User::Panic() wird eine Systemreaktion (Panic) ausgelöst. Dies führt dazu, daß der Kernel die Programmausführung stoppt und den kompletten zum Prozess gehörenden Speicher freigibt. Das eigentliche Verhalten der Anwendung wird durch die Befehle Printf() und Getch() des Konsolenobjekts realisiert. Printf() gibt dabei eine Zeichenkette auf der Konsole aus, während Getch() auf eine Benutzereingabe wartet und danach mit der Ausführung des Programms fortfährt. Der Parameter _L("Hello World!\n"), welcher Printf() übergeben wird, ist mit einem String-Objekt vergleichbar. In Symbian werden anstelle von Strings so genannte Deskriptoren verwendet. Diese entsprechen im Grunde einer String-Klasse und bieten ähnliche Funktionen an. Dazu zählt u.a. das Suchen von Zeichen oder der lexikographische Vergleich. Zur Erstellung von Deskriptoren existieren zwei Makros. Das Makro _L erzeugt einen Deskriptor ohne einen Namen dafür zu vergeben. Er kann so direkt als Parameter übergeben werden. Werden Deskriptoren an mehreren Stellen benötigt, ist es sinnvoll mittels _LIT 25 einen benannten Deskriptor zu erzeugen Graphische-Anwendung GUI-Anwendungen 26 für Symbian basieren auf CONE 27 und EIKON 28. CO- NE ist hierbei die zugrunde liegende Schicht, die eine Zeichenfläche auf dem Display bereitstellt und für die Eventbehandlung zuständig ist. EI- KON hingegen verwaltet das Look&Feel der Oberfläche. Die Komponenten von EIKON sind entsprechend austausch- und erweiterbar. So können Gerätehersteller die GUI-Komponenten ihrer Software anpassen und erweitern ohne tief in den Code des Betriebssystems einzugreifen. Auf der nächsten Schicht des Frameworks erben Klassen des UIKON-Frameworks von EIKON- 25 _L bzw. _LIT steht dabei für Literal 26 GUI: Graphical User Interface bzw. Grafische Benutzeroberfläche 27 Control-Environment 28 Griechisch für Aussehen, Form 13

14 Model CExampleDocument +CreateAppUiL() CExampleAppView +Draw() View Controller CExampleAppUi +HandleCommandL() CExampleApplication +AppDlluid() +CreateDocumentL() erzeugt Abbildung 3: Model-View-Controller Klassen und bieten eine User-Interface-Klassenbilbliothek für Standard-GUI- Komponenten (Vergleiche [SymbOS, Seite 110]). Das Application Famework, das graphische Anwendungen unter Symbian OS ermöglicht, wendet das klassische Model-View-Controller-Paradigma 29 an. Ein Programm mit graphischer Oberfläche besteht aus mindestens vier Klassen. Neben den Klassen für die Daten (Model), die Darstellung (View) und die Datenverarbeitung (Controller) gibt es eine weitere Applikationsklasse, die für das Starten der Anwendung verantwortlich ist. Beim Starten der Anwendung wird zunächst vom Framework eine Instanz der Klasse CExampleApplication erstellt. Danach wird die UID 30 der Anwendung ausgelesen und geprüft, ob das Programm bereits läuft. Ist dies der Fall wird zu der laufenden Instanz gewechselt. Auf diese Weise wird verhindert, dass mehrere Instanzen eines Programms gestartet werden. Läuft eine Anwendung noch nicht, wird anschließend die Model-Klasse CExampleDocument instanziiert. Dabei werden persistent gespeicherte Daten geladen, falls solche vorhanden sind. Ist das Laden der Daten abgeschlossen, wird vom Model aus eine Instanz der Klasse CExampleAppUi erstellt. Dabei handelt es sich um die Controller-Klasse, über die die Daten des Modells manipuliert werden können. Abschließend instanziiert die Controller-Klasse die View-Klasse CExampleAppView. Diese ist für die Darstellung der Anwendung auf dem Display zuständig. Sie ist für das Zeichnen der Oberflächenkomponenten verantwortlich. 4.5 Der Buildprozess Um ein Projekt zu erstellen, werden zunächst Makefiles benötigt, die den Kompilierprozess steuern. Zum Erstellen der genannten Makefiles wird zu- 29 Architekturmuster zur Trennung von Software-Systemen 30 Unique Identifier 14

15 CEikApplication +AppDlluid() +CreateDocumentL() Uikon-Framework CEikDocument +CreateAppUiL() CEikAppUi +HandleCommandL() Control Environment CONE CCoeControl +Draw() CExampleApplication CExampleDocument CExampleAppUi CExampleAppView +AppDlluid() +CreateDocumentL() +CreateAppUiL() +HandleCommandL() +Draw() Abbildung 4: GUI-Klassen nächst die Datei Bld.inf benötigt. Sie enthält in der Regel nur einen Verweis auf die Projektdefinitionsdatei und wird vom Entwickler erstellt. Ihr Inhalt muss mindestens aus zwei Zeilen bestehen: PRJ_MMPFILES. \ group \ h e l l o w o r l d.mmp Die Projektdefinitionsdatei enthält weitere Informationen über das zu erstellende Projekt. Ihr Inhalt wird in Abschnitt A genauer beschrieben. Der Aufruf bldmake bldfiles verarbeitet die Datei Bld.inf bzw. die darin angegebene Projektdefinitionsdatei und generiert dabei sämtliche Makefiles für die verschiedenen Build-Targets (siehe Abschnitt 4.5.1) sowie die Batchdatei Abld.bat. Zu diesem Zweck wird während der Ausführung das Makefile Creation Utility makmake aufgerufen, welches aus einer Projektdefinitionsdatei ein Makefile für eine beliebige Plattform generieren kann. Durch das Ausführen der Batchdatei Abld.bat mit dem gewünschten Build-Target als Parameter, wird das Kompilieren und Linken der entsprechenden Dateien angestoßen. Intern wird dabei das Perl-Skript Abld.pl 31 mit den entsprechenden Parametern aufgerufen. Dieses lokalisiert das gewünschte Makefile und parametrisiert das Tool nmake damit. Während der darauffolgenden Verarbeitung des Makefiles werden Compiler und Linker aufgerufen, um aus den Quellcode-Dateien ausführbaren Programmcode zu erzeugen Build-Targets Bei der Anwendungsentwicklung für Symbian OS ist zu beachten, daß Software auf PCs entwickelt wird, die in der Regel mit einer x86 CPU 32 laufen. 31 ABLD: Automatic Build Tool 32 Prozessor mit CISC-Architektur 15

16 bldmake Aufruf: verarbeitet bldmake bldfiles bld.inf verweist auf *.mmp ruft auf makmake erzeugt Abld.bat *.WINS *.ARMI... Abbildung 5: BldMake Die entwickelte Anwendung wird später jedoch auf einen anderen Gerät eingesetzt, das einen anderen Chipsatz verwendet. In Geräten, die unter dem Symbian Betriebsystem laufen, werden meist StrongARM-Prozessoren 33 verbaut. Diese beherrschen weniger und andere Befehle als x86 CPUs. Somit ist kompilierter Code nur auf dem Gerät lauffähig, für den er übersetzt wurde. Um auf einem PC ausführbare Dateien für ein Symbian-Gerät zu erstellen wird daher ein Cross-Compiler eingesetzt. Da Programme für verschiedene Prozessorarchitekturen anders erstellt werden und andere Compiler nutzen, werden verschiedene Makefiles benötigt, die die entsprechenden Schritte und Abhängigkeiten definieren. Für jede Zielplattform wird ein eigenes Makefile benötigt, das mit Hilfe des Tools makmake erstellt werden kann. Um alle Makefiles für alle verfügbaren Plattformen in einem Schritt zu erstellen, kann das Tool bldmake wie in Abschnitt 4.5 beschrieben genutzt werden Build für den Emulator Wurden die Makefiles bereits, wie in Abschnitt 4.5 beschrieben erstellt, kann der Buildprozess direkt angestoßen werden. Durch den Aufruf abld build wins udeb wird mit Hilfe des Makefiles mit der Endung WINS ausführbarer 33 Prozessor mit RISC-Architektur 16

17 abld.bat ruft auf Aufruf: abld build udeb wins abld build urel armi abld.pl ruft auf nmake ruft auf verarbeitet *.WINS *.ARMI... Compiler/ Crosscompiler verarbeitet Quellcode (*.h, *.cpp) Linker erzeugt verarbeitet Objektcode (*.o, *.obj) erzeugt Programmcode (*.app, *.exe, *.dll) Abbildung 6: Automatic Build Tool Build UREL UDEB Typ Unicode Release Unicode Debug WINS ARMI WINS ARMI Zielplattform WINS: Emulator ARMI: Device Abbildung 7: Build-Targets 17

18 Bld.inf bldmake bldfiles Bld.inf bldmake bldfiles Abld.bat *.app, *.rsc Abld build wins urel oder Abld build wins udeb Abld.bat *.app, *.rsc Abld build wins urel oder Abld build wins udeb makesis *.pkg *.sis Abbildung 8: Build-Prozess für Emulator und Endgerät Code für das Build-Target WINS erzeugt. Ergebnis des Builprozesses sind zwei Dateien mit den Endungen.app und.rsc. Beide Dateien liegen im Verzeichnis \epoc32\release\wins\udeb\z\system\apps\projektname. Die APP- Datei ist dabei das ausführbare Programm und die RSC-Datei die kompilierte Ressource (siehe Abschnitt D). Wurde in der Projektdefinitionsdatei als Zieltyp EXE angegeben wird eine ausführbare Datei mit selbiger Endung im Verzeichnis \epoc32\release\wins\udeb\ erzeugt. Diese Datei kann direkt aus Windows gestartet werden und lädt das Programm direkt in den Emulator Build für die Zielplattform Der Buildprozess für die Zielplattform ist ähnlich dem für den Emulator. Da das Programm jedoch noch auf dem Symbian-Gerät installiert werden muß, sind einige weitere Schritte notwendig. Der Aufruf abld build armi urel stößt den Buildprozess unter der Verwendung des Makefiles mit der Endung ARMI an. Die dabei entstandenen Dateien mit den Endungen APP und RSC müssen anschließend in eine Installationsdatei verpackt werden, die auf dem Endgerät ausgeführt werden kann. Hierzu wird eine PKG-Datei benötigt, die Installationsinformationen und Systemvoraussetzungen enthält (siehe Abschnitt B). Diese Datei ist mit dem Java-Application-Descriptor (JAD-Datei) bei J2ME zu vergleichen und wird vom Programmierer geschrieben. Die Installationsdatei mit der Endung SIS (siehe Abschnitt C) kann schließlich aus der PKG-Datei generiert werden. Dies geschieht mit Hilfe des Tools makesis. Die Installationsdatei enthält den ausführbaren Programmcode und ist mit einem JAR-Archiv auf der J2ME- Plattform vergleichbar. 18

19 5 Anhang A Projekdefinitionsdatei In der Projektdefinitionsdatei mit der Endung MMP werden alle Informationen aufgelistet, die für das Erstellen der Buildskripte und schließlich der fertigen Anwendung nötig sind. Hier stehen neben allen benötigten Dateien (Sourcecode, Ressourcen) auch die zugehörigen Quell-Pfade, sowie weitere Angaben zur zu erstellenden Datei (Ziel-Pfad, Name, Typ). Weiterhin sind auch sämtliche verwendeten Bibliotheken aufgelistet, die später durch den Linker eingebunden werden müssen. Weiterhin ist auch die aus bis zu drei 32 Bit Werten bestehende Unique ID (UID) enthalten. Die UID teilt dem Betriebssystem z.b. den Typ und den Subtyp der Anwendung mit. Die wichtigste Funktion der UID ist jedoch die eindeutige Identifikation eines Programms. Anhand der UID wird z.b. überprüft, ob ein Programm schon läuft und nur zu ihm gewechselt werden muss, oder ob es neu in den Speicher zu laden ist. Zum Entwickeln können UIDs zwischen 0x und 0x0fffffff verwendet werden. Für Software, die an Kunden ausgeliefert wird, müssen jedoch gültige UIDs bei Symbian beantragt werden. Dies ist kostenlos möglich. TARGET HelloWorld.app TARGETTYPE app UID 0x100039CE 0x10008ACE TARGETPATH \\system\\apps\\helloworld SOURCEPATH. SOURCE HelloWorld_main.cpp SOURCE HelloWorld_Application.cpp SOURCE HelloWorld_Document.cpp SOURCE HelloWorld_AppUi.cpp SOURCE HelloWorld_AppView.cpp USERINCLUDE. SYSTEMINCLUDE \\epoc32\\include RESOURCE HelloWorld.rss LIBRARY euser.lib apparc.lib cone.lib eikcore.lib B Package-Datei Die Package-Datei wird benötigt, um alle Dateien eines Programms in ein Installationspaket zu packen. Zu diesem Zweck enthält das PKG-File Infor- 19

20 mationen über alle zu paketierenden Programmdateien. Weiterhin sind Programmversion, Zielplattform und verfügbare Sprachversionen angegeben. ; Languages &EN,DE ; UID #{"HelloWorld","HalloWelt"},(0x10008ACE),1,0,0 ; Supports Series 60 v 0.9 (0x101F6F88), 0, 0, 0, {"Series60ProductID"} ; Files to install "\Symbian\6.1\Siemens\SX1\bin\Epoc32\release\armi\urel\HelloWorld.app"- "!:\system\apps\helloworld\helloworld.app" "\Symbian\6.1\Siemens\SX1\bin\Epoc32\release\armi\urel\HelloWorld.rsc"- "!:\system\apps\helloworld\helloworld.rsc" "\Symbian\6.1\Siemens\SX1\bin\Epoc32\release\armi\urel\HelloWorld_caption.rsc"- "!:\system\apps\helloworld\helloworld_caption.rsc" "\Symbian\6.1\Siemens\SX1\bin\Epoc32\release\armi\urel\HelloWorld.aif"- "!:\system\apps\helloworld\helloworld.aif" C Installationsdatei Auf Symbian-Endgeräten können Anwendungen aus Installationsarchiven mit der Endung SIS installiert werden. Um eine solche Datei zu erstellen wird ein Package-File benötigt, wie es in Abschnitt B näher beschrieben wurde. Das Tool makesis packt die dort angegebenen Dateien zusammen mit zusätzlichen Metainformationen in eine Installationsdatei. Die fertige Sis-Datei kann schließlich mit Hilfe des im SDK enthaltenen Tools Sisar oder durch den Kommandozeilenaufruf makesis programm.pkg generiert werden. Um die Herkunft einer Installationsdatei zu verifizieren bietet Symbian ein sicheres Softwareinstallationssystem an, welches signierte Software auf ihre Vertrauenwürdigkeit überprüfen kann. Eigene Software kann mit Hilfe des Tools Makekeys signiert werden. Makekeys integriert ein digitales Zertifikat in die Sis-Datei. Somit kann der Softwarehersteller identifiziert werden und es ist sichergestellt, dass die Software nicht von Dritten verändert wurde. 20