![]() |
|
|||||
Wir könnten die Überprüfung auch über ein InetAdress Objekt realisieren.
Listing 20.5 AppletURLConstructor.java import java.applet.Applet; 20.4.3 Was ein Applet alles darf
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
interface java.applet.AppletContext |
| AudioClip getAudioClip( URL ) Erzeugt ein AudioClip-Objekt, welches durch die URL-Angabe angegeben ist. |
Wir platzieren die Audiodatei in unserem Code-Verzeichnis, sodass über die Methode getCodeBase() keine weiteren Angaben zum Host zu machen sind. Das Applet bekommt eine Minimalausführung. In der init()-Funkiton lesen wir die Datei, und die start()-Methode spielt den AudioClip mit seiner ureigensten Methode play() ab.
Listing 20.6 AudioPlayer.javaimport java.applet.Applet;
import java.awt.*;
public class AudioPlayer extends Applet
{
String file = "lala.au";
AudioClip ac;
public void init()
{
ac = getAudioClip( getCodeBase(), file );
start();
}
public void start()
{
ac.play();
}
public void stop()
{
ac.stop();
}
}
Da das Applet lediglich beim Starten Musik abspielen muss, benötigt es auf dem Bildschirm auch keine Ausmaße – wir können somit Höhe und Breite bedenkenlos auf Null setzen. Das Applet-Tag ist herzlich kurz.
Listing 20.7 index.html<applet code=AudioPlayer.class width=0 height=0></applet>
Dass das Programm noch wesentlich kürzer programmiert werden kann, zeigt folgende Überlegung: In der init()-Methode können wir schon sofort mit dem Abspielen der Musik beginnen. Wir vereinbaren eine Variable musiFileName, über die wir die Musikdatei austauschen. Somit ist unser Programm wesentlich flexibler.
Listing 20.8 AudioPlayer.javaimport java.applet.Applet;
import java.awt.*;
public class AudioPlayer extends Applet
{
public void init()
{
String soundFile = getParameter( "musiFileName" );
play( getCodeBase(), soundFile );
}
}
Zum Einbinden dieses Applets können wir etwa folgenden HTML-Code verwenden:
Listing 20.9 index.html<applet code="AudioPlayer.class" width=0 height=0>
<param name="musiFileName" value="lala.au">
</applet>
Sounddateien im WAV- oder MIDI-Format können erst seit 1.2 abgespielt werden. Vorher war dies nicht möglich. Bevor wir zur neuen Variante kommen, im Folgenden die Auflösung, wie es früher gemacht wurde. Hier blieb nur eine Konvertierung in das AU-Format, etwa mit dem Programm GoldWave.
Seit Java 1.2 hat sich im Bereich Soundwiedergabe einiges getan, so ist die Sound-Engine gründlich überarbeitet worden. Sie unterstützt nun die folgenden Audio-Formate: AIFF, AU und WAV.
Ebenso ist ein MIDI-Renderer enthalten, der die Dateiformate TYPE 0 MIDI, TYPE 1 MIDI und RMF unterstützt. Dieser erzeugt softwaremäßig mit einem 4 MB großen Wave-RAM – dies liegt unter java/lib – General Midi. Die Soundmaschine kann 8- oder 16-Bit Audio-Daten rendern, entweder Mono oder Stereo. Dabei werden Sampling-Raten von 8 KHz bis 48 KHz unterstützt.
Nun können aber auch Applikationen Musik abspielen. Dazu bietet die Klasse java.applet.Applet – wie sinnig! – die statische Methode
public static final AudioClip newAudioClip( URL )
Damit lässt sich ein AudioClips-Objekt auch ohne ein AppletContext erzeugen. Anschließend spielt die uns schon bekannte Routine play() vom AudioClip die Musikdatei vor.
Wer noch mit älteren Versionen (also vor 1.2) arbeiten muss, kann sich nur mit dem undokumentiertierten Paket sun.audio vergnügen Ein Demo findet sich zum Beispiel in der comp.lang.java FAQ (etwa auf SunSITE.Informatik.RWTH-Aachen.DE/javafaq/javafaq.html). Ein weiteres Paket mit dem Namen audio kommt von Mike Piff (http://www.shef.ac.uk/~cs1mjp/Java/WhiteBoard/WavePlayer.html). Es basiert auf dem undokumentierten Paket sun.audio, funktioniert aber unter Winows und Linux problemlos.
Wenn unser Browser Java Applets ausführen soll, aber Java überhaupt nicht aktiviert ist, dann lassen sich einige interaktive Benutzeraktionen nicht durchführen. Wir sollten daher zumindest eine Meldung anbieten, dass der Browser Java gerade nicht aktiviert hat. Dies kann beabsichtigt oder nicht beabsichtigt sein. Natürlich kommt Java dafür nicht in Frage, aber eine Skript-Sprache, die sich ähnlich anhört: JavaScript. Ab JavaScript Version 1.1 bietet uns der Interpreter die Funktion javaEnabled() an, sodass wir eine Weiterschaltung vornehmen können:
if ( !navigator.javaEnabled() )
{
self.location.href = "nix_mit_java.html";
}
Für diese Lösung muss natürlich JavaScript aktiviert sein. Für einige Surfer ist selbst dies schon eine Sicherheitslücke, und wenn JavaScript deaktiviert ist, lässt sich hier nichts mehr machen. Falls JavaScript aktiviert ist, kommen wir dem Benutzer einen Schritt entgegen, sodass er nicht mehr manuell angeben muss, ob Java aktiviert ist oder nicht. Von dieser Technik sollten wir auch Gebrauch machen, denn nicht immer hat der Benutzer aktiv Java abgeschaltet. Im Beispiel oben haben wir eine Seite angesteuert, wobei natürlich andere Anweisungen denkbar sind. Doch diese Form ist sinnvoll, denn wir können Benutzern eine Kurzbeschreibung liefern, wie Java im Browser aktiviert wird. Zusammen mit der Browservariante ist eine browsergenaue Beschreibung einsetzbar.
Kann der Browser ein Applet aus irgendwelchen Gründen nicht auführen, so sind die Meldungen an den Benutzer meist mager. Oft beschränken sie sich auf eine Exception-Angabe in der Statuszeile. Dies mag keiner mehr sehen wollen. Doch leider verschärfen inkompatible Browser die Situation. Was hier hilft, ist ein kleines Programm, welches zunächst herausfindet, auf welchem Browser es läuft. Dann können unter Umständen browser- und versionsabhängige Varianten ausgeführt werden.
Wir verwenden einen Trick, der auch beim Erkennen von Prozessortypen angewendet wird. Wir versuchen Operationen aufzurufen, die es für den jeweils anderen Browser nicht gibt. Wenn dann eine Exception geworfen wird, wissen wir Bescheid. Nun haben ja IE und Communicator jeweils ihre eigenen Klassen, der Communicator zum Beispiel die Klasse netscape.applet.MozillaAppletContext und IE com.ms.applet.GenericAppletContext.
| Beispiel Wir versuchen über die selbstgebastelten Methoden isNetscape() und isMicrosoft() etwas über unsere Laufzeitumgebung herauszufinden. |
import java.applet.*;
public class BrowserDetector extends Applet
{
public void init()
{
if ( isNetscape() )
System.out.println("This browser is a Netscape Browser.");
if ( isMicrosoft() )
System.out.println("This browser is a Microsoft Browser.");
}
public static boolean isNetscape()
{
try {
Class.forName("netscape.applet.MozillaAppletContext");
}
catch ( ClassNotFoundException e ) { return false; }
return true;
}
public static boolean isMicrosoft()
{
try {
Class.forName("com.ms.applet.GenericAppletContext");
}
catch ( ClassNotFoundException e ) { return false; }
return true;
}
}
Da der Netscape Navigator sowohl Java als auch JavaScript unterstützt, hat Netscape eine Technik implementiert, mit der das Java-Applet und JavaScript-Programm Daten austauschen können.
Innerhalb von JavaScript lassen sich alle öffentlichen Variablen und Methoden vom Applet in der Form document.appletname.variable bzw. document.appletname.methode() ansprechen.
Das Java-Applet kann Funktionen von JavaScript aufrufen, indem die Klasse JSObject aus dem Package netscape.javascript verwendet wird. Daher muss eine Anweisung ähnlich wie die folgende dabei sein:
import netscape.javascript.*;
Im Paket liegt JSObject, eine spezielle Klasse von Netscape. Interessanterweise ist das Objekt auch beim IE mit dabei.
Ein Applet ist nichts weiter als eine besondere Form einer Applikation. Somit lassen sich auch beide vereinigen. Es muss nur in einem Applet eine main()-Funktion geben und schon ist das Programm sowohl unter dem Appletviewer als auch unter der Kommandozeile normal auszuführen.
Sind mehrere Applets auf einer Web-Seite untergebracht, so gibt es Fälle, in denen die Applets Daten austauschen wollen. Zwei Lösungen bieten sich an. Da alle Applets in einer einzigen JVM laufen, lässt sich über statische Attribute auf die anderen Elemente zugreifen. Dies spricht jedoch gegen die Datenkapselung und ist sehr unfein. Aber diese Technik hat noch einen weiteren Schwachpunkt. Statische Variablen hängen eng mit dem Klassenlader zusammen. Hier gab es in der Vergangenheit beim Netscape einige Probleme (die aber nun behoben sein sollten). Eleganter ist da schon die Möglichkeit über die Schnittstelle AppletContext.
class java.applet.Applet |
| AppletContext getAppletContext() Bestimmt die Umgebung eines Applet. |
interface java.applet.AppletContext |
| Applet getApplet(String name) Sucht das Applet mit dem Namen name in dem Dokument, die durch den AppletContext gegeben ist. Der Name kann durch das HTML-Tag gesetzt sein. Falls kein Applet des Namens existiert, liefert die Methode null. |
| Enumeration getApplets() Findet alle Applets, die durch AppletContext gegeben sind. |
Zwei Lösungen bietet sich nun an. Die ältere Variante erwartet, dass das Applet einen Namen besitzt. Dieser wird mit dem NAME-Attribut im APPLET-Tag zugewiesen, etwa <APPLET ... NAME=Name ...>.
Eine Verbindung der Methode aus Applet und AppletContext führt zu der Zeile
Applet anotherApplet = getAppletContext.getApplet( "Name" );
Wie wir oben gesehen haben, lässt sich auch eine Enumeration aller Applets einer Seite mit getApplets() besorgen.
Applet otherApplet = null;
Enumeration applets = getAppletContext.getApplets();
while ( applets.hasMoreElements() )
{
otherApplet = (Applet)applets.nextElement();
if ( otherApplet != this)
break;
// Jetzt können wir etwas mit dem anderen Applet machen, etwa
// if ( otherApplet instanceof MeinApplet )
// ...
}
Ein Applet kann sich, falls bekannt, in eine Unterklasse casten. Dann lassen sich alle Methoden aufrufen und die Variablen auslesen. Leider funktionieren beide vorgestellten Methoden nur, wenn die Applets in einem gleichen Frame liegen. Liegen sie in verschiedenen Frames, findet zumindest die Netscape Methode getApplet() das Applet leider nicht. Hier bleibt aber noch die Variante über statische Variablen übrig. Eine weitere Möglichkeit Applets über verschiedene Frames kommunizieren zu lassen, geht über eine JavaScript-Funktion. Sie fungiert als Brücke. Dies wird hier allerdings nicht beschrieben.
Das folgende Beispiel zeigt zwei Applets Applet1 und Applet2 auf einer Web-Seite. Zunächst der HTML-Code:
Listing 20.11 Applets.html<HTML><BODY>
<APPLET CODE="Applet1.class"
NAME="applet1"
HEIGHT=200 WIDTH=200>
</APPLET>
<APPLET CODE="Applet2.class"
NAME="applet2"
HEIGHT=200 WIDTH=400>
</APPLET>
</BODY></HTML>
Es folgen die Implementierungen für die beiden Applets:
Listing 20.12 Applet1.javaimport java.applet.Applet;Listing 20.13 Applet2.java
import java.awt.*;
public class Applet1 extends Applet
{
TextField inputText;
public void init()
{
setLayout( new FlowLayout() );
inputText = new TextField( "", 10 );
add( inputText );
add( new Button( "Sende an Applet2" ) );
}
public boolean action( Event ev, Object arg )
{
if ( ev.target instanceof Button )
{
String textMsg = inputText.getText().trim();
Applet2 applet2 =
(Applet2)getAppletContext().getApplet("applet2");
if ( applet2 != null ) {
applet2.appendTheText( textMsg );
return true;
}
}
return false;
}
}
import java.applet.Applet;
import java.awt.*;
public class Applet2 extends Applet
{
TextArea textBox;
public void init()
{
setLayout( new FlowLayout() );
textBox = new TextArea( 5, 40 );
add( textBox );
}
public void appendTheText( String s )
{
textBox.appendText( s + "\n" );
}
}
Bevor Software auf den Rechner ab läuft, wird sie in der Regel installiert. Dazu legen die Hersteller der Software ein spezielles Installationsprogramm bei, unter Windows oft die InstallShields. Das Installationsprogramm legt passenden Verzeichnisse an und initialisiert etwa die Registrierdatenbank unter Windows. Etwas anders sieht das bei Java-Programmen aus. Die Installation erfordert jedoch zuerst eine Java-Laufzeitumgebung. Anschließend kann das Programm entpackt und gestartet werden. Wünschenswert ist jedoch eine Art Umgebung sowie sie bei Java-Applets definiert ist. Ein Java Applets läuft innerhalb eines Browsers in einem speziellen Sicherheitsmodus und es wäre günstig, wenn auch für alle anderen Applikationen möglich wäre. Das bedeutet, eine beliebige Applikationen soll etwa von einer Webseite geladen und auf dem lokalen Rechner ausgeführt werden. Die Applikationen soll sich nicht von anderen Applikationen, die lokal installiert sind, unterscheiden. Damit so etwas möglich ist, müssen wir unsere eigene Programme mit einer Sun-Technologie ausstatten, die Web-Start heißt. Webstart deckt die Bereiche Installation, Start und Update ab durch ein eigenes Protokoll ab, dass Java Network Launcher Protocol (JNLP). Die Technologie wurde auf der JavaOne 2000 erstmals vorgestellt. Mehr Informationen sind unter der Webadresse http://java.sun.com/products/javawebstart nachzulesen. Einige Demos zum Ausprobieren gibt es dann unter der Adresse http://java.sun.com/products/javawebstart/demos.html. Neben der Webseite von Sun widmet sich auch die Webseite von Gerald Bauer mit einer FAQ unter einem einfachen Beispiel unter http://www.geocities.com/vamp201/tutorial.html dem Thema.
| << zurück |
| |||||
| |||||
| |||||
| |||||
| |||||
| |||||
| |||||
Copyright © Galileo Press GmbH 2002
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.