Seminar. Komponentenorientierte Softwareentwicklung. und Hypermedia

Transkript

1 Seminar Komponentenorientierte Softwareentwicklung - Von Damian Raschka Betreuer Prof. Dr. F. Thiesing Autor: Damian Raschka.pdf 1 / 35

2 Inhaltsverzeichnis 1. Einleitung Überblick Geschichte 2. Aufbau Configurations Virtual Machines Profiles Zusammenfassung 3. Installation Einzelkomponenten Wireless Toolkit - WTK 4. Erstellen von Programmen Nötige Schritte KToolbar Aufbau eines Programms MIDP-GUI-Modell 5. Ausblick / Empfehlung 6. Referenzen Autor: Damian Raschka.pdf 2 / 35

3 Abbildungsverzeichnis Abbildung 1 Typische Anwendungsgeräte 05 Abbildung 2 Java 2 Plattform 06 Abbildung 3 J2ME Aufbau/Strukturierung 09 Abbildung 4 J2ME Strukturierung CDC/CLDC 14 Abbildung 5 Systemeigenschaften 16 Abbildung 6 Umgebungsvariablen 17 Abbildung 7 PATH CLDC bin 17 Abbildung 8 MIDP PATH bin 18 Abbildung 9 MIDP_HOME 18 Abbildung 10 MIDP CLASSPATH 18 Abbildung 11Eingabeaufforderung Installation testen 19 Abbildung 12 WTK Installation 21 Abbildung 13 KToolbar opened 23 Abbildung 14 KToolbar new project 23 Abbildung 15 KToolbar open project 24 Abbildung 16 KToolbar new project settings 24 Abbildung 17 KToolbar new project settings 2 25 Abbildung 18 KToolbar new project saved 25 Abbildung 19 KToolbar Build 26 Abbildung 20 KToolbar Settings 27 Abbildung 21 KToolbar Run Emulator 27 Abbildung 22 KToolbar Run Emulator 27 Abbildung 23 Quellcode Programmaufbau 28 Abbildung 24 MIDlet Zustände 29 Abbildung 25 Display-Screen 31 Tabellenverzeichnis Tabelle 1 Vergleich CDC-CDLC 10 Autor: Damian Raschka.pdf 3 / 35

4 1 Einleitung Java-fähig, Java-Spiele, auf Java-Basis, Java-Kompatibel, etc. Dies sind alles Stichworte, die dem einem oder anderen beim Kontakt mit Handys oder anderen mobilen Geräten schon einmal begegnet sind. Vor allem in den Produktblättern oder in der Werbung des einen oder anderen Gerätes tauchen diese Begrifflichkeiten schon mal auf. Aber was genau heißt denn nun Java-tauglich? Und was hat J2ME damit zu tun? Ja, was ist denn überhaupt J2ME?? Diese Fragen sollen hier in diesem Kapitel beantwortet werden. Daneben soll kurz auf den Ursprung von J2ME und die groben Einsatzgebiete eingegangen werden. Autor: Damian Raschka.pdf 4 / 35

5 1.1 Überblick Wie in der Einleitung angekündigt wollen wir hier nun klären, um was es sich bei J2ME überhaupt handelt. Dies ist an sich schnell getan, J2ME steht für Java 2 Micro Edition, womit man auf den ersten Blick auch den ungefähren Verwendungszweck einordnen könnte: Kleinstgeräte. Ganz so einfach ist dies jedoch nicht, wie wir in Kapitel 2 noch sehen werden. Wir können jedoch schon mal grob festhalten, dass der Verwendungszweck klar im mobilen, limitierten (bzgl. Ressourcen) Kleingerätebereich liegt. Dies ist vor allem im Vergleich zu Desktop-Rechnern zu sehen. Dabei machen sich die Einschränkungen vor allem in der Displaygröße, der Speicherausstattung und der Prozessorleistung bemerkbar. Als Beispiele lassen sich hier Mobiltelefone, Smartphones und PDAs nennen, wobei wir auch schon die momentanen Haupteinsatzgebiete (-Geräte) genannt hätten. Abb. 1: Typische Anwendungsgeräte Aber warum wird eine extra Java-Version benötigt? Während Desktop-PCs heutzutage über genügend großen Speicher und mehr als ausreichende Rechenleistung besitzen, zeigen die oben erwähnten Gerätschaften dahingehend eher (noch) eine Schwäche, auch wenn die Leistungskraft in den letzten Jahren auch hier stetig zugenommen hat. Zwar ist die J2SE (Java 2 Standard Edition) in den letzten Jahren hinsichtlich ihrer Performance stetig verbessert worden, aber gleichzeitig wuchs durch den anwachsenden Bestand an mitgelieferten Klassenbibliotheken der Umfang ebenfalls enorm. Hier liegt neben den höheren Leistungsanforderungen gleich der zweite Kritikpunkt: viele Klassen und Funktionen werden auf den kleineren Geräten überhaupt nicht benötigt! Autor: Damian Raschka.pdf 5 / 35

6 1.1 Überblick Es wird also eine Version von Java benötigt, die sowohl keine hohen Hardware- Anforderungen stellt, als auch von der möglichen Funktionalität gerade ausreichend genug ist. Mit der J2ME wurde solch eine Plattform geschaffen, die sowohl diesen Beschränkungen als auch den modernen Möglichkeiten und Anforderungen genügt. Gleichzeitig erschließt sich damit für Java ein weiteres, neben der J2SE (Standard Applikationen) und J2EE (Java 2 Enterprise Edition (Firmenübergreifende) Client- Server Applikationen), 3. Anwendungsgebiet. Das Argument der Plattformunabhängigkeit wird weiter gestärkt. Abb. 2 Java 2 Plattform Autor: Damian Raschka.pdf 6 / 35

7 1.2 Geschichte Vorgestellt wurde J2ME das erste mal 1999 auf der Java-One Konferenz. Somit ist es noch sehr jung. Die Idee aber ist schon sehr viel älter und eng mit der Entstehung und Geschichte von Java verwoben: Das Green Project stellte man bei Sun Überlegungen zur zukünftigen Entwicklung von Rechnern und Computern an. Das primäre Ziel dabei war es, dass Sun an dieser Entwicklung teilhaben / mitarbeiten solle. Dabei entstand die Idee einer Verschmelzung von digitalen Verbrauchergeräten (für die Zeit typisch: Taschenrechner und elektr. Übersetzer) mit Computern. Man könnte sagen, so eine Art Vorläufer der heutigen PDA. Daraufhin entwickelte man einen Prototyp, der wegen seinem geringen Hauptspeicher jedoch auch ein neues Betriebssystem brauchte. Da die Entwickler jedoch nicht so wirklich von C++ begeistert waren, entwickelten sie (maßgeblich James Gosling) eine neue Programmiersprache. Das Ergebnis war Oak, der Vorfahre von Java. Während der Jahre der Weiterentwicklung von Java wuchs dieses jedoch immer mehr an. Es wurde immer umfangreicher und das Ziel wurde immer mehr der Einsatz auf leistungsstarken Desktop-PCs. So verlor sich das einstige Hauptziel, der Einsatz auf mobilen Geräten, immer mehr. Erst 1998 erfolgte mit dem Start des Forschungsprojekts Spottless System eine Art Rückbesinnung zu alten Zielen: Man wollte eine Java-Laufzeitumgebung speziell für eingebettete Systeme entwickeln. Dabei sollte sie folgende Ziele erfüllen: kleinstmögliche, vollständige Java-Laufzeitumgebung (inklusive dem nachladen von Java-Klassen, allerdings ohne Klassen für eine GUI) Portierung auf eine größtmögliche Menge von verfügbaren eingebetteten Systemen Die erste Laufzeitumgebung kam dann auch mit nur 300 KB Speicher aus. Für die Portierung auf Endgeräte testete man zunächst den Rolodex REX Personal Organizer von Franklin Electronic Publishers. Aufgrund mangelnder Unterstützung entschied man sich dann jedoch für Palm-PDA (damals von 3Com). Diese erste Laufzeitumgebung war sehr Eingeschränkt und Gerätespezifisch und für andere Geräte/Systeme nicht portabel. Autor: Damian Raschka.pdf 7 / 35

8 1.2 Geschichte 1999 erfolgte dann das Einfließen der Ergebnisse des Spottless-Projekts in die Java Familie. Ergänzt wurde dabei auch die virtuelle Maschine um die KVM, dem Nachfolger des Spottless-Systems. Von nun ab erfolgte (und erfolgt bis heute) die weitere Entwicklung nicht mehr ausschließlich von Sun-Ingenieuren, sondern durch verschiedene Firmen. Dies geschieht durch die so genannten JCPs (Java Community Process, Bildung von Expertengruppen mit dem Ziel von Java-Spezifizierungen). Zusammenfassend kann man also sagen, Java und J2ME entstanden aus der Idee, (für) kleine, mobile Geräte entwickeln zu wollen. An Bedeutung hat es seit 1999 in den letzten Jahren vor allem durch die rasche technische Entwicklung im Bereich mobile Telefone / Smartphones gewonnen. Diese machen der ursprünglichen Plattform, dem PDA auch mehr und mehr Konkurrenz. Autor: Damian Raschka.pdf 8 / 35

9 2 Aufbau Wir haben in Kapitel 1 schon erfahren, dass es sich bei den Zielgeräten um vorwiegend mobile Geräte mit limitierter Leistungsfähigkeit handelt. Diese Feststellung alleine reicht jedoch nicht aus, wenn man bedenkt, wie viele Kleingeräte es gibt. Es sind also weitere Einteilungen innerhalb dieser Eingrenzung notwendig. Die verschiedenen Geräte liegen in ihren beabsichtigten Anwendungsfeldern mehr oder weniger stark auseinander, was sich auch in der Leistungsfähigkeit und den Systemarchitekturen der Geräte wieder spiegelt. Die J2ME-Plattform darf diese Tatsache nicht einfach ignorieren und muss eine weitest mögliche Unterstützung gewährleisten. Dies tut sie mit ihrer besonderen (Baukasten ähnliche) Architektur: Abb. 3 J2ME Aufbau Autor: Damian Raschka.pdf 9 / 35

10 2.1 Configuration Wir wollen uns zunächst der Configuration-Ebene widmen. Sie wird den Anforderungen des strukturellen Aufbaus (verschiedener Endgeräte) gerecht. Durch Festlegung bestimmter Merkmale stellt eine Configuration quasi eine Plattform für bestimmte Gruppen von Endgeräten dar. Konkret sehen diese Merkmale die Angabe der Unterstützung von Merkmalen und Features der Java-Programmiersprache, der JVM und der Java-API's vor. Momentan existieren zwei Configurations, die grob zwei Gerätegruppen abdecken: CDC (Connected Device Configuration) CLDC (Connected Limited Device Configuration) konkrete Unterscheidung: CDC min 512 KB Speicher für Java-Umgebg. min 256 KB für Laufzeitumgebg. 32-Bit Prozessor Tabelle 1 Vergleich CDC-CLDC CLDC min 128 KB für Java-Umgebg. min 32 KB für Laufzeitumgebg. mobile Stromversorgung Für beide Configurations gilt: Verbindung zu einem Netzwerk muss vorhanden/möglich sein (wahlweise drahtlos). Während CDC vergleichsweise seltener Eingesetzt wird (Set Top Boxen, Screenphones, etc), kommt CLDC gerade im Schwerpunkt Handys und mobile Organizer bevorzugt zum Einsatz. Für PDA's ist eine dritte Configuration geplant, befindet sich jedoch noch in der Entwicklung. Momentan werden PDA's noch von beiden Configurations abgedeckt: CDC für High-End-PDA's und CLDC für Low-End-PDA's. Autor: Damian Raschka.pdf 10 / 35

11 2.2 Virtual Machine (VM) Zur Erinnerung: Der Java-Compiler erzeugt keine, in Maschinensprache ausführbaren Programme, sondern Byte-Code für den Interpreter. Programme laufen in der Virtual Machine ab. Für das J2ME gibt es aber nun zwei Virtual Machines: CVM für CDC Alle Features und Möglichkeiten der gewöhnlichen J2SE VM. Lediglich bei den API's leichte Einschränkungen. Dies liegt daran, dass die Geräte meist größer sind und über großzügigere Ressourcen verfügen. KVM für die CLCD Starke Begrenzung durch die Zielrichtung auf stark limitierte Endgeräte im mobilen Bereich (Umfang der Funktionen stark reduziert). Dabei steht das K für Kilobyte, da diese VM nur wenige Kilobyte Speicher erfordert. Basis in C entwickelt worden, dadurch mehr Hardware-Nähe. Festzuhalten ist also, dass durch die Configuration die Verwendung und somit der Umfang der VM bestimmt wird. Es existieren unterschiedliche Implementierungen der VM für die jeweilige Configuration. Da wir uns im weiteren Verlauf (bedingt durch die Zielgruppe der Geräte und Anwendungen) mehr mit dem CLDC und dem (wichtigsten darauf aufbauenden Profile) MIDP beschäftigen werden, will ich hier noch kurz auf die Pakete der CLDC eingehen: Implementiert wurden java.io java.lang java.util Es ist jedoch anzumerken, dass sich die Implementierungen der Funktionen grundlegend unterscheiden. Zusätzlich hinzugekommen ist noch das Paket java.microedition.io, welches Verbindungs-Klassen enthält (spezielle Netzwerk-Funktionen der Endgeräte, werden auch Generic Connection Framework GCF genannt). Autor: Damian Raschka.pdf 11 / 35

12 2.2 Virtual Machine (VM) Weitere Unterschiede: keine Fließkommazahlen (da zu rechenintensiv) Fehlerbehandlung wesentlich geringer Fehlendes JNI (Java Native Interface Fähigkeit, Bibliotheken aus anderen Programmiersprachen verwenden zu können) keine Reflections kein Class-Loader Autor: Damian Raschka.pdf 12 / 35

13 2.3 Profiles Die Profile-Ebene setzt auf der Configuration-Ebene auf und erweitert die bestehenden API's. Da die Spezifikation durch die Configurations immer noch sehr grob ist (z.b. Handys: benutzen zwar CLDC, aber viele verschiedene Modelle, mit verschiedenen Displays oder anderen differenzierenden Merkmalen), besteht durch die Profiles die Möglichkeit, eine Anpassung an spezielle Endgeräte vorzunehmen. Sie umfassen z.b. Schnittstellen für grafische Benutzeroberflächen oder die persistente Datenhaltung, etc. Einige mögliche Profiles: Foundation: Erweiterung der CDC, bzw. Basis für weitere, auf CDC aufbauende Profiles. Personal: Weitere Unterstützung des Foundation Profiles. Erweiterung der Schnittstelle um GUI-Komponenten. PDA: Erweiterung der CLDC. Optimierung für den Einsatz auf PDA's. MIDP: Mobile Information Device Profile. Geht auf spezielle Anforderungen von mobilen Endgeräten ein (Handys, Pager, usw.). Das am meisten eingesetzte Profil. Autor: Damian Raschka.pdf 13 / 35

14 2.4 Zusammenfassung Letztendlich ergibt sich durch diese drei Ebenen und durch die zwei verschiedenen Configurations ungefähr folgender Aufbau: Abb. 4 Beispiel Aufbau, OS = Operating System (Betriebssystem) Ergänzend sei hier jedoch noch angemerkt, dass es sich bei der Aufzählung der Profiles nur um einen Ausschnitt der möglichen handelt. Jede Seite könnte also noch mit weiteren ergänzt werden. Autor: Damian Raschka.pdf 14 / 35

15 3 Installation Für die Installation bestehen zwei Möglichkeiten: 1. Installation der Einzelkomponenten (hier: CLDC und MIDP), oder 2. das J2ME Wireless Toolkit (WTK) Wie Abb.2 bereits zeigte, ist die Basis einer J2ME-Entwicklungsumgebung die J2SE. Sie muss also vor der Installation der J2ME bereits installiert sein. (J2SE unter java.sun.com/j2se/index.jsp) Autor: Damian Raschka.pdf 15 / 35

16 3.1 Einzelkomponenten CLDC Den Download finden Sie unter: wwws.sun.com/software/communitysource/j2me/cldc/download.html Installation in ein beliebiges Verzeichnis. Nach der Installation sollte das Unterverzeichnis \bin als globale Pfadvariable aufgenommen werden. Dabei gehen Sie folgendermaßen vor: Win 95/98/ME Die Datei Autoexec.bat bearbeiten und folgende Zeile entweder anlegen oder ergänzen: PATH=[Ziellaufwerk\Installationsverzeichnis]\bin\win32. Beispiel: PATH=C:\j2me\j2me_cldc\bin\win32 Win2000/XP => Start =>Systemsteuerung => System => Erweitert => Umgebungsvariablen Abb.5 - Systemeigenschaften Autor: Damian Raschka.pdf 16 / 35

17 3.1 Einzelkomponenten => Eintrag PATH suchen Abb.6 - Umgebungsvariablen und wie oben beschrieben anpassen Abb.7 PATH CLDC bin Autor: Damian Raschka.pdf 17 / 35

18 3.1 Einzelkomponenten Als nächstes wird das MIDP installiert. Den Download finden Sie unter: wwws.sun.com/software/communitysource/j2me/midp/download20.html Nach der Installation ebenfalls das Unterverzeichnis \bin der Umgebungsvariablen PATH hinzufügen. Abb.8 MIDP PATH bin Ist dies erledigt, müssen noch zwei weitere Umgebungsvariablen gesetzt werden: MIDP_HOME C:\j2me\midp2.0fcs Abb.9 - MIDP_HOME CLASSPATH C:\j2me\midp2.0fcs\classes Abb.10 - CLASSPATH Autor: Damian Raschka.pdf 18 / 35

19 3.1 Einzelkomponenten Um die erfolgreiche Installation zu testen öffnet man einfach eine Eingabeaufforderung und tippt dann in der Kommandozeile folgendes ein: midp -version Abb.11 - Eingabeaufforderung Das Ergebnis (die Ausgabe) sollte dem in Abb.11 entsprechen Autor: Damian Raschka.pdf 19 / 35

20 3.2 Wireless Toolkit (WTK) Statt der Einzelkomponenten bietet Sun auch ein Gesamtpaket an. Dies macht nicht nur die Installation einfacher, sondern bringt auch noch die GUI- Anwendung KToolbar mit. Sie erspart einem wesentliche Arbeit, nicht nur, weil man durch nicht mehr über Kommandozeile arbeiten muss, sondern auch, weil sie die in der Entwicklungsphase auszuführenden Schritte (siehe Kapitel 4) vereinfacht und beschleunigt. Ein weiterer großer Vorteil sind die enthaltenen Emulatoren für verschiedene Endgeräte. Durch sie wird es ermöglicht, die Anwendung ausgiebig zu testen, ohne sie jeweils auf das Endgerät laden zu müssen. Das WTK kann unter java.sun.com/products/j2mewtoolkit/download-2_1.html in der Version 2.1 runter geladen werden. Es sei jedoch darauf hingewiesen, dass es sich bei dem WTK um keine komplette Entwicklungsumgebung (IDE) handelt! Es ist kein Editor enthalten! Das WTK nur ein Werkzeug Projektverwaltung. Der Quellcode muss mit einem externen Editor erstellt werden. In früheren Versionen war es jedoch möglich, das WTK in eine bestehende Forte for Java Installation zu integrieren. Aus dieser Kombination erhielt man eine komplette MIDP-Entwicklungsumgebung. Bei der Installation des WTK wäre noch auf folgendes zu achten: Vor der Bestimmung des Installationspfades wird noch nach dem Installationspfad einer installierten J2SE (VM) gefragt. Wenn eine installiert ist, wird automatisch dessen Verzeichnis vorgeschlagen. Sind jedoch mehrere installiert, wird nicht automatisch die aktuellste Version vorgeschlagen! Hier muss man dann über die Schaltfläche Browse selber das Verzeichnis bestimmen. Auf Abb.12 sehen wir solch einen Fall. Entdeckt wurde jdk1.4 in dem Installations- Verzeichnis von JBuilderX (eine umfangreiche Entwicklungsumgebung von Borland). Das Verzeichnis wurde daraufhin manuell auf die Installation umgestellt. Autor: Damian Raschka.pdf 20 / 35

21 3.2 Wireless Toolkit (WTK) Abb.12 WTK-Install Es sollte jedoch noch angemerkt werden, dass es neben dieser Standard/Referenz Umgebung von Sun auch noch Umgebungen von Drittanbietern gibt. Seien es nun geräte-/serienspezifische SDKs/APIs, wie z.b. von Nokia, Sony Ericsson, Siemens, o. A. als auch IDE Umgebungen/Plugins, wie z.b. das erwähnte JBuilderX von Borland oder das Eclipse J2ME Plugin (Vers ). Zusätzliche SDK/API bringen z.b. zusätzliche gerätespezifische Funktionen für Zugriffe/Benutzung von Tasten, Grafiken, Sound, Vibration, Beleuchtung, usw. Auf den Download, Installation und Benutzung/Verwendung wird hier jedoch nicht weiter eingegangen. Download-Adressen entnehmen Sie bitte Kapitel 6 - Referenzen Autor: Damian Raschka.pdf 21 / 35

22 4 Erstellen von Programmen Bevor wir nun KToolbar vorstellen und danach ( endlich ;-) zum Aufbau von Programmen kommen, erfolgt zuerst noch mal eine kurze Zusammenfassung der nötigen Schritte zur Erstellung eines Programms. Abgeschlossen wird das Kapitel durch eine kurze Einführung in das MIDP-GUI- Modell. 4.1 Nötige Schritte Hier seien nur kurz die 6 nötigen Schritte zur Erstellung einer lauffähigen Applikation (bei MIDP Applikationen auch MIDlet genannt) erklärt. Es wird nur kurz auf die Bedeutung einzelner Schritte eingegangen, jedoch nicht die Ausführung erklärt. Wird ein Tool wie z.b. KToolBar benutzt, wird einem mehr oder weniger ein Großteil der Arbeit abgenommen (außer 1. ;-). Wird jedoch ausschließlich per Hand (Kommandozeile) gearbeitet, bleibt einem nicht erspart, die einzelnen Schritte selbst auszuführen. 1. Schreiben des Java-Quellcodes (Kein Kommentar) 2. Kompilieren (Kein Kommentar) 3. Pre-Verifizieren: Überprüft alle class-dateien auf mögliche Laufzeitfehler. Warum? Auch bei J2SE wird eine Verifizierung durchgeführt. Dies geschieht dort jedoch während der Laufzeit und dabei wird ein zusätzlicher Speicher von KB benötigt. Bei CLCD-Geräten wäre dadurch jedoch bereits ein beträchtlicher, wenn nicht sogar der Großteil des Speichers belegt. Deshalb wird hier der Preverifizierer aufgerufen, der diesen nötigen Schritt vorher (vor der Laufzeit) erledigt. Die Informationen werden innerhalb der class-datei abgelegt und das CLDC-Gerät überprüft dann nur noch mal kurz die class-datei auf diesen Hinweis. 4. Erstellen eines JAR-Archivs: Alle benötigten Klassen (MIDlets) und Ressourcen werden für die Auslieferung in einer JAR-Datei zusammengefasst 5. Erstellen einer JAD-Datei: Der Java Application Descriptor stellt Informationen über eine Anwendung zur Verfügung. Sie ähnelt der Manifest Datei (wird in einem JAR-Archiv angelegt), nur das sie außerhalb des JAR-Archivs liegt. Sie dient dazu, Informationen über die Anwendung zu liefern, bevor diese (auf das Gerät/in den Speicher) geladen wird! 6. Testen des MIDlet (im Emulator) Autor: Damian Raschka.pdf 22 / 35

23 4.2 KToolbar Wie bereits erwähnt, handelt es sich um KToolbar um eine Anwendung zur Projekt- Verwaltung. Dabei nimmt es einem so gut wie alle oben erwähnten Schritte ab. Hier nun ein kleiner User-Guide : Öffnen sie das Programm über Start => Programme => J2ME Wireless Toolkit => KToolbar Abb.13 KToolbar Opened Wählen Sie dann New Project Im nun erscheinenden Dialog müssen sie einen Projekt-Namen und den MIDlet- Klassen-Namen eingeben. Abb.14 KToolbar New Project Autor: Damian Raschka.pdf 23 / 35

24 4.2 KToolbar Sie können aber auch ein bereits existierendes Projekt öffnen. Dabei sucht KToolbar standardmäßig im J2ME-Installationsverzeichnis, im Unterordner Apps. Abb.15 KToolbar Open Project Hat man sich für ein neues Projekt entschieden und die erforderlichen Namen eingegeben, erscheint als nächstes der Settings-Dialog. Abb.16 KToolbar New Settings Autor: Damian Raschka.pdf 24 / 35

25 4.2 KToolbar Wie man sieht, sind bereits alle wichtigen Einstellungen vorgenommen worden. Abb.17 KToolbar New Settings2 Wenn man den Settings Dialog bestätigt erscheint nun in der Hauptkonsole folgende Ausgabe. In \Apps wurde ein neuer Ordner mit dem Projekt-Namen erstellt. Abb.18 KToolBar New Project Saved Hier wird uns auch nun mitgeteilt, wohin wir unsere fertige Java-Quellcode-Datei und andere Ressourcen hin kopieren sollen. Nachdem wir alle notwendigen Dateien in die entsprechenden Verzeichnisse kopiert haben betätigen wir den Knopf Build. Autor: Damian Raschka.pdf 25 / 35

26 4.2 KToolbar KToolbar kompiliert daraufhin die Quell-Dateien. Sollten dabei Fehler auftreten, werden die Fehlermeldungen (mit Angabe der Fehler-Zeile) in der Konsole angezeigt. Abb.19 KToolbar - Build Autor: Damian Raschka.pdf 26 / 35

27 4.2 KToolbar Wenn Sie sich beim Erzeugen des Projekts mit dem MIDlet-Namen vertippt haben, können Sie das jetzt immer noch über Settings/MIDlets korrigieren. Abb.20 KToolbar Settings Ist dann alles reibungslos abgelaufen können Sie nun mit Run Ihre Anwendung testend. Abb.21 Abb.22 KToolbar Emulator Autor: Damian Raschka.pdf 27 / 35

28 4.2 KToolbar Wenn nach dem Testen alles problemlos läuft, können Sie nun unter der Menü- Option Project/Package/Create Package die JAR- und JAD-Datei anlegen lassen. Die beiden Dateien werden im \bin Verzeichnis des Projekts abgelegt. Abschließend können Sie nun einen Ordner mit den beiden Dateien auf Ihr Gerät laden. Wenn alles geklappt hat sollte es nun dort laufen. 4.3 Aufbau eines Programms Schauen wir nun mal in unser erstes Programm. Abb.23 Quellcode Zunächst sehen wir die beiden import-anweisungen. Die erste ermöglicht uns die Nutzung des MIDlet Pakets, während uns die zweite gestatten soll, grafische Elemente in unser MIDlet einzubinden. Autor: Damian Raschka.pdf 28 / 35

29 4.3 Aufbau eines Programms Als nächstes müssen wir unsere Klasse von MIDlet ableiten, da wir ja ein MIDlet erstellen wollen. Als nächstes fallen hier jetzt 4 Methoden auf. Die erste beschreibt den Konstruktor, der jedoch nicht unbedingt notwendig ist. Die anderen drei sind die Methoden startapp(), pauseapp() und destroyapp(). Sie müssen immer implementiert werden, der Rumpf kann aber leer gelassen werden. Die Implementation ist deshalb so wichtig, da sie den Programmablauf, und somit auch die 3 Zustände eines MIDlets widerspiegeln. Abb.24 MIDlet Zustände Paused: Zustand der Inaktivität nachdem Ausführen des Konstruktors. Kann mehrfach eingeleitet und wieder verlassen werden. Active: Führt gerade eine Funktion aus. Nicht Paused. Destroyed: Nach dem Ende der Ausführung. Freigabe der Ressourcen. Normalerweise übernimmt der Applikations-Manager die Steuerung des MIDlets. Er erkennt z.b. automatisch, wenn das MIDlet keine Aktionen ausführt und nimmt entsprechenden Zustandswechsel vor. Man kann den Manager jedoch auch explizit Zustandswechsel durchführen lassen. Dies geschieht durch folgende Methoden: resumerequest() Wechsel in den Zustand Active notifypaused() Wechsel in den Zustand Paused notifydestroyed() Zustand Destroyed, beendet MIDlet Autor: Damian Raschka.pdf 29 / 35

30 4.4 MIDP-GUI-Modell Das Paket javax.microedition.lcdui beinhaltet alle Wichtigen Komponenten und Schnittstellen für grafische Darstellung des MIDP-GUI-Modells. Allen Voran die Klassen Display und Screen, aber dazu gleich noch mehr. Vielmehr sollte aber auch noch erklärt werden, dass dieses Modell keine eingeschränkte Version der AWT-API ist, also nichts mit AWT oder auch SWING zu tun hat, sondern ein völlig anderes, eigenes Display-Konzept verfolgt. Gründe gegen AWT: AWT ist für Anwendungen von Desktop-Rechnern ausgelegt Unterscheidung von Eingabegeräten am Desktop und mobilen Rechnern Layout- und Fenster-Verwaltungsoptionen von AWT übersteigen die Anforderungen von mobilen Geräten bei weitem. Die Klasse Display Sie liefert den Zugriff auf das Display eines Gerätes. Pro MIDlet kann nur ein einziges Display-Objekt existieren (da das Objekt auch den Display-Manager zur Verfügung stellt). Die Klasse Screen Die aktuelle, sichtbare Darstellung auf dem Display wird Screen genannt. Es kann und wird immer nur ein Screen gleichzeitig dargestellt. Mehrere Screens sind jedoch beliebig austauschbar. Autor: Damian Raschka.pdf 30 / 35

31 4.4 MIDP-GUI-Modell Abb.25 Display-Screen Model Durch die Display-Methode setcurrent(screen scr) setzt und aktualisiert man die Referenz auf den jeweils anzuzeigenden Screen. Aber bevor wir weiter darauf eingehen, müssen wir noch eine kleine Unterscheidung der MIDP-API in zwei Teilbereiche machen: 1. High-Level-API: Allgemeine Darstellung ohne direkten Hardware-Zugriff. Nur sehr begrenzte Möglichkeiten der Einflussnahme auf die Grafik- Elemente. Bei Zielsetzung einer höchstmöglichen Kompatibilität zu wählen. Klasse: Screen 2. Low-Level-API: Weitergehende Möglichkeiten zur Manipulation und zur Anpassung von Grafikkomponenten, Umfassende Kontrolle über die grafische Darstellung auf dem Bildschirm. Kompatibilität des MIDlet ist für andere Geräteplattformen (als das Zielsystem) nicht Gewährleistet. Klasse: Canvas. Autor: Damian Raschka.pdf 31 / 35

32 4.4 MIDP-GUI-Modell Theoretisch ist Canvas auch ein Screen, da es ebenfalls den ganzen Bildschirm ausfüllt. Der Unterschied liegt nur darin, dass Canvas den vollen manipulativen Zugriff auf seine Elemente zulässt. Screen ist jedoch eine abstrakte Klasse und wird in der High-Level-API von den 4 folgenden abgeleiteten Klassen repräsentiert: Textbox: (Texteingabe, Eingabefeld) List (Auswahl-Listen) Alert (Angabe von Informationen oder Meldungen. Form (Container für andere/mehrere Elemente) Dabei wird die Darstellung der ersten drei auch als Screen realisiert, also auf dem ganzen Bildschirm. Weshalb auch nur eine Komponente dargestellt werden kann. So eine Art Gegenstück zu Screens sind Items, da sie meist nur einen teil des Bildschirms einnehmen, sich in einem gewissen Rahmen positionieren lassen und auch mehrere gleichzeitig zulassen. Der Behälter für Items ist Form. Autor: Damian Raschka.pdf 32 / 35

33 5 Ausblick / Empfehlung Eine klare Empfehlung auszusprechen ist meiner Meinung nach ein wenig schwierig. Gerade durch die technische Entwicklung im Segment der Mobiltelefone erfolgt in den letzten 2, 3 Jahren ein drastischer Anstieg in der Entwicklung von Software. In dem momentanen Boom kriegt man vor allem die Verbreitung von Software im Unterhaltungssektor, also Spiele mit. Aber auch andere Produkte machen sich jetzt mehr und mehr auch auf Handys breit, die man vorher nur auf leistungsstärkeren PDAs gefunden hat (z.b. GPS, Satellitennavigation). Gerade durch den technischen Schub im Handy-Bereich erhält die Technik Java mit J2ME die Möglichkeit sich zu verbreiten und nicht nur eine Größere Konsumentenschar zu bedienen, sondern auch vermehrt das Interesse von Entwicklern an sich zu ziehen. Ein Manko wird jedoch auch weiterhin bleiben, sich mit Java auf kleinen Geräten, gerade auf Handys, nicht die volle Leistungsfähigkeit nutzbar machen zu können. Zumindest nicht ohne an Portabilität zu verlieren. Zudem kommt hinzu, dass sich auch nicht jeder mit den kleinen, bunten, nervigen Dingern anfreunden kann. Für manche sind diese Geräte einfach nur nervig, für andere nur Gebrauchsgegenstände. Trotz der Beschränkung der Ressourcen effizient zu Programmieren könnte aber auch für so manch einen ein weiterer Anreiz sein. Mit Prognosen vorsichtig zu sein zeigt die Seminar-Arbeit von Marco Dubacher und Markus Blatter für das Institut für Informatik der Universität Zürich von Thema des Seminars war Java, Embedded Systems and Mobile Commerce. Dabei untersuchten die beiden das MIDP genauer und Prognostizierten/Mutmaßten letztendlich, dass es MIDP sehr schwer haben würde, sich (wenn überhaupt) am Markt durchzusetzen. Das verwundert nicht unbedingt, war das MIDP zu diesem Zeitpunkt weder so entwickelt wie heute, noch gab es die große Masse an Geräten dafür. Der größte Einsatzbereich, PDA's war noch durch individuellere, hardwarenähere Lösungen bedient. Dies zeigt nur, wie schnell sich der Markt und Nachfrage und Bedürfnisse ändern können. Ich komme zu dem Schluss, dass durch momentane hohe Nachfrage die Entwicklung sowohl im Konsumenten als auch im Bereich m-commerce und Dienstleistungen weiter steigen und positiv verlaufen wird. Dabei kommt die technische Weiterentwicklung dem nur zugute, vor allem was die Portabilität anbelangt. Autor: Damian Raschka.pdf 33 / 35

34 6 Referenzen Verwendete Quellen: Java 2 Micro Edition J2ME Developers Guide Das Einsteigerseminar Michael Kroll, Stefan Haustein Sebastian Eschweiler Markt + Technik Verlag, 2003 Verlag moderne industrie Buch, 2003 Links: J2SE Download: J2SE unter java.sun.com/j2se/index.jsp CLDC Download: wwws.sun.com/software/communitysource/ j2me/cldc/download.html MIDP Download: wwws.sun.com/software/communitysource/ j2me/midp/download20.html WTK Download: java.sun.com/products/j2mewtoolkit/download-2_1.html MIDP Emulatoren: developers.sun.com/techtopics/mobility/midp/ articles/emulators Tutorials: developers.sun.com/techtopics/mobility/learn Techn. Artikel: developers.sun.com/techtopics/mobility/reference/ techart/index.html Beispiele: developers.sun.com/techtopics/mobility/reference/ Anwendungen codesamples/index.html Dokumentationen: developers.sun.com/techtopics/mobility/reference/ docs/index.html FAQs: developers.sun.com/techtopics/mobility/reference/ faqs/index.html 3 rd Party: developers.sun.com/techtopics/mobility/allsoftware Autor: Damian Raschka.pdf 34 / 35

35 6 Referenzen Beispiel-Anwendungen Falk Activepilot Navigationssystem Mobile Education Mobiles Lernen, Dienst der Fernuniversität Hagen Firma Dialogs Software GmbH mehrere Applikationen und Dienste Materna Anny Way, Mobile Solutions by Materna Spiele Autor: Damian Raschka.pdf 35 / 35