18.2 Entwicklungsumgebung 

Einige Entwickler schwören auf einen einfachen Texteditor, um Programmcode zu erstellen. Wieder andere können nicht mehr ohne eine umfangreiche integrierte Entwicklungsumgebung (IDE) leben. Letztendlich kommt es dabei einfach nur darauf an, dass Sie ein oder mehrere Werkzeuge finden, die Sie bei Ihrer Arbeit optimal unterstützen.

18.2.1 Werkzeuge 

Siehe Entwicklungsumgebung, Kapitel 4

Bei Flash hat Macromedia die Wahl der richtigen Entwicklungsumgebung dadurch erschwert, dass der Compiler zur Erzeugung von SWF-Dateien immer eine FLA-Datei als Quelle benötigt. Diese FLA-Datei lässt sich jedoch nur mit Flash erstellen. Zwar gibt es einige wenige Alternativen, mit denen auch SWF-Dateien generiert werden können, doch leider verstehen diese meist nicht den vollen Funktionsumfang von Flash.

18.2.2 Trennung von Ressourcen und Programmierung 

Eine FLA-Datei ist nur noch ein Container für Ressourcen. Die Programmierung liegt extern. Um die Wahl eines beliebigen Editors zu erlauben, kann der Programmcode von der FLA-Datei getrennt werden. Diese FLA-Datei dient dann nur noch als Container für Ressourcen (also für jegliche Medien wie Bilder und Ton). Der Flash-Compiler verbindet die Medien mit der Programmierung und wandelt alles gemeinsam in eine SWF-Datei um.

Das Einbinden der Programmierung in eine sonst fast leere FLA-Datei geschieht bei ActionScript 1 über eine Include-Anweisung im ersten Schlüsselbild der Anwendung:

// Skript im FLA-Container

Codedesign\Entwicklungsumgebung\include

#include "application.as"

Beachten Sie bitte bei Include-Anweisungen, dass diese auf keinen Fall mit einem Semikolon abgeschlossen werden dürfen, da es sich um eine Compiler-Anweisung und keinen ActionScript-Befehl handelt!

Die zugehörige ActionScript-Datei ist dabei wie ein ganz normales Skript aufgebaut, das auch anstelle der Include-Anweisung platziert sein könnte:

// ActionScript 1 in externer Datei
var ressource_mc:MovieClip;
ressource_mc = _root.attachMovie("ressource", "ressource_mc", 1);
ressource_mc._x = Stage.width/2;
ressource_mc._y = Stage.height/2;

Bei ActionScript 2.0 können Sie sich zunutze machen, dass Flash externe Klassen ohnehin automatisch einbindet:

// Skript im FLA-Container
var application:Application;
application = new Application();

Die zugehörige Klasse sieht dann wie folgt aus:

// ActionScript 2.0 in externer Datei
class Application {
   var ressource_mc:MovieClip;
   function Application() {
      ressource_mc = _root.attachMovie("ressource", "ressource_mc", 1);
      ressource_mc._x = Stage.width/2;
      ressource_mc._y = Stage.height/2;
   }
}

Oft soll eine Anwendungssteuerung nur einmal vorkommen. Dies erlaubt zu diesem Zweck den Einsatz einer statischen Klasse (siehe »ActionScript 2.0« ab Seite 396). Da von einer statischen Klasse jedoch keine Instanzen erzeugt werden, muss in diesem Fall explizit eine Methode aufgerufen werden. In diesem Beispiel ist diese Methode in Anlehnung an Java mit main bezeichnet:

// Skript im FLA-Container

Entwicklungsumgebung\statische Klasse

Application.main();

Die zugehörige Klasse könnte wie folgt aussehen:

// ActionScript 2.0 in externer Datei
class Application {
   static var ressource_mc:MovieClip;
   private function Application() {
   }
   static function main() {
      ressource_mc = _root.attachMovie("ressource", "ressource_mc", 1);
      ressource_mc._x = Stage.width/2;
      ressource_mc._y = Stage.height/2;
   }
}

Da nun die gesamte Programmierung in Textform vorliegt, können diese Textdateien mit einem beliebigen Werkzeug bearbeitet, durchsucht und verwaltet werden. Dreamweaver erlaubt hier beispielsweise das Suchen und Ersetzen in ActionScript-Dateien innerhalb ganzer Verzeichnisse – sogar mit Hilfe von regulären Ausdrücken.

Format der ActionScript-Dateien

Flash MX 2004 erwartet die ActionScript-Dateien standardmäßig im Unicode-Format (UTF-8). Dies können Sie sowohl für den Im- als auch Export in den Einstellungen von Flash auf Standardkodierung des Systems umstellen, um die Abwärtkompatibilität zur Flash MX-Entwicklungsumgebung in einem gemischten Entwicklerteam zu gewährleisten.

18.2.3 Aufteilung in einzelne Module 

Bei umfangreichen Projekten ist es vorteilhaft, die einzelnen Inhalte auf unterschiedliche Module aufzuteilen. So erreichen Sie, dass sich das Ladeverhalten verbessert, da nicht alles auf einmal, sondern nur wenn benötigt geladen wird. Außerdem erleichtert dies die Entwicklung, da unterschiedliche Entwickler zur gleichen Zeit an unterschiedlichen Modulen arbeiten können. Veränderungen am laufenden System lassen sich ebenfalls besser durchführen, da nur einzelne Module und nicht alles ausgetauscht werden muss.

ActionScript-Code über mehrere Module hinweg nur einmal laden!

Die einzelnen Module können Sie wie im vorherigen Kapitel beschrieben in den ActionScript-Code und den FLA-Container mit den grafischen Elementen aufteilen. Dabei ist jedoch ein Zusammenhalt in Form eines oder mehrerer übergeordneter Objekte und Klassen erforderlich, um Daten zwischen den Modulen austauschen zu können. Dies wiederum führt dazu, dass die einzelnen Module trotz ihrer Unabhängigkeit gemeinsame Klassen verwenden. An sich ist dieser objektorientierte Gedanke der Wiederverwendbarkeit lobenswert, wären da nicht wieder Flash-spezifische Probleme.

Flash bindet nämlich sämtliche verwendete Klassen und die in den Klassen genutzten Klassen komplett in die zugehörigen SWF-Dateien ein. Da Flash ja nicht wissen kann, ob SWF-Dateien im gleichen Kontext ablaufen, gehören die Klassen zum Inhalt jeder betreffenden SWF-Datei. Dies führt zum einen zu unnötig großen SWF-Dateien und zum anderen zu Inkonsistenzen, falls einzelne SWF-Dateien mit unterschiedlichen Versionen der Klassen erstellt wurden.

Ein einfacher Trick hilft, auch dieses Problem zu lösen. Zum einen zwingen Sie eine am Anfang zu ladende SWF-Datei, alle gemeinsam genutzten Klassen einzubinden. Dafür reicht es aus, diese Klasse einmal zu verwenden, indem Sie wenigstens den Klassennamen Klasse angeben, falls die Klasse sonst nicht benötigt wird.

Ab dann steht die Klasse im Arbeitsspeicher allen weiteren Modulen zu Verfügung, sofern diese von der gleichen Domain geladen werden. Um nun zu erreichen, dass diese Module diese Klasse nicht mehr mit in die SWF-Datei aufnehmen, benötigen Sie für jedes Modul eine XML-Datei, in der die auszuschließenden Klassen aufgeführt sind. Diese XML-Datei platzieren Sie im selben Verzeichnis wie die Quelldatei im FLA-Format und geben ihr den Namen der Quelldatei gefolgt von _exclude in der Form module_exclude.xml. Innerhalb der Datei führen Sie jede auszuschließende Klasse inklusive Package auf – leider muss dies für jede einzelne Klasse geschehen, da die Exclude-Datei nicht die Angabe von kompletten Packages erlaubt:

<excludeAssets>
   <asset name="Klasse"></asset>
   <asset name="package.NochEineKlasse"></asset>
</excludeAssets>

Auch wenn Flash diese Klassen nicht mehr mit in die SWF-Datei einbaut, funktioniert die Typprüfung weiterhin. Und auch die Ausführung des Codes wird davon nicht beeinträchtigt, sofern die Klassen von einer früheren SWF-Datei in den Speicher geladen wurden.

Ladevorgang kontrollieren

Ein weiteres Problem bei einer modularisierten Anwendung resultiert aus dem Wunsch, Teile einzeln laden zu können. Denn diese Inhalte werden von Flash gestreamt, so dass das Starten des Ladevorgangs nicht zwangsläufig sicherstellt, dass das Modul auch wirklich vollständig verfügbar ist. Um sicherzustellen, dass alles geladen ist, und um den Ladevorgang auch ansprechend zu visualisieren, nutzt man so genannte Preloader, die durch Programmierung den Ladevorgang kontrollieren.

Für die Anwendungsentwicklung gibt es jedoch eine weitere Variante der »Ladekontrolle«, die gleich noch ein oft auftretendes, aber selten realisiertes Fehlverhalten vermeidet. Denn der reine Abschluss des Ladevorgangs bedeutet nicht zwangsläufig, dass auch alle Objekte und Methoden bereits initialisiert sind – selbst dann nicht, wenn alles direkt im ersten Schlüsselbild des Moduls platziert ist. So könnten Methodenaufrufe im Modul fehlschlagen, selbst nachdem alles geladen ist.

Eine einfache Lösung ist, dass nicht das Hauptmodul den Abschluss des Ladens kontrolliert, sondern das Modul selber diesen mitteilt – davon unabhängig können Sie den Ladefortschritt natürlich weiterhin aus dem Hauptmodul heraus anzeigen. Ein Hauptmodul mit entsprechender Ladekontrolle könnte mit der folgenden statischen Klasse umgesetzt werden:

class Application {
   // Container für Module
   static var desktop:MovieClip;
   // Hauptprogramm
   static function main(Void):Void {
      desktop = _root.createEmptyMovieClip("desktop", 1);
      load("module.swf");
   }
   // Lade Modul
   static function load(url:String):Void {
      startPreloader();
      desktop.loadMovie(url);
   }
   static function initModule(module:Object) {
      stopPreloader();
   }
   // Starte Preloader
   static function startPreloader() {
      trace("Laden gestartet");
   }
   // Stoppe Preloader
   static function stopPreloader() {
      trace("Laden beendet");
   }
}

In dem Hauptmodul nutzen Sie die Klasse einfach durch die folgende Zeile Code:

Application.main();

Das zu ladende Modul verwendet eine Klasse, die dem Hauptmodul mitteilt, wenn alles da ist:

class Module {
   static function main() {
      Application.initModule(Module);
   }
}

Der Code in der FLA-Datei zum Modul lenkt dann Module.main();.

18.2.4 Versionsmanagement 

Ein Versionsmanagement hilft, Stress vorzubeugen. Denn sobald mehrere Personen an einem Projekt oder sogar an ein- und denselben Dateien arbeiten, bleibt es nicht aus, dass dabei falsche Versionen überarbeitet oder Fehler eingebaut werden. Selbst das versehentliche Überschreiben oder sogar Löschen von Dateien ist eher die Regel als die Ausnahme!

Ein Versionsmanagement speichert die einzelnen Versionen einer Datei in einer Datenbank und verhindert so zum einen den Verlust von Informationen und erlaubt zum anderen das Nachverfolgen von Änderungen bzw. den Rücksprung zu einer älteren Version – dies ist im Übrigen auch nützlich, wenn man alleine an einem Projekt arbeitet.

Außerdem gestatten die meisten Versionsmanager das Sperren von Dateien, so dass das gleichzeitige Bearbeiten durch unterschiedliche Entwickler verhindert wird.

Trennen Sie Programmcode und FLA-Dateien möglichst voneinander!

Flash verärgert die Administratoren von Versionsmanagementsystemen jedoch durch die verhältnismäßig großen Quellen in Form von FLA-Dateien. Diese wachsen schnell auf mehrere Megabyte an, sobald auch Medien Verwendung finden. In diesem Fall vergrößert sich die Datenbank des Versionsmanagers bei jeder Änderung der FLA-Datei gleich um diese Megabytes, selbst wenn nur ein Zeichen in der Programmierung verändert wurde. Aus diesem Grund sollte der Programmcode von der FLA-Datei getrennt werden, damit bei der Bearbeitung auch nur dieser erneut ins System eingespielt werden muss! Außerdem erleichtert dies die Nachverfolgung von Änderungen, da Versionsmanager diesen Vergleich von Quellcode in der Regel nur bei Textdateien beherrschen.

18.2.5 Strukturierung der Dateien 

Der Aufbau der kompletten Verzeichnisstruktur für ein Projekt gestaltet sich bei Flash schwierig, da hier zwischen dem webbasierten und dem eher objektorientierten Aufbau unterschieden werden muss. Der objektorientierte Aufbau beschreibt die Abhängigkeiten der Klassen untereinander, der webbasierte Aufbau die Struktur der einzelnen Module in Form von SWF-Dateien. Angenommen, Sie entwickeln ein Shopsystem mit Produktsuche und Bestellwesen, dann könnte die objektorientierte Welt ungefähr so aussehen (hier wurde für eine einfachere Darstellung auf separate Ordner für die ActionScript-Quellcode und die FLA-Dateien verzichtet):

Hier klicken, um das Bild zu Vergrößern

Abbildung 18.2   Shopsystem in der objektorientierten Welt

Die weborientierte Welt ist jedoch meist deutlich einfacher gehalten und sieht während der Entwicklung eher so aus, um das Verzeichnis für die Anwendung (hier shop) so möglichst einfach auf einen Webserver kopieren zu können:

Hier klicken, um das Bild zu Vergrößern

Abbildung 18.3   Shopsystem in der weborientierten Welt

Aus diesem Grund bietet es sich an, den eigentlichen Webordner mit den fertigen Dateien (z.B. deploy, engl. für einsetzen) von den Quellen (z.B. src für Source, engl. für Quelle) wie in diesem Beispiel zu trennen. Einige Unternehmen haben noch umfangreiche Vorschriften, wie die Verzeichnisstrukturen von Projekten angelegt werden müssen, und arbeiten z.B. noch den Firmennamen mit ein – solange dadurch die voll qualifizierten Bezeichner von Klassen inklusive der Packages nicht mehr als 69 Zeichen betragen, stört dies auch nicht weiter (siehe »Klassen« in »ActionScript 2.0«, Seite 396).