Archives du mot-clé labelField

AIR Mobile – Application Pokémon (5) – Liste des Pokémon depuis la BDD SQLite

Dans les tutoriaux Flex précédents, on a vu comment ouvrir la base de données SQLite et comment lancer notre projet dans l’émulateur:

AIR Mobile – Application Pokémon (3) – Ouverture de la BDD SQLite

AIR Mobile – Application Pokémon (4) – Lancer l’application dans l’émulateur + debugger

On va maintenant travailler sur notre première vue et afficher la liste des pokémons. Pour cela, on va effectuer une requête SQL (SELECT) et afficher le résultat dans un composant List.

Effectuer le traitement au bon moment

Avant d’effectuer notre requête SELECT, il faut savoir à quel moment on va la faire. En effet, si vous avez suivi l’article sur le cycle de vie des View en Flex, vous savez que celle-ci propage des évènements lors de sa création et de sa destruction.

Les évènements qui vont nous intéresser sont:

  • creationComplete : Propagé quand tous les composants de la vue (comme notre List) sont instanciés et accessible. La vue n’est pas encore affichée à l’écran mais vous pouvez la manipuler
  • viewActivate : Propagé après « creationComplete », une fois que la transition entre les vues est terminée.

Alors lequel utiliser? Et bien cela dépend. En effet, si vous effectuez trop de traitement lors du « creationComplete », la transition de la vue va peut-être saccader. Mais en même temps, si vous faîtes votre traitement sur « viewActivate », il sera presque « trop tard » et si votre traitement est d’afficher / masquer des composants, votre vue va légèrement clignoter. A vous donc de voir et de choisir la meilleure solution, c’est à dire la plus adaptée à votre utilisation.

Pour cette première vue, ce n’est pas très important car en fait, la première vue n’arrive pas avec une transition. Que vous soyez sur « creationComplete » ou sur « viewActivate » ne fera donc que très peu de différence. Mais si on était sur une autre vue, sur laquelle on arrive par une transition, on aurait sûrement mis notre SELECT sur l’évènement « viewActivate » car nous effectuons nos requêtes en mode synchrone. Si nous l’avions ouverte en mode asynchrone, on aurait utilisé « creationComplete » plutôt. Voilà le genre de question qu’il faut se poser, souvent résolues par de rapides tests.

Récupérer la connexion SQL (SQLConnection)

Ouvrez donc le fichier « PokemonInfosHomeView.mxml » qui est notre première vue. Comme vous l’avez fait dans la 3eme partie du tutorial, ajouter un écouteur d’évènement sur « creationComplete » que vous allez appeler « onCComplete ». De la même manière, laissez-vous guider par Flash Builder:

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark" title="HomeView"
        creationComplete="onCComplete(event)">
  <fx:Script>
    <![CDATA[
      import mx.events.FlexEvent;

      protected function onCComplete(event:FlexEvent):void
      {

      }

    ]]>
  </fx:Script>
  <fx:Declarations>
    <!-- Place non-visual elements (e.g., services, value objects) here -->
  </fx:Declarations>
</s:View>

Première chose que l’on va faire dans onCComplete, on va récupérer la connexion SQL que l’on avait ouvert dans la partie 3 du tutorial. Notre connexion est conservée au niveau de l’application. Celle ci peut être accédée depuis n’importe quel endroit grâce à la variable static:

FlexGlobals.topLevelApplication

Pour éviter de récupérer à chaque fois la référence vers notre SQLConnection depuis notre application, on va conserver une référence directement dans notre vue:

import mx.core.FlexGlobals;
  import mx.events.FlexEvent;

  private var _sqlConnection:SQLConnection = null;

  protected function onCComplete(event:FlexEvent):void{
	_sqlConnection = FlexGlobals.topLevelApplication.sqlConnection;
  }

Ajouter le composant List

Pour avoir un affichage visuel de notre liste de pokémons, on va ajouter un composant List. Pour une liste des composants (non exhaustive) des composants du SDK 4.5, je vous conseille de lire cet article:

AIR Mobile – Les composants et le thème Mobile Flex 4.5

Rendez-vous donc entre la fin du tag fx:Declaration et la fin du tag View puis tapez le caractère « < ». Appuyez sur Ctrl+Espace et la liste des composants disponibles va s’afficher. Tapez « List » puis appuyez sur Entrée:

list

Appuyez sur Espace et la liste des propriétés du composant va s’afficher. Vous pouvez commencer à taper le nom des propriétés comme « width » ou « height » et valider par Entrée. Comme exercice, on va fixer les propriétés « width » et « height » à la valeur « 100% ». Cela signifie que notre liste va prendre toute la place offerte par son conteneur, la vue.

Une fois que vous avez terminé, fermez le tag avec un chevron fermant « > ». Le tag XML </s:List> fermant la balise sera automatiquement ajouté:

<s:List width="100%" height="100%">

  </s:List>

Le composant List et la propriété « dataProvider »

Notre composant List est un composant graphique permettant d’afficher de la donnée. Pour définir quelle donnée doit être affichée dans ce composant, on renseigne la propriété « dataProvider ». Ce « dataProvider » est de type IList. Comme vous pouvez le voir dans la documentation, dans la partie « Implementors », les classes qui implémentent IList sont ArrayList, AsyncListView, ListCollectionView et les classes qui en héritent.

Lire la suite

Flex 4 – (2) Création de composants Flex ré-utilisables, les meilleures techniques

La création de composants est un must quand on travaille avec Flex. Mais autant faut-il savoir les créer de la meilleures manière afin qu’ils puissent être ré-utilisés et faciliter la maintenance de votre code.

A ce propos, Tom Sugden a écrit un très bon article qui explique bien les meilleures manières pour faire un bon composant Flex:

Writing Genuinely Reusable Flex Components

Pour faire simple, je vais traduire cet article, et rajouter quelques commentaires et suggestions…

Pour de gros projets, en entreprise, on se retrouve souvent à extraire un ensemble de composants réutilisables dans un projet Flex Library. En théorie, les mêmes composants peuvent être utilisés dans plusieurs modules et/ou dans des applications Flex / Air. Cela permet d’avoir une base de code solide et facile à maintenir pour un développement plus rapide.

Cependant, dans la pratique, certaines erreurs de conception sont faites, qui limitent la ré-utilisabilité des composants. Cet article explique comment créer un composant totalement ré-utilisable et met en avant certaines techniques du SDK Flex qui peuvent être appliquées à vos propres composants.

Comment définir un composant « vraiment » réutilisable?

Il y a différents niveaux de ré-utilisabilité, mais un composant ré-utilisable devrait toujours pouvoir faire le rendu de n’importe quel type de donnée. Il devrait pouvoir fonctionner avec un tableau d’objets basiques (type Object) ou une collection d’objet de type Kangaroo par exemple.

Le composant Flex DataGrid permet de faire cela:

<mx:DataGrid dataProvider="{ kangaroos }">
 <mx:columns>
 <mx:DataGridColumn headerText="Name" dataField="name"/>
 <mx:DataGridColumn headerText="Weight" labelFunction="calculateWeight"/>
 </mx:columns>
</mx:DataGrid>

Notez que les propriétés « dataField » et « labelFunction » indiquent au composant comment récupérer sa donnée depuis les objets de type Kangaroo, sans imposer de dépendance. On a ici deux mécanismes possibles pour rendre un composant vraiment ré-utilisable. Même si le développeur n’as pas le contrôle sur la classe Kangaroo (si elle fait partie d’une librairie externe par exemple), il peuvent tout de même être rendu dans une DataGrid.

L’Anti-Pattern Data Interface

Une des erreurs courantes est d’obliger la donnée qui va être rendue par un composant à implémenter une interface spécifique. Par exemple, on va prendre le composant DistributionBar qui fait le rendu d’un graphique comme celui-ci:

DistributionBar

On affiche un certain nombre de régions de tailles différentes, chacune contenant un label. Il est tentant de configurer ce composant pour qu’il utilise un tableau d’objet IRegion:

public interface IRegion
{
 function get label() : String;
 function get size() : int;
}

Le composant pourra ensuite extraire les informations de taille et de label pour chaque région par cette interface. L’argument en faveur de cette démarche est que l’interface découple le composant de l’objet concret qui est rendu. N’importe quel objet peut être rendu tant qu‘il implémente IRegion, mais c’est dans le « tant que » que réside la faille de conception.

En imposant l’utilisation de l’interface IRegion, la ré-utilisabilité du composant est limitée. L’interface doit être implémentée par les classes du Model avant de pouvoir être rendue par le composant. Encore pire, si vos models sont produits par une autre librairie (dont vous pouvez ne pas avoir les sources) ou par une autre équipe, il se peut que vous ne puissiez pas changer les classes, elles devront donc être « wrappées » (encapsulées dans d’autres objets qui implémentent IRegion).

Pour ces raisons, le composant n’est pas vraiment ré-utilisable.

Notez que cette considération est importante pour les composants qui doivent être complètement ré-utilisables comme les DataGrid ou les List Flex. Pour des composants plus « métiers » ou le fait de pouvoir instancier son composant sans configurer trop de propriétés, on pourra utiliser le « pattern Data Interface ». Parfois, il vaut mieux passer du temps à créer un composant qui soit ré-utilisable mais parfois il est plus aisé/rapide de créer plusieurs composants (par héritage) pour des besoins métiers spécifiques.

Les composants ré-utilisables du SDK Flex

Le SDK Flex contient de nombreux composants ré-utilisables, utilisant plusieurs approches:

  1. Data Fields
  2. Data Functions
  3. Data Descriptor
  4. Factory Objects

Ces approches et ces techniques peuvent être appliquées à vos propres composants pour les rendre ré-utilisables.

Lire la suite

Flex Option Bars – Les composants ButtonBar, LinkBar, MenuBar et ToggleButtonBar

Dans la catégorie des Option Bars, on trouve 4 composants Flex: ButtonBar, LinkBar, MenuBar et ToggleButtonBar. Ces types se ressemblent par leur capacité à rassembler des composants par groupe (LinkButton, Button, Menu…). De plus, vous pouvez utiliser ces Option Bars en conjonction avec des ViewStack/TabNavigator.
Voici un exemple montrant ces 4 composants Flex:

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

This movie requires Flash Player 11

Lire la suite

Flex PopUpMenuButton – Exemple simple de PopUpMenuButton en MXML

Le composant PopUpMenuButton simplifie l’association d’un menu avec un bouton en créant automatiquement le menu assigné au dataProvider du bouton.
Voici un exemple simple de son utilisation:

<mx:PopUpMenuButton labelField="@label">
	<mx:dataProvider>
		<mx:XMLListCollection>
			<mx:XMLList xmlns="">
				<item label="ActionScript">
					<item label="Classe"/>
					<item label="Interface"/>
				</item>
				<item label="MXML">
					<item label="Application"/>
					<item label="Component"/>
				</item>
			</mx:XMLList>
		</mx:XMLListCollection>
	</mx:dataProvider>
</mx:PopUpMenuButton>

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

This movie requires Flash Player 11

Lire la suite

Flex PopUpButton – Menu en PopUp avec une XMLListCollection et labelField

Utilisation de mx.controls.Menu

Les Menus sont des instances de mx.controls.Menu. Comme les Flex Tree, les menus requièrent des data providers hiérarchiques. Le code suivant crée un menu et le peuple avec un dataProvider de type XMLListCollection. Il fixe aussi la propriété labelField, comme on le fait pour un composant Tree:

var menu:Menu = new Menu();
var xmlList:XMLList = XMLList('<item label="ActionScript"><item label="Classe"/><item label="Interface"/></item><item label="MXML"><item label="Application"/><item label="Component"/></item>');
menu.dataProvider = new XMLListCollection(xmlList);
menu.labelField = "@label";

Lire la suite