Anwendungsentwicklung für Symbian OS

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 5
3.1 Oberflächen des Betriebssystem . . . . . . . . . . . . . . . . . 5
3.2 Dateisystem und Speichermedien . . . . . . . . . . . . . . . . 6
3.3 Speichermanagement . . . . . . . . . . . . . . . . . . . . . . . 8
4 Entwicklung für Symbian OS 9
4.1 Programmiersprachen . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Entwicklungsumgebungen . . . . . . . . . . . . . . . . . . . . 10
4.3 Sichere Speicherverwaltung . . . . . . . . . . . . . . . . . . . . 11
4.4 Erste Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5 Der Buildprozess . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 Anhang 19
A Projekdefinitionsdatei 19
1

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

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 E-Mail 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

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].
1 http://java.sun.com/j2me/
2 http://www.bluetooth.com/bluetooth/
3 Multimedia Messaging Service
4 Synchronization Markup Language, http://www.openmobilealliance.org/syncml/
5 Internet Protocol, Version 6, http://www.ietf.org/rfc/rfc2460.txt
6 http://www.symbian.com/
7 http://www.microsoft.com/windowsmobile/
4

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., http://www.symbian.com
9 Nokia GmbH, http://www.nokia.de/
10 User Interface Quartz, http://www.uiq.com/
5

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.
11 http://www.microsoft.com/windows/
12 Read Only Memory
6

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
14 http://www.compactflash.org/
7

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

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

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.
19 http://www.python.org/
20 Software Development Kit
21 http://msdn.microsoft.com/visualc/
22 http://www.metrowerks.com/
23 http://www.borland.com/downloads/download_cbuilderx.html
24 Integrated Development Environment: Entwicklungsumgebung
10

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

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

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.
4.4.2 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

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

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.
4.5.1 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

ldmake
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.
4.5.2 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

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

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.
4.5.3 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

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 0x01000000 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

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

D
Ressourcen
In Ressourcedateien wird die Benutzerschnittstelle eines Programms definiert.
Neben den in der Anwendung Texten werden hier auch Menüstrukturen
festgelegt. Die Auslagerung von Texten hat den Vorteil, daß eine Anwendung
leicht lokalisiert werden kann. Dafür muss nur die jeweilige Ressource-Datei
ausgetauscht werden. Ein erneutes Kompilieren des Programms ist nicht notwendig,
da Ressourcen dynamisch geladen werden.
NAME HELLOWORLD
#include
#include
#include
#include "helloworld.hrh"
RESOURCE RSS_SIGNATURE {}
RESOURCE EIK_APP_INFO
{
menubar=r_helloworld_menubar;
status_pane=R_AVKON_STATUS_PANE_LAYOUT_USUAL;
cba=R_AVKON_SOFTKEYS_OPTIONS_EXIT;
}
RESOURCE MENU_BAR r_helloworld_menubar
{
titles =
{
MENU_TITLE { menu_pane = r_helloworld_options_menu;
txt = "Options";}
};
}
Ressourcedateien müssen, wie Quellcode auch in ein binäres Format übersetzt
werden. Dies geschieht mit Hilfe des Ressourcencompilers. Dieser erzeugt
aus einer RSS-Datei eine kompilierte Ressource mit der Endung RSC und
eine Ressource-Header-Datei mit der Endung RSG. Die Ressource-Header-
Datei wird schließlich in die Quellcodedateien inkludiert, um hier die symbolischen
IDs der Ressourcen bekannt zu machen.
Neben den RSS-Ressourcedateien gibt es noch AIF-Ressourcen. AIF steht
dabei für Application Information File. Diese Ressource wird bei der Installation
einer Anwendung auf einem Symbian-Gerät berücksichtigt. Sie enthält
21

Informationen darüber, wie ein Programm in die Oberfläche eines Symbian-
Gerätes integriert werden soll und wie dies dargestellt wird. Hier werden sowohl
die Icons einer Anwendung als auch deren Name in verschiedenen Sprachen
abgelegt. Ausserdem kann hier festgelegt werden, ob die Applikation
in den Application-Launcher 34 eingebunden wird. Fehlt die AIF-Ressource,
werden Standard-Icons und Einstellungen verwendet.
Das AIF wird entweder direkt mit dem AIF-Builder 35 oder automatisch
während des Build-Prozesses generiert. Für die automatische Generierung
müssen allerdings die AIF-Informationen in der Projektdefinitionsdatei eingetragen
und zusätzlich eine weitere RSS-Ressource erstellt werden.
#include
RESSOURCE AIF_DATA
{
caption_list =
{
CAPTION { code=ELangEnglisch; caption "HelloWorld!";},
CAPTION { code=ELangGerman; caption "HalloWelt!";},
};
app_uid=0x10008ACE;
num_icons=2;
embeddability=KAppNotEmbeddable;
newfile=KAppDoesNotSupportNewFile;
}
Diese Ressource enthält den Anwendungsnamen in mehreren Sprachen,
die Unique ID, die Anzahl der verwendeten Icons, sowie Informationen darüber,
ob die Anwendung in andere Programme integriert werden kann, und
ob sie neue Dateien erstellen darf. Die Icons, die als Bitmap-Grafik in der Projektdefinitionsdatei
angegeben sind, werden beim Erstellen der AIF-Ressource
in das Multiple-Bitmap-Format (.mbm) umgewandelt und dem AIF hinzugefügt.
34 Hauptmenü eines Smartphones
35 Teil des Symbian SDKs
22

Literatur
[SymbOS] Ansgar Gerlicher, Stephan Rupp: Symbian OS, Dpunkt Verlag,
Mai 2004, ISBN 3898642852
[Task00] Martin Tasker et.al., Professional Symbian Programming, Wrox
Peer Information, 2000, ISBN 186100303X
[Symbian] Symbian, http://www.symbian.com
23