L'avantage de pouvoir utiliser les composants Flex par rapport à une application pure AS3 est de simplifier le développement en vous donnant toute une bibliothèque de composants prêts à l'emploi. Certains composants sont de nouveaux composants, d'autres ont simplement une autre "Skin" optimisée pour le rendu mobile (plus gros, système de cache, etc.). Bien sûr, vous pouvez toujours faire vos propres composants mais on va voir ceux qui sortent directement du four. Dans ce billet, on va découvrir ces composants et leurs looks pour vous donner une idée.
Notez que les itemRenderer seront couverts dans un autre billet sur flex-tutorial.
Bouton
Ce n'est pas un nouveau composant, seulement le composant s:Button avec un look différent lorsque vous l'utilisez dans un projet de type Mobile:
Notez que le composant Spark Button a retrouvé sa propriété "icon" vous permettant d'ajouter un icône directement avec la Skin de base (il fallait faire sa propre Skin auparavant).
Prenons tout d’abord le composant HSlider de base de Flex 4 :
Comme on l’a vu dans l'article précédent, dans la déclaration des SkinPart, on a "thumb" et "track" qui sont des boutons. On va laisser de côté, pour cet exemple, la Skin du DataTip. Pour créer une Skin, on va donc créer deux Skins de Button, un peu comme on l’a fait dans l’exemple précédent.
Pour la "track", on va simplement créer un rectangle arrondi avec un remplissage et une ombre portée. Ce fichier s’appellera MyTrackSkin.mxml:
Il ne nous reste plus qu’à créer la Skin du Slider à proprement parler. Celle-ci sera constituée de nos deux composants. Notez leurs propriétés « id », liées aux SkinPart que l’on a décrit plus haut :
Depuis l'écriture de cet article, Adobe a décidé de ne pas créer un framework mobile mais bien d'intégrer ces notions / composants dans la prochaine version de Flex: Flex 4.5 alias Hero: Hero – Le prochain Flex SDK (4.5) avec composants pour mobiles
Si vous étiez à Adobe MAX, ou que vous avez suivi les keynotes en live, vous avez entendu parler de Flash Player 10.1, de Air 2.0 ou bien des applications Flash sur iPhone. Adobe a aussi présenté Slider, le framework Flex pour plate-forme mobile. En effet, Flex est trop lourd en natif pour pouvoir être utilisé sur plate-forme mobile. Il faut en effet prendre en compte les ressources limitées en CPU et en RAM.
Slider est basé sur Flex 4 est n'est pour l'instant (Novembre 2009) qu'à un stade peu avancé mais on peut déjà voir des applications crées grâce à Slider sur iPhone. Vous pouvez trouver sur la Adobe TV, une session sur Slider qui présente les fonctionnalités du framework. Si vous développez en Flex, je vous conseille fortement de regarder cette présentation:
Sont abordés de nombreux points importants pour le développement de RIA mobiles. Par exemple, la navigation par écran ou bien la gestion de la sauvegarde des données. Slider viendra donc avec de nouveaux composants qui seront bien sur compatibles avec les autres composants Flex. Le Binding, skinning et autres éléments-clé de Flex seront toujours au rendez-vous.
Une nouveauté, l'introduction des "Conditions". Ceux-ci seront utilisés un peu comme les states. C'est-à-dire que vous pouvez créer une condition (une sorte d'état if (iPhone)) qui va vous permettre de créer une application avec des fonctionnalités spécifiques à une plate-forme ou à une capacité de l'appareil. Rassurez-vous, il ne vous faudra pas écrire des dixaines de Conditions pour tous les OS, Slider va assurer lui-même un maximum de compatibilité avec les appareils sans que vous n'écriviez de code "device-specific".
Cette présentation parle aussi de la résolution des problèmes qui apparaissent lors d'un développement pour plate-forme mobile comme par exemple la gestion des résolutions, l'input, la navigation, la taille de l'écran, …
Tout cela peut encore changer, ce SDK est toujours en préparation. On peut quand même remarquer que pour porter une application Flex vers une application mobile, on pourra réutiliser du code et de la logique, spécialement si votre application respecte bien un modèle type MVC.
Voici une erreur assez étrange qui se produit quand vous ajoutez un Slider dans Flex en ActionScript avec un addChild(). Cette erreur lance une RTE (RunTime Error) au moment de l'opération.
private function createBackgroundTrack():void{
if (!track){
var trackSkinClass:Class = getStyle("trackSkin");
track = new trackSkinClass();
if (track is ISimpleStyleClient)
ISimpleStyleClient(track).styleName = this;
innerSlider.addChildAt(DisplayObject(track),0);
}
}
Quand on passe en mode debug, on se rend compte que la variable de type Class "trackSkinClass" est bien null et ne peut donc pas passer dans le constructeur. Apparemment, le problème vient du fait que la classe Slider n'a pas de sélecteur CSS. Quand le code essaie de faire getStyle("trackSkin");, il obtient donc une valeur nulle. HSlider et VSlider ont un sélecteur mais pas Slider.
Voici la suite des articles de Peter Ent sur les item renderers. Cette fois-ci, il nous parle de la communication entre un itemRenderer et une application. Dans certains des exemples précédents, il a utilisé un Button qui propage un évènement personnalisé (BuyBookEvent) pour que l'application réagisse au clic sur le bouton. Cet article couvre quant à lui les différentes options pour communiquer entre votre itemRenderer et votre application MXML plus en détail.
Quelques règles et stratégies
La première règle à respecter est qu'il ne faut pas garder de référence à une instance d'itemRenderer et la modifier (en modifiant ses propriétés public) ou appeler ses méthodes public. Les itemRenderer sont difficiles d'accès depuis l'extérieur pour une raison assez simple: les item Renderer sont recyclés et réutilisés. En récupérer une instance un pourrait troubler le comportement du Framework Flex.
Une fois que vous avez cette règle primordiale en tête, voici les différentes stratégies de communication que vous pouvez utiliser avec un itemRenderer:
Un itemRenderer peut propager (dispatch) des évènements via son "list owner" (le composant qui utilise l'itemRenderer en question).
Un itemRenderer peut utiliser des variable membre de classe static. Cela peut inclure par exemple Application.application. Si vous avez stocké des valeurs de manière globale dans votre objet application, vous pouvez les atteindre de cette manière. Cette méthode fonctionne mais n'est pas conseillée car elle limite l'encapsulation).
Un itemRenderer peut utiliser des variables public de la liste qui le contient (exemple plus loin)
Un itemRenderer peut utiliser n'importe quelle data de votre enregistrement. Par exemple, vous pouvez avoir un item dans l'enregistrement qui ne sert pas à l'affichage direct mais qui influence le comportement de l'itemRenderer
Modifier les itemRenderer de manière dynamique
Voici l'itemRenderer MXML utilisé pour une <mx:TileList> dans les articles précédents. On va le rendre plus dynamique en le faisant réagier aux changements d'une source externe. (Ce composant est appelé BookItemRenderer.mxml):
