Zusammenfassung - auf ThomasKaelin.ch

Transcription

Mobile Devices
Mobile Devices
Zusammenfassung v1.3
Kälin Thomas, MSE ICT
HS 08/09
Kälin Thomas, Abt I
1/61
20.02.2009
Mobile Devices
1. EINLEITUNG & GRUNDLAGEN .......................................................................................................... 6
1.1. Themengebiete bei Mobile Devices .................................................................................... 6
1.2. Definition ............................................................................................................................ 6
1.2.1.
Gebräuchliche Features ...................................................................................................... 6
1.3. Teile von mobilen Geräten.................................................................................................. 6
1.4. Beispiele für mobile Geräte ................................................................................................ 6
1.4.1.
PDA (Personal Digital Assistant) .......................................................................................... 6
1.4.2.
EDA (Enterprise Digital Assitant) ......................................................................................... 6
2. SPEZIELLE PERIPHERIEGERÄTE ........................................................................................................ 7
2.1. Smart Card.......................................................................................................................... 7
2.2. Barcode............................................................................................................................... 7
2.2.1.
Vor- und Nachteile ............................................................................................................. 7
2.2.2.
Scanner............................................................................................................................. 7
2.3. RFID – Radio Frequency Identification .............................................................................. 7
2.3.1.
Hauptkomponenten............................................................................................................ 7
2.3.2.
Aktive und passive Transponder.......................................................................................... 7
2.3.3.
Frequenzbänder ................................................................................................................. 7
2.3.4.
Einsatzgebiete ................................................................................................................... 7
3. ARCHITEKTUREN ........................................................................................................................... 8
3.1. Generic Architecture........................................................................................................... 8
3.1.1.
Hardware .......................................................................................................................... 8
3.1.2.
Software............................................................................................................................ 8
3.2. System on Chip (SoC) ......................................................................................................... 9
3.2.1.
Mobile eXtreme Convergence (MXC).................................................................................... 9
3.2.2.
Purple Magic .................................................................................................................... 10
3.3. Testplattformen................................................................................................................ 10
3.3.1.
OpenMoko Neo FreeRunner .............................................................................................. 10
3.3.2.
Google Android ................................................................................................................ 10
4. CASE STUDY – TEIL 1 .................................................................................................................. 11
4.1. Einleitung.......................................................................................................................... 11
4.1.1.
USB Kit Architektur........................................................................................................... 11
4.2. Requirements ................................................................................................................... 11
4.3. Technological Choices ...................................................................................................... 11
4.3.1.
Microprozessor................................................................................................................. 11
4.3.2.
Wireless Peripherals ......................................................................................................... 11
4.3.3.
Wired Peripherals............................................................................................................. 12
4.3.4.
Sensors ........................................................................................................................... 12
4.3.5.
Human Interface .............................................................................................................. 12
4.4. Power Requirements ........................................................................................................ 12
4.4.1.
Sorten von Akkus ............................................................................................................. 12
4.5. Vertiefung: ZigBee............................................................................................................ 13
5. CASE STUDY – TEIL 2 (COMMUNICATION) ...................................................................................... 14
5.1. Theoretische Grundlagen ................................................................................................. 14
5.2. Kommunikationstechniken............................................................................................... 14
5.3. Wireless Kommunikation.................................................................................................. 14
5.4. HF-Section ........................................................................................................................ 14
5.4.1.
Transmission Line ............................................................................................................ 14
5.4.2.
Antenne .......................................................................................................................... 15
5.4.3.
HF Electronic ................................................................................................................... 15
5.5. Test Ausrüstung................................................................................................................ 15
5.6. Wichtige Formeln ............................................................................................................. 15
5.6.1.
Beispiel Pathloss .............................................................................................................. 16
5.6.2.
Beispiel: Uplink / Downlink ............................................................................................... 16
6. CASE STUDY – TEIL 3 (DIGITAL SECTION) ...................................................................................... 17
6.1. Der Mikroprozessor .......................................................................................................... 17
6.1.1.
Architekturen ................................................................................................................... 17
2/61
20.02.2009
Mobile Devices
6.2. Der Kernel......................................................................................................................... 17
6.3. System Memory ................................................................................................................ 17
6.4. Elektrisches Design .......................................................................................................... 17
6.4.1.
PCB-Layout...................................................................................................................... 17
6.5. Produktion und Verifikation ............................................................................................. 18
6.6. Implementierung der Firmware ....................................................................................... 18
6.7. Von FPGA zu ASIC............................................................................................................. 18
7. SYMBIAN OS (ARCHITEKTUR)....................................................................................................... 19
7.1. Einleitung.......................................................................................................................... 19
7.1.1.
Gerätetypen..................................................................................................................... 19
7.1.2.
Mobile vs PC .................................................................................................................... 19
7.1.3.
Betriebssysteme............................................................................................................... 19
7.1.4.
Programmiersprachen ...................................................................................................... 19
7.1.5.
Design-Ziele..................................................................................................................... 19
7.2. Systemarchitektur ............................................................................................................ 20
7.2.1.
Schichten-Architektur ....................................................................................................... 20
7.2.2.
UI-Layer .......................................................................................................................... 20
7.2.3.
Grundlegende Konzepte ................................................................................................... 20
7.3. Memory Model .................................................................................................................. 20
7.3.1.
Zweistufiges Mapping ....................................................................................................... 20
7.3.2.
Memory-Modelle .............................................................................................................. 21
7.3.3.
Moving Model (ARMv5)..................................................................................................... 21
7.3.4.
Multiple Model (ARMv6).................................................................................................... 22
7.4. Sicherheit.......................................................................................................................... 22
7.4.1.
Trust Model ..................................................................................................................... 22
7.4.2.
Capabilities ...................................................................................................................... 23
7.4.3.
Data Caging..................................................................................................................... 23
7.4.4.
Identifiers........................................................................................................................ 24
7.4.5.
Signierung der Anwendungen ........................................................................................... 24
8. SYMBIAN OS (PROGRAMMIERUNG) ............................................................................................... 25
8.1. Eigenheiten von Symbian C++......................................................................................... 25
8.1.1.
Datentypen...................................................................................................................... 25
8.1.2.
String-Konstanten ............................................................................................................ 25
8.1.3.
Writable Static Data (WSD)............................................................................................... 25
8.1.4.
Error Handling ................................................................................................................. 25
8.1.5.
Stack-Grösse.................................................................................................................... 25
8.1.6.
Objekterzeugung auf dem Heap........................................................................................ 25
8.1.7.
Deskriptoren .................................................................................................................... 25
8.2. Konventionen ................................................................................................................... 25
8.2.1.
Präfixe für Klassennamen ................................................................................................. 25
8.2.2.
Postfixe für Methodennamen ............................................................................................ 25
8.2.3.
Prefixe für Variablen......................................................................................................... 26
8.3. Error-Handling .................................................................................................................. 26
8.3.1.
Regeln............................................................................................................................. 26
8.3.2.
Leaves von Methoden abfangen ........................................................................................ 26
8.3.3.
Cleanup Stack .................................................................................................................. 26
8.3.4.
Two-Phase Construction ................................................................................................... 26
8.4. Aktive Objekte .................................................................................................................. 27
8.4.1.
Grundprinzip .................................................................................................................... 27
8.4.2.
Implementierung: Active Object........................................................................................ 27
8.4.3.
Aktive Objekte vs Threads ................................................................................................ 27
8.5. Hello-World für die Konsole ............................................................................................. 28
8.5.1.
Header-Datei ................................................................................................................... 28
8.5.2.
Quellcode-Datei ............................................................................................................... 28
8.6. GUI-Programmierung ....................................................................................................... 29
8.6.1.
S60 vs UIQ ...................................................................................................................... 30
9. WINDOWS CE (ARCHITEKTUR) .....................................................................................................31
9.1. Allgemeine Informationen ............................................................................................... 31
3/61
20.02.2009
Mobile Devices
9.2. Applikationsentwicklung .................................................................................................. 31
9.3. Systemarchitektur (v6.0) ................................................................................................. 31
9.4. Das Speichermodell (v6.0) ............................................................................................... 31
9.4.1.
Static Mapped Memory ..................................................................................................... 32
9.4.2.
Cached vs Uncached Memory ........................................................................................... 32
9.5. Scheduling ........................................................................................................................ 32
9.5.1.
Prioritäten & Priority Inversion .......................................................................................... 33
9.6. Realtime / Interrupt Verarbeitung................................................................................... 33
9.7. Gerätetreiber .................................................................................................................... 34
9.8. Sicherheit.......................................................................................................................... 34
10. WINDOWS CE (PROGRAMMIERUNG) .............................................................................................. 35
10.1. Möglichkeiten zur Programmierungen ............................................................................. 35
10.2. Ungarische Notation ......................................................................................................... 35
10.3. Error Handling .................................................................................................................. 36
10.4. Message Loop ................................................................................................................... 36
10.5. Win32 – Hello World......................................................................................................... 37
10.6. Win32 – Komplexere Anwendung .................................................................................... 37
11. APPLICATION FRAMEWORKS ......................................................................................................... 39
11.1. Java ME............................................................................................................................. 39
11.1.1. Unterschied JME und JSE.................................................................................................. 39
11.1.2. Konfigurationen und Profile............................................................................................... 39
11.1.3. Java Community Process (JCP) und Java Specification Requests (JSR) ................................ 39
11.1.4. Mobile Service Architecture (JSR-248) ............................................................................... 40
11.1.5. Java ME Virtual Machine ................................................................................................... 40
11.1.6. MIDlets ........................................................................................................................... 40
11.1.7. JAR und JAD .................................................................................................................... 41
11.2. Java FX.............................................................................................................................. 41
11.3. Windows Mobile (Windows CE)........................................................................................ 41
11.3.1. Programmierung: Win32 vs .NET Compact Framework ....................................................... 41
11.3.2. Garbage Collection ........................................................................................................... 41
11.3.3. .NET CF vs JME................................................................................................................ 42
11.3.4. GUI-Programmierung ....................................................................................................... 42
11.4. Google Android ................................................................................................................. 42
11.4.1. GUI-Programmierung ....................................................................................................... 42
11.4.2. Datenbankzugriff.............................................................................................................. 42
11.5. Apple OS X (iPhone) ......................................................................................................... 43
11.6. Symbian OS ...................................................................................................................... 43
11.7. BREW – Binary Runtime Environment for Wireless ......................................................... 43
11.8. Blackberry......................................................................................................................... 43
11.9. Native vs Managed Applications....................................................................................... 43
11.10.
Vergleich der Plattformen – Teil 1 ............................................................................ 43
11.11.
Vergleich der Plattformen – Teil 2 ............................................................................ 44
12. JAVA ME – ENTWICKLUNG EINES MIDLETS ..................................................................................... 45
12.1. Arbeitsschritte .................................................................................................................. 45
12.2. Grundstruktur eines MIDlet ............................................................................................. 45
12.3. High-Level vs Low-Level GUI ........................................................................................... 45
12.4. Eventhandling................................................................................................................... 45
12.5. GUI-Elemente ................................................................................................................... 46
12.5.1. Display und Screen........................................................................................................... 46
12.5.2. Alert................................................................................................................................ 46
12.5.3. Listen .............................................................................................................................. 46
12.5.4. Formulare........................................................................................................................ 46
12.6. Beispielanwendung – Adressbuch.................................................................................... 46
13. JAVA ME – APPLICATION DESIGN.................................................................................................. 49
13.1. Persistente Datenspeicherung (RMS) .............................................................................. 49
13.2. JME GUI ............................................................................................................................ 50
13.2.1. Problem von LCDUI .......................................................................................................... 50
13.2.2. Kommerzielle GUI Tookits................................................................................................. 50
4/61
20.02.2009
Mobile Devices
13.2.3. Patterns für JME-GUI........................................................................................................ 50
13.3. Starten von Anwendungen ............................................................................................... 51
13.4. Over the Air (OTA) Deployment........................................................................................ 51
13.5. Threads ............................................................................................................................. 51
13.5.1. Grundlagen...................................................................................................................... 51
13.5.2. Stoppen von Threads ....................................................................................................... 51
13.6. Sicherheitsfunktionen ...................................................................................................... 52
14. NETWORK PROGRAMMING ............................................................................................................ 53
14.1. Designprobleme bei Netzwerken ..................................................................................... 53
14.1.1. Private IP-Adressen .......................................................................................................... 53
14.1.2. Belastung für Server......................................................................................................... 53
14.1.3. TCP / IP .......................................................................................................................... 53
14.1.4. Erreichbarkeit von Mobilgeräten ........................................................................................ 53
14.2. Low-Level Programmierung ............................................................................................. 54
14.2.1. Verbindungsorientiert / verbindungslos.............................................................................. 54
14.2.2. Sockets in C..................................................................................................................... 54
14.3. High-Level Programmierung ............................................................................................ 55
14.3.1. Vergleich: JME mit GCF und Windows Mobile mit WCF ....................................................... 55
14.3.2. Windows Mobile – WCF .................................................................................................... 55
14.3.3. Java ME – GCF................................................................................................................. 56
14.4. Protokoll und Applikationsdesign..................................................................................... 56
14.4.1. Mögliche Probleme ........................................................................................................... 56
14.4.2. Mögliche Gegenmassnahmen ............................................................................................ 56
14.5. WAP – Wireless Application Protocol ............................................................................... 57
14.5.1. Grundlegendes................................................................................................................. 57
14.5.2. Kommunikationsmodell..................................................................................................... 57
14.5.3. WAP 1.0 .......................................................................................................................... 57
14.5.4. WAP 2.0 .......................................................................................................................... 57
14.5.5. WAP Push........................................................................................................................ 57
14.6. OBEX – Object Exchange .................................................................................................. 58
15. MOBILE APPLICATION DESIGN ......................................................................................................59
15.1. Allgemeine Architektur mobiler Anwendungen ............................................................... 59
15.2. Design Prinzipien.............................................................................................................. 59
15.2.1. Einschränkende Faktoren.................................................................................................. 59
15.2.2. Allgemeine Lösungsansätze .............................................................................................. 59
15.2.3. Spezielle Probleme und Lösungsansätze ............................................................................ 59
15.3. Persistente Speicherung................................................................................................... 59
15.3.1. Anforderungen an eine mobile Datenbank ......................................................................... 59
15.3.2. Typen von Datenbanken................................................................................................... 60
15.3.3. Möglichkeiten von Microsoft .NET CF ................................................................................. 60
15.4. Starten und Beenden von mobilen Anwendungen ...........................................................60
15.4.1. Spezielles für JME ............................................................................................................ 60
15.4.2. Spezielles für .NET CF ...................................................................................................... 60
15.5. Synchronisierung von Daten ............................................................................................ 60
15.5.1. SyncML (Java ME) ............................................................................................................ 60
15.5.2. ActiveSync (Windows Mobile)............................................................................................ 61
15.5.3. SQL Server Compact (Windows Mobile) ............................................................................. 61
5/61
20.02.2009
Mobile Devices
1.
EINLEITUNG & GRUNDLAGEN
1.1. Themengebiete bei Mobile Devices
Ein Mobile Device Entwickler braucht Ahnung von allen ihn tangierenden Themen. Die Kenntnis von
nur einem Themengebiet genügt nicht.
Signal Transport Channels
Antennen
Hardware für Übertragungsplattformen
Firmware und Software (Netzwerke, Algorithmen und Protokolle)
Integration von Sicherheit (Crypto-Koprozessor)
Netzwerk Leistungsüberprüfung
NIR (Non-Ionizing Radiation) Emissionen: Elektrosmog
1.2. Definition
A mobile device is typically a handhelf device that can conveniently be stored in a pocket and used
while you’re holding it. It can run business logic, store data, perform network communication, voice
and data communication. It may offer integrated data capture devices like bar code, RFID, smart card
reader and present a richt user interface.
1.2.1.
Gebräuchliche Features
Grösse im Taschenformat
Wird in der Hand gehalten
Licht
Interne Spannungsversorgung (Durchhaltezeit der Batterie ist immens wichtig!)
Konnektivität (Indoor wie WLAN, Outdoor wie GPS oder GSM)
User Interfaces (Input wie Tastaturen und Mikrophone, Output wie Display und Speaker)
Erweiterbarer Speicher
Sensoren (Licht, Temperatur, Druck, Beschleunigung)
Integrierte Datenerfassungsgeräte (RFID, Barcode, Kamera)
1.3. Teile von mobilen Geräten
Display (Touch Screen, Rollable Display, LCD)
Mikrofon und Lautsprecher
Tastatur (Touch / Tap Screen, Laser Keyboard, externes wireless / wired Keyboard)
Wired / Wireless Konnektivität (USB, IEEE1394, IrDa, ZigBee, Bluetooth, WLAN, GSM, UMTS, …)
o Wichtige Überlegung: welche Dienste werden wirklich benötigt?
Sensoren (Beschleunigung, Temperatur, Druck, Licht)
Integrierte Datenerfassungsgeräte (Kamera, Barcode-Scanner, RFID-Reader, Smartcard Reader)
Batterie (Kapazität, Abmessung, Gewicht, Ladungszyklen, Spannung)
o Problematisch: verschiedene Spannungen gleichzeitig benötigt eine Management-Elektronik zur
Umwandlung. Wärmeverlust sollte vermieden werden!
1.4. Beispiele für mobile Geräte
1.4.1.
PDA (Personal Digital Assistant)
PDAs are used to organize meetings, contacts and notes that can be access at anytime and anywhere.
Features are: Touchscreen, memorycard-slot, wired/wireless-connectivity, synchronization of data
with a PC.
Übliche Hardware: 200 – 400 MHz CPU, 64 MB RAM, 128 MB Flash.
Übliche OS sind: PalmOS, Windows Mobile, iPhone OS, Symbian OS, Linux-based OS
1.4.2.
EDA (Enterprise Digital Assitant)
EDAs allow business applications to combine a portable device with their data warehouse systems.
Same features as PDA, extend with integrated data capture devices.
Verwendungszweck: Inventarkontrolle, Bestellungsaufnahme in Restaurants
6/61
20.02.2009
Mobile Devices
2.
SPEZIELLE PERIPHERIEGERÄTE
2.1. Smart Card
Plastikkarte mit einem integrierten Mikrochip
Lesegeräte mit Kontakt (8 Pins) und kontaktlos (Nähe zur Antenne) mittels RFID-Technologie
Verwendung: Sicherheitssysteme (Crypto-Cards), Zahlungssysteme, Gesundheitskarten
2.2. Barcode
Eindimensional
Zweidimensional
1D-Barcodes haben weniger Speicherplatz als 2D-Barcodes
2D-Barcodes haben mehr Informationen auf weniger Fläche
Einsatzgebiete: Verkauf, Post, Objekt-Tracking
2.2.1.
Vor- und Nachteile
Pro: Öffentlicher Standard, bekannte Technologie, sehr billig
Kontra: Beschränkter Speicherplatz, unveränderlich, Sichtkontakt nötig, evt. Unlesbarkeit
2.2.2.
Scanner
Lesegerät erfasst mit optischem CCD-Sensor den Code und kann den Code in eine computerverständliche Repräsentation umwandeln.
2.3. RFID – Radio Frequency Identification
2.3.1.
Hauptkomponenten
Reader: Kommuniziert mit Anwendung oder Middleware, Kommuniziert mit Tags
Antenne: Verschiedene Bauarten (Omni, Schleusen, …)
Transponder: Enthält Antenne und Mikrochip, aktiv oder passiv
Middleware: optionale Komponente, validiert / filtert / speichert Daten der Reader
2.3.2.
Aktive und passive Transponder
Passiv: Spannung wird dem elektromagnetischen Feld des Readers entzogen, sehr billig (~1 Dollar)
Aktiv: Integrierte Batterie, höhere Reichweite, grössere Bauform, teurer (~30 Dollar)
2.3.3.
Frequenzbänder
LF: 120kHz .. 145kHz
HF: 13.56 MHz
UHF: 865.6 MHz .. 867.6 MHz, 868 MHz .. 869 MHz (in Europa, USA anders)
MW: 2.4GHz .. 2.483 GHz (in Europa, USA anders)
2.3.4.
Einsatzgebiete
Objekttracking
Warenmanagement in Warenhäusern
Zugangskontrolle
7/61
20.02.2009
Mobile Devices
3.
ARCHITEKTUREN
3.1. Generic Architecture
Bei diesem Ansatz sind jegliche Elemente als komplette „Bausteine“ verfügbar. Durch Modularisierung
und Standardisierung können einmal entwickelte Bausteine in anderen Projekten eingesetzt werden
und es entsteht ein hochgradig anpassbares Design. Ausserdem ist das Debugging einfach, da für
jede Funktion ein eigener Baustein vorhanden ist.
Im Gegenzug fallen sehr hohe Entwicklungskosten an, da eine generalisierte und spezialisierte
Hardware entworfen werden muss. Diese Architektur eignet sich deshalb besonders für „Proof-ofConcepts“ und „Rapid Prototyping“.
3.1.1.
Mikroprozessor: 8–32 bit Adressraum, RISC (Reduced Instruction Set Computing), Brücke HW/SW
Wired Communication: Modem, RS232, USB, Ethernet (meist als „Bausteine“ verfügbar)
Wireless Communication: IrDA, Wi-Fi, GSM, GPRS
Human-Computer Interaction: Touch Screen, Keypad, Jog Dial, GPIO (General Purpose I/O)
Audio/Video: Hardware Codec, Mikrofon, Lautsprecher, LCD, Kamera
Power Management Unit (PMU): Voltage Reg benötigt, da theoretisch jedes Bauteil seine eigene
Betriebsspannung benötigen kann.
3.1.2.
Hardware
Software
Display: Graphic Server (Mapping), Window Manager (Object Colour)
Mobile Telephony and Data: GSM Modem Controller, GPRS-Scripts
CODEC: VoIP, Audio (mp3), Video (mp4)
Operating System: Linux, Symbian, Windows Mobile, …
8/61
20.02.2009
Mobile Devices
3.2. System on Chip (SoC)
Im Gegensatz zum vorherigen Ansatz werden bei dieser Architektur praktisch alle wichtigen Elemente
direkt auf einem Chip integriert, woraus ein kompakteres Design und eine einfachere
Stromversorgung resultieren. An den SoC werden dann nur noch externe Geräte (Reader, Bluetooth,
…) angeschlossen. Durch das kompaktere Design sinken die Design- und Produktionskosten, es eignet
sich somit für Massenproduktionen.
Als Nachteil ist das sehr komplexe Debugging der Hardware zu nennen, ausserdem können keine
Anpassungen an Chip vorgenommen werden (was unter Umständen bedeutet, dass keine weiteren
externen Geräte angesprochen werden können).
3.2.1.
Mobile eXtreme Convergence (MXC)
Hierbei handelt es sich um eine stark spezialisierte SoC-Architektur, welche für den gezielten Einsatz
bei Mobiltelefonen entworfen wurde. Jegliche für Mobiltelefone überflüssigen Komponenten wurden
weggelassen. Durch den Verzicht auf überflüssige Elemente resultiert ein kleineres PCB.
9/61
20.02.2009
Mobile Devices
MXC enthält in der Architektur eine CPU mit OS (Symbian oder Linux), einen separaten Prozessor für
das Modem und Module für GSM, GPRS, EDGE und UMTS. Der Entwickler muss sich somit nicht um
die Plattform für Mobilkommunikation kümmern. Ferner können optional Bluetooth, WiFi und GPSGeräte angeschlossen werden.
3.2.2.
Purple Magic
Bei Purple Magic handelt es sich um ein low-cost Referenzdesign für Mobiltelefone, welche auf einem
stark spezialiserten SoC-Ansatz basiert. In der Basis-Spezifikation sind bereits Module für GSM, GPRS,
EDGE und UMTS enthalten. Ausserdem ist der Prozessor VIRTUALISIERUNGSFÄHIG, dass heisst: ein
Prozessor kann von verschiedenen unabhängigen System („Gastsysteme“) ohne Anpassung verwendet
werden. Das spart Kosten und Energie, da auf einen zweiten Prozessor verzichtet werden kann. Die
Gastsysteme können untereinander kommunizieren.
3.3.Testplattformen
Ziel dieses Skripts: zeigen, dass nicht alles komplett selber gemacht werden muss, sondern auf Basis
von bestehenden Architekturen die Produktionszeit und Produktionskosten reduziert werden können.
3.3.1.
OpenMoko Neo FreeRunner
Open Source Mobiltelefon
Software / Schematics / Designs frei verfügbar
Kann als Basis für ein self-customized System verwendet werden
3.3.2.
Google Android
Application Framework mit integriertem Browser und SQLit Datenbank
Basiert auf Linux und enthält eine eigene Java VM
Unterstützung für GSM, GPS, Bluetooth, Kamera, …
10/61
20.02.2009
Mobile Devices
4.
CASE STUDY – TEIL 1
4.1. Einleitung
Ziel der Case Study ist es, einen Demonstrator („Proof of Concept“) und ein USB-Dongle („Prototyp
der Baumform“) für eine neue, ultra low-power Prozessorfamilie zu entwickeln. Zur Kommunikation
soll eine Schnittstelle für WPAN enthalten sein, da das Gerät als WSN-Modul verwendet werden soll.
4.1.1.
USB Kit Architektur
Der CPU-Core des USB-Kits wird in einer ersten Version als ein FPGA (Field Programmable Gate Array)
entworfen. Dadurch kann die CPU-Logik während der Entwicklung auf bequeme Art und Weise
angepasst werden. Erst in einem zweiten Schritt wird aus dem Prototyp ein 16bit Silizium-Chip (RISC)
entwickelt.
Speziell ist, dass der FPGA-Chip einen „AES Cryptor“ besitzt. Dies hat den Grund, dass beim Schreiben
der Logik jegliche Daten symmetrisch verschlüsselt werden. Somit wird ein anschliessendes Auslesen
der Applikationslogik verunmöglicht.
4.2. Requirements
Speziell hervorzuheben sind, dass jegliche eingesetzt Software und Libraries komplett Open Source
sein müssen. Natürlich soll auch der Energieverbrauch auf ein Minimum reduziert werden. Weiter
sollen verschiedene Schnittstellen (USB, RS232, …) eingebaut werden. Die Komponenten sollen JTAG
unterstützen. Dadurch wird das Debugging stark vereinfacht.
4.3. Technological Choices
4.3.1.
Microprozessor
Üblicherweise erhält der Prozessor (8, 16 oder 32 bit Datenbus) verschiedene CO-PROZESSOREN zur
Unterstützung bei bestimmten Berechnungen. Beispiele sind:
FPU = Floating Point Unit (grundlegende arithmetische Operationen), üblicherw. in MPU enthalten
GPU = Graphic Processing Unit (Grafisches Rendering, primitive Zeichenoperationen)
DSP = Digital Signal Processing (Echt-Zeit Berechnung)
Oft werden auch CRYPTO CONTROLLER eingesetzt. Grund dafür ist die hohe CPU-Belastung bei der
Berechnung von Verschlüsselungen. Diese würde ohne zusätzlichen Chip den Hauptprozessor 100%ig
auslasten.
4.3.2.
Wireless Peripherals
11/61
20.02.2009
Mobile Devices
4.3.3.
Wired Peripherals
RS-232: Standard für die serielle Punkt-zu-Punkt Datenübertragung. Asynchrone Datenübertragung
bis 19.2kbit/s und über maximal 100 Meter.
USB: Serieller Bus um Schnittstellen-Geräte mit einem Host-Computer zu verbinden. Maximal 127
Geräte an einem Controller, je nach Version 12MBit/s (V 1.0 und V1.1), 480 MBit/s (V 2.0) oder 4.8
GBit/s (V 3.0) über maximal 5 Meter möglich ohne Hubs, bis 30 Meter mit Hubs.
ETHERNET: Sammlung von Standards für lokale Netzwerke (LANs). Je nach Typ unterschiedliche
Bandbreiten (10 MBit/s, 100 MBit/s, 1000 MBit/s) und Distanzen. Oft besitzen Geräte zur
Fernwartung eine Ethernet-Schnittstelle.
4.3.4.
Sensors
Sensoren messen physikalische Daten und konvertieren diesen in einen für Computer verständlichen
Wert. Sensoren gibt es in vielen verschiedenen Ausführungen (Licht, Druck, Temperatur, Infrarot,
Beschleunigung).
Moderne Sensoren werden meistens mittels der MEMS (MICRO ELECTOMECHANICAL SYSTEMS)
Technologie entworfen. Dabei werden elektronische Schaltungen mit winzigen mechanischen
Systemen kombiniert (Beispiel: Beschleunigungssensor mit beheizter Gas-Blase).
Besitzen die MEMS optische Komponenten, so werden sie MOEMS (MICRO OPTO-ELECTROMECHANICAL SYSTEM) genannt. Beispiel: Kleiner Beamer in einem Mobiltelefon.
4.3.5.
Human Interface
HUMAN INTERFACES: Keyboard, Jog Dial, Touch Screen, Handwriting Recognition
CAMERA: Oftmals zwei grafische Sensoren – einer für Bildaufnahmen (hohe Auflösungen) und einer
für Video Streaming (tiefe Auflösung). Zwei verschiedene Sensoren CCD (Voltlevels müssen noch zu
Bildern verarbeitet werden) und CMOS (Umwandlung direkt in der Zelle umgesetzt). Beide Sensoren
erzeugen nur Monochrom-Bilder, für Farben muss ein Color-Filter eingesetzt werden.
GPS DEVICE: Oft ein eigener Koprozessor zur Verarbeitung der Daten. Die Antenne ist das
wichtigste Element, sie beeinflusst stark die Leistung des Empfängers.
4.4. Power Requirements
In diesem Entwicklungsschritt macht man sich Gedanken über externe (Netzteil, USB, …) und interne
(Akku, Batterie) Speisung. Unser Proof of Concept bezieht seine Speisung direkt über USB und lädt
damit auch den integrierten Lithium Ionen Akku.
4.4.1.
Sorten von Akkus
NICKEL-CADIUM: Einsatz in Autos, kann schnell aufgeladen werden, entlädt sich selber und besitzt
einen Memoryeffekt.
NICKEL-METAL HYDRIDE: Verwendung in portablen elektronischen Geräten, ist leicht und
leistungsstark, entlädt sich jedoch selber und besitzt einen schwachen Memoryeffekt.
LITHIUM ION: Einsatz in Mobiltelefonen und Notebooks, extrem leistungsstark, kein Memoryeffekt
und kaum Selbstentladung. Dafür ziemlich Teuer und entzündbar.
ALKALINE: Verwendung in verschiedenen elektronischen Systemen, keine Selbstentladung,
maximale Anzahl Ladungen beschränkt.
12/61
20.02.2009
Mobile Devices
4.5. Vertiefung: ZigBee
Zigbee wurde für Wireless Sensor Netzwerke entworfen. Hauptziele sind tiefe Kosten und eine
geringe Leistungsaufnahme.
Einsatz in: Sensoren, Automation, PC-Peripherals
Einsatz im WPAN- und WLAN-Bereich bei Datenraten zwischen 0.01 – 0.1 MBit/s
3 Klassen:
o @868MHZ, 20 KBit/s, BPSK (Binary Phase Shift Keying, zwei Punkte [0°, 180°])
o @915MHZ, 40 KBit/s, BPSK (Binary Phase Shift Keying, zwei Punkte [0°, 180°])
o @2.4GHZ, 250KBit/s, OQPSK (Offset Quadrature Phase Shift Keying, 4 Punkte [45°, 135°, …])
Drei Gerätetypen auf MAC-Layer:
o NETWORK COORDINATOR: Gerät mit den meisten Funktionen. Speichert Informationen über
Netzwerk und bildet die Wurzel der Baum-Topologie. Kann als Brücke zu anderen Netzwerken
fungieren. Nur einmal in einem ZigBee-Netz vorhanden.
o FULL FUNCTION DEVICE (FFD): Fungiert als erweiterter Router (Weiterleiten von Datenpakete
anderer Geräte).
o REDUCED FUNCTION DEVICE: Gerade genug „Intelligent“ um mit den Elternknoten zu
kommunizieren.
13/61
20.02.2009
Mobile Devices
5.
CASE STUDY – TEIL 2 (COMMUNICATION)
5.1. Theoretische Grundlagen
KOMMUNIKATIONSMETHODEN: Simplex, Half-Duplex, Full-Duplex
o FDD: Frequency Division Duplex (Unterschiedliche Bänder für Up- und Downlink)
o TDD: Time Division Duplex (Unterschiedliche Zeitslots für Up- und Downlink, selbe Frequenz)
o FDMA: Frequency Division Multiple Access (Benutzertrennung durch untersch. Frequenzbänder)
o TDMA: Time Division Multiple Access (Benutzertrennung durch untersch. Timeslots)
o CMDA: Code Division Multiple Access (Benutzertrennung durch orthogonale Codes)
ÜBERTRAGUNGSMODI VON UP- UND DOWNLINK: Symmetrisch, Asymmetrisch
5.2. Kommunikationstechniken
SINGLE-ENDED: ein Draht überträgt das Signal, ein weiterer ist als „Ground“ angeschlossen. Ist billig
und es werden weniger Drähte benötigt (Leitungen = Signale + 1, zusätzliche Leitung für Ground).
Dafür wird am Kanalende das Noise nicht gefiltert.
DIFFERENTIAL-SIGNALING: Zwei invertierte Signale werden über zwei separate Leitungen
übertragen. Am Ende des Kanals kann dadurch das Noise weg subtrahiert werden. Durch Verdrillung
der Adern kann das Rauschen weiter reduziert werden. Wird eingesetzt in: USB und Ethernet.
5.3. Wireless Kommunikation
Grundsätzlich drei Möglichkeiten zur drahtlosen Übertragung: Radio- und Mikrowellenfrequenzen,
Infrarot, Laser.
Frequenzbänder werden weltweit von Organisationen verwaltet. Einzig das ISM-Band (2.4GHz) ist
weltweit frei verfügbar. Bei allen anderen Frequenzbändern gibt es lokale Unterschiede.
Nicht-Ionisierende Strahlung („Elektrosmog“) kann, abhängig von der Intensität, die Gesundheit von
Lebewesen bedrohen. Darum beschäftigt sich die ONIR (Ordinance relating to Protection from NonIonising Radiation) mit der Spezifikation von Grenzwerten (SHORT-TERM und LONG-TERM Exposure,
Unterscheidung in Zeitdauer der Strahlenbelastung).
5.4. HF-Section
5.4.1.
Transmission Line
Eine „Transmission Line“ ist das Medium, welches elektromagnetische oder optische Wellen
überträgt. Beispiele sind: Drähte, Coaxial-Kabel, optische Glasfasern.
Eine Daumenregel sagt, dass ein Kabel als Transmission Line betrachtet werden sollte, wenn die
Länge grösser ist als 1/10 der Wellenlänge.
Die Berechnung von Widerständen (Beispiele: MICROSTRIP, STRIPLINE) kann ziemlich komplex sein.
Das Programm AppCad unterstützt beim Berechnen der Werte.
14/61
20.02.2009
Mobile Devices
5.4.2.
Antenne
Die Antenne wandelt elektrische Signale in elektromagnetische Wellen um.
Daumenregeln für finden der „idealen“ Antenne:
o Halbierung der Frequenz verdoppelt die Reichweite.
o Grössere Antennen haben bessere Leistung („Gain“).
Die Berechnungen von Dämpfungen und Empfangsleistungen können ziemlich komplex sein (siehe
Formeln). Zur Unterstützung gibt es moderne Software (Beispiel: WinProp) zur 3D-Berechnung von
Signalstärken in Häusern.
Typ
PCB Antenne
Chip Antenne
Pro
- billig
- Gute Leistung möglich
- Kleine Grösse für hohe Frequenz
- klein
Whip Antenne
- gute Leistung
5.4.3.
Cons
- Effizient & klein = schwieriges Design
- Für tiefe Frequenzen grosse Antenne
-
durchschnittliche Leistung
durchschnittliche Kosten
hohe Kosten
gross, somit oft nicht möglich
HF Electronic
Hochfrequenz-Verstärker:
o Diskrete Schaltungslösung: viel manuelle Arbeit, viel Platz auf PCB, hohe Entwicklungszeit
o Modulare Lösung: keine manuelle Arbeit, wenig Platz auf PCB, geringe Entwicklungszeit
Der „Gain“ misst die Fähigkeit eines Verstärkers die Leistungsamplitude zu erhöhen.
5.5. Test Ausrüstung
OSZILLOSZKOP: Zeigt Frequenz in Relation zur Zeit an
SPECTRUM ANALYZER: Zeigt das Frequenzspektrum eines Signals an
NETWORK ANALYZER: Analysiert die Eigenschaften eines elektrischen Netzwerks.
5.6. Wichtige Formeln
dB-Power
dBm
Wellenlänge
P 
LdB = 10 * log 1 
 P0 
 P[mW ] 
x = 10 * log

 1[mW ] 
c
299'972'458m / s
λ=
=
f [ Hz ]
f
15/61
0 dBm = 1mw
10 dBm = 10 mW
20 dBm = 100 mW
20.02.2009
Mobile Devices
PRX , PTX = [mW ]
Receive Power
 G *G *λ
PRX = PTX  TX 2 RX n
 (4π ) * d
2



GRX , GTX = [dBi ]
d = Strecke[m]
n=2
 f 
 d 
PL(d ) = 32.4dB + 20 * log
 + 10 * n * log 
 1GHz 
 1m 
Path Loss
Gain
Signal to Noise
5.6.1.
 Pout 
g = 10 * log
[dB]
 Pin 
 Psignal 
SNR = 10 * log
[dB ]
 Pnoise 
Beispiel Pathloss
PTX = 0dBm = 1mw
GTX = G RX = 1dBi
f = 2.445GHz
λ=
c 299'972'458m / s
=
= 0.12269m
f
2.445 * 10 9
PRX
 GTX * G RX * λ2 
 1dBi *1dBi * 0.12269 2


= PTX 
n
2
 = 1mW  (4π ) 2 * (100m) 2
(
4
π
)
*
d



d = 100m

 = 3.812 * 10 −10 mW = − 80.21dBm

Liegt die Sensitivität der Empfangsantenne unter dem Wert von -80.21dBm, so kann das empfangene
Signal nicht mehr erkannt werden. Wir brauchen eine bessere Antenne, bzw. mehr Sendeleistung. Die
Differenz von der Sende zur Empfangsleistung entspricht dem PATH LOSS (hier: 80.21 dB).
5.6.2.
Beispiel: Uplink / Downlink
Bei GSM ist das tiefere Frequenzband üblicherweise das Uplink-Band. Das liegt daran, dass mit
steigenden Frequenzen der Path-Loss grösser, bzw. die Leistung bei der Empfangsantenne kleiner
wird. Damit die Handy-Antennen weniger Leistung benötigen ist es empfehlenswert, dies so zu
wählen.
16/61
20.02.2009
Mobile Devices
6.
CASE STUDY – TEIL 3 (DIGITAL SECTION)
6.1. Der Mikroprozessor
Die Wahl der geeigneten CPU ist eine schwierig, aber ungemein wichtige Entscheidung beim
Projektstart. Eine falsche Wahl kann schwerwiegende und teure Folgen nach sich ziehen.
Prozessoren unterscheiden sich in der Regel stark beim Takt, Speicher, dem Adressbus (8, 16 oder
32bit) und der Anzahl an IO-Schnittstellen (GIPOs).
Wichtig: Unterstützung von JTAG für einfacheres Debugging.
Der Energieverbrauch steigt proportional zum CPU-Takt, aber nicht zur Temperatur.
6.1.1.
Architekturen
AVR: 8-bit RISC, Programm- und Datenspeicher getrennt, kein externer Speicher benötigt.
ARM: 32-bit RISC, sehr gute Stromsparfunktionen, geeignet für tragbare Geräte (keine Desktops)
MSP430: 16bit, tiefe Kosten und tiefer Spannungsverbrauch, kein externer Memorybus möglich
REISC: 16bit, konfigurierbar (flexible Grösse des Datenbusses), external RAM möglich
6.2. Der Kernel
Der Kernel ist „das erste Programm, das auf der CPU läuft“.
ON TIME RTOS: 32- und 64-bit CPU, für i386 und höher, mindestens 16kB ROM, Royalty Free
ECOS: Viele versch. Architekturen, enthält auch Applikationen, Royalty Free
UC/OS-II: Verschiedene Architekturen (ARM, MIPS, PowerPC), nur gerade 2kB ROM, Realtime
Multitasking CPU, für kommerzielle Nutzung Lizenz nötig
EMBEDDED LINUX: Für Mikrocontroller ohne MMU, viele verfügbare Anwendungen und Bibliotheken,
benötigt 4 MB RAM, Free Software
TINYOS: Für AVR und MSP430, Kernel abhängig von Komponenten, Zielgruppe „Wireless Sensor
Networks“, Free Software
FREE RTOS: Viele versch. Architekturen, geeignet für embedded Devices, Free Software
6.3. System Memory
RAM: Verwendet als temporärer (flüchtiger) Datenspeicher
o DRAM: Dynamic RAM, benötigt periodischer Refresh
o SDRAM: Synchronous DRAM, wartet auf Clock-Signarl für Antwort
o SRAM: Static RAM, benötigt keinen periodischen Refresh, sind schneller aber teurer
ROM: Hauptsächlich als Programmspeicher verwendet. Üblicherweise nicht immer „Read-Only“,
auch wenn der Name anderes vermuten lässt. In der Regel Flash-Speicher.
o NOR: Normalerweise wird ein kleiner NOR-Speicher für die Software verwendet.
o NAND: Ein grösserer NAND-Speicher dient als Dateisystem für nicht-flüchtige Daten.
EEPROM: Nicht-flüchtiger Speicher für Computer. Enthalten üblicherweise Gerätekonfigurationen.
6.4. Elektrisches Design
Das elektrische Design erfolgt üblicherweise in zwei Stufen: auf der ersten Stufe wird die physische
Plattform entworfen (PCB-Layout), in der zweiten werden die Programme für die programmierbaren
Elemente erstellt.
Es ist ratsam, für jegliche Bauteile eine SECOND SOURCE (Alternativquelle) zu haben. Das schützt
gegen Totalausfall eines Herstellers.
Die Wahl der Spannungsversorgung ist von besonderer Wichtigkeit, da diese von allen Geräten
eingesetzt wird.
6.4.1.
PCB-Layout
Alle Elemente sollten so nahe als möglich zum IC platziert werden (lange Distanz = schlechte
Leistung).
Alle Komponenten für die DC-Konverter müssen auf derselben Seite und demselben Layer des PCB
platziert werden, um starke Störsignale zu vermeiden.
Alle Komponenten eines speziellen Teilbereichs (Beispiel: ZigBee-Modul) sollten in funktionalen
Blöcken möglichst nahe auf dem PCB zusammengefasst werden.
Effizientes PCB-Design, möglicherweise mit mehreren Layern, ist schwierig. Programme helfen beim
Entwurf von optimalen Platzierungen.
17/61
20.02.2009
Mobile Devices
6.5. Produktion und Verifikation
Mehrstufige PCB-Boards werden nach der Produktion zusammengeleimt.
Elektrisches Testen (mittels Messsonden) ist Kosten- und Zeitintensiv. Dennoch müssen PCB’s
getestet werden, da die Kosten bei einem Fehlerfall in einem kompletten System noch höher wären.
Optisches Untersuchung („Vergrösserung“) ist eine hoch-qualitative, aber billigere Alternative
In besonderen Fällen, beispielsweise bei BGAs (=Ball Grid Array, Bauform von modernen CPUs)
werden Röntgenstrahlen eingesetzt.
6.6. Implementierung der Firmware
Wurde ein passender Kernel gewählt, so muss dieser auf die Zielarchitektur angepasst werden. Dabei
müssen oft Änderungen an Konfigurationsdateien gemacht werden. Am einfachsten wird der Vorgang,
wenn eine bestehende Portierung untersucht und abgeändert wird.
6.7. Von FPGA zu ASIC
Es ist wichtig, dass das FPGA-Layout sehr ähnlich zur endgültigen ASIC-Lösung ist. Das spart Zeit (und
somit Kosten), welche durch ein komplettes Redesign verloren ginge. ASIC’s benötigen im übrigen viel
weniger Leistung als FPGAs.
18/61
20.02.2009
Mobile Devices
7.
SYMBIAN OS (ARCHITEKTUR)
7.1. Einleitung
7.1.1.
Gerätetypen
PDA: tragbare Geräte, meistens Touchscreen (Pen), OS: Palm OS, Windows CE
MOBILE PHONES: tragbare Kommunikationsgeräte, meistens limitierte Inputdevices (Keyboard)
HYBRIDS: Kombination von PDA und Mobile
7.1.2.
Mobile vs PC
Die Limitationen von mobilen Geräten sind Herausforderungen für den Entwurf von SW. Einige dieser
Limitationen ändern auch in Zukunft nicht, z.B. Network Quality, Screen und Input.
7.1.3.
Betriebssysteme
Symbian OS ist am weitesten verbreitet (65%), vor Windows CE (15%). Regional gibt es sehr starke
Unterschiede. So sind beispielsweise Blackberry (RIM) und Windows CE in Nordamerika 70%, in allen
anderen Teilen der Welt maximal 10% vertreten.
Symbian OS wird von der Firma Symbian vertrieben, hinter welcher viele Mobiltelefon-Firmen (Nokia,
Ericsson, Sony Ericsson, Panasonic, …) stehen. Nokia hält knapp 48% der Aktien. Die Firmen
erwerben Lizenzen für Symbian OS um Mobiltelefone mit diesem System anbieten zu dürfen.
7.1.4.
Programmiersprachen
Symbian OS unterstützt verschiedenste Programmiersprachen. Am komplexesten, dafür auch
performantesten ist der Einsatz von C++. Es gibt ausserdem auch eine JavaME-Variante für Symbian.
7.1.5.
Design-Ziele
BESCHRÄNKTE RESSOURCEN: Wenig CPU und RAM
KEINE FESTPLATTE: Kein unbegrenzter virtueller Speicher (Swapping)
POWER MANAGEMENT: Daten müssen auch bei Verlust der Spannungsversorgung erhalten bleiben
KOMPAKTHEIT: Kein Platz für komplexe Userinterfaces
VERLÄSSLICHKEIT: Ein Mobiltelefon ist üblicherweise ständig eingeschaltet
19/61
20.02.2009
Mobile Devices
7.2. Systemarchitektur
7.2.1.
Schichten-Architektur
Symbian OS bietet für eine grosse Zahl an Diensten (GMS, GPRS, SMS, MMS, Email, HTTP, FTP, …)
bereits integrierte APIs an. Auch die Unterstützung für Hardware (Bluetooth, IrDA, USB) ist fester
Bestandteil des Systems.
7.2.2.
UI-Layer
Auf der obersten Schicht existieren momentan drei verschiedene UI-Plattformen, welche von unterschiedlichen Mobiltelefonanbietern lizenziert werden können:
S60 (NOKIA): für Mobiltelefone ohne Touchscreen entworfen, seit 2008 auch Touchscreen-Support
UIQ (SONYERICSSON): Sowohl für Tastatur als auch Touchscreen-Einsatz entworfen
FOMA (JAPANISCHER MOBILANBIETER): Closed Platform, Anwender können keine SW installieren
7.2.3.
Grundlegende Konzepte
SINGLE USER: keine mehrfachen Logins möglich
SCHEDULING: Basierend auf Prioritäten, Vererbung von Prioritäten
MULTITHREADING: Preemptive (Verdrängend)
REALTIME
7.3. Memory Model
7.3.1.
Zweistufiges Mapping
20/61
20.02.2009
Mobile Devices
7.3.2.
Memory-Modelle
Die Memory-Modelle sind für die Verwaltung des physikalischen und virtuellen Speichers (RAM, MMU
und Cache) verantwortlich.
MOVING MEMORY MODEL: siehe Kapitel 7.3.3
MULTIPLE MEMORY MODEL: siehe Kapitel 7.3.4
DIRECT MEMORY MODEL: deaktiviert die MMU und geht davon aus, dass das Mapping der virtuellen
auf die physischen Adressen direkt vorgenommen wird. Ist nur für Testzwecke empfohlen.
EMULATOR-MODEL: Zur Unterstützung des Emulators auf Windows-Systemen. Jeglicher dem
Windows-Prozess zur Verfügung gestellter Speicher wird dem Emulator zur Verfügung gestellt.
7.3.3.
Moving Model (ARMv5)
Bis ARMv5-Architekturen wurde das Moving Model eingesetzt. Bei üblichen Computer-Systemen ist
zum Schutz der Prozesse pro Prozess ein eigenes PAGE DIRECTORY vorhanden. Somit kann jeder
Prozess nur auf den Speicherbereich zugreifen, welcher in seinem Context ist. Ein Content Switch ist
somit nichts anderes als das Ersetzen des TTBR (Translation Table Base Register). Beim Moving Model
teilen sich alle Prozess ein einziges Page Directory (4096 Einträge zu je 4 Byte = 16kByte), da der
Speicherverbrauch für ein Page Directory pro Prozess für Mobilgeräte zu verschwenderisch wäre.
Dennoch müssen die Prozesse irgendwie von unzulässigem Zugriff abgehalten werden. Eine erste
Sicherheitsmassnahme sind die PAGE TABLE PERMISSIONS. Jeder Eintrag der Page Tables besitzt ein
Bit, welches definiert, ob der Eintrag für alle oder nur für Superuser-Mode-Prozesse lesbar sein soll.
Das allein genügt allerdings noch nicht zur Prozesstrennung, da beim Context Switch die Attribute für
jede Page Table auf den neuen Prozess angepasst werden müssen.
Darum gibt es auch noch das Konzept der DOMAINS. Jeder Eintrag des Page Directory wird einer von
16 Domänen zugewiesen. Ein spezielles Register (DACR, Domain Access Control Register) verwaltet
Zugriffsrechte (Allow, Verwenden der Page Table Permissions, Disallow) des aktuellen Prozesses auf
die Domänen. Hierdurch könnte ein einfaches Context Switching erzeugt werden, falls jeder Prozess
genau zu einer Domäne gehört: beim Prozesswechsel wird der DACR mit den Zugriffsberechtigungen
des neuen Prozesses überschrieben. Allerdings wäre dadurch die Anzahl der Prozess auf 16 begrenzt.
Deshalb wurde noch eine andere Variante umgesetzt: von den 16 Domänen werden nur die Domänen
0 und 1 verwendet. Auf alle PD-Einträge der Domäne 0 erhält der aktuelle Prozess Zugriff, auf
diejenigen der Domäne 1 hingegen keinen Zugriff (zumindest im User Mode). Bei einem Context
Switch werden nun die Blöcke des neuen Prozesses in die „Speicherslots“ der Domäne 0 verschoben,
die Blöcke des alten Prozesses in die Slots der Domäne 1. Aus diesem zeitintensiven Vorgang erhält
das Memory Model seinen Namen („Moving Memory“). Dadurch kann eine Trennung der Prozesse
erreicht werden, obwohl sich alle dasselbe Page Directory teilen.
Problem beim CACHING: weil für den Cache nur die virtuellen Adressen als Index verwendet werden
muss bei einem Prozesswechsel der komplette Cache geleert werden, da nach einem Prozesswechsel
und dem damit verbundenen Blöcke verschieben unter den meisten virtuellen Adressen andere Inhalte
eingetragen werden. Dadurch wird der Prozesswechsel sehr zeitintensiv.
21/61
20.02.2009
Mobile Devices
7.3.4.
Multiple Model (ARMv6)
Die Weiterentwicklung des Moving Models besitzt immer noch ein Page Directory mit 4096 Einträgen
(16 kByte). Allerdings wird dieses in zwei Teile (einer für den Kernel, einer für die Threads) mit
veränderbaren Grössen aufgeteilt. Von diesen unterschiedlichen Grössen leitet sich auch der Name
des Modells ab. Bei einer „Halbierung“ des Speicherbereichs (8kB) bleiben so immer noch bis zu 2 GB
für einen User-Prozess übrig. Bei Systemen mit noch weniger Memory kann die zweite Hälfte sogar
auf 4kB (1 GB) reduziert werden. Dies resultiert in einem geringeren Speicher-Verbrauch bei vielen
Prozessen. Bei einem PROZESSWECHSEL der TTBR für den User-Bereich ersetzt werden. Dazu muss die
Context-ID auf die ASID des neuen Prozesses gewechselt werden.
Eine weitere Verbesserung wurde bei der CACHE-Verwaltung vorgenommen: neben den virtuellen
Adressen werden neu auch die physikalischen Adressen berücksichtig. Dadurch muss der Cache nicht
mehr bei jedem Wechsel komplett geleert werden. Als neue Sicherheitsmassnahme wurde ein NEVEREXECUTE-BIT zu den Frames hinzugefügt. Dies vermindert die Anfälligkeit auf Buffer-OverflowAttacken.
7.4.Sicherheit
In alten Symbian-Versionen war der einzige Sicherheitscheck für unsignierte Software eine „Möchten
Sie wirklich fortfahren?“-Überprüfung. Von Symbian signierte Software wurde direkt installiert.
Symbian OS 9 besitzt verschiedene Mechanismen zum Schutz des Systems. Dabei soll primär der
Zugriff auf private Daten und Systemdienste (=API, Beispiel: Verbindungsaufbau) geschützt werden.
Es wird allerdings keine Verschlüsselung oder Virenscanner eingesetzt.
7.4.1.
Trust Model
Die kleinste „Trust-Unit“ in Symbian ist ein einzelner Prozess. Somit erhält jeder Prozess
Berechtigungen (Capabilities, Kapitel 7.4.2) bei der Ausführung. Wir unterscheiden dabei zwischen 4
Vetrauensstufen:
TRUSTING COMPUTING BASE: Höchste Stufe, üblicherweise nur der Systemkern inklusive Installer auf
diesem Level aktiv.
TRUSTED COMPUTING ENVIRONMENT: Einzelne Services, welche eine Software-API gegenüber
Programmen mit geringeren Capabilities anbieten.
TRUSTED APPLICATIONS: Benötigen Rechte um auf die TCE-Dienste zugreifen zu können. Alle TA
besitzen eine „offizielle“ Signatur, beispielsweise von Symbian selber.
UNTRUSTED APPLICATIONS: Programme, welche keinen Zugriff auf die TCE-Dienste benötigen.
Haben die wenigsten Rechte und sind „self-signed“. Genügt meist für einfache Anwendungen,
beispielsweise für Spiele.
22/61
20.02.2009
Mobile Devices
7.4.2.
Capabilities
Die Capabilities legen die Möglichkeiten eines Prozesses fest. Sie werden beim Kompilieren (!) der
Anwendung festgelegt und können nach der Installation nicht mehr verändert werden. Wir
unterscheiden dabei ferner zwischen USER- und SYSTEM-CAPABILITIES: erstere können beim
Programmaufruf vom Benutzer vergeben werden, zweitere wird nur an von Symbian signierte
Software vergeben. Es gibt sogar Rechte (DMC), welche nur den Telefonanbietern vorbehalten sind.
REGELN FÜR CAPABILITIES
Regel #1: Capabilities eines Prozesses ändern niemals
Regel #2: Ein Prozess darf keine DLLs laden, welche weniger Berechtigungen als er besitzt („Boost“)
Regel #3: Capabilities sind nicht hierarchisch (Besitzen von TCB <> Vollzugriff!)
7.4.3.
Data Caging
Eine Anwendung darf üblicherweise in seinem Home und allen „normalen“ Verzeichnisse lesen und
schreiben. Zusätzlichdürfen DLLs aus dem Ressourcen-Ordner gelesen werden. Es gibt zwar
Capabilities, welche den Zugriff erhöhen (AllFiles und TCB), allerdings sind diese den
Mobiltelefonherstellern vorbehalten.
Um die Manipulation von Programmen (\sys\bin) auf Wechseldatenträgern zu vermeiden merkt sich
Symbian von jedem Programm einen Hashwert, der bei jeder Ausführung überprüft wird.
23/61
20.02.2009
Mobile Devices
7.4.4.
Identifiers
UID 1: Typ der Anwendung, ab V9 „EXE“
UID 2: Unterteilung für gewisse Typen aus UID 1
UID 3: Eindeutige Identifikation der Anwendung, wird durch Symbian zugewiesen
SID: Secure ID, üblicherweise dieselbe wie UID 3
VID: Vendor ID, eindeutige Identifizierung des Herstellers, wird durch Symbian zugewiesen
7.4.5.
Signierung der Anwendungen
SELF SIGNED: Sicherheitswarnung während Installation, nur Zugriff auf „User Capabilities“
OPEN SIGNED: Zertifizierung für Testversion (Warnung bei Installation!), neben den „User
Capabilities“ auch Zugriff auf „System Capabilities“
SYMBIAN SIGNED: höchste Stufen. Neben UC und SC auch die „Certified Signed“-Capabilities. Für
Hersteller sogar die vollen Rechte (inkl. TCB!)
24/61
20.02.2009
Mobile Devices
8.
SYMBIAN OS (PROGRAMMIERUNG)
8.1. Eigenheiten von Symbian C++
Symbian C++ unterscheidet sich vom ANSI C++ in einigen Elementen. Dies resultiert daraus, dass die
frühen Compiler Probleme mit dem „normalen“ Standard hatten.
8.1.1.
Datentypen
Symbian verwendet anstelle der üblichen Typen eine eigene Variante, um Grössen-Unterschiede bei
verschiedenen Systemarchitekturen und Compilern vermeiden zu können.
Beispiele:
TInt, TUInt, TReal32, TBool
8.1.2. String-Konstanten
Normales C++:
const char* aString = "Text"
Symbian C++:
_LIT(aString, "Text");
8.1.3.
Writable Static Data (WSD)
Üblicherweise werden DLL’s nur einmal geladen und anschliessend in jedem Prozess eingeblendet, der
auf diese Library zugreift. Durch die Verwendung von statischen Daten (=WSD, pro Prozess
vorhanden) muss die DLL mehrmalig eingebunden werden, was zu einem erhöhten Speicherbedarf
führt. Alternative: THREAD-LOCAL STORAGES (TLS, nicht näher behandelt).
8.1.4.
Error Handling
try, catch und throw) ist in Symbian OS bis
Der ANSI C++ Mechanismus zur Fehlerbehandlung (t
zur Version 9 nicht enthalten. Die beiden (heute nicht mehr gültigen) Gründe sind:
Frühe GCC-Versionen hatten mit diesem Konstrukt Probleme
Das ANSI C++ Konstrukt ist zu gross und benötigt übermässig viel Speicher
8.1.5.
Stack-Grösse
Der Stack wird beim Programmstart auf 12kB festgelegt und kann während der Laufzeit nicht
wachsen. Er sollte somit nur für kleine Objekte verwendet werden, alles andere nach Möglichkeit auf
dem Heap erzeugen.
8.1.6.
Objekterzeugung auf dem Heap
Alle Klassen müssen von CBase erben. Diese Klasse bietet einen überschriebenen new-Operator an,
welcher alle Felder mit 0-Werten initialisiert.
CMyClass myObject = new (ELeave) CMyClass();
8.1.7.
Deskriptoren
Ein Deskriptor ist so etwas wie die „String“-Klasse für Symbian OS. Er ist „self-describing“, was
bedeutet, dass er neben dem Inhalt auch den Typentyp sowie die Länge des Inhalts besitzt.
8.2. Konventionen
8.2.1.
T
C
R
M
S
E
8.2.2.
L
Präfixe für Klassennamen
Typedef
Klassen, die keinen Speicher auf dem Heap belegen und
somit typischerweise auf dem Stack erzeugt werden.
Cleanup
Erben von CBase und müssen immer auf dem Heap erzeugt
werden.
Ressources Client-seitige Ressource-Klassen.
Mixing
Abstrakte Klassen, enthalten nur virtuelle Methoden.
Struct
C-Structs erhalten dieses Präfix.
Enum
Enumerationen erhalten dieses Präfix.
Postfixe für Methodennamen
Leave
Jede Methode, welche „Verlassen“ kann (Exit, Exception)
muss dieses Postfix erhalten.
25/61
20.02.2009
Mobile Devices
8.2.3.
i
Prefixe für Variablen
Instance
Markierung für Instanzvariable. Sollte nie auf dem Stack
erzeugt werden.
8.3. Error-Handling
Wegen den beschränkten Speicher-Ressourcen ist das Fehlerhandling in Symbian OS besonders
wichtig. Da ANSI C++ standardmässig keine Garbage-Collection bietet, wurde für Symbian ein eigener
Ansatz (Leaves, Traps) entworfen.
8.3.1.
Regeln
RULE 1: Alle Methoden, welche „Verlassen“ können, müssen ein L am Ende des Namens haben.
RULE 2: Auf dem Heap erzeugte automatic Variablen müssen auf den Cleanup-Stack gelegt werden.
RULE 3: Ein Konstruktor darf niemals fehlschlagen oder verlassen (Lösung: 2-Phasen Konstruktor)
8.3.2. Leaves von Methoden abfangen
TRAPD(error, leavingMethodL());
if(error != KErrGeneral) {}
8.3.3.
//„try“, „catch“
//Behandeln (Code im „catch“)
Cleanup Stack
CMyClass myObject = new (ELeave) CMyClass();
CleanupStack::PushL(myObject);
myObject::useLeavingMethodL();
//Methode kann verlassen
CleanupStack::PopAndDestroy(myObject);
8.3.4.
Two-Phase Construction
Wie erwähnt dürfen Konstruktoren in C++ niemals fehlschlagen. Der Grund dafür ist, dass bei
Verwendung des new-Operators zuerst der Speicher für das Objekt alloziert wird. Schlägt der
Konstruktor nun fehl, so wird dieser Speicherplatz niemals mehr freigegeben.
class CMyClass : public CBase{
//Wenn möglich private -> Verwendung von NewL() und NewLC() erzwingen
CMyClass() {}
/*
* 2-Phasen Konstruktor: hier folgt Code, der „Verlassen“ kann
* Wenn möglich private -> Verwendung von NewL() und NewLC() erzwingen
*/
void ConstructL() {}
//Verantwortlichkeit für Aufräumen wird an besitzendes Objekt übergeben
static CMyClass* NewL() {
CMyClass* self = CMyClass::NewLC();
CleanupStack::Pop();
return self;
}
//Objekt soll sich selber um das Aufräumen kümmern (für Automatic Vars)
static CMyClass* NewLC() {
CMyClass* self = new (ELeave) CMyClass();
CleanupStack::PushL(self);
self->ConstructL();
return self;
}
};
//Verwendung ohne Helfer
CMyClass* myObject = new (ELeave) CMyClass();
CleanupStack::PushL(myObject);
myObject->ConstructL();
//Verwendung mit Helfer
CMyClass* myObject = CMyClass::NewLC();
26/61
20.02.2009
Mobile Devices
8.4. Aktive Objekte
Üblicherweise wird für die Abarbeitung von asynchronen Ereignissen ein eigener Thread (oder
Prozess) eingesetzt. Das verursacht jedoch einen Overhead (Kontextwechsel) und erschwert die
Programmierung (Synchronisierung von gemeinsamen Objekten). Als Alternative bieten sich „Aktive
Objekte“ an. Dieser Task läuft in einem separaten Prozess und ist „non-preemptive“, kann also durch
andere Aufgaben nicht unterbrochen werden, bis er selber fertig ist.
8.4.1.
Grundprinzip
Obige Grafik zeigt das Grundprinzip von aktiven Objekten. Jeder Thread kann einen so genannten
ACTIVE SCHEDULER besitzen, welcher als eigener Thread der Anwendung läuft und die aktiven Objekte
mittels prioritätsbasiertem FIFO bedient (keine Verdrängung!). Beim AKTIVEN OBJEKT selber handelt
es sich um einen Container, welcher die asynchrone Anfrage (ASYNCHRONOUS SERVICE PROVIDER)
kapselt und jederzeit über den Status der Anfrage informiert ist. Der ASP meldet dem Scheduler nach
Abarbeitung des asynchronen Requests den Statuswechsel.
8.4.2.
Implementierung: Active Object
Das Active Object registriert sich bei seiner Instaziierung beim Scheduler (C
CAc tiveScheduler::
Add(this)). Ferner muss das AO die folgenden Methoden implementieren:
DoCancel() für das Abbrechen des asynchronen Aufrufs. Allerdings sollte diese Methode nie direkt
aufgerufen werden, sondern nur über die geerbte Methode Cancel().
RunL() für den Callback des Schedulers nach Abarbeiten des Aufrufs, sollte möglichst kurze
Laufzeit besitzen, da ein AO wie erwähnt nicht verdrängt werden kann.
RunError() für die (optionale) Fehlerbehandlung von Leaves in RunL().
Destruktor sollte auf jeden Fall Cancel() aufrufen, da beim Löschen von AO ohne vorheriges
Abbrechen des Requests ein STRAY-SIGNAL ausgelöst wird. Ein Stray-Signal bedeutet, dass der ASP
nach Beendigung des Requests das auslösende AO nicht finden konnte
8.4.3.
Aktive Objekte vs Threads
Aktive Objekte haben weniger Overhead und sind einfacher zu implementieren. Für lange Aufgaben
sollten diese in mehrere kleine „low priority“-AO’s aufgeteilt werden (Erinnerung: RunL() kann nicht
verdrängt werden!).
27/61
20.02.2009
Mobile Devices
8.5. Hello-World für die Konsole
8.5.1.
Header-Datei
#ifndef __HELLO_WORLD_H__
#define __HELLO_WORLD_H__
//e32base.h ist typischer Include für Symbian, e = Epoc
#include <e32base.h>
/*
* E32Main() wird bei Programmstart aufgerufen
* GLDEF_C = Global Definition Code, markiert global verfügbare Funktion
* TInt = Integer für Symbian, vermeidet „Grössenunterschiede“
*/
GLDEF_C TInt E32Main();
#endif
8.5.2.
Quellcode-Datei
#include
#include
#include
#include
"HelloWorld.h"
<e32base.h>
<e32std.h>
<e32cons.h>
//String-Konstanten definieren, dasselbe wie [char * KTextConsoleTitle]
_LIT(KTextConsoleTitle, "Console");
_LIT(KTextFailed, " failed, leave code = %d");
_LIT(KTextPressAnyKey, " [press any key]\n");
//LOCAL_D = Lokale Daten, nur in diesem File sichtbar
LOCAL_D CConsoleBase* console;
//Main-Funktion (global sichtbar), wird beim Programmstart augerufen
GLDEF_C TInt E32Main() {
__UHEAP_MARK;
//Anweisung für Debugging, vermeidet Memory-Leaks
CTrapCleanup* cleanup = CTrapCleanup::New();
//???
//Konsole-Output erstellen, TRAPD für Error-Handling ("try ... catch")
TRAPD(createError, console = Console::NewL(KTextConsoleTitle,
TSize(KConsFullScreen,KConsFullScreen)));
if (createError)
return createError;
TRAPD(mainError, DoStartL());
//L = Leave, also in TRAPD
if (mainError)
console->Printf(KTextFailed, mainError);
console->Printf(KTextPressAnyKey);
console->Getch();
//Test ausgeben
//Auf Input warten
delete console;
delete cleanup;
//Aufräumen
__UHEAP_MARKEND;
return KErrNone;
//Für Debugging
}
28/61
20.02.2009
Mobile Devices
//Lokale Methode, L = Kennzeichnung für Leave („Throw“)
LOCAL_C void DoStartL() {
/*
* Active-Scheduler führt „Active Objects“ aus.
* Klassen mit C als Prefix immer mittels "new" auf dem Heap erstellen
*/
CActiveScheduler* scheduler = new (ELeave) CActiveScheduler();
//Objekte auf dem Heap immer auf CleanupStack platzieren (Memory Leaks)
CleanupStack::PushL(scheduler);
CActiveScheduler::Install(scheduler);
MainL();
/*
* Nach Gebrauch des „C-Objekts“ dieses wieder vom CleanupStack entfernen.
* Bei Exception werden jegliche Objekte auf dem CleanupStack automatisch
* aufgeräumt.
*/
CleanupStack::PopAndDestroy(scheduler);
}
//Lokale Methode, L = Kennzeichnung für Leave („Throw“)
LOCAL_C void MainL() {
console->Write(_L("Hello, world!\n"));
}
8.6. GUI-Programmierung
Das Application Framework (UIKON) von Symbian OS setzt auf das bekannte MVC-Pattern und
schreibt einer Applikation eine fixe Struktur vor.
Eine Anwendung muss, gemäss obigem Schema, mindestens die vier grau hinterlegten Klassen
Application, Document, AppUI sowie AppView implementieren. Abhängig vom eingesetzten UIFramework (S60, UIQ) wird eine weitere Hilfsschicht eingeschoben. Beispiel für S60 und UIQ:
S60: CAknApplication zwischen CEikApplication und CXyApplication, …
UIQ: CQikApplication zwischen CEikApplication und CXyApplication, …
Unabhängig vom gewählten UI-Framework fallen den einzelnen Klassen folgende Aufgaben zu:
APPLICATION: Einstiegspunkt der Applikation, E32Main() befindet sich üblicherweise jedoch in
einer separaten Datei. Definiert und verwaltet Eigenschaften der Applikation. Dient zur Erzeugung
eines neuen Document-Objekts.
DOCUMENT: Repräsentiert das Model (Problem Domain) der Applikation und kann dessen Persistenz
implementieren (Datenhaltung in Dateien, jedoch nicht von allen Applikationen genutzt). Dient auch
zur Erzeugung eines neuen AppUI-Objekts.
APPUI: Für den Anwender nicht sichtbar. Verwaltet die Views (Bildschirmmasken) der Applikation
und behandelt Ereignisse, die von den CBA-Tasten (Control Button Array, Softkeys unter dem
Display), vom Menu oder von der Tastatur stammen. Entspricht dem Controller im MVC-Patern.
APPVIEW: Visualisiert die Daten der Applikation und erlaubt die Interaktion mit der Applikation.
29/61
20.02.2009
Mobile Devices
Diese Basisklassen enthalten einige rein virtuelle Methoden, die von den abgeleiteten Klassen
implementiert werden müssen. Es handelt sich dabei um Template- bzw. Factory-Methoden.
APPLICATION::APPDLLUID(): Eine UID "Unique Identifier" identifiziert ein Symbian Objekt, oder ein
bestimmtes Programm. Das Framework ruft beim Applikationsstart diese Funktion zum Abfragen der
UID auf.
APPLICATION::CREATEDOCUMENTL(): Factory-Methode für Document. Das Framework ruft diese
Methode beim Applikationsstart auf.
DOCUMENT::CREATEAPPUIL(): Factory-Methode zur Erstellung des AppUI. Das Framework ruft diese
Methode beim Applikationsstart auf.
APPUI::CONSTRUCTL(): Template-Methode, die als erstes CEikAppUi::BaseConstructL()
aufruft. Im Weiteren erzeugt sie jegliche Views der Anwendung. Das Framework ruft diese Methode
beim Applikationsstart auf.
APPUI::HANDLECOMMANDL(): Behandelt Ereignisse von den CBA–Buttons, vom Menu oder von der
Tastatur. Das Framework ruft diese Methode für die Behandlung von Ereignissen der
Bedienoberfläche auf.
APPVIEW::DRAW(): Visualisierung der Daten auf dem Display. Das Framework ruft diese Methode
beim Applikationsstart auf. Kann explizit mit DrawNow() aufgerufen werden (z.B. bei Änderungen in
den Daten).
Das Application Framework stellt das Bindeglied zwischen Benutzer, Symbian OS und der Applikation
dar. Dabei übernimmt es folgende Aufgaben:
VISUALISIEREN DES APPLIKATIONS-GUI: Dazu ruft das Framework die Methode CXyAppView::Draw() auf.
ENTGEGENNEHMEN VON BENUTZEREINGABEN und Weiterleiten von Benutzerereignissen an die
Applikation durch Aufruf von CXyAppUi::HandleCommandL(). Alle nichtbehandleten Ereignisse
rufen anschliessend die Methode Panic() auf, welche die Applikation sofort mit Fehlermeldung
beendet.
Applikationspezifischer Code ist also in dem automatisch generierten Applikationsgerüst hauptsächlich
in diesen zwei Methoden zu ergänzen. Selbverständlich können daneben weitere eigene PD-Klassen
geschrieben werden.
8.6.1.
S60 vs UIQ
Bei S60 findet die Event-Verwaltung in der Methode AppUI::HandleCommandL() statt. Bei UIQ
befindet sich diese in AppView::HandleCommandL(). Auch speziell bei UIQ: eine Anwendung kann
nicht beendet werden. Diese bleibt ständig im Hintergrund laufen, man wechselt ganz einfach auf eine
andere Anwendung zum „Beenden“.
30/61
20.02.2009
Mobile Devices
9.
WINDOWS CE (ARCHITEKTUR)
9.1. Allgemeine Informationen
Windows CE wurde für mobile Endgeräte mit eingeschränkter Funktionalität entworfen. Es unterstützt,
im Gegensatz zu Symbian OS, verschiedene Prozessoren (ARM, MIPS, SHx, X86). Der Kernel basiert
auf keinem bekannten Desktop-Windows und wurde völlig eigenständig programmiert. Allerdings
wurde das Look and Feel beibehalten, um den Windows-Usern das vertraute Erscheinungsbild zu
bewahren.
Microsoft bietet verschiedene Tools für Windows CE an, unter anderem den so genannten PLATFORM
BUILDER, welcher eine modulare Zusammenstellung der Betriebssystemkomponenten (bzw. des
Kernels) abhängig von den Anforderungen des Zielgeräts erlaubt.
9.2. Applikationsentwicklung
WinCE unterstützt alle bekannten C-Sprachen (C, C++, C#) und enthält eine reduzierte Windows-API
(~2'000 Funktionen). Da dasselbe Programmiermodell wie bei den Desktop-Windows verwendet wird,
können jegliche CE Applikationen auch auf dem Desktop ausgeführt werden (aber nicht umgekehrt!).
Für die IPK existieren viele Möglichkeiten, um nur einige zu nennen: Mutex, Semaphore, Critical
Sections.
9.3. Systemarchitektur (v6.0)
WinCE implementiert ab Version 6.0 eine Schichtenarchitektur mit Trennung zwischen User-Space und
Kernel-Space. In früheren Versionen wurde noch der so genannte Mikrokern-Ansatz verfolgt.
Im KERNELMODE laufen: das Dateisystem (F
FileSys.dll), das GUI (G
GWES.dll, GWES = Graphics,
Windowing and Events Subsystem), das Networking, die Geräteverwaltung (D
Device.dll) und selbstKernel.dll), welcher sich um das Prozess- / Thread- / Memoryverständlich der Kernel selber (K
Management kümmert. Über die Datei KCoreDll.dll kann auf die Kernel API zugegriffen werden.
Der USERMODE beherbergt die Shell (eine vorgegebene oder angepasste Schnittstelle zum Benutzer),
die Diensteverwaltung (s
services.exe) sowie Usermode-Treiber (U
UDevice.exe).
9.4. Das Speichermodell (v6.0)
Ab Version 6.0 wird der 32bit grosse virtuelle Adressraum (insgesamt 4 GB) halbiert: die eine Hälfte (2
GB) wird für den Kernel reserviert, die andere für die Prozesse (Userspace). Wichtig ist dabei zu
wissen, dass der KERNELSPACE für jegliche Prozesse derselbe ist und nur der USERSPACE abhängig
vom momentan ausgeführten Prozess gewechselt wird (Schutzmassnahme zur Trennung von
Prozessen). Insgesamt können 32'000 unterschiedliche Prozesse gleichzeitig gestartet werden.
31/61
20.02.2009
Mobile Devices
9.4.1.
Static Mapped Memory
Im Kernelspace gibt es zwei „Static Mapped Memory“ Bereiche (Cached & Uncached). Diese sind, im
Gegensatz zu den „Dynamically Mapped“, immer verfügbar und werden direkt auf fixe physikalische
Adressen mapped. Dadurch können garantiert keine Page Faults mehr auftreten. Ausserdem kann
durch das Mapping auf Speicherbereiche zugegriffen werden, welche üblicherweise nicht verfügbar
wären. Dies ist nötig, da low-level Code oft auf eine fest vorgeschriebene Adresse zugreifen muss.
9.4.2.
Cached vs Uncached Memory
Wie erwähnt wird der „static mapped Memory“-Block in zwei Teile zu je 512MB aufgeteilt: einen
cached und einen uncached Bereich. Wird über den „uncached“ Block auf den Memory zugegriffen, so
wird der in der CPU integrierte Cache überbrückt. Das ist nötig, da bestimmte Anwendungen (Beispiel:
Realtime-Clock) Werte direkt ins Memory schreiben, ohne den CPU-Cache darüber zu informieren. In
diesem Fall würde ein Lesen vom Cache einen veralteten Wert liefern.
9.5. Scheduling
Der Prozess stellt die Ausführungsumgebung bereit, in welchem eine unbegrenzte Anzahl an Threads
ablaufen kann. Es wird ein PRIORITY BASED PREEMPTIVE SCHEDULING mit Zeitscheiben („RoundRobin“) für Threads gleicher Priorität eingesetzt. Die Zeitscheibengrösse ist standardmässig 1ms, jeder
Thread hat ein eigenes Zeitquantum. Standardwert hierbei sind 100 Einheiten, somit: 100 * 1ms =
100ms.
32/61
20.02.2009
Mobile Devices
9.5.1.
Prioritäten & Priority Inversion
Das Prioritätensystem kennt 256 Stufen, wobei der Level 0 die höchste Priorität darstellt. Prioritäten
für einen Thread werden vom OS beim Belegen eines Mutex erhöht, sobald ein anderer Thread mit
höherer Priorität zu warten beginnt. Der momentan aktive Thread im Mutex erhält dann die (höhere)
Priorität des wartenden Threads. Ziel des Vorganges ist, dass der Mutex so als möglich wieder frei
wird. Dieser Vorgang wird PRIORITY INVERSION genannt. Es kann zu jedem Zeitpunkt die Priorität von
maximal 1 Thread umgekehrt werden.
9.6. Realtime / Interrupt Verarbeitung
Windows CE erfüllt die Anforderungen für ein Hard Real-Time System. Die harte Echtzeitfähigkeit wird
dadurch erreicht, dass für die kernabhängigen Zeitteile eine Maximalzeit garantiert wird. Ausserdem
wird durch die Prioritäten ein berechenbareres Verhalten erzielt. Sehr kleine Time Slices erlauben
schnellere Reaktionszeiten.
Bei einem einkommenden IRQ (Interrupt, Signal von HW an Mikroprozessor) wird der momentan
aktive Thread verdrängt und der INTERRUPT SERVICE HANDLER (ISH) im Kernel entscheidet, welches
die zu diesem IRQ gehörige INTERRUPT SERVICE ROUTINE (ISR) ist. Die ISR selber bearbeitet nur
gerade den wirklich zeitkritischen Teil und startet für die endgültige Verarbeitung des IRQ einen
INTERRUPT SERVICE THREAD (IST). Dieser muss anschliessend mit den normalen Threads um die
CPU-Zeit konkurrieren. Es ist also ratsam, für zeitkritische Requests eine hohe Priorität zu vergeben.
Die ISR sollte eine möglichst geringe Laufzeit haben, da während ihrer Laufzeit IRQs mit derselben
und tieferen Prioritäten nicht bedient werden.
33/61
20.02.2009
Mobile Devices
9.7. Gerätetreiber
Gerätetreiber können sowohl als Kernelmode-, als auch als Usermode-Treiber entwickelt werden. Die
KM-TREIBER haben Zugriff auf den kompletten Speicherbereich – fehlerhafte Zugriffe gefährden somit
die Stabilität des Systems (Bluescreen). Dafür sind sie einiges performanter. Da die UM-TREIBER nur
auf ihren Speicherbereich zugreifen können, gelten diese als stabiler, besitzen allerdings deutlich mehr
Overhead (Beispiel: Umkopieren von grossen Datenmengen vom K-Speicher in den U-Speicher).
Ferner können UM-Treiber nicht direkt auf die Hardware zugreifen.
Selber entwickelte Treiber sollten in der Regel das STREAM-INTERFACE implementieren. Ausnahmen
sind Display-, Tastatur- und Touchtreiber. Dieses Interface schreibt Methoden vor, welche vom
Treiber überschrieben werden müssen (o
open(), read(), write(), …). Beim Zugriff auf ein Gerät
wird zuerst über die Methode IOControl() die neue Aufgabe initiiert. Anschliessend kann auf das
Gerät zugegriffen werden (Beispiel: Lesen oder Schreiben).
Die eigenen Treiber können ferner so genannten TREIBERKLASSEN zugewiesen werden. Durch diese
Zuweisung hat das OS eine Aussage über die Art des Treibers (Stream-Interface gibt darüber keine
Information).
9.8. Sicherheit
Wie auch Symbian verwendet Windows CE für die Ausführung von Programmen Zertifikate. Auch der
Zugriff auf die API ist nur eingeschränkt möglich (Restrictions = Capabilities bei Symbian). Im
Allgemeinen besitzt WinCE aber viel weniger Sicherheitsmechanismen als Symbian.
34/61
20.02.2009
Mobile Devices
10. WINDOWS CE (PROGRAMMIERUNG)
10.1. Möglichkeiten zur Programmierungen
Anwendungen für Windows CE können auf verschiedene Arten geschrieben werden. Die erste und
grundlegendste Methode ist die Verwendung der klassischen WIN32-API.
Auf dieser API baut die MFC (MICROSOFT FOUNDATION CLASSES) auf. Beim MFC handelt es sich um
eine grosse Sammlung an Klassen, welche die Windows-API abstrahieren und kapseln. Weiter wird
durch MFC ein Framework für eigene Klassen angeboten. Dieses Framework gleicht sehr stark dem
aus Symbian bekannten Aufbau.
Obige Grafik vergleicht den Aufbau von Symbian (blau) mit MFC (grün). Die Klasse CObject ist die
Basisklasse, von welcher alle MFC-Klassen abgeleitet sind. CDocument und CView sind die
Basisklassen für das Dokument, bzw. die View.
Als dritte Möglichkeit steht noch das .NET-FRAMEWORK zur Verfügung. Es wird empfohlen, dass
jegliche neue Anwendungen basierend auf .NET entworfen werden.
10.2. Ungarische Notation
35/61
20.02.2009
Mobile Devices
10.3. Error Handling
Das Error-Handling in Windows CE kann auf zwei Methoden gestaltet werden. Die erste Variante setzt
auf das aus C++ bekannte try-catch Prinzip.
//Klassische Methode
try {
throw xxx;
} catch (Exception xxx) {
…
} catch(…) {
…
}
//Win32-Methode
__try {
…
…
…
} __except (Exception xxx) {
…
}
Die zweite, unbekanntere Methode wird WIN32-EXCEPTION genannt. Diese ist von der Syntax her
sehr ähnlich. Der grosse Unterschied zur normalen Variante: es können jegliche Exceptions gefangen
werden (z.B. auch Access Violations).
10.4. Message Loop
Der Kern einer klassischen Win32-Anwendung besteht
aus dem so genannten MESSAGE-LOOP. In diesem
Codefragment befindet sich das Programm nach der
Initialisierung und Erstellung der benötigten Objekte.
Jedes Programm besitzt mindestens eine Message-Loop,
oft auch mehrere (z.B. pro View eine Loop).
Die Programmkomponenten erzeugen im Betrieb
Messages. Diese landen in einem Buffer der Anwendung
und werden von der Message-Loop ausgelesen.
Abhängig von der Message werden nun unterschiedliche
Aktionen ausgeführt. Von der Anwendung nicht
behandelte Messages werden an die nächst höhere
Softwareschicht (i.d.R. das OS) weitergegeben.
Nachfolgend ist eine typische Message-Loop abgebildet.
Die Methode TranslateMessage wandelt die interne
Repräsentation in eine für uns verständliche Form um.
Dieser Schritt ist optional – es kann problemlos auch mit
der „internen“ Form gearbeitet werden. Durch
DispatchMessage wird das gerade aktive Fenster
(„Fokus“) gesucht und die Meldung an die zu diesem
Fenster gehörige WINDOW PROCEDURE übergeben.
while(GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
36/61
20.02.2009
Mobile Devices
10.5. Win32 – Hello World
/*
* WinMain ist die Startfunktion der Anwendung.
* Rückgabewert ist der Exit-Code (0 = alles OK!)
*/
int WINAPI WinMain(HINSTANCE hInstance,
//Refer. zur Instanz dieser EXE
HINSTANCE hPrevInstance, //Nicht verwendet, Altlast
LPTSTR
lpCmdLine,
//CMD-Line Argumente
int
nCmdShow)
//Anzeigemodus des Fensters
{
/*
* MessageBox() zeigt eine einfache Dialogbox an. Das Macro TEXT() wird
* für Unicode-Eingaben benötigt. Als Return-Value wird ein Code für den
* angeklickten Button (z.B. IDOK, IDCANCEL) geliefert.
*/
MessageBox( NULL,
//Handle auf Eltern-Fenster
TEXT("Hello World"),
//Inhalt der Msg-Box
TEXT("Hello World"),
//Titel der Msg-Box
MB_OK);
//Buttons der Dialogbox
return 0;
}
10.6. Win32 – Komplexere Anwendung
Nachfolgende Anwendung wurde auf das Wesentliche reduziert. Sie ist in dieser Form nicht lauffähig,
sollte aber alle wichtigen Elemente enthalten.
/*
* Main-Methode.
*/
int WINAPI WinMain(HINSTANCE hInstance, …) {
//Die Fenster-Klasse registrieren
WNDCLASS wc;
wc.style
wc.lpfnWndProc
wc.cbClsExtra
wc.cbWndExtra
wc.hInstance
wc.hIcon
wc.hCursor
wc.hbrBackground
wc.lpszMenuName
wc.lpszClassName
=
=
=
=
=
=
=
=
=
=
CS_HREDRAW | CS_VREDRAW;
//Window-Style
WndProc;
//Window-Procedure
0;
0;
hInstance;
//Handle auf Owner
LoadIcon(hInstance, MAKEINTRESOURCE(IDI_EXAMPLE2));
0;
(HBRUSH) GetStockObject(WHITE_BRUSH);
0;
TEXT("MyClass");
//Klassen-Name
RegisterClass(&wc);
//Fenster erzeugen
HWND hWnd;
hWnd = CreateWindow(
TEXT("MyClass"),
TEXT("MyTitle"),
WS_VISIBLE,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL);
37/61
//Name der Klasse
//Fenster-Titel
//Style-Flags
//X-Pos
//Y-Pos
//Width
//Height
//Parent-Window
//Menu, muss null sein
//Application-Instanz
//Create-Parameter
20.02.2009
Mobile Devices
//Fenster anzeigen
ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);
//Erzeugt WM_PAINT Message
//Message-Loop
MSG msg;
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
//Message in verständliche Form
DispatchMessage(&msg);
//Message an Window-Procedure senden
}
return (int) msg.wParam;
}
/*
* Methode zur Verarbeitung von Message-Events („Window-Procedure“).
*
* 1. Parameter: Handle auf das Fenster
* 2. Parameter: Die zu verarbeitende Message
* 3. Parameter: 1. frei verwendbarer Parameter (z.B. Keycode)
* 4. Parameter: 2. frei verwendbarer Parameter
*/
CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {
PAINTSTRUCT ps;
RECT rect;
HDC hdc;
switch (message) {
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
GetClientRect(hWnd, &rect);
DrawText(hdc, TEXT("Hello World"), -1, &rect, DT_CENTER |
DT_VCENTER | DT_SINGLELINE);
EndPaint(hWnd, &ps);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
//Erzeugt ein WM_QUIT = Abbruch
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
38/61
20.02.2009
Mobile Devices
11. APPLICATION FRAMEWORKS
11.1. Java ME
Java Platform, Micro Edition, abgekürzt Java ME, ist eine Umsetzung der Programmiersprache Java für
so genannte »embedded consumer products« wie etwa Mobiltelefone oder PDAs. Grosser Vorteil von
Java ist die grosse Unterstützung durch verschiedene Plattformen. Sun hat angekündigt, die Plattform
Java ME zugunsten der Java SE aufzugeben. Grund hierfür seien die immer leistungsfähiger
werdenden Geräte, für die Java ME einst geschaffen wurde.
11.1.1. Unterschied JME und JSE
JME ist eine stark limitierte Teilmenge der JSE (Standard Edition). Ergänzend wurden einige
zusätzliche Packages, beispielsweise für Bluetooth, eingefügt. Ausserdem gibt es einige weitere
Einschränkungen (Aufzählung unvollständig):
Bis CLDC 1.0 keine Unterstützung von reellen Zahlen (d
double und float).
Keine Finalisierung von Objekten (Methode finalize()).
Eingeschränktes Error-Handling (gerätespezifisches Verhalten)
11.1.2. Konfigurationen und Profile
Die Grundlage von Java ME bilden Konfigurationen und Profile. Die KONFIGURATIONEN stellen
verschiedene Bibliotheken (Core API) und eine Virtuelle Maschine zur Verfügung. Eine Konfiguration
kann die Connected Device Configuration (CDC) oder die Connected Limited Device Configuration
(CLDC) sein. Momentan stehen nur diese beiden Konfigurationen zur Verfügung. Bei der CLDC
beobachtet man eine sehr starke Zunahme, da fast jedes aktuelle Handy diese Konfiguration in
Kombination mit dem Mobile Information Device Profile (MIDP) nutzt.
CDC: Grössere PDAs und Set-Top Boxen.
CDLC: Kleinere PDAs, Pager und Mobiltelefone. Teilmenge der CDC – Anwendungen, die für CDLC
entwickelt wurden können somit auch auf einer CDC-Konfiguration ausgeführt werden.
PROFILE setzen auf den
So existiert vor allem
Anwendungen, die auf
Mittlerweile gibt es auch
erweitert worden.
Konfigurationen auf und erweitern somit die zur Verfügung stehenden APIs.
für Mobiltelefone das Mobile Information Device Profile (MIDP). JavaGrundlage der MIDP entwickelt wurden, nennt man auch kurz MIDlet.
MIDP2.0. Diese Version ist um die Bedürfnisse vor allem der Spieleentwickler
11.1.3. Java Community Process (JCP) und Java Specification Requests (JSR)
Für viele Einsatzzwecke sind die einfacheren Konfigurationen nicht genug, da sie keinen Zugriff auf die
internen Funktionen eines Gerätes bieten. Deshalb gibt es viele Erweiterungen, die zusätzliche
Funktionalitäten (Beispiel: Zugriff auf das Adressbuch) ermöglichen. Die notwendigen Erweiterungen
werden im Rahmen des Java Community Process (JCP) in Form von Java Specification Requests (JSR)
durchgeführt. Erlaubt sind Vorschläge von jedem, allerdings müssen diese durch eine langwierige
Vernehmlassung bestätigt werden.
39/61
20.02.2009
Mobile Devices
(+) Referenz-Implementationen für alle JSR vorhanden
(+) Inputs von einer grossen Community
(-) Sehr träger und formaler Prozess
(-) Kann zu API-Fragmentation (verschiede Mobiles unterstützen verschiedene JSR) führen
11.1.4. Mobile Service Architecture (JSR-248)
Bei der Entwicklung neuer JSRs werden momentan zwei Prinzipien verfolgt: die erste tendiert drauf,
für jedes unterstützte Gerät ein eigenes JSR einzureichen (API Fragmentation). Dies ist allerdings
nicht wünschenswert, da so kaum generell lauffähige Anwendungen entwickelt werden können.
Darum verfolgt ein zweiter Einsatz die Festlegung von „allgemeingültigen“ JSR. Eine Sammlung
solcher JSR ist unter dem Namen Mobile Service Architecture (MSA) bekannt. Die MSA vereint
insgesamt 16 einzelne Java-Standards unter einem Dach. Zum Paket gehört unter anderem der JSR
184 für die Darstellung von 3D-Grafiken oder der JSR 75 für den Zugriff auf Dateisystem, Kalenderund Adress-Informationen des jeweiligen Handys. Solange ein Handy nicht alle 16 Standards
beherrscht, darf dieses Gerät nicht als "MSA"-kompatibel bezeichnet werden.
11.1.5. Java ME Virtual Machine
Jede Konfiguration bringt seine eigene Virtual Machine mit. Bei CLDC war dies ursprünglich die KVM
(KILO VIRTUAL MACHINE), welche in C von Grund auf neu geschrieben wurde. Sie ist optimiert für
eine reduzierte API, bietet allerdings kein JIT. Just-in-time-Compilierung (JIT-Kompilierung) ist eine
Technik um die Performance von Anwendungssoftware, die als Bytecode vorliegt, zu verbessern. Der
JIT-Compiler übersetzt während der Laufzeit bei Bedarf den Bytecode in einen nativen MaschinenCode (also einen Code, den der Prozessor direkt verarbeiten kann).
Eine Weiterentwicklung der KVM ist CLDC HOTSPOT. Sie zeichnet sich durch stark verbesserte
Performance (~10x schneller als KVM) aus und bietet JIT. Auch die Garbage-Collection wurde
verbessert: der Speicher wird in verschiedene Bereiche (Seldom, Often, Frequency) aufgeteilt.
Abhängig von der Zugriffshäufigkeit wird der Speicher mehr oder wenig oft aufgeräumt.
11.1.6. MIDlets
Ein Midlet ist eine Anwendung für Geräte mit CLDC-Konfiguration und MIDP (Mobile Information
Device Profile) Profil. Es handelt sich somit um JME-Anwendungen für typische Mobiltelefone mit
limitierter Leistung und Akkubetrieb. Mehrere MIDlets können zu einer MIDlet-Suite zusammengefasst
werden, so dass sich die einzelnen MIDlets Ressourcen und Programmcode teilen können (Eine JAR =
mehrere Midlets).
Ein MIDlet hat keine vollständige Kontrolle über seinen Lebenszyklus, sondern wird durch die AMS
(Application Management Software) kontrolliert. So kann es beispielsweise passieren, dass bei einem
einkommenden Anruf das MIDlet beendet wird. Obwohl die Zustandwechsel durch die AMS
vorgenommen werden können die Wechsel auch explizit durch die Methoden resumeRequest(),
notifyPaused() und notifyDestroyed() gefordert werden.
ACTIVE: Während dieser Phase wird gerade eine Funktion ausgeübt und das MIDlet ist damit aktiv,
deshalb auch der Name Active.
40/61
20.02.2009
Mobile Devices
PAUSED: Der Zustand Paused wird nach dem Ausführen des Konstruktors und vor der Aktivierung
durch den Applikationsmanager eingeleitet. Der Zustand kann auch während dem Ausführen
mehrfach eingeleitet und wieder verlassen werden. Diese Phase zeigt die Inaktivität des MIDlets.
DESTROYED: Wenn die Ausführung beendet und die Ressource wieder freigegeben ist, gilt ein MIDlet
als Destroyed (zerstört).
11.1.7. JAR und JAD
Eine typische JME-Anwendung besteht aus einer JAR- und einer JAD-Datei. Die JAD (Java Application
Desriptor) enthält im Grossen und Ganzen denselben Inhalt wie die Manifest-Datei innerhalb des JARs.
Grund: Möchte ein Mobiltelefon Daten über eine Anwendung abrufen, so reicht es, wenn sie die JADDatei lädt. Für das betrachten der Manifestdatei müsste zuerst das komplette JAR mit möglicherweise
bösartigem Code heruntergeladen werden.
11.2. Java FX
JME hat stark eingeschränkte GUI-Möglichkeiten, JSE ist meist zu umfangreich für Mobiltelefone. Ein
Zwischenweg ist JavaFX: eine verbesserte Version von Java ME mit viel besserem Aussehen. JavaFX
ist dabei im Wesentlichen eine Scripting-Sprache für deklaratives GUI-Programmierung (Trennung des
UI von der Problemdomain, Konzentrierung auf die UI-Programmierung).
11.3. Windows Mobile (Windows CE)
Windows CE (Basis von Windows Mobile) wurde für mobile Endgeräte mit eingeschränkter
Funktionalität entworfen. Der Kernel basiert auf keinem bekannten Desktop-Windows und wurde völlig
eigenständig programmiert. Microsoft bietet verschiedene Tools für Windows CE an, unter anderem
den so genannten Platform Builder, welcher eine modulare Zusammenstellung der Betriebssystemkomponenten (Kernel) abhängig von den Anforderungen des Zielgeräts erlaubt.
11.3.1. Programmierung: Win32 vs .NET Compact Framework
Anwendungen für Windows Mobile können entweder mit der Win32 API oder dem .NET Framework
entwickelt werden. WIN32 bietet nur eine sehr rudimentäre API, ist jedoch die Basis für jegliche
anderen APIs und ist auch in anderen Windowsversionen enthalten. Durch die Maschinennähe ist der
Code sehr schnell, allerdings ist die Entwicklung alles andere als komfortabel. Es eignet sich besonders
für die Entwicklung von Treibern (da dort Hardwarezugriff benötigt wird).
Das .NET CF eignet sich für Applikationen, welche nicht auf low-level Funktionen zugreifen müssen.
Es handelt sich um eine Untermenge des kompletten .NET Frameworks, ergänzt um spezialisierte
Klassen für Mobilgeräte.
Es werden verschiedene MANAGED LANGUAGES (C#, C++, VB) unterstützt. Die unterschiedlichen
Sprachen teilen sich ein Common Type Set (CTS) und eine Common Language Specification (CLS):
Diese Standardtypen, bzw. Spracheigenschaften müssen von allen Sprachen unterstützt werden um
die Interoperabilität, bzw. Kommunikation zwischen verschiedenen Sprachen garantieren zu können.
So kann man z.B. mittels VB-Code auf C#-Klassen zugreifen.
Durch Verwendung einer EXCECUTION-ENGINE sollten Binaries, auch Assembly genannt, auf
unterschiedlichen Plattformen lauffähig sein. .NET CF Anwendungen werden Just in Time kompiliert.
Das bedeutet, dass eine beim Ausführen einer Anwendung die Intermediate Language (Zwischenform
des Codes) in Maschinencode umgewandelt wird. JIT-Code ist potentiell schneller als nativer Code, da
der JIT-Compiler Runtime-Informationen beim Kompiliervorgang berücksichtigen kann. Eine „install
time Compilation“ ist nicht möglich.
11.3.2. Garbage Collection
Der Garbage Collector räumt periodisch nicht mehr benötigte Objekte auf dem Heap auf. Dazu erstellt
er, ausgehend von einer Wurzel („Applikation“) einen Baum mit erreichbaren Objekten. Anschliessend
werden alle nicht mehr referenzierten Objekte vom Heap entfernt. Während dem ganzen Vorgang
werden die laufenden Threads eingefroren.
Defragmentierung (KOMPAKTIERUNG) des Speichers ist nötig, da bei einer grossen Speicherplatzanforderung wegen verstreuter Objekte unter Umständen kein genügend grosser, zusammenhängender Speicherbereich gefunden werden kann.
41/61
20.02.2009
Mobile Devices
11.3.3. .NET CF vs JME
.NET CF
JIT
Verschiedene Sprachen (C#, VB, C++, …)
Beschränkte Plattformen (Win CE, PocketPC)
Vorgegebene API
Schnellerer Spezifikationsprozess durch MS
API vergleichbar mit Desktop-API
JME KVM / CLDC HotSpot
Kein JIT (KVM), JIT (CLDC HotSpot)
Java
Weit verbreitet auf unterschiedlichen Plattformen
API-Fragmentation
Langsamer Spezifikationsprozess durch JCP
Teilweise grosse Unterschiede zu Desktop-Java
11.3.4. GUI-Programmierung
Fenster in Windows Mobile Applikationen erben von der Klasse Form. Eine Anwendung besteht aus
einem oder mehreren Fenstern. Die Navigation zwischen den Fenstern entspricht dem Anzeigen der
neuen Form (n
newForm.Show()), bzw. dem Ausblenden der bestehenden Form (o
oldForm.Hide()).
Die Verwendung des Schliessen-Symbols ([
[X] oben rechts) versteckt eine Anwendung nur. Dadurch
muss der zeitintensive Vorgang beim Starten der Anwendung nur einmal beim ersten Applikationsstart
durchgeführt werden. Soll eine Anwendung endgültig geschlossen werden, so ist ein Aufruf der APIFunktion Application.Exit() nötig.
Die Anbindung von GUI-Elementen an eine PERSISTENTE DATENSPEICHERUNG kann auf zwei Varianten
erfolgen:
Manuelle Programmierung: Grössere Kontrolle über Datenvalidierung, allerdings auch mehr Arbeit
um die Werte den GUI-Elementen zuzuweisen.
Bindung an DataSource: das GUI-Framework kümmert sich automatisch um das Abfüllen von
Werten in die GUI-Elemente, somit weniger Code für den Applikationsentwickler. Benötigt aber eine
lokale Datenbank, welche den Ladevorgang der Daten verlangsamt.
11.4. Google Android
Google Android ist eine neue, noch wenig verbreitete, javabasierte Plattform. Es baut auf einer
Teilmenge der bestehenden Java-Klassen auf, bietet aber zusätzlich einige properitären JavaErweiterungen. Als Grundlage wird ein Linux-Kernel 2.6 verwendet, auf welchem eine neu
programmiere JVM läuft. Im Gegensatz zu den normalen Java-VM’s (Stackmaschinen) ist die VM von
Google eine Registermaschine.
11.4.1. GUI-Programmierung
Der GUI-Funktionsumfang von Android ist geringer als derjenige von JSE (Swing), aber bei weitem
flexibler als die Möglichkeiten in Java ME. Wie Java FX wird auf deklarative GUI-Programmierung
gesetzt (Konzentrierung der Layout-Definitionen innerhalb einer XML-Datei).
11.4.2. Datenbankzugriff
Zugriff auf eine Datenbank erfolgt in Android über eine standardisierte Schnittstelle. Der Zugriff auf
die Daten funktioniert ähnlich wie die aus JDBC bekannten Cursor. Zeigen GUI-Elemente Daten aus
der DB an, so werden diese ohne explizite Programmierung aktualisiert!
42/61
20.02.2009
Mobile Devices
11.5. Apple OS X (iPhone)
Das Betriebssystem des iPhones setzt auf dem BSD-basierten Kernel des Desktop OS (Mac OS X) auf.
Als Folge davon kann derselbe Code für Desktops und iPhones verwendet werden. Da OS X unter
einer BSD-Lizenz vertrieben wird besteht für Entwickler kein Zwang ihren Quellcode offen zu legen.
11.6. Symbian OS
Kennen wir aus den vorhergehenden Kapiteln. Momentan der Marktführer. Die Programmierung
mittels C++ ermöglicht einen grossen Funktionsumfang, allerdings auf einem sehr komplexen Niveau.
11.7. BREW – Binary Runtime Environment for Wireless
BREW abstrahiert das Mobilgerät und das installierte OS indem es gegenüber Anwendungen eine
standardisierte API anbietet. Diese API ist sehr umfangreich – praktisch jegliche Funktionen der
Telefone können ausgenützt werden. Nachteilig an BREW: es ist nur in den USA verfügbar, ausserdem
müssen jegliche Anwendungen digital signiert und von Qualcomm getestet worden sein. Dieser
Vorgang ist nicht ganz billig.
11.8. Blackberry
Vergleichsweise „geschlossene“ Umgebung. APIs werden erst seit 2007 teilweise offen gelegt. Einsatz
der Anwendungen nur für Blackberry-Geräte.
11.9. Native vs Managed Applications
NATIVE APPLIKATIONEN sind üblicherweise in C/C++ geschrieben. Wegen der Systemnähe wird
bessere Performanz und Zugriff auf die fast alle Systemfunktionen (API) gewährleistet. Oft sind
Zertifizierungen nötig, um vollen Zugriff auf alle Systemcalls zu erhalten.
MANAGED APPLICATIONS werden üblicherweise in einer Hochsprache wie Java oder C# geschrieben.
Dies ermöglicht eine komfortablere Entwicklung welche einen robusteren Code hervorbringt. Durch
plattformunabhängigen Bytecode wird hohe Kompatibilität erreicht. Leider leidet unter der nötigen
Interpretation des Bytecodes die Performanz.
11.10. Vergleich der Plattformen – Teil 1
43/61
20.02.2009
11.11. Vergleich der Plattformen – Teil 2
44/61
20.02.2009
Mobile Devices
Mobile Devices
12. JAVA ME – ENTWICKLUNG EINES MIDLETS
12.1. Arbeitsschritte
Der Weg bis eine Applikation lauffähig ist, besteht aus mehreren Schritten. Prinzipiell sieht die
Reihenfolge der Entwicklung bis zur fertigen Applikation folgendermassen aus:
12.2. Grundstruktur eines MIDlet
public class MyMIDlet extends MIDlet {
public MyMIDlet(){}
public void startApp(){}
public void pauseApp(){}
public void destroyApp(boolean unconditional){}
}
12.3. High-Level vs Low-Level GUI
Das MIDP-API gliedert sich in ein High-Level-API und ein Low-Level-API. Das HIGH-LEVEL-API ist für
die Darstellung ohne direkten Zugriff auf die Hardware zuständig. Damit sind die Möglichkeiten
eingeschränkt, es existiert jedoch eine möglichst grosse Kompatibilität zu anderen Plattformen.
Das LOW-LEVEL-API hingegen unterstützt weitere Möglichkeiten zur Manipulation und Darstellung. Es
stellt eine Applikation dar, welche speziell für ein bestimmtes Endgerät entwickelt worden ist. Das
Low-Level-API besteht aus den Klassen Canvas und Graphics vom lcdui-Package.
12.4. Eventhandling
Ein Ereignis wird normalerweise durch eine Interaktion des Benutzers ausgelöst. Dies kann das
Betätigen einer Taste oder die Aktivierung einer Schaltfläche sein. Mit der Ereignisbehandlung kann
man beim Auftreten eines bestimmten Ereignisses die gewünschte Funktion ausführen lassen.
Um auf ein Ereignis speziell reagieren zu können, muss das Interface CommandListener
implementiert werden. Dieses Interface zieht zugleich auch die Implementierung der Methode
commandAction(Command c, Displayable d) nach sich. Darin wird geregelt, wie auf ein
bestimmtes Ereignis reagiert werden soll. Der entsprechende CommandListener muss sich beim
betreffenden Objekt mit der Methode setCommandListener(CommandListener cl) registrieren.
Das auslösende Objekt wird über den Parameter c der Methode commandAction() identifiziert.
Command-Objekte sind üblicherweise Buttons, welche über die Method addCommand() an ein GUIElement angehängt werden können.
45/61
20.02.2009
Mobile Devices
12.5. GUI-Elemente
12.5.1. Display und Screen
Zuerst muss mit der Methode getDisplay() eine Referenz auf das Display erzeugt werden. Dieses
Objekt ist vom Typ Display. Pro MIDlet kann nur ein einziges Display-Objekt bestehen. Um eine
Anzeige auf dem Bildschirm darzustellen, muss ein anzeigbares Objekt dem Display hinzugefügt
werden. Dies geschieht mit der Methode setCurrent(Screen).
Die Darstellung, welche gerade auf dem Display aktiv ist, wird als SCREEN bezeichnet. Es kann jeweils
nur ein Screen dargestellt werden, zudem muss jeder Screen dem Display zugeordnet werden. Es
besteht die Möglichkeit zwischen den Screens beliebig zu wechseln. Dies geschieht mit der Methode
setCurrent() von der Klasse Display. Somit ist es möglich, ein MIDlet mit mehreren Anzeigen zu
haben. Es gibt prinzipiell drei verschiedene Arten von Screen-Objekten:
Canvas oder Graphics)
Low-Level API (C
Ein Formular (F
Form)
Die Typen List oder TextBox
12.5.2. Alert
Die Klasse Alert existiert zur Ausgabe von Meldungen auf dem Display. Der aktuelle Programmablauf
wird durch ein Alert immer unterbrochen. Die Fortsetzung des Programms erfolgt automatisch nach
einer gewissen Zeitspanne oder durch manuelles Betätigen.
12.5.3. Listen
Listen werden dann verwendet, wenn der Benutzer eine Auswahl treffen soll. Es gibt verschiedene
Listentypen, welche unterscheiden, ob es sich z.B. um eine Mehrfach- oder Exklusivauswahl handelt.
In JavaME existiert für Listen die Klasse List.
12.5.4. Formulare
Um mehrere GUI-Elemente (wie TextBox oder List) gruppieren zu können verwenden Formulare
verwendet. Dazu existiert in Java ME die Klasse Form.
12.6. Beispielanwendung – Adressbuch
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class Adressbuch extends MIDlet implements CommandListener {
private Person[] arrPersons;
private int numberOfPersons = 0;
private final int MAX_ENTRIES = 20;
private
private
private
private
private
private
private
private
private
private
Display display;
List lstMenu;
Form frmContact;
Form frmAdd;
TextField frmAddName;
TextField frmAddNumber;
Command cmdSelect;
Command cmdExit;
Command cmdBack;
Command cmdAddEntry;
46/61
20.02.2009
Mobile Devices
public Adressbuch() {
createContacts();
initComponents();
}
protected void destroyApp(boolean arg0) {}
protected void pauseApp() {}
protected void startApp() {
showMenu();
}
public void commandAction(Command c, Displayable d) {
if (c == cmdExit) {
destroyApp(false);
notifyDestroyed();
} else if (c == cmdBack) {
showMenu();
} else if (c == cmdSelect) {
switch(lstMenu.getSelectedIndex()) {
case 0:
showContacts();
break;
case 1:
showAddForm();
break;
}
} else if (c == cmdAddEntry) {
addPerson(frmAddName.getString(), frmAddNumber.getString());
frmAddName.setString("");
frmAddNumber.setString("");
showAddAlert();
}
}
private void initComponents() {
display = Display.getDisplay(this);
cmdExit = new Command("Exit", Command.EXIT, 1);
cmdBack = new Command("Back", Command.BACK, 1);
cmdSelect = new Command("Select", Command.SCREEN, 1);
cmdAddEntry = new Command("Add", Command.SCREEN, 1);
lstMenu = new List("Auswahl", List.IMPLICIT);
lstMenu.append("Show entries", null);
lstMenu.append("Add entry", null);
lstMenu.addCommand(cmdExit);
lstMenu.addCommand(cmdSelect);
lstMenu.setCommandListener(this);
frmAdd = new Form("Add contact");
frmAddName = new TextField("Name", "", 30, 0);
frmAddNumber = new TextField("Number", "", 30, 0);
frmAdd.append(frmAddName);
frmAdd.append(frmAddNumber);
frmAdd.addCommand(cmdBack);
frmAdd.addCommand(cmdAddEntry);
frmAdd.setCommandListener(this);
}
47/61
20.02.2009
Mobile Devices
private void createContacts() {
arrPersons = new Person[MAX_ENTRIES];
addPerson("Thomas Kaelin", "079 305 47 49");
addPerson("Fabian Mauchle", "079 752 93 48");
}
private void addPerson(String name, String number) {
arrPersons[numberOfPersons] = new Person(name, number);
numberOfPersons++;
}
private void showMenu() {
display.setCurrent(lstMenu);
}
private void showContacts() {
frmContact = new Form("Contacts");
String index;
StringItem name, number;
for (int i=0; i < numberOfPersons; i++) {
index = String.valueOf(i+1);
name = new StringItem(index, arrPersons[i].getName());
number = new StringItem(null, arrPersons[i].getNumber());
frmContact.append(name);
frmContact.append(number);
}
frmContact.addCommand(cmdBack);
frmContact.setCommandListener(this);
display.setCurrent(frmContact);
}
private void showAddForm() {
display.setCurrent(frmAdd);
}
private void showAddAlert() {
Alert alertSuccess = new Alert("Added contact");
display.setCurrent(alertSuccess, lstMenu);
}
}
48/61
20.02.2009
Mobile Devices
13. JAVA ME – APPLICATION DESIGN
13.1. Persistente Datenspeicherung (RMS)
MIDP stellt spezielle APIs für die permanente Speicherung von Daten bereit, die die Realisierung
einfacher Datenbank-gestützter Anwendungsprogramme erlaubt. Die Speicherung von Daten
innerhalb des Dateisystems am Mobilgerät ist unter J2ME aus Sicherheitsgründen und zur
Beibehaltung grösstmöglicher Portierbarkeit nicht möglich. MIDP stellt für die persistente Speicherung
von Daten eine Alternative zur Verfügung, das RECORD MANAGEMENT SYSTEM (RMS). "Persistent"
bedeutet hierbei die Erhaltung der Daten nach mehrmaligen Neustarts des MIDlets und des
Mobilgerätes, selbst nach einem Batteriewechsel (Package: javax.microedition.rms).
Ein MIDlet kann beliebig viele Datenbanken als Instanzen von RecordStore eröffnen. MIDlets
innerhalb einer Suite können auf die gleichen Datenbanken zugreifen. MIDlets aus verschiedenen
Suiten bleibt der Zugriff verwehrt.
Ein RecordStore besteht aus einer Sammlung von Byte-Arrays mit einer zugehörigen, eindeutigen
ID beginnend bei 1. Sie wird als Primärschlüssel genutzt. IDs von gelöschten Einträgen werden nicht
wiederverwertet. Wird ein neuer Eintrag hinzugefügt, erhält er die nächst höhere ID der grössten
jemals vorgekommenen ID.
Öffnen eines Storage:
RecordStore db = RecordStore.openRecordStore(„MyDatabase“, true);
Eintrag hinzufügen:
String myRecord = "Ich erhalte die ID 1";
db.addRecord(myRecord.getBytes(), 0, myRecord.getBytes().length);
Eintrag auslesen:
myRecord = new String(db.getRecord(1));
Eintrag aktualisieren:
myRecord = "Immernoch ID 1, mit neuem Text";
db.setRecord(1, myRecord.getBytes(), 0, myRecord.getBytes().length);
Eintrag löschen:
db.deleteRecord(1);
Storage schliessen:
db.closeRecordStore();
49/61
20.02.2009
Mobile Devices
13.2. JME GUI
Java ME bietet verschiedene Möglichkeiten zur GUI-Entwicklung.
Grundsätzlich gilt: je portabler eine Anwendung sein muss, desto
höher wird die benötigte Abstraktion und desto eingeschränkter
sind die Möglichkeiten des GUI.
LWUIT: LightWeight UserInterface Toolkit. Ähnlich wie Swing aus
der Java SE. Viele GUI-Elemente und grosse Kontrolle über das
Aussehen der Oberfläche, Unterstützung für Styles und Themes.
Layout-Manager ermöglichen eine einfache Platzierung von
Objekten. Package: com.sun.lwuit
LCDUI HIGH-LEVEL API: Fest vorgegebene GUI-Elemente, hohe
Abstraktion und Portabilität, dafür eingeschränkte Möglichkeiten.
Typische Klassen für die High-Level API sind Screen, Form oder
Textbox. Package: javax.microedition.lcuid
LCDUI LOW-LEVEL API: geringere Portabilität durch Verwendung von low-level Zeichenmethoden.
Erbt von der Klasse Canvas (Leinwand) und überschreibt die Methode paint(Graphics g). Das
Graphics-Objekt bietet Zeichenmethoden (z.B. g.drawLine()). Anwendungen, welche diese API
einsetzen, müssen Tastenevents direkt verarbeiten, da keine Listener registriert werden können.
Package: javax.microedition.lcuid
LCDUI GAME API: spezialisierte Version der LCDUI low-level API mit spielspezifischen Klassen. Die
meisten Applikationen verwenden diese API, da sie die grössten grafischen Möglichkeiten bietet.
Typische Klassen sind GameCanvas, Layer, Sprite, TiledLayer und LayerManager. Package:
javax.microedition.lcuid.game
13.2.1. Problem von LCDUI
LCDUI steht für „Lowest Common Denominator User Interface“ und ist Teil des MIDP 2.0 Profils. Der
Name ist leider Programm: LCDUI konzentriert sich auf das Gerät mit dem geringsten Funktionsumfang, somit sind viele Features von besser ausgerüsteten Geräten nicht unterstützt.
13.2.2. Kommerzielle GUI Tookits
Neben den oben genannten, frei erhältlichen Packages gibt es auch kommerzielle GUI-Toolkits (J2MEPolsish, TWUIK oder eSWT). Diese bieten komfortable Programmierung und zugleich Portabilität.
13.2.3. Patterns für JME-GUI
Typische JME-Anwendungen verwenden das MVC (MODEL VIEW CONTROLLER) oder das MVP (MODEL
VIEW PRESENTER) Pattern.
Die Aufgabe des Presenter ist die Vermittlung zwischen der View und dem Model. Durch diesen Ansatz
wird eine bessere Trennung des UIs vom Model ermöglicht.
50/61
20.02.2009
Mobile Devices
13.3. Starten von Anwendungen
Bis MIDP 1.0 war es nur möglichen, Anwendungen manuell über den AMS zu starten. Ab MIDP 2.0 ist
es neu zusätzlich möglich, Anwendungen über das Netzwerk (Push) oder über Timer zu starten. Das
Startsignal kann über UDP, TCP oder SMS (ergänzt durch JSR-120) erfolgen. Üblicherweise ist das
jedoch nur eingeschränkt möglich, da das Mobiltelefon i.d.R. eine private IP besitzt. Für einen
sinnvollen Einsatz müsste ausserdem ständig eine Verbindung zum Netzwerk offen sein (sehr teuer).
13.4. Over the Air (OTA) Deployment
Das Grundprinzip von OTA basiert darauf, dass ein lokaler, http-fähiger Browser auf dem mobilen
Endgerät das JAD-File auf einem Server abruft. Der Browser verarbeitet dieses JAD-File und fragt den
Benutzer, ob er die verknüpfte JAR-Datei herunterladen und installieren möchte.
Das JAD-File kann ausserdem Referenzen zu Webseiten enthalten, welche nach einem erfolgreichen
Installations-, bzw. Deinstallationsvorgang aufgerufen werden sollen. Dies wird für die Verrechnung
der herunter geladenen Anwendung verwendet (Auswertung des HTTP Status ermöglicht Billing).
13.5. Threads
13.5.1. Grundlagen
Java ME verwendet ein sehr ähnliches Threadmodell wie Java SE (siehe obige Abbildung). Auch das
Starten eines Threads ist sehr ähnlich:
Erben von der Klasse Thread und überschreiben der Methode run()
Implementieren des Interface Runnable und implementieren der Methode run()
13.5.2. Stoppen von Threads
Threads werden am besten gestoppt, indem diese in der run()-Methode ein lokales boolean-Flag
überprüfen. Möchte ein anderer Thread den Thread beenden, so kann er über eine öffentliche
Methode das Flag setzen und so den Thread sich selbständig beenden lassen. Der Zugriff auf die
lokale Variable sollte selbstverständlich synchronisiert werden.
51/61
20.02.2009
Mobile Devices
13.6. Sicherheitsfunktionen
MIDlets werden in einer Schutzdomäne (PROTECTION DOMAIN) ausgeführt. Diese Domäne bestimmt
die Rechte eines MIDlets. Sie wird vom ausführenden Mobilgerät ausgewählt. Unsignierte MIDlets
werden automatisch als „untrusted“ eingestuft. Das bedeutet, dass der User vor jedem Zugriff auf
eine geschützte API eine Kontrollfrage bestätigen muss.
Die Berechtigungen, welche ein MIDlet benötigt, werden innerhalb der JAD-DATEI definiert. So kann
das Mobilgerät bereits vor der Installation überprüfen, ob eine Anwendung installiert werden soll und
darf.
Das Gerät kann bestimmte Funktionen ausserdem auf SIGNIERTE MIDLETS einschränken. Durch die
Signierung werden die Warnmeldungen reduziert und der Hersteller der Anwendung offiziell bestätigt.
Das bietet dem Anwender eine gewisse Vertrauensbasis.
52/61
20.02.2009
Mobile Devices
14. NETWORK PROGRAMMING
14.1. Designprobleme bei Netzwerken
14.1.1. Private IP-Adressen
Mobile Endgeräte haben üblicherweise eine private IP-Adresse wegen dem Mangel an genügend
Adressen in IPv4. Für „Upstream“-Anwendungen ist das kein Problem – was aber, wenn ein
Anwendungsserver eine Verbindung zu einem Mobiltelefon aufbauen sollte? Mögliche Lösungen sind:
VPN: Hier wird das mobile Endgerät über einen Tunnel mit dem Firmennetz verbunden. Über den
Tunnel kann es auch aus dem Firmennetz angesprochen werden, da es eine IP aus dem FirmenSubnet erhält. Aber: JME unterstützt von Haus aus keine VPN-Funktionalität.
SMS NOTIFICATIONS: Server sendet SMS an das Mobiltelefon, worauf dieses aktiv wird und eine
Verbindung zum Server aufbaut.
MOBILE IP: Protokoll, welches ähnlich zu einem VPN-Tunnel ist. Jedes Mobilgerät besitzt ein
Heimnetzwerk. In diesem findet sich ein der so genannte Home Agent (=HA) mit einer
unveränderlichen IP-Adresse. Bewegt sich das Mobilgerät, auch Mobile Node (=MN) genannt, in
eine fremdes Netz, so informiert der MN den HA über seinen neuen Standort, bzw. seine neue IP im
fremden Netz. Möchte nun ein Server mit dem Mobilgerät kommunizieren, so baut er eine
Verbindung zum Home Agent auf (1). Dieser sendet das Paket über einen Tunnel an den MN im
Fremdnetz (2, 3). Der MN kann nun entweder auf direktem Weg an den CN antworten (5a) oder
über den Umweg durch den HA (5b). Nachteil an der ersten Variante ist, dass das Paket von
Firewalls abgelehnt werden kann (wegen „falscher“ IP).
14.1.2. Belastung für Server
Bei einer normalen Anwendung kommuniziert üblicherweise eine grosse Zahl an Mobilgeräten mit nur
einem Server. Wegen den häufigen Netzwechseln muss der Server so eine grosse Anzahl an
Verbindungsanfragen bewältigen können. Mögliche Lösungen sind:
SESSION POOLING: Nur eine bestimmte Anzahl Clients kann gleichzeitig zum Server verbinden.
LOAD BALANCING: Verteilung der Last auf mehrere Server.
VERFÜGBARKEIT: Einschränken der „Online-Zeit“ des Mobiltelefons. Verunmöglicht aber „Push“.
14.1.3. TCP / IP
Funknetze sind ungeeignet für den Einsatz mit TCP/IP, da diese üblicherweise grosse Verzögerungen
in der Kommunikation verursachen. Wegen eingebauter Kontrollfluss-Mechanismen von TCP wird der
Datendurchsatz stark eingeschränkt. Eine Faustregel besagt:
Maximaler Durchsatz = Window Size / Roundtrip Time
Es existiert zwar ein RFC mit Empfehlungen, allerdings zielen die meisten davon auf Änderungen im
Netzwerk-Stack ab und sind somit nicht gerade massentauglich umzusetzen.
14.1.4. Erreichbarkeit von Mobilgeräten
Mobile Geräte können im Normalfall nicht direkt untereinander kommunizieren – es ist eine indirekte
Kommunikation über einen Verwaltungsserver nötig.
53/61
20.02.2009
Mobile Devices
14.2. Low-Level Programmierung
Sockets (= Buchsen) bilden die unterste Stufe des Netzwerkzugriffs. Jede Plattform bietet eine leicht
modifizierte Syntax zu Verwendung von Sockets – eine netzwerkfähige Anwendung muss folglich für
verschiedene Plattformen angepasst werden.
14.2.1. Verbindungsorientiert / verbindungslos
14.2.2. Sockets in C
Ein Socket ist immer an einen Port und an eine IP-Adresse gebunden. Die C-Funktionen erlauben auch
das binden einer Anwendung an alle IP-Adressen eines Systems (i
inaddr_any). Jedes Socket besitzt
einen Sende- und einen Empfangsbuffer. Auf diese kann mit den üblichen Methoden des Dateizugriffs
(r
read(), write()) zugegriffen werden. Ein Lese-Zugriff auf einen leeren Empfangsbuffer führt in
der Standardkonfiguration zur BLOCKIERUNG der Anwendung bis am Socket Daten eingetroffen sind.
Dasselbe gilt für TCP-Sockets beim Warten auf eingehende Verbindungen (Methode accept() beim
Server).
In TCP unterscheiden wir zwischen SERVER SOCKET und CLIENT SOCKET. Das Server-Socket nimmt
Verbindungsanfragen von Client Sockets entgegen und erzeugt anschliessend serverseitig ein eigenes
Client Socket zur Kommunikation. Das Server Socket wartet darauf wieder auf neue Anfragen.
Beim verbindungslosen UDP haben sowohl Client- als auch Server-Sockets dieselben Funktionen. Da
kein Verbindungsaufbau nötig ist kann über ein UDP-Socket mit mehreren anderen UDP-Sockets
kommuniziert werden.
Ein Problem ergibt sich, wenn lokale Daten über ein Socket zu einem Fremdrechner übertragen
werden sollen. Da die Darstellung der Daten auf dem Netzwerk anders aussehen kann („Big Endian“)
also beim Endknoten (z.B. „Little Endian“) kann es beim Empfänger zu Problemen mit der Daten
kommen. Die Daten müssen darum in ein geeignetes Format gebracht werden (PARAMETER
MARSHALLING). In C existieren dazu die Methoden htonl() und ntohl().
54/61
20.02.2009
Mobile Devices
14.3. High-Level Programmierung
Im Gegensatz zur low-level Programmierung wird bei der high-level Programmierung das Netzwerk
durch eine Softwareschicht (Middleware) abstrahiert. Dadurch wird jeglichen Anwendungen ein
gemeinsames Interface geboten. Auch kann der zu verwendende Netzwerktyp ohne Änderungen an
der Anwendung ausgetauscht werden.
14.3.1. Vergleich: JME mit GCF und Windows Mobile mit WCF
WCF bietet, zusätzlich zur Netzwerkabstraktion, auch noch eine Service-API an. Diese Funktionalität
enthält das GCF nicht. Dafür ist dieses, im Gegensatz zum WCF, dazu im Stande, auch mit anderen
Transportprotokollen (UDP, Bluetooth, Infrarot) als nur TCP/IP umgehen zu können.
14.3.2. Windows Mobile – WCF
Microsoft will mit der WINDOWS COMMUNICATION FOUNDATION (WCF) viele Netzwerk-Funktionen
zusammenführen und den Programmierern solcher Anwendungen mittels einer standardisierten API
zur Verfügung stellen. Die WCF gehört zum .NET Framework 3.0. Im Gegensatz zur Java-Lösung GCF
erlaubt WCF nur die Verwendung TCP/IP.
Die WCF abstrahiert das Konzept des Endpunktes durch eine Trennung in Address, Binding und
Contract (ABC-PRINZIP):
Die ADDRESS (Adresse) ist ein URI, der den Ort des Dienstes beschreibt und somit seine
Erreichbarkeit für die Dienstkonsumenten kennzeichnet.
Das BINDING (Anbindung) beschreibt die Art der Kommunikation, worunter unter anderem die
Merkmale der Kodierung und des Protokolls fallen.
Der CONTRACT (Vertrag) stellt die Dienstdefinition, insbesondere die zur Verfügung gestellten
Methoden beinhaltend, dar.
Das standardisierte Nachrichtenformat von WCF nennt sich SOAP. SOAP ist ein Netzwerkprotokoll, mit
dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt
werden können. SOAP stützt sich auf andere Standards: XML zur Repräsentation der Daten und
Internet-Protokolle der Transport- und Anwendungsschicht (z.B. TCP/IP) zur Übertragung der
Nachrichten. Die gängigste Kombination ist SOAP über HTTP und TCP.
55/61
20.02.2009
Mobile Devices
14.3.3. Java ME – GCF
Das GENERIC CONNECTION FRAMEWORK (GCF) ist das Netzwerkframework in Java ME. Im Gegensatz
zum WCF von Windows Mobile kann das GCF neben TCP/IP auch mit anderen Verbindungen, z.B.
Bluetooth, umgehen. Es abstrahiert die Netzwerk-Schnittstellen und versteckt den Verbindungsaufbau
vor der Anwendung, indem es Factory-Methoden zum Aufbau von Verbindungen zur Verfügung stellt.
HTTP Connection:
Socket Connection:
Datagram Connection:
TCP Server Socket:
Connector.open("http://[url]")
Connector.open("socket://[host]:[port]")
Connector.open("datagram://[host]:[port]")
Connector.open("socket://:[port]")
Ein einfaches TCP-SOCKET kann wie folgt geöffnet werden:
String request = "GET / HTTP/1.1\nHost: www.url.org\n";
StreamConnection con = Connector.open("socket://www.url.org:80");
OutputStream os = con.openOutputStream();
os.write(request.getBytes());
os.close();
InputStream is = con.openInputStream();
StringBuffer sb = new StringBuffer();
int c = 0;
while ((c = is.read()) != -1) {
sb.append((char) c);
}
is.close();
con.close();
Obiges Code-Sniplet zeigt die Verwendung von Streams mittels den Byteoperationen read() und
write(). Über so genannte STREAM WRAPPER können diese grundlegenden Streams gekapselt und
mit zusätzlichen komfortablen Methoden (z.B. readLine() oder readInt()) erweitert werden:
14.4. Protokoll und Applikationsdesign
14.4.1. Mögliche Probleme
Unzuverlässige Verbindung
Verbindungen mit hohem Delay
Stark schwankende und eingeschränkte Bandbreiten
Eingeschränkte Rechenleistung / Speicherplatz auf den mobilen Endgeräten
14.4.2. Mögliche Gegenmassnahmen
Datenkompression zur Reduktion des Datenvolumens
Sessions so lange als möglich offen halten (auch bei Verbindungsverlust!)
Vermeiden von „Polling“ durch den Client (PUSH / PULL)
Zusammenfassen von mehreren logischen Datenströmen in einen Kanal (PIGGY-BACKING)
Lokale Zwischenspeicher (Cache)
56/61
20.02.2009
Mobile Devices
14.5. WAP – Wireless Application Protocol
14.5.1. Grundlegendes
Das Wireless Application Protocol (WAP) bezeichnet eine Sammlung von Techniken und Protokollen,
deren Zielsetzung es ist, Internetinhalte für die langsamere Übertragungsrate und die längeren
Antwortzeiten im Mobilfunk sowie für die kleinen Displays der Mobiltelefone verfügbar zu machen.
14.5.2. Kommunikationsmodell
Die primäre Aufgabe bei WAP ist es, neben der Berücksichtigung der geringen Displaykapazitäten und
Rechenleistung von WAP-Clients, bei der Kodierung der Internetinhalte die offene Struktur und
Lesbarkeit einer Auszeichnungssprache (Markup-Language) beizubehalten, und zugleich die Menge
der zu übertragenden Daten zu reduzieren. Die Lösung des Problems besteht darin, dass bei WAP
zwar die offene Form einer Auszeichnungssprache beibehalten wird, diese jedoch nicht als Text,
sondern in kompilierter Form zum WAP-Client übertragen wird. Dazu erfolgt die Kommunikation
zwischen WAP-Client und Webserver über einen Proxy, den so genannten WAP-Gateway. Dieser
übersetzt die binär vom WAP-Client eintreffenden Anfragen in Klartext (HTML) an den Web-Server.
14.5.3. WAP 1.0
Das WAP-Forum verabschiedete 1997 den WAP 1.0-Standard. Der Standard war nicht ausgereift und
es fehlte an entsprechender Browser-Software und auch an WAP-fähigen Endgeräten. So konnte sich
der Standard nicht kommerziell durchsetzen und blieb praktisch ohne jegliche Bedeutung. Dies lag mit
unter auch daran, dass WAP 1.0 eine Vielzahl spezialisierter Protokolle verwendete.
14.5.4. WAP 2.0
Bei der Spezifikation von WAP 2.0 hat man auf Mobilfunk-Spezifika weitgehend verzichtet und hat die
ursprünglichen WAP-Protokolle WSP, WTP und WTLS durch HTTP und SSL ersetzt. Damit fällt der
Übergang zum Internet wesentlich leichter. Der Vorteil, auch direkt normale Internetseiten im WAPDienst benutzen zu können, zeigt sich wegen der langen Wartezeiten erst mit EDGE oder UMTS. Mit
WAP 2.0 wurde auch das Proxy-Konzept aufgeweicht. Der Standard sieht nun auch die Möglichkeit
vor, dass der Client unter Umgehung des Gateways direkt mit dem Web-Server kommuniziert.
14.5.5. WAP Push
WAP Push ist ein System zur Distribution verschiedener Inhalte von einem Server zu einem
Mobilgerät. Der Content wird dabei prinzipiell ohne Initiative seitens des Clients vom Server auf das
Mobilgerät „geschoben“. Der Server übernimmt daher die Initiative der Übertragung und „pusht“ den
Content zum Client. WAP Push kann als Transportmechanismus SMS oder MMS verwenden.
Ein PI ist grundsätzlich ein Programm, dass eine Push-Nachricht gemäß PAP-Spezifikationen erstellt.
Die Push-Nachricht kann dabei drei verschiedene Formen annehmen, die alle in XML 1.0 verfasst sind
und optional über WBXML kodiert sind. Die drei möglichen Typen sind:
SERVICE INDICATION (SI): Eine SI ist die am häufigsten auftretende Form einer WAP Push
Nachricht und wird im deutschen Sprachraum häufig mit „Dienstmitteilung“ übersetzt (beispielsweise
Nokia Endgeräte) oder einfach als „WAP Push“ angezeigt (Endgeräte von Sony Ericsson). Die SI
benachrichtig den Client über die Verfügbarkeit eines externen Services mittels eines Uniform
Resource Identifiers (URI). In anderen Worten: die SI ist ein Nachricht, die einen Link zu einem
bestimmten Content enthält (auch bekannt als WAP Push Link). Der Client hat nach dem Empfang
der SI drei Möglichkeiten: er kann den Service öffnen, die Nutzung verschieben oder die SI löschen.
57/61
20.02.2009
Mobile Devices
SERVICE LOAD (SL): Empfängt der Client eine SL-Nachricht, hat er im Gegensatz zu SI, keine
Möglichkeiten die URI zu ignorieren. Der Client wird somit nicht über den Empfang eines Services
informiert und erfährt möglicherweise nicht einmal, dass eine SL empfangen wurde, da diese direkt
in den Cache geladen wurden. Obwohl dies ein offensichtliches Sicherheitsproblem darstellt,
verzichtete das WAP Forum auf konkrete Sicherheitsspezifikationen und gab nur einige Richtlinien
zum Schutz von Clients vor Missbrauch. Daher ist die Annahme von SL-Nachrichten bei vielen
mobilen Clients deaktiviert.
CACHE OPERATIONS (CO): Eine CO erlaubt das ungültig machen von Content, das der mobile Client
gecached hat. Dies kann notwendig werden, wenn der Service die zeitliche Gültigkeit des Contents
nicht im Voraus bestimmten kann und die Nutzung einer SI somit nicht praktikabel ist. Ein Beispiel
hierfür wären Mailbox-Anwendungen. Gelesene oder gelöschte Mails können so leicht deaktiviert
werden.
14.6. OBEX – Object Exchange
OBEX ist ein einfaches Client-Server Protokoll für den Objektaustausch zwischen Geräten. Übliche
Objekte sind Kalendereinträge (iCalender), Dateiaustausch (OBEX FTP), Visitenkarten (vCard) und
Nachrichten. Es wurde ursprünglich für den Einsatz mit Infrarot-Schnittstellen entwickelt, wurde
allerdings durch die Bluetooth SIG adaptiert.
58/61
20.02.2009
Mobile Devices
15. MOBILE APPLICATION DESIGN
15.1. Allgemeine Architektur mobiler Anwendungen
Eine übliche mobile Anwendung synchronisiert seine Daten über ein Netzwerk mit einem Server.
Damit die Anwendung auch beim Ausfall der Netzwerkverbindung einsatzfähig bleibt muss ein lokaler
Zwischenspeicher (Cache) vorhanden sein.
Im Gegensatz zur heutigen Situation geht der Trend ganz klar dazu über, dass IN ZUKUNFT die Geräte
nur noch selten verbunden sind, sich dafür aber mit mehreren Datenbanken gleichzeitig abgleichen.
15.2. Design Prinzipien
15.2.1. Einschränkende Faktoren
Arbeitsspeicher
Display
Rechenleistung
Eingabegeräte
Netzwerkverbindung
Persistenter Speicher
Verfügbare Bandbreite
Firewall Probleme
Private IP
15.2.2. Allgemeine Lösungsansätze
Sparsamer Umgang mit beschränkten Ressourcen
Freigabe nicht mehr benötigter Ressourcen
Wenn möglich tastaturgesteuerte Anwendungen (wg. Kompatibilität keine Touchscreens!)
15.2.3. Spezielle Probleme und Lösungsansätze
LIMITIERTE DISPLAYGRÖSSE: Nicht zu viele Elemente im GUI präsentieren
LOKALE BERECHNUNGEN: in Worker-Threads auslagern, um Reaktionszeit des GUI zu erhalten
EINHÄNDIGE VERWENDUNG: nur Geräte mit Keypad-Modalität verwenden
INTERNATIONALISIERUNG: Verwendung von Icons wo immer möglich (vermeidet Übersetzungen)
CODE OBFUSCATION: Erlaubt den Schutz des geistigen Eigentums, Reduktion des Speicherbedarfs
PERFORMANCE:
o Objekte nach Möglichkeit vermeiden, Basistypen verwenden
o Verwendung des Heap (n
new-Operator) reduzieren, besser lokale Variablen auf Stack verwenden
o Objekte nur dann erzeugen, wenn diese gebraucht werden (Lazy Instantiation)
o Bestehende Objekte erneut verwenden („Recycling“)
o Rekursionen im Programmfluss vermeiden
o Thread-Synchronisierung weitgehend vermeiden (grosser Overhead)
o Verwendung von PROFILING-TOOLS zur Optimierung des Codes
EXCEPTIONS: Sind zeitintensiv, deshalb wirklich nur für Ausnahmesituationen einsetzen
15.3. Persistente Speicherung
Wie in der Einleitung dieses Kapitels beschreiben muss ein mobiles Gerät auch dann einsatzfähig sein,
wenn gerade keine Netzwerkverbindung besteht. Daher ist ein persistenter Datenspeicher auf dem
Gerät unabdingbar.
15.3.1. Anforderungen an eine mobile Datenbank
Konstante Performance
Transaktionen
Referenzielle Integrität
Flexible Synchronisation
59/61
Geringes Datenvolumen (Sync.)
Sicherheit der Daten
20.02.2009
Mobile Devices
15.3.2. Typen von Datenbanken
FLACHE DATEIEN: Einfach, aber nicht geeignet für komplexe Datenmodelle. Ein bekanntes Beispiel ist
das RMS von Java ME.
RDBMS: flexibles und weit verbreitetes Paradigma, fehlende Übereinstimmung beim Modell von OO
und RDBMS. Beispiel: MS Embedded SQL Server.
ODBMS: Kein Missmatch mehr zwischen OO-Modell und DB-Modell. Abfragesprache noch nicht
ausgereift. Beispiel: db4o.
XDBMS: Datenbanken basieren auf XML, Effizient in der Interaktion mit XML Daten, dafür erhöhter
Speicher- und Verarbeitungsbedarf.
15.3.3. Möglichkeiten von Microsoft .NET CF
SQL SERVER COMPACT: hierbei handelt es sich um eine kompakte Datenbank, welche direkt mit der
Applikation verknüpft wird (1.4MB grosses SDF-File). Es ist nicht nötig, einen zusätzlichen Server zu
starten. Zugriff auf die Daten ist mittels ADO.NET (ähnlich wie JDBC) oder LINQ (SQL Queries
werden direkt in die .NET Sprache eingebettet) möglich.
DATEISYSTEM: Speicherung im Dateisystem, beispielsweise in einer XML-Datei
REGISTRY: kann für kleine, selten benötigte Daten als Speicherort genügen
15.4. Starten und Beenden von mobilen Anwendungen
Da mobile Anwendungen für den ersten Start in der Regel einige Zeit benötigen ist es weit verbreitet,
die geladenen Anwendungen beim „Schliessen“ nicht vollständig zu beenden, sondern diese einfach
im Hintergrund zu verstecken. Bei einem erneuten „Starten“ der Anwendung wird das versteckte
Fenster nach vorne geholt.
15.4.1. Spezielles für JME
Vor dem manuellen Beenden eines MIDlet über die Methode notifyDestroyed() sollte unbedingt
die Methode destroyApp() aufgerufen werden. Wird das MIDlet über das AMS beendet, so ruft
dieses die Methode auf. Innerhalb von destroyApp() kümmert sich das MIDlet um die Freigabe von
belegten Ressourcen. Durch den boolean-Parameter der Methode kann das sofortige Beenden des
MIDlets erzwungen werden.
try {
destroyApp(false);
//Aufräumen, kein sofortiges Beenden erzwingen
notifyDestroyed();
//MIDlet beenden
} catch (MIDletStateChangeException ex) {
//Ist das MIDlet noch nicht fertig mit aufräumen, so wirft es diese Exc.
}
15.4.2. Spezielles für .NET CF
Wegen des nicht deterministischen Verhaltens des Garbage Collectors sollten Ressourcen nicht
innerhalb eines Destruktors freigegeben werden. Als einfache Lösung empfiehlt sich die Verwendung
der Finalize()-Methode, welche vom GC vor dem Aufräumend es Objektes aufgerufen wird.
15.5. Synchronisierung von Daten
15.5.1. SyncML (Java ME)
SyncML ist ein plattformunabhängiger Standard zur Datensynchronisation zwischen Computern. Bei
den Daten kann es sich um beliebige Informationen handeln, meist PIM-Daten wie Adressen,
Kalendereinträge oder E-Mail-Nachrichten. Die Syntax beruht auf XML und es ist auf keine
Netzwerkarchitektur festgelegt. Dadurch ist eine Synchronisation über das Internet, das Mobilfunknetz
oder zwischen zwei direkt miteinander verbundenen Endgeräten (TCP/IP, WSP oder OBEX) möglich.
SyncML unterstützt 7 verschiedene Synchronisationsarten, wovon das TWO-WAY SYNC das wichtigste
und am meisten eingesetzte ist (siehe Flussdiagramm auf nächster Seite).
60/61
20.02.2009
Mobile Devices
15.5.2. ActiveSync (Windows Mobile)
Microsoft ActiveSync ist eine Software zur Datensynchronisation eines PCs mit einem mobilen Gerät.
Es werden verschiedene Produkte von Microsoft unterstützt, ab dem Betriebssystem Windows Vista
wird die Software nicht mehr unterstützt und durch Windows Mobile-Gerätecenter ersetzt. Die
Software ermöglicht einen Zugriff auf die Ordnerstruktur, Kontakte und Termine des mobilen Gerätes
und synchronisiert dabei Änderungen im Personal Information Manager, die auf dem PC oder dem
PDA vorgenommen wurden.
15.5.3. SQL Server Compact (Windows Mobile)
Auch für die Synchronisation der Embedded SQL Server Datenbank für Windows Mobile Anwendungen
gibt es Synchronisationsmechanismen. Nachfolgend eine Auflistung der wichtigsten Eigenschaften:
61/61
20.02.2009

Zusammenfassung - auf ThomasKaelin.ch

Transcription

Similar documents

Technische Universität Ilmenau Fakultät für Elektrotechnik und

Vertiefungsarbeit - Drahtlose Internetzugänge

ISACA Glossary of Terms English

Pioneer VSX821 - HIFI

Argumentstruktur - Hu

Sophos Control Center Hilfe

Kurzfassung - HAW Hamburg

Rassismus Report 2001

erfahrungen

M55

Umbruch Aufbruch Meilenstein

Java Virtual Machine - DBIS

Bedienungsanleitung

Pflichtenheft - Home

Nero 7 QuickStart