Zusammenfassung - auf ThomasKaelin.ch
Transcription
Zusammenfassung - auf ThomasKaelin.ch
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 Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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, … Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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, … Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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!) Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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(); Kälin Thomas, Abt I 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!). Kälin Thomas, Abt I 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 } Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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“. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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); } Kälin Thomas, Abt I 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( Kälin Thomas, Abt I 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; } Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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! Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 43/61 20.02.2009 Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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); } Kälin Thomas, Abt I 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); } } Kälin Thomas, Abt I 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(); Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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(). Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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) Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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. Kälin Thomas, Abt I 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 Kälin Thomas, Abt I 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). Kälin Thomas, Abt I 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: Kälin Thomas, Abt I 61/61 20.02.2009