Unterschiede zwischen Flex 3 und Flex 4
Geändert
4 October 2009
Voraussetzungen
Erforderliche Kenntnisse
Dieser Artikel setzt voraus, dass Sie mit dem Framework Flex 3 vertraut sind.
Niveau
Experten
Benötigte Produkte
- Flex 4 (Download trial)
Flex 4 (Codename: Gumbo) wurde im Vergleich zu Flex 3 umfassend überarbeitet. Flex 4 führt eine neue Architektur für Komponenten und Skins ein. Als Flex 3-Entwickler sollten Sie aber kaum Probleme beim Kompilieren von Flex 3-Anwendungen mit Flex 4 haben, denn ein erklärtes Ziel der neuen Version ist die Abwärtskompatibilität mit Flex 3.
In diesem Artikel finden Sie eine allgemeine Übersicht über die wichtigsten Ziele von Version 4, Unterschiede in der Architektur sowie Änderungen in Bezug auf Komponenten, Layouts, Effekte und die Verwendung von Status. Außerdem erhalten Sie Antworten auf einige Fragen, z. B. was Sie erwarten sollten, wenn Sie Ihre Flex 3-Anwendungen in Flex 4 kompilieren. Dieser Artikel behandelt nicht alle neuen Funktionen in Flex 4. Lesen Sie zu diesem Thema bitte den Artikel Neuerungen in Flex 4.
Der im vorliegenden Dokument verwendete Begriff MX-Komponenten bezieht sich auf Komponenten, die bereits in Flex 3 enthalten waren. Der Begriff Spark-Komponenten bezeichnet eine neue Gruppe von Komponenten in Flex 4.
Migration von Anwendungen zu Flex 4
Bei der Migration von Flex 3-Anwendungen zu Flex 4 erwartet Sie kein großer Arbeitsaufwand. Abgesehen von Bugfixes und einer Änderung der Standardpräsentation hat sich für bestehende Anwendungen kaum etwas geändert. Sie können sich also darauf verlassen, dass sie genauso gut (wenn nicht sogar besser) funktionieren wie mit Flex 3. Auf einige Punkte müssen Sie dennoch achten.
Player-Abhängigkeit
Achten Sie darauf, Ihre Anwendung für Flash Player 10 zu kompilieren. Das Flex 4-SDK arbeitet nur mit Flash Player 10.
Für Typselektoren ist ein Namespace erforderlich.
Ein CSS-Typselektor ordnet die Flex-Klasse einem Stil zu. „Button“ (Schaltfläche) und „DateField“ (Datenfeld) können z. B. folgende Typselektoren aufweisen:
Button {
cornerRadius: 10;
}
DateField {
color: #780800;
}
Ab Flex 4-SDK ist ein Namespace erforderlich, wenn eine Anwendung Typselektoren verwendet. Wenn Sie in Ihrer Flex-Anwendung nur den MXML 2006-Namespace verwenden, müssen Sie die folgende Standard-Namespace-Deklaration zu Ihrem CSS hinzufügen:
<mx:Style>
@namespace "http://www.adobe.com/2006/mxml";
…
</mx:Style>
Wenn Sie mehrere Namespaces verwenden, müssen Sie jeden Namespace im CSS angeben. Ein Beispiel finden Sie später in diesem Artikel unter Namespaces und Pakete in Flex 4.
Wenn die Anwendung eine Methode wie z. B. „StyleManager.getStyleDeclaration("Button")“ verwendet hat, muss der Typselektor auch das Paket benennen. Zum Beispiel würde der Aufruf von „getStyleDeclaration()“ in „StyleManager.getStyleDeclaration ("mx.controls.Button")“ geändert.
Designänderung
Das Standarddesign für Flex 3-Komponenten (MX-Komponenten) ist jetzt das Spark-Design. Deshalb sieht Ihre Anwendung eventuell anders aus und weist eine andere Größe auf, wenn sie mit dem Flex 4-SDK kompiliert wird. Wenn die Anwendung weiterhin so aussehen soll wie bisher, müssen Sie in Flex 4 das Halo-Design von Flex 3 festlegen. Geben Sie dazu das zusätzliche Compilerargument „-compatibility-version=3.0“ an. In Flash Builder 4 ist dies im Bereich „Eigenschaften“ möglich. Wählen Sie die Option „Flex Compiler“, und aktivieren Sie das Kontrollkästchen „Verwenden Sie den Flex 3-Kompatibilitätsmodus“ (siehe Abbildung 1).
Alternativ können Sie das standardmäßige Spark-Design im Bereich „Eigenschaften“ > „Flex-Design“ in Halo ändern. Klicken Sie im Bereich „Flex-Design“ auf das Halo-Design (siehe Abbildung 2).
Wenn Sie sich für das neue Spark-Design entscheiden, beachten Sie, dass viele der unter dem Halo-Design möglichen Stile mit dem Spark-Design nicht mehr funktionieren. Das Spark-Design unterstützt nur eine begrenzte Anzahl von Stilen. In ASDoc finden Sie genauere Angaben dazu, welche Stile für die Spark-Skin zur Verfügung stehen. Für jeden pro Komponente aufgelisteten Stil wird ein Design angegeben. Wenn kein Design genannt wird, steht der Stil sowohl im Halo- als auch im Spark-Design zur Verfügung. In Flex 4 gibt es auch eine neue Wireframe-Skin, die für die schnelle Erstellung von Modellen konzipiert ist. Stiländerungen werden vom Wireframe-Design nicht unterstützt.
Abgesehen von der Designänderung wurde der standardmäßige Preloader für Flex 4-Anwendungen geändert. Der neue Preloader heißt „mx.preloaders.SparkDownloadProgressBar“. Dieser kompakte Preloader dürfte die Startdauer etwas verkürzen. Wenn Sie den Preloader von Flex 3 verwenden möchten, brauchen Sie nur eine Codezeile zu ändern. Fügen Sie dem Tag Application Folgendes hinzu: preloader="mx.preloaders.DownloadProgressBar".
In den meisten Fällen lohnt es sich nicht, alle vorhandenen Flex 3-MX-Komponenten gegen die entsprechenden Flex 4-Komponenten auszutauschen, da diese Arbeit relativ viel Zeit in Anspruch nimmt. Setzen Sie die Flex 4-Komponentenstruktur stattdessen von Anfang an ein, wenn Sie neue Anwendungen erstellen.
Neuer Speicherort für Automatisierungsbibliotheken
In Flex 3 standen Automatisierungsbibliotheken unter „{sdk}/frameworks/libs“ zur Verfügung, in Flex 4 sind sie unter „{sdk}/frameworks/libs/automation“ zu finden. Bitte vergewissern Sie sich, dass unter „frameworks/libs“ keine Kopien von Automatisierungsbibliotheken gespeichert sind.
Übersicht über Änderungen der Flex 4-Architektur
Das Flex 4-SDK stellt das Erstellen reibungsloser Workflows zwischen Designern und Entwicklern in den Vordergrund. Zu diesem Zweck trennt das Framework die visuellen Elemente einer Komponente klar vom Rest ihres Verhaltens. In Flex 3 enthielt der Code einer Komponente logische Funktionen zu Verhalten, Aussehen und Änderungen der visuellen Elemente. In Flex 4 sind die Komponenten in verschiedene Klassen aufgeteilt, von denen jede einen bestimmten Teil des Verhaltens regelt.
Im Gumbo Architecture Document wird dies wie folgt spezifiziert:
Die Hauptkomponentenklasse, d. h. die Klasse, deren Klassenbezeichnung mit der MXLM-Tagbezeichnung übereinstimmt, enthält das Kernverhalten der Komponente. Dies umfasst die Definition, welche Ereignisse die Komponente übergibt, die von der Komponente dargestellten Daten, die Verbindung aller untergeordneten Komponenten, die als Bestandteile der Hauptkomponente fungieren, und die Verwaltung und Verfolgung des internen Komponentenstatus. Auf den letzten Punkt wird später detaillierter eingegangen.
Mit der Komponentenklasse ist eine Skinklasse gekoppelt, von der alles im Zusammenhang mit dem visuellen Erscheinungsbild der Komponente verwaltet wird, einschließlich Grafiken, Layout, Datendarstellung, Änderungen des Erscheinungsbilds in verschiedenen Status und des Übergangs von einem Status zu einem anderen. Im Halo-Modell waren Skins für Flex-Komponenten Elemente, die nur für einen Teil der Grafik einer Komponente zuständig waren. Für die Änderung jedes anderen Aspekts des Erscheinungsbilds einer Komponente, wie beispielsweise Layout oder Visualisierung von Status, war eine Unterteilung der Komponente in untergeordnete Klassen erforderlich und der ActionScript-Code musste direkt bearbeitet werden. Im Gumbo-Modell wird all dies in der Skinklasse deklarativ definiert, und zwar primär über neue Grafiktags, die als FXG-Tags bezeichnet werden.
Weitere Informationen über die neuen Grafiktags in Flex 4 finden Sie in der FXG-Dokumentation.
Ein Beispiel für die oben erläuterte Architektur ist der Code für die Klasse „spark.components.Button“. Diese Klasse enthält nur logische Funktionen zum Verhalten der Komponente. Alle visuellen Elemente der Komponente sind in der Skinklasse „spark.skins.spark.ButtonSkin“ definiert.
Zur Leistungsoptimierung stellt Flex 4-SDK Bausteine für Entwickler bereit, die für die jeweils benötigte Funktionalität abgerufen werden können. Aufwendige Funktionalitäten wie das Durchblättern oder Virtualisieren, die nicht von allen Anwendungen benötigt werden, sind nicht standardmäßig aktiviert.
Namespaces und Pakete in Flex 4
Flex 3-Klassen werden unverändert in den gleichen „mx.*“-Paketen beibehalten, doch führt das Flex 4-SDK auch „spark.*“-Pakete für Komponenten, Kernklassen, Effekte, Filter, Layouts, Primitive, Skins und Dienstprogramme ein.
Das Flex 4-SDK bietet ein neues Set von Komponenten und Effekten, die mit den Flex 3-Komponenten viele Klassennamen gemeinsam haben. Um Namenskonflikte in MXML zu vermeiden, enthält das Flex 4-SDK vier unterschiedliche Namespaces: MXML 2006, MXML 2009, Spark und Mx.
MXML 2006: der Namespace, der bisher von Flex verwendet wurde. Flex 3-Anwendungen, die mit der Betaversion von Flex 4 kompiliert wurden, können diesen Namespace weiterhin verwenden.
URI: http://www.adobe.com/2006/mxml
Standardpräfix: mx
MXML 2009: der neue Namespace für MXML. Dies ist ein reiner Sprachen-Namespace, der keinerlei Komponententags enthält.
URI: http://ns.adobe.com/mxml/2009
Standardpräfix: fx
Spark: Dieser Namespace enthält alle neuen Spark-Komponenten und sollte zusammen mit dem Sprachen-Namespace MXML 2009 verwendet werden.
URI: library://ns.adobe.com/flex/spark
Standardpräfix: s
MX: Dieser Namespace enthält alle MX-Komponenten Halo-Komponenten und sollte zusammen mit dem Sprachen-Namespace MXML 2009 verwendet werden.
URI: library://ns.adobe.com/flex/mx
Standardpräfix: mx
Im Folgenden sehen Sie ein kleines Beispiel, in dem mithilfe von MXML 2009-, Spark- und Halo-Namespaces eine einfache Flex 4-Anwendung Beta erstellt wird. Im Beispiel werden das MX-Kalenderelement „DataChooser“ und eine Spark-Schaltfläche „Button“ verwendet.
<s:Application
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
<mx:DateChooser id="main_calendar" x="20" y="20"/>
<s:Button label="submit" x="220" y="20"/>
</s:Application>
Das Flex 4-SDK unterstützt auch die Angabe mehrerer Namespaces im CSS. Wenn Sie die Namespaces MXML 2009, Spark und MX zusammen mit Typselektoren verwenden, müssen Sie in der CSS-Definition eine Gruppe von Namespaces definieren, um Namenskonflikte zu vermeiden.
Im folgenden CSS-Beispiel werden Typselektoren für MX- und Spark-Komponenten verwendet:
<fx:Style>
@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/mx";
s|Button {
color: #FF0000;
}
mx|DateChooser {
color: #FF0000;
}
</fx:Style>
Standardeigenschaften und das Tag „Declarations“
Vor dem Release des Flex 4-SDK konnte das Root-Tag Application in der Flex-Sprache visuelle und nicht-visuelle untergeordnete Elemente enthalten. Die visuellen untergeordneten Elemente wurden dem Tag Application mit addChild() hinzugefügt und nicht-visuelle untergeordnete Elemente als Eigenschaft-Deklarationen behandelt. In Flex 4 können nicht-visuelle untergeordnete Elemente, die neue Eigenschaft-Deklarationen darstellen, einem Application-Tag nicht mehr direkt untergeordnet werden. Stattdessen werden sie unter einem Tag <fx:Declarations> hinzugefügt. Zu den nicht-visuellen untergeordneten Elementen gehören z. B. Effekte, Validierungs- und Formatierungskomponenten, Datendeklarationen und RPC-Klassen. Ein kurzes Beispiel:
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark">
<fx:Declarations>
<s:Fade id="fadeEffect" target="{targetButton}" alphaFrom="1" alphaTo="0" />
</fx:Declarations>
<s:Button id="targetButton" />
<s:Button label="play effect" click="fadeEffect.play()" x="80" />
</s:Application>
Neue Komponenten und Container
Wie bereits erwähnt, führt das Flex 4-SDK eine Reihe neuer Komponentenklassen ein, die mit der neuen Architektur arbeiten. Sie sollen Skinfunktionen und Anpassungen einfacher gestalten. Im Folgenden sehen Sie eine Tabelle mit Flex 3-MX-Komponenten und ihren Spark-Entsprechungen in Flex 4:
| MX-Komponente in Flex 3 | Spark-Komponente in Flex 4 (Beta) |
|---|---|
| mx.controls.Button | spark.components.Button |
| mx.controls.ButtonBar | spark.components.ButtonBar |
| mx.controls.CheckBox | spark.components.CheckBox |
| mx.controls.ComboBox | spark.components.DropDownList (mit/ohne Bearbeitungsmöglichkeit) |
| mx.controls.HorizontalList | spark.components.List (mit „HorizontalLayout“) |
| mx.controls.HRule | spark.primitives.Line |
| mx.controls.HScrollBar | spark.components.HScrollBar |
| mx.controls.HSlider | spark.components.HSlider |
| mx.controls.Image | spark.primitives.BitmapImage (mit/ohne Unterstützung externer Bilder) |
| mx.controls.LinkBar | spark.components.ButtonBar (mit selbstentworfener Skin) |
| mx.controls.LinkButton | spark.components.Button (mit selbstentworfener Skin) |
| mx.controls.List | spark.components.List |
| mx.controls.NumericStepper | spark.components.NumericStepper |
| mx.controls.RadioButton | spark.components.RadioButton |
| mx.controls.RadioButtonGroup | spark.components.RadioButtonGroup |
| mx.controls.TextArea. | spark.components.TextArea |
| mx.controls.TabBar | spark.components.TabBar |
| mx.controls.TextInput | spark.components.TextInput |
| mx.controls.TileList | spark.components.List (mit „TileLayout“) |
| mx.controls.ToggleButtonBar | spark.components.ButtonBar |
| mx.controls.VideoDisplay | spark.components.VideoPlayer |
| mx.controls.VRule | spark.primitives.Line |
| mx.controls.VScrollBar | spark.components.VScrollBar |
| mx.controls.VSlider | spark.components.VSlider |
| mx.core.Application | spark.components.Application |
| mx.core.Window | spark.components.Window |
| mx.core.WindowedApplication | spark.components.WindowedApplication |
| mx.containers.ApplicationControlBar | spark.components.Application (mit „controlBarContent“) |
| mx.containers.Canvas | spark.components.Group |
| mx.containers.ControlBar | spark.components.Panel (mit Eigenschaft „controlBarContent“) |
| mx.containers.HBox | spark.components.HGroup |
| mx.containers.Panel | spark.components.Panel |
| mx.containers.Tile | spark.components.Group (mit „TileLayout“) |
| mx.containers.VBox | spark.components.VGroup |
Adobe empfiehlt, die MX-Komponenten und -Container zusammen mit Spark-Komponenten zu verwenden. Da Komponenten auch in Zukunft auf Basis der gleichen Klasse (UIComponent) entwickelt werden, sollte die volle Interoperabilität zwischen Spark und MX gegeben sein. Im Folgenden finden Sie eine Tabelle der Komponenten und Container, die derzeit über keine direkt gleichwertigen Klassen unter Spark verfügen.
| Flex 3-Klassen ohne direkte Entsprechung in Flex 4 Beta |
|---|
| mx.controls.Alert |
| mx.controls.ColorPicker |
| mx.controls.DataGrid |
| mx.controls.DateChooser |
| mx.controls.DateField |
| mx.controls.Menu |
| mx.controls.MenuBar |
| mx.controls.PopUpButton |
| mx.controls.PopUpMenuButton |
| mx.controls.ProgressBar |
| mx.controls.RichTextEditor |
| mx.controls.Tree |
| mx.containers.Accordion |
| mx.containers.DividedBox |
| mx.containers.Form |
| mx.containers.Grid |
| mx.containers.TabNavigator |
| mx.containers.TitleWindow |
| mx.containers.ViewStack |
Damit der MX-Navigator (ViewStack, Accordion, TabNavigator) zusammen mit Spark-Komponenten genutzt werden kann, müssen die untergeordneten Navigatorelemente „NavigatorContent“-Komponenten sein. Andernfalls können Sie im MX-Navigator keine Spark-Primitiven verwenden. Beispiel:
<mx:ViewStack id="vs" selectedIndex="{tb.selectedIndex}">
<s:NavigatorContent label="bar">
<s:layout>
<s:VerticalLayout />
</s:layout>
<s:Label text="bar" />
<s:TextInput />
</s:NavigatorContent>
</mx:ViewStack>
Änderungen in der Statussyntax
Flex 4 hat die Statusfunktionalität zur Vollfunktion der MXML-Sprache erhoben. Sie werden daher wahrscheinlich feststellen, dass die Arbeit mit Status wesentlich flexibler und direkter ist. Die neue Statussyntax bezieht sich direkt auf die Komponente und ermöglicht die Angabe statusbezogener Änderungen im Kontext. Die wichtigsten Neuerungen der Flex 4-Syntax:
- Im Statusarray werden nur Status definiert.
- Im Rahmen der neuen Statussyntax können
AddChildundRemoveChildnicht verwendet werden. Stattdessen definieren Sie die Rolle einer Komponente in einem bestimmten Status unter Verwendung der AttributeincludeInundexcludeFromdirekt in der Komponente.
Im folgenden Flex 3-Beispiel wird über den Status definiert, dass eine Schaltfläche angezeigt und ein Texteingabefeld entfernt wird, falls der Status currentState des Dokuments submitState lautet. Dieser Ansatz kann bei komplexeren Status sehr aufwendig werden.
<mx:states>
<mx:State name="submitState" basedOn="">
<mx:AddChild relativeTo="{loginForm}" >
<mx:Button label="submit" bottom="10" right="10"/>
</mx:AddChild>
<mx:RemoveChild target="{firstTextInput}"/>
</mx:State>
</mx:states>
<mx:TextInput id="firstTextInput" />
<mx:Canvas id="loginForm" />
Im Folgenden sehen Sie den einfacheren Flex 4-Code, der mit includeIn und excludeFrom arbeitet.
<s:states>
<s:State name="submitState" />
</s:states>
<s:TextInput id="firstTextInput" excludeFrom="submitState" />
<s:Group id="loginForm" >
<s:Button label="submit" bottom="10" right="10" includeIn="submitState"/>
</s:Group>
-
SetProperty,SetStyleundSetEventHandlerwurden durch eine neue Syntax ersetzt, mit der Sie MXML-Attributwerte mit einer spezifischen Statuskennung qualifizieren können.
Im folgenden Flex 3-Beispiel werden für eine Schaltfläche im Status submitState eine Eigenschaft, ein Stil und ein Ereignis definiert.
<mx:states>
<mx:State name="submitState" basedOn="">
<mx:SetProperty target="{submitButton}" name="label" value="submit" />
<mx:SetStyle target="{submitButton}" name="textDecoration" value="underline"/>
<mx:SetEventHandler target="{submitButton}" name="click" handler="trace('done');"/>
</mx:State>
<mx:State name="clearState" basedOn="">
<mx:SetProperty target="{submitButton}" name="label" value="clear" />
<mx:SetEventHandler target="{submitButton}" name="click" handler="emptyDocument()" />
</mx:State>
</mx:states>
<mx:Button id="submitButton" />
In Flex 4 sieht der Code wie folgt aus:
<s:states>
<s:State name="submitState" />
<s:State name="clearState" />
</s:states>
<s:Button label.submitState="submit" textDecoration.submitState="underline"
click.submitState="trace('done')" click.clearState="emptyDocument()"
label.clearState="clear" textDecoration.clearState="none"/>
- Eine Komponente kann sich nicht mehr in einem undefinierten Status befinden. Standardmäßig ist der erste deklarierte Status der „Grundzustand“ einer Komponente.
Die neue Syntax steht zur Verfügung, wenn ein Dokument den Sprachen-Namespace MXML 2009 verwendet. Sie können die bisherige Syntax und die neue Statussyntax nicht gleichzeitig verwenden. Die alte Syntax steht nur im MXML 2006-Namespace zur Verfügung.
Außerdem unterstützt jede Komponente jetzt eine Gruppe von Status, die in der Komponenten-Skinklasse definiert sind. Dies vereinfacht die Anwendung visueller Änderungen je nach Status der Komponente. Für die Skin der Spark-Schaltfläche sind beispielsweise die folgenden Status definiert:
<s:states>
<s:State name="up" />
<s:State name="over" />
<s:State name="down" />
<s:State name="disabled" />
</s:states>
Die Klasse „ButtonSkin“ definiert, wie sich jeder dieser Status visuell auf die Spark-Schaltfläche auswirkt.
Der vorliegende Text ist nur eine kurze Einführung in die neue Statussyntax der Betaversion von Flex 4. Weitere Details finden Sie in der Dokumentation zu erweiterten Status.
Änderungen bei den Effekten
Die Infrastruktur der Flex 4-Effekte wurde zahlreichen Verbesserungen unterzogen. Während MX-Effekte nur für Steuerelemente auf „UIComponent“-Basis eingesetzt werden können, lassen sich Spark-Effekte für alle Ziele nutzen, einschließlich der neuen Grafikprimitiven im Framework. Alle Effektklassen finden Sie im „spark.effects.*“-Paket. Da Spark-Effekte für MX-Komponenten, Spark-Komponenten und Grafikprimitive verwendet werden können, empfiehlt Adobe, für zukünftige Anwendungen Spark-Effektklassen zu verwenden.
Die vorliegende Beschreibung wurde bewusst knapp gehalten, denn Sie finden wesentlich detailliertere Informationen über die neue Funktionalität in den Effektklassen im Artikel Effekte in Adobe Flex 4 von Chet Haase.
Änderungen im Layout
In früheren Flex-Versionen wurde das Layout von Komponenten und Containern über einzelne Steuerelemente definiert. Daher gab es Komponenten wie „List“, „TileList“ und „HorizontalList“, die, abgesehen vom Layout, die gleiche Funktionalität nutzten. Ihre Layoutlogik war jedoch immer noch in diesen Komponentenklassen definiert. In Flex 4 wurde das Layout von den Komponenten abgekoppelt. Jetzt können Spark-Komponenten wie „Application“, „List“, „ButtonBar“ und „Panel“ ihre Layouts deklarativ definieren. In allen Komponenten werden die enthaltenen Elemente über die Gruppenklasse verwaltet und das Layout der untergeordneten Elemente der Gruppe wird an ein zugehöriges Layoutobjekt delegiert. Die Layouts unterstützen neben Spark- und MX-Komponenten auch FXG-Grafikprimitive. Layouts können sogar zur Laufzeit geändert werden.
Als Entwickler können Sie problemlos eigene Layouts schreiben und beliebig zwischen Komponenten austauschen. Im Folgenden finden Sie ein Beispiel für die Definition einer vertikalen oder horizontalen sowie einer im Kachelformat angeordneten Liste.
Vertikale Liste das Standardlayout einer Spark-Liste ist „VerticalLayout“ :
<s:List />
Horizontale Liste:
<s:List>
<s:layout>
<s:HorizontalLayout />
</s:layout>
</s:List>
Liste im Kachelformat:
<s:List>
<s:layout>
<s:TileLayout />
</s:layout>
</s:List>
Wie bereits erwähnt, ist die Flex 4-Architektur so konzipiert, dass Bausteine bereitgestellt werden, die der Entwickler entsprechend der benötigten Funktionalität einsetzen kann. Die Funktionen für das Virtualisieren und Durchblättern sind standardmäßig deaktiviert. Wenn Sie einer Gruppe die Option für Bildlaufleisten hinzufügen und die Virtualisierung aktivieren möchten, gehen Sie wie folgt vor:
useVirtualLayout in Ihrem Layoutobjekt auf true.Scroller hinzu.Im Folgenden finden Sie ein Beispiel für Virtualisierung und Durchblättern in einer Spark-Ansicht:
<s:Panel title="Horizontal Panel" width="300" height="220" left="20" top="20">
<s:Scroller width="100%" height="100%">
<s:Group>
<s:layout>
<s:HorizontalLayout useVirtualLayout="true" />
</s:layout>
<s:TextInput />
<s:Button label="clear" />
<mx:DateChooser />
<s:Button label="submit" />
</s:Group>
</s:Scroller>
</s:Panel>
Weitere Informationen zu allen Änderungen in Flex 4-Layouts sowie zur besseren Unterstützung von Transformationen finden Sie in der Dokumentation zum Spark-Layout.
Textformatierung
Alle Spark-Komponenten verwenden die neue Textengine in Flash Player 10. Die neuen Klassen bieten eine einfache Unterstützung der Steuerung von metrischen Schriftdaten, vertikalem Text, typografischen Elementen wie Ligaturen und bidirektionalem Text. Das Flex 4-SDK nutzt diese Funktionalität in allen Spark-Komponenten, die Text verwenden. Weitere Informationen über Textprimitive und Textkomponenten in Flex 4 finden Sie in der Spezifikation für Spark-Textprimitive.
Spark-Komponenten verwenden in Flash Player 10 und AIR 1.5 das eingebettete Schriftformat „DefineFont4“. MX-Komponenten arbeiten standardmäßig nicht mit „DefineFont4“. Daher verursacht das Vermischen von Spark- und MX-Komponenten innerhalb der gleichen Application und das Einbetten von Schriften einigen Zusatzaufwand. Wenn Sie für alle Komponenten die gleiche eingebettete Schrift verwenden möchten, müssen Sie dem Projekt ein zusätzliches Compilerargument für das Design hinzufügen. Mit diesem neuen Design verwenden dann MX- und Spark-Komponenten die gleiche Schriftengine „DefineFont4“. Dieses Compilerargument wird durch Aktivieren der Option „Flash-Textwiedergabefunktion in MX-Komponenten verwenden“ im Bereich „Eigenschaften“ > „Flex-Compiler“ hinzugefügt siehe Abbildung 3 .
Wenn in einer Flex 4-Anwendung Text verwendet wird, sollte am besten eine der Spark-Textkomponenten von Flex 4 eingesetzt werden. Alle drei verwenden die neue Textengine von Flash Player 10 und sorgen für eine höhere Qualität bei Text, Kerning und Drehung von Geräteschriften und bidirektionalem Text. Die Unterschiede zwischen den verfügbaren Textkomponenten in Flex 4:
| Mehrzeilig | Verkürzbar | Auswählbar | |
|---|---|---|---|
| mx.controls.Label | Nein | Ja | Ja |
| mx.controls.Text | Ja | Nein | Ja |
| spark.components.Label | Ja | Ja | Nein |
| spark.primitives.RichEditableText | Ja | Ja | Nein |
| spark.primitives.RichText | Ja | Nein | Ja |
| Editier- barkeit |
HTML-Forma- tierung |
Bildlauf | |
|---|---|---|---|
| mx.controls.Label | Nein | Ja | Nein |
| mx.controls.Text | Nein | Ja | Nein |
| spark.components.Label | Nein | Nein | Nein |
| spark.primitives.RichEditableText | Nein | Ja | Nein |
| spark.primitives.RichText | Ja | Ja | Ja |
Abwärtskompatibilität mit Flex 3
Wie in Flex 3 können Sie Ihre Anwendung mit einem zusätzlichen Compilerargument kompilieren:
-compatibility-version=3.0.0.
Dieses Compilerargument ermöglicht es Ihren Anwendungen, statt des neuen Verhaltens von Flex 4 im Wesentlichen das Verhalten von Flex 3 zu verwenden. Eine vollständige Liste aller Änderungen bezüglich der Abwärtskompatibilität in Flex 4, die das Argument -compatibility-version unterstützen, finden Sie im Dokument zur Abwärtskompatibilität.
Hinweis: Das teilweise Beibehalten von Flex 4-Verhaltensmustern ist beim Aufrufen der Flex 3-Kompatibilität nicht möglich. Wenn Sie mit dem Argument -compatibility-version=3.0.0 kompilieren, wird das in der Dokumentation beschriebene Flex 3-Verhalten komplett übernommen.
Weiterführende Informationen
Die Migration von Flex 3 zu Flex 4 sollte relativ unproblematisch verlaufen. Das Framework ist für größtmögliche Abwärtskompatibilität konzipiert. Sobald Sie die neue Architektur kennengelernt haben, werden Sie feststellen, dass sie wesentlich flexibler ist als die bisherige. Weitere Informationen zu den Funktionen von Flex 4 finden Sie in der Onlinehilfe.
More Like This
- Neuerungen in Flex 4
- Using Flex effects to animate changes in application state
- Flex Solutions excerpt: Migrating Flex applications onto the desktop with Adobe AIR
- Introducing Cairngorm
- Managing application state with Flex 3
- Choosing a Flex framework
- Flex quick start guide for HTML and PHP developers
- Project Hendrix: A call center Customer Experience Management solution
- Migrating Flex 3 applications to Flex 4 – Part 2: Beginning migration of the Dashboard application to Flex 4
- Migrating Flex 3 applications to Flex 4.5 – Part 2: Beginning migration of the Dashboard application to Flex 4.5
Tutorials & Samples |
Tutorials
- Flex mobile performance checklist
- Flex and Maven with Flexmojos – Part 3: Journeyman
- Migrating Flex 3 applications to Flex 4.5 – Part 4
Flex User Forum |
More |
Flex Cookbook |
More |
| 02/09/2012 | Using Camera with a MediaContainer instead of VideoDisplay |
|---|---|
| 02/08/2012 | Digital Clock |
| 01/20/2012 | Skinnable Transform Tool |
| 12/12/2011 | Date calculations using 'out-of-the-box' functions |