Seite 2: Entwickler-Komfort

Inhaltsverzeichnis

Entwickler wollen mehr Komfort

Flex Builder ist für Programmierer konzipiert, die MXML und Actionscript 3 zur Entwicklung von SWF-Anwendungen nutzen, nicht aber für Designer und Entwickler, deren Präferenz die Arbeit mit der Flash-Autorenumgebung ist. Vielfach wünschen sich diese Anwender jedoch eine funktional reichhaltigere Code-IDE für die Arbeit mit Actionscript 3, als sie die Flash-Autorenumgebung zur Verfügung stellt. In diesen Markt stößt das in Flash-Kreisen nicht unbekannte Aachener Unternehmen Powerflasher mit FDT (Flash Development Tool), einer Eclipse-basierten Flash-/Actionscript-IDE.

Die aktuelle Version 3.0 kam Ende 2007 heraus und liegt zurzeit in drei Versionen vor: Basic, Professional unterscheiden sich in ihrem Funktionsumfang hinsichtlich einiger weniger Features (mehr dazu weiter unten). Eine weitere Version (FDT 3.0 Enterprise) mit Debugger, MXML-Integration und verbesserten Refactoring-Möglichkeiten gibt es seit Frühjahr 2008.

Dieser Test bezieht sich auf FDT 3.0 Professional als Eclipse-Plug-in in einer Installation von Eclipse 3.3.1.1 auf einem Macbook Pro mit 2,4 GHz Dual-Core CPU und 4 GByte Hauptspeicher. Das zugrunde liegende Betriebssystem war Mac OS X 10.4.11. Der empfohlene und vorgeblich einfachste Weg, um FDT zu installieren, führt über das Software-Update-Feature der Eclipse-IDE. Powerflasher bietet eine FDT-Update-Site, die sich selbst für Eclipse-Neulinge mit einigen wenigen Schritten einrichten lässt. Nach erfolgreicher Installation bittet das Plug-in um einen Neustart der Eclipse-Umgebung und stellt danach in der Theorie eine neue Perspektive für Flash FDT zur Verfügung.

"In der Theorie" heißt es hier, weil die Standardeinstellungen des JVM-Speichers von Eclipse 3.3.1.1 (-Xmx256m) ein erfolgreiches Umschalten von der Java- zur FDT-Perspektive reproduzierbar verhinderte. Mit der Trial-Version von FDT führte das beim Umschalten zu einer Situation, in der sich Eclipse-Fehlermeldung und Trial-/Lizenz-Popup von FDT gegenseitig blockierten und keine Bedieneraktion in Eclipse mehr möglich war. Erst systemseitiges Beenden des Eclipse-Prozesses und die Änderung der Speichereinstellungen in eclipse.ini auf -Xmx512m in der Package-Ansicht der Datei Eclipse.app schaffte Abhilfe. Hier wünscht man sich eine detaillierte Installationsanleitung zur Problemlösung in solchen oder ähnlichen Fällen; immerhin findet man in der Eclipse-FDT-Hilfe nach einiger Suche eine Erwähnung des Speicher-Setting in den FAQs. Ein Posting im FDT-Blog verweist zudem auf eine PDF-Version des User Guide.