Know-how für Kreative

Inhaltsverzeichnis
1 Erste Schritte
2 Versionen
3 Einführung in die Programmierung
4 Die Entwicklungsumgebung
5 Regeln
6 Anweisungen und Aktionen
7 Werte und Datentypen
8 Ausdrücke und Operatoren
9 Funktionen
10 Kontrollstrukturen
11 Dokumenten-Objektmodell und Gültigkeitsbereich (Scope)
12 Ereignisse
13 Objekterstellung
14 Vererbung
15 Movieclips
16 ActionScript 2.0
17 Komponenten
18 Codedesign und Konzeption
19 Flashdetection
20 Aussergewoehnliche Benutzerfuehrung
21 D mit Flash
22 Macromedia Central
23 HTML
24 JavaScript, ActiveX und Java
25 Flash undokumentiert
26 Vergangenheit, Gegenwart und Zukunft
27 Kurzreferenz
28 Buchtipps
29 Links
30 Die CD-ROM zum Buch
Index
Download: - ZIP, ca. 9,8 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Design / <openbook> / ActionScript | vor >>
ActionScript 1 und 2 von Sascha Wolter (http://www.saschawolter.de/) Objektorientierung und Codedesign mit Flash MX 2004
ActionScript 1 und 2 672 S., mit CD, Referenzkarte, 44,90 Euro Galileo Design ISBN 3-89842-221-6 |
| Kapitel 18 Codedesign und Konzeption
|  | 18.1 Analyse und Konzeption
|  |  | 18.1.1 Veränderliche Anforderungen und Konzepte
|  |  | 18.1.2 Mehr Vorstellungskraft durch Prototypen
|  | 18.2 Entwicklungsumgebung
|  |  | 18.2.1 Werkzeuge
|  |  | 18.2.2 Trennung von Ressourcen und Programmierung
|  |  | 18.2.3 Aufteilung in einzelne Module
|  |  | 18.2.4 Versionsmanagement
|  |  | 18.2.5 Strukturierung der Dateien
|  | 18.3 ActionScript
|  |  | 18.3.1 Bezeichner
|  |  | 18.3.2 Typisierung
|  |  | 18.3.3 Codehinweise
|  |  | 18.3.4 Kommentare und Dokumentation
|  | 18.4 Optimierung
|  |  | 18.4.1 Bytecode optimieren und extrahieren
|  |  | 18.4.2 Eigenständige Anwendungen und Bildschirmschoner
## 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.

Tabelle 18.1 Eine Auswahl alternativer Editoren

Name | URL | Beschreibung
PrimalScript | http://www.sapien.com/ | Kostenpflichtiger Editor für eine Vielzahl von Programmiersprachen, darunter auch ActionScript 1 und 2.0.
SciTE|Flash | http://www.bomberstudios.com/ sciteflash/ | Einfacher kostenloser Editor für ActionScript.
SE|PY | http://www.sephiroth.it/python/sepy.php | Der momentan beliebteste kostenlose Editor für ActionScript 1 und 2.0.
Eclipse | http://www.eclipse.org/ | Einer der beliebtesten Editoren im Java-Umfeld. Leider steht (momentan) nur ein Bruchteil der leistungsfähigen Zusatzfunktionen für ActionScript zur Verfügung.
Dreamweaver | http://www.macromedia.com/de/software/dreamweaver/ | Macromedias zentrale Entwicklungsplattform mit ActionScript-Unterstützung.
Flex Builder | http://www.macromedia.com/de/software/flex/flexbuilder/ | Basierend auf Dreamweaver besitzt dieses Werkzeug eine verbesserte ActionScript-Unterstützung für Flex, die auch normalen Flash-Entwicklern zugute kommt.
Visual Studio | http://www.microsoft.de | Microsofts Entwicklungsumgebung eignet sich dank dem auf ECMAScript 4 basierenden JScript.NET auch für die Programmierung von ActionScript 2.0.
### 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.

Tabelle 18.2 Versionsmanager (Auswahl)

Name | URL | Beschreibung
SourceSafe | http://www.macromedia.com | Versionsmanagement à la Microsoft. Flash unterstützt momentan nur dieses Produkt direkt aus der Entwicklungsumgebung heraus.
WinCvs | http://www.wincvs.org/ | Kostenloses Frontend fuer den beliebtesten Standard bei Versionsmanagementsystemen namens CVS (Concurrent Versions System).
### 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).
<< zurück | <top> | vor >>
Zum Katalog
ActionScript 1 und 2 bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchtipps
| Einstieg in ActionScript
| Einstieg in Flash 8
| Flash 8 und PHP
| Flash 8-Tutorials
| Dreamweaver 8
| Webseiten programmieren und gestalten
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press GmbH 2005
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.

[Galileo Design]
Galileo Press GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de