Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Développement mobile AIR (Approche Flex Tutorial) – Architecture projet

Dans un de mes derniers billets, je présentais une vidéo qui montre l'avancement de mon "framework mobile", un peu en marge de Hero:

Flex et composants mobile (AIR pour Android – iOS) – Mon approche

Cette fois-ci, je vais expliquer de manière globale, quelle est l'architecture des applications mobile que je crée.

Recyclage de projets? Non. Recyclage de librairies? Oui!

A la vue des dernières améliorations de Flex, notamment de Hero, certains doivent penser qu'ils peuvent simplement prendre leur projet, et le rendre compatible pour mobile. Ce n'est pas vraiment le cas pour plusieurs raisons.

Tout d'abord, on est dans un contexte d'application native, pas une application Web. On est donc du côté AIR et non Flex. Rien que pour cela, le type de projet change, il n'y a pas de réutilisation directe.

Ensuite, la philosophie des applications mobiles est différente, notamment au niveau du comportement des composants. Ceux-ci doivent être plus gros par exemple ou répondre aux évènements TOUCH.

Pour créer une application mobile, il vous faudra donc un nouveau projet de type Desktop AIR. Mais cela ne veut pas pour autant dire qu'il faut jeter vos projets par la fenêtre et tout refaire. En effet, vous pouvez ré-utiliser les classes / composants qui se trouvent dans des projets de type Flex Library. Il vous suffit pour cela d'ajouter ces projets au "Library Path" de votre projet AIR et vous pourrez en profiter dans votre code.

C'est là où vous allez voir si votre application est plutôt "monolithique" ou plus modulaire. En effet, si vous avez créé un projet Flex dans lequel se trouve toutes vos classes et que vous n'avez pas utilisé de librairie, vous allez devoir effectuer un travail important pour passer toutes ces classes dans un / des librairies.

Si votre code est bien organisé, vous n'aurez pas de mal à effectuer cette opération. Si vous avez trop de dépendances (couplage) entre vos classes, cet exercice va se révéler périlleux voire impossible. N'ayez pas peur de créer des librairies, quitte à découper des librairies en plusieurs librairies. Au final, votre code pourra être ré-utilisé bien plus facilement et les temps de compilation seront plus rapide. Pour un projet mobile par exemple, j'utilise entre 6 et 8 projets de type Flex Library.

Pour faire simple, les librairies sont des ressources et les projets Flex Project sont des assemblages de ces ressources.

Architecture d'un projet mobile chez Business Geografic (simplifiée)

Voici en version simplifiée, la structure des projets chez BG en terme de librairies / projets.Vous verrez souvent mention de "Aigle" qui est la marque de notre produit phare.

Cette version est simplifiée car certaines librairies contiennent en fait d'autres librairies (AigleFramework contient par exemple une librairie cartographie):

Un petit point rapide sur l'objectif de chaque projet:

• AigleFrameworkCommunication: Contient les classes permettant de communiquer avec un service Aigle
• AssetsLibrary: Contient la majorité des icônes utilisés ainsi que des classes static permettant d'y accéder. Cette librairie est très peu souvent modifiée ce qui a permit de réduire considérablement le temps de build des autres projets
• FlexUtils: Contient des classes utilitaires, type manipulation de String, de couleurs, Logger, HashMap, …
• FlexComponents: Ensemble de composants Flex ré-utilisables et non-métier. Par exemple un champ de texte avec suggestions, un fieldset, une image avec cache, …
• AigleCharting: Permet d'afficher les statistiques renvoyées par Aigle
• AigleDataViz: Contient une AdvancedDataGrid bidouillée
• AigleFramework: Librairie pivot contenant tous les composants ortientés métiers, tous les MVC métiers. Cette librairie utilise toutes les librairies citées précédemment
• Projets Web 1-N: Projets de type Flex Project, utilisant AigleFramework pour intégrer des composants métier + modules spé à chaque application
• MobileComponents: Librairie contenant uniquement des composants à destination des mobiles (listes, conteneurs, vues pour mobiles…). Pas de composants métier
• MobileTopLevelComponents: Librairie permettant de partager des "composants métier mobiles" entre plusieurs application AIR. Par exemple, la vue "Carte" de base sera dans cette librairie et héritée par une classe dans chaque projet AIR
• Projets AIR Mobiles 1-N: Projets faisant l'assemblage des composants mobiles métiers et des composants spécifiques à chaque application.

Voilà pour l'architecture des projets qu'il faut mettre en place. On bien sûr avoir tout dans un même projet, cela fonctionnerait. Mais lorsque vous allez vouloir créer une 2e application, vous aurez un gros travail à faire. Il faut aussi garder à l'esprit qu'il est préférable de séparer les classes / composants ré-utilisables des classes / composants métiers pour ne pas créer de couplage.

package com.russback
{
	/**
	 * Class containing constants for each icon image available for use in the application
	 */
	[Bindable]
	public final class IconLibrary
	{

		/**
		 * Displays the accept icon from the FamFamFam Silk Icons library
		 */
		[Embed(source="assets/images/famfamfam/silkicons/accept.png")]
		public static const ACCEPT:Class;

		/**
		 * Displays the bomb icon from the FamFamFam Silk Icons library
		 */
		[Embed(source="assets/images/famfamfam/silkicons/bomb.png")]
		public static const BOMB:Class;

		/**
		 * Constructor
		 */
		public function IconLibrary()
		{
		}

	}
}