Archives pour la catégorie StyleManager

Flex Modules – Décharger (Unload) correctement ses modules

Le principal intérêt des modules Flex est de découper votre application en plusieurs SWF pouvant être chargés et déchargés à la volée. Le fait de décharger (unload) permet de libérer la mémoire prise par le module une fois qu’il n’est plus utilisé. Cependant, même en faisant un unload() du module, il ne sera pas forcement libéré de la mémoire par le Garbage Collector. En effet, si des références vers ce module existent toujours, le module ne sera pas libéré. Parfois ces références sont évidentes mais parfois elles sont plus difficiles à trouver, surtout quand elles se trouvent au fin fond du framework Flex.

La Flex Team a publié un article pour récapituler les principales cause connues qui font qu’un module n’est pas libéré de la mémoire. Voici le détail.

Chargement de modules dans différents « applicationDomain »

Le fait de charger des modules depuis différents « applicationDomain » peut obliger Flex à référencer des classes dans ses Managers. Ces références peuvent causer la persistence du module en mémoire. Essayez de charger les modules avec l’applicationDomain par défaut (en utilisant les paramètres par défaut de la méthode load().

Fuites mémoire

Les « Memory leaks » peuvent créer des références vers votre module qui vont empêcher le Garbage Collector de libérer le Module Flex de la mémoire. Voici les causes principales:

Styles

Cela se produit même sans tag mx:Style dans votre MXML. Si votre module utilise un composant qui n’est pas utilisé par l’application principale, le module va enregistrer le style par défaut pour ce composant dans le StyleManager et coincer la première instance de votre module. Vous pouvez utiliser l’option du compilateur -compiler.keep-generated-actionscript pour voir quels styles le module et l’application principale utilisent. Vous pouvez aussi utiliser l’option -compiler.keep-all-type-selectors dans l’application principale pour forcer l’application principale à enregistrer les styles par défaut de chaque composant dans le fichier defaults.css. Les CSS chargés à l’exécution (StyleManager.loadStyleDeclarations) ne sont pas concernés par ce problème car ils sont chargés de manière différente.

Resources

Si votre module utilise des composants qui utilisent de ResourceBundles non-utilisés par l’application principale, ces Resource Bundles vont être enregistrés dans le ResourceManager et coincer la première instance du module. Vous pouvez utiliser l’option du compilateur -compiler.keep-generated-actionscript pour voir quels Resource Bundles le module et l’application mère utilisent. Vous pouvez forcer l’application principale à avoir ces Resource Bundles additionnels en ajoutant les metadata du Resource Bundle dans l’application principale.

Par exemple, vous ajouter le Resource Bundle « controls », vous devez ajouter à votre application:[ResourceBundle("controls")]. Si vous chargez vos Resource Bundles comme des modules, assurez-vous que les Resource Module ont bien fini leur chargement avant de charger le module Flex qui utilise le Resource Bundle.

ExternalInterface.addCallback

Les modules ne devraient pas utilier la méthode ExternalInterface.addCallback(). Cela enregistre la méthode dans le navigateur et il n’y a, à ce jour, aucun moyen de la supprimer. Il est recommandé de laisser l’application principale enregistrer une méthode qui va appeler une référence de fonction. Il suffit ensuite de remplacer cette référence par la méthode du module. Quand le module est déchargé, il suffit de mettre cette référence à null.

Timers et autres mécanismes de Timing

L’utilisation de Timer, setTimeout() et setInterval() peuvent causer des fuites mémoire. Les Timer doivent être arrêtés et avoir leurs listeners supprimés. setTimeout et setInterval doivent faire quant à elles appel à clearTimeout() et clearInterval() pour pouvoir être GCed correctement.

Listeners sur évènements depuis des objets à l’extérieur du module

Utilisez des références faibles (weak references) ou assurez vous d’avoir bien supprimé les event listener. Rappelez-vous que lorsque vous appelez A.addEventListener(« foo », B.someMethod), « A » a une référence vers B, et pas l’inverse.

Focus

Si un des objets du module a le focus, le FocusManager aura toujours une référence vers le module. Il est conseillé de bouger le focus vers un autre objet à l’extérieur du module avant de le décharger.

RemoteObject

Si un module amène une nouvelle classe qui va faire partie d’une requête serveur, cette classe va être enregistrée par Flash Player et amener une référence vers le module. Liez les Data Classes à l’application principale lorsque c’est possible.

Images chargées

Si un module charge une image, cette image doit être déchargée sinon Flash Player va garder des buffers autour de cette image.

Autres éléments à connaitre

Une fois qu’ils n’y a plus de référence vers les objets d’un module, Flash Player peut encore garder un module en mémoire pendant un moment si certains des objets d’un module on eu le focus. Essayez de taper du texte ou de cliquez dans l’application pour éventuellement libérer des références vers le module.

Les versions Debug d’un module peuvent empêcher le module d’être libéré de la mémoire. Les version de debug contiennent des informations de debug qui peuvent être enregistrées par le debugger. Assurez-vous de tester avec des versions realease des modules et une application lue par un Flash Player classique.

Flex 4 – Différences entre Flex 3 et Flex 4 (1-Migration vers Flex 4)

Traduction de l’article Differences between Flex 3 and Flex 4 beta de Joan Lafferty.

Flex 4 (nom de code Gumbo) représente un changement majeur par rapport à Flex 3. Flex 4 introduit en effet une nouvelle architecture de composants et de skinning. En tant que développeur Flex 3, vous ne devriez cependant par rencontrer trop de difficultés pour compiler vos applications Flex 3 avec le SDK Flex 4, car la compatibilité descendante (backwards compatibility) avec Flex 3 est conservée.

Dans cette série d’articles, je vais donner d’ensemble des objectifs principaux de Flex 4, des différences d’architecture ainsi qu’une introduction aux changements de composants, de mise en pages mais aussi l’utilisation des States et des effets. On verra aussi comment compiler votre application Flex 3 avec le SDK Flex 4. Cet article ne couvre pas les nouvelles fonctionnalités de Flex 4.

Tout au long de cette série d’articles, le terme de « Composants Halo » réfère aux composants inclus dans Flex 3. Le terme « Composants Spark » réfère au nouvel ensemble de composant de Flex 4.

Migration d’applications vers Flex 4

Pour une migration d’application Flex 3 vers Flex 4, vous n’aurez que peu de choses à modifier. A part quelques résolutions de bugs et un changement du thème par défaut, attendez-vous à ce que votre application fonctionne de la même manière (voire mieux) qu’elle le faisait en Flex 3. Cependant, voici quelques points sur lequels vous devriez être attentifs.

Dépendance à Flash Player 10

Compilez bien pour Flash Player 10. Flex 4 impose la compilation en FP10.

Les Type Selector (style) ont besoin d’un namespace

Un type selector CSS lie une classe Flex à un style. Par exemple, les sélecteurs CSS suivant agissent sur Button et DateField:

Button {
    cornerRadius: 10;
}
DateField {
   color: #780800;
}

Dans Flex 4, quand une application utilise des Type Selector, un namespace est requis. Si vous utilisez uniquement le namespace MXML 2006 dans votre application Flex, ajouter la déclaration de namespace par défaut à votre CSS:

<mx:Style>

@namespace "http://www.adobe.com/2006/mxml";
…
</mx:Style>

Si vous utilisez plusieurs namespaces dans votre application, vous devrez les indiquer dans votre CSS (voir plus loin).

De plus, si votre application utilise une méthode comme StyleManager.getStyleDeclaration(« Button »), le type selector devra inclure le package. Par exemple, l’appel à getStyleDeclaration() deviendrait StyleManager.getStyleDeclaration(« mx.controls.Button »)

Changement de theme

Le theme par défaut des composant Flex 3 (Halo) est maintenant le theme Spark. C’est pourquoi le look et les tailles de votre application pourraient être différent en utilisant Flex 3. Si vous voulez tout de même utiliser le look Flex 3, vous le pouvez car Flex 4 inclut toujours le thème Halo de Flex 3. Pour compiler en utilisant le thème Halo, utilise le flag -compatibility-version=3.0 dans les arguments du compilateur ou bien le flag -theme. Pour cela, dans Flash Builder 4, vous devez modifier le paramètre Additional Compiler Arguments dans la section Flex Compiler du panel de propriétés. Si vous utilisez ces arguments, assurez vous que le répertoire framework/themes/Halo est bien dans votre Source Path.
Lire la suite →

Flex PopUp – Contrôler le style d’une PopUp modale

Par défaut, quand vous ouvrez une fenêtre popUp de type Alert dans Flex grâce à la méthode show(), l’application se recouvre d’une sorte de voile gris qui empêche l’utilisateur d’utiliser l’application. Voici l’apparence d’une fenêtre modale par défaut:

Ce type de fenêtre avec un voile derrière est appelé fenêtre modale.

Vous pouvez bien sur modifier certains paramètres pour changer l’apparence de ce voile modal. Il existe 4 paramètres que vous pouvez modifier:

modalTransparency:Number. Valeur par défaut 0.5. Définit l’opacité du voile appliqué. Une valeur de 0 rend le voile complètement transparent. Une valeur de 1 le rend totalement opaque.
modalTransparencyBlur:Number. Valeur par défaut 3. Définit le flou (blur) appliqué au reste de l’application Flex.
modalTransparencyColor:uint .Valeur par défaut 0xDDDDDD. Définit la couleur du voile.
modalTransparencyDuration:Number. Valeur par défaut 100. Définit en millisecondes, le temps que met l’effet de transparence à se jouer (ouverture et fermeture).

Lire la suite →

Flex PopUp – Personnaliser les styles d’une Alert (couleur, icône, alpha, boutons et texte)

Il y a déjà plusieurs articles sur flex-tutorial qui portent sur la manière de personnaliser l’apparence d’une fenêtre Alert. Voici une application trouvée sur ce blog qui résume bien les modifications que vous pouvez faire avec un démonstrateur. Il faut rappeler que l’utilisation des Alert est assez simpliste, si vous voulez affichez de la donnée de manière plus complexe, il vaut mieux ouvrir des fenêtres avec le PopUpManager.

Voici l’application en question (traduite):

Flex Source Code Download: Télécharger le code source complet de l’application

This movie requires Flash Player 11

Flex ToolTip – Appliquer des Styles aux ToolTips

Vous pouvez personnaliser l’apparence des toolTips en utilisant les styles. Le Framework Flex ne permet pas de fixer des styles pour des toolTips individuels, vous devez fixer le style des toolTips globalement pour toutes les instances. Vous pouvez le faire en changeant la définition du style ToolTip en utilisant le sélécteur CSS de la classe. L’exemple suivant montre comment changer la définition du style en utilisant le tag Style (il peut aussi être fait dans une feuille CSS séparée):

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" viewSourceURL="srcview/index.html">
	<mx:Style>
		ToolTip{
			fontFamily: "_typewriter";
			background-color:#FFFFFF;
		}
	</mx:Style>
	<mx:Button label="Tool Tip" toolTip="Exemple de toolTip avec style"/>
</mx:Application>