Retrouvez gratuitement la notice de l'appareil FLEX ADOBE au format PDF.
Téléchargez la notice de votre Framework de développement web au format PDF gratuitement ! Retrouvez votre notice FLEX - ADOBE et reprennez votre appareil électronique en main. Sur cette page sont publiés tous les documents nécessaires à l'utilisation de votre appareil FLEX de la marque ADOBE.
Développement d'applications mobiles avec ® Définition de menus dans une application mobile
Intégration de polices dans une application mobile Utilisation de texte HTML dans des contrôles mobiles Chapitre 6 : Habillage Notions de base sur l’habillage mobile
La version Adobe Flex 4.5 permet d’utiliser Flex et Adobe Flash Builder sur les smartphones et les tablettes. En tirant profit d’Adobe AIR, vous pouvez maintenant développer des applications mobiles dans Flex avec la même aisance et la même qualité que sur les plateformes d’ordinateurs de bureau. De nombreux composants Flex existants ont été étendus pour fonctionner sur les périphériques mobiles, y compris l’ajout de la prise en charge du défilement tactile. Flex 4.5 contient également un ensemble de nouveaux composants conçus pour simplifier la création d’applications qui suivent les modèles de conception standard pour les téléphones et les tablettes. Flash Builder a également été mis à jour pour fournir de nouvelles fonctionnalités pour la prise en charge du développement d’applications pour les périphériques mobiles. Avec Flash Builder, vous pouvez développer, tester et déboguer des applications sur votre ordinateur de bureau ou directement sur votre périphérique mobile.
En raison de la taille d’écran réduite des périphériques mobiles, les applications mobiles sont généralement conçues différemment des applications pour navigateur. Lors du développement d’applications mobiles, vous divisez en général le contenu en une série de vues à afficher sur un périphérique mobile. Chaque vue contient les composants qui se rapportent à une tâche individuelle ou qui contiennent un ensemble unique d’informations. L’utilisateur passe généralement d’une vue à l’autre pour obtenir plus de détails en appuyant sur les composants d’une vue. L’utilisateur peut alors utiliser le bouton Retour du périphérique pour retourner à une vue précédente ou intégrer la navigation dans l’application. Dans l’exemple suivant, la vue initiale de l’application montre une liste de produits :
Si vous concevez une application pour les plateformes mobiles, Web et d’ordinateurs de bureau, concevez des interfaces utilisateur distinctes pour chaque plateforme. Toutefois, les applications peuvent partager un code d’accès au modèle et aux données sous-jacent entre toutes les plateformes.
Pour une application destinée à des tablettes, les limites de taille d’écran sont moins contraignantes qu’avec les téléphones. Vous n’êtes pas tenu de structurer une application de tablette autour de petites vues. A la place, vous pouvez créer l’application en utilisant le conteneur Spark Application standard avec les composants et habillages mobiles pris en charge. Remarque : vous pouvez créer une application pour un téléphone mobile basée sur le conteneur Spark Application. Toutefois, vous utilisez généralement les conteneurs ViewNavigatorApplication et TabbedViewNavigatorApplication à la place. Créez un projet mobile dans Flash Builder pour les tablettes comme vous le feriez pour les téléphones. Les applications pour les tablettes et les téléphones requièrent le même thème mobile pour tirer profit des composants et habillages optimisés pour les applications mobiles.
Flash Builder introduit un flux de travail productif de conception, création et débogage dans le développement mobile. L’objectif des fonctionnalités mobiles dans Flash Builder est de rendre le développement d’une application mobile basée sur ActionScript ou Flex aussi simple que le développement d’une application de bureau ou Web. Flash Builder offre deux options pour les tests et le débogage. Vous pouvez lancer et déboguer l’application sur l’ordinateur de bureau en utilisant AIR Debug Launcher (ADL). Pour bénéficier d’un contrôle plus important, lancez et déboguez l’application directement sur un périphérique mobile. Dans les deux cas, vous pouvez utiliser les capacités de débogage de Flash Builder, y compris la définition de points d’arrêt et l’examen de l’état de l’application à l’aide des volets Variables et Expressions. Lorsque votre application est prête à être déployée, utilisez le processus Exporter vers une version validée, tout comme vous le feriez pour préparer une application de bureau ou Web. La principale différence tient au fait que lorsque vous exportez une version validée d’un projet mobile, Flash Builder groupe la version en tant que programme d’installation natif et non pas en tant que fichier .air. Par exemple, sur Android, Flash Builder produit un fichier .apk qui ressemble à un package d’application Android natif. Le programme d’installation natif permet de distribuer les applications AIR de la même façon que les applications natives sur chaque plateforme.
Déployez des applications mobiles créées dans Flex en utilisant Adobe AIR pour les périphériques mobiles. Tout périphérique sur lequel vous souhaitez déployer une application mobile doit prendre en charge AIR. Vos applications peuvent bénéficier pleinement de l’intégration d’AIR à la plateforme mobile. Par exemple, une application mobile peut gérer un bouton de retour et de menu matériel et accéder au stockage local. Vous pouvez également bénéficier de toutes les fonctions fournies par AIR pour les périphériques mobiles. Ces fonctions comprennent la géolocalisation, l’accéléromètre et l’intégration d’une caméra. Sur un périphérique mobile, il n’est pas nécessaire d’installer AIR avant d’exécuter une application créée dans Flex. La première fois qu’un utilisateur exécute une application créée dans Flex, l’utilisateur est invité à télécharger AIR.
WindowedApplication et Window. A la place, utilisez les conteneurs ViewNavigatorApplication et TabbedViewNavigatorApplication. Dans le cas du développement d’applications destinées à des tablettes, vous pouvez également utiliser le conteneur Spark Application. Pour plus d’informations, voir Utilisation des composants Flex AIR et « Définition d’une application mobile et d’un écran de démarrage » à la page 27.
Un thème définit l’aspect et l’ergonomie des composants visuels d’une application. Un thème peut simplement définir la palette chromatique ou la police commune d’une application, ou peut redéfinir entièrement l’habillage de l’ensemble des composants utilisés par l’application. Vous pouvez définir des styles CSS sur les composants Flex uniquement si le thème actuel comprend ces styles. Pour déterminer si le thème actuel prend en charge le style CSS, affichez l’entrée du style dans le Guide de référence ActionScript 3.0 pour la plate-forme Adobe Flash. Flex prend en charge trois thèmes principaux : Mobile, Spark et Halo. Le thème Mobile définit l’aspect par défaut des composants Flex lorsque vous créez une application mobile. Afin de rendre certains composants Flex compatibles avec le thème Mobile, Adobe a créé de nouveaux habillages pour les composants. Par conséquent, certains composants ont les habillages spécifiques d’un thème. Les applications créées avec Flex peuvent cibler différents périphériques mobiles, chacun présentant des tailles et des résolutions d’écran différentes. Flex simplifie le processus de production d’applications indépendantes de la résolution en proposant des habillages indépendants des PPP pour les composants mobiles. Pour plus d’informations sur les habillages mobiles, voir « Notions de base sur l’habillage mobile » à la page 96. Pour plus d’informations sur les styles et les thèmes, voir Styles et thèmes et « Styles mobiles » à la page 96.
Découvrez les nouvelles fonctions intégrées dans Flex 4.5 et Flash Builder 4.5, dans :
• Développement mobile à l’aide d’Adobe Flex 4.5 SDK et de Flash Builder 4.5 de Narciso Jaramillo, chef de produit chez Adobe.
Le Pôle de développement Flex contient de nombreuses ressources conçues pour vous aider à commencer à créer des applications mobiles à l’aide de Flex 4.5 :
• Exemples d’applications réelles créées dans Flex
Vous trouverez ici des informations sur Flash Builder 4.5 mobile compilées par Holly Schinsky. Mark Doherty, évangéliste Adobe, a publié une vidéo sur la génération d’applications pour les ordinateurs de bureau, les téléphones portables et les tablettes. James Ward, spécialiste d’Adobe, propose une vidéo concernant la génération d’applications mobiles avec Flex 4.5. Le blogueur Joseph Labrecque a communiqué sur une démonstration de Flex 4.5 mobile. Le blogueur Fabio Biondi a communiqué sur la création d’un lecteur YouTube utilisant AIR pour les dispositifs Android à l’aide de Flash Builder.
Utilisez Flex pour développer des applications pour les environnements de déploiement suivants : Navigateur Déployez l’application en tant que fichier SWF à utiliser dans Flash Player s’exécutant dans un navigateur. Bureau Déployez une application AIR autonome pour un ordinateur de bureau, tel qu’un ordinateur exécutant Windows ou un Macintosh. Mobile Déployez une application AIR autonome pour un périphérique mobile, tel qu’un téléphone ou une tablette.
Les applications destinées aux périphériques mobiles à écran tactile diffèrent des applications de bureau et de navigateur de plusieurs manières :
• En raison de la mémoire limitée disponible sur les périphériques mobiles, les applications doivent être soucieuses d’économiser la mémoire.
Par conséquent, la création d’une application pour un périphérique mobile ne se résume pas au redimensionnement d’une application de bureau pour un écran de plus petite taille. Flex vous permet de créer différentes interfaces utilisateur appropriées pour chaque facteur de forme, tout en partageant le code d’accès au modèle et aux données sous-jacent entre les projets mobiles, de navigateur et de bureau.
Utilisez le composant Spark défini lors de la création des applications mobiles dans Flex. Les composants Spark sont définis dans les composants Spark.* packages. Toutefois, pour des raisons de performance ou parce que tous les composants Spark n’ont pas d’habillage pour le thème Mobile, les applications mobiles ne prennent pas en charge la totalité des composants Spark. A l’exception des contrôles graphiques MX et du contrôle MX Spacer, les applications mobiles ne prennent pas en charge l’ensemble de composants MX défini dans les packagesmx.*. Le tableau ci-dessous répertorie les composants que vous pouvez utiliser, que vous ne pouvez pas utiliser ou qui requièrent un soin particulier pour être utilisés dans une application mobile : Composant
Composants MX autres que Spacer et les graphiques
BarChart, dans une application mobile. Les contrôles graphiques MX sont dans les graphiques MX.mx.*. Toutefois, leurs performances sur un périphérique mobile peuvent être amoindries selon la taille et le type des données graphiques. Par défaut, Flash Builder n’inclut pas les composants MX dans le chemin d’accès aux bibliothèques des projets mobiles. Pour utiliser les composants graphiques MX dans une application, ajoutez les fichiers mx.swc et charts.swc à votre chemin d’accès à la bibliothèque.
• Pas de prise en charge du contrôle ToolTip. • Pas de prise de charge des bibliothèques RSL.
En raison des contraintes de performances qui pèsent sur les périphériques mobiles, certains aspects du développement d’applications mobiles diffèrent de ceux du développement d’applications de navigateur et de bureau. Les considérations liées aux performances comprennent :
Pour les applications mobiles, le défilement dans les listes doit être aussi performant que possible. Rédigez des rendus d’élément dans ActionScript pour bénéficier de performances optimales. Il est possible de rédiger les rendus d’élément dans MXML, mais les performances de vos applications peuvent en souffrir. Flex fournit deux rendus d’élément qui sont optimisés à utiliser dans une application mobile : spark.components.LabelItemRenderer et spark.components.IconItemRenderer. Pour plus d’informations à propos de ces rendus d’élément, voir Using a mobile item renderer with a Spark list-based control. Pour plus d’informations sur la création de rendus d’élément personnalisés dans ActionScript, voir Custom Spark item renderers. Pour plus d’informations sur les différences entre les rendus d’élément mobiles et de bureau, voir Differences between mobile and desktop item renderers.
Les habillages mobiles livrés avec Flex sont rédigés dans ActionScript avec des graphiques FXG compilés afin d’offrir des performances optimales. Vous pouvez rédiger les habillages dans MXML, mais les performances de votre application peuvent en souffrir, selon le nombre de composants qui utilisent les habillages MXML. Pour des performances optimales, rédigez les habillages dans ActionScript et utilisez des graphiques FXG compilés. Pour plus d’informations, voir Habillage Spark et Graphiques FXG et MXML.
Bon nombre des contrôles de texte Spark dépendent de TLF. L’utilisation de contrôles TLF dans une application mobile peut affecter les performances. Pour plus d’informations à propos de TLF, voir About the Spark text controls. Le contrôle Spark Label ne dépend pas de TLF. Les contrôles Spark TextInput et TextArea disposent d’habillages pour le thème mobile qui ne dépendent pas de TLF. Pour des résultats optimaux, utilisez les contrôles Label, TextInput et TextArea dans votre application, sauf lorsque vous rédigez des rendus d’élément personnalisés. Dans les rendus d’élément personnalisés, utilisez le contrôle StyleableTextField. Pour plus d’informations, voir Custom Spark item renderers. Les contrôles Spark RichText et RichEditableText dépendent de TLF. Vous pouvez utiliser ces contrôles pour afficher un contenu riche, mais leur utilisation risque de nuire aux performances.
Vous pouvez utiliser les contrôles graphiques MX, tels que les contrôles AreaChart et BarChart, dans une application mobile. Toutefois, ils peuvent nuire aux performances selon la taille et le type des données graphiques. Le blogueur Nahuel Foronda a créé une série d’articles sur Mobile ItemRenderer dans ActionScript. Le blogueur Rich Tretola a créé une entrée de cookbook sur la création d’une liste avec un élément ItemRenderer pour une application mobile.
« Conception d’une application mobile » à la page 1 .
Remarque : si vous ne disposez pas d’un périphérique prenant en charge AIR 2.6, vous pouvez utiliser Flash Builder pour lancer et déboguer des applications mobiles sur le bureau. Chaque version du SDK Flex inclut la version requise d’Adobe AIR. Si vous avez installé des applications mobiles sur un périphérique exécutant une version antérieure du SDK Flex, désinstallez AIR du périphérique. Flash Builder installe la version correcte d’AIR lorsque vous exécutez ou déboguez une application mobile sur un périphérique.
1 Dans Flash Builder, sélectionnez Fichier > Nouveau > Projet Flex Mobile. Lorsque vous créez un projet Flex Mobile, Flash Builder génère les fichiers suivants pour le projet :
Pour plus d’informations sur la définition des vues, voir « Définition de vues dans une application mobile » à la page 30. Vous pouvez aussi créer un projet mobile ActionScript seulement. Voir « Création d’un projet mobile ActionScript » à la page 11. 2 (Facultatif) Ajoutez du contenu au contrôle ActionBar du fichier de l’application principale.
« Définition de contrôles de navigation, de titre et d’action dans une application mobile » à la page 45. 3 Disposez le contenu de la vue initiale de votre application.
Utilisez uniquement des composants pris en charge par Flash pour le développement mobile. En mode Création comme en mode Source, Flash Builder vous guide dans l’utilisation des composants pris en charge. Voir « Interface utilisateur et présentation » à la page 19 Dans la vue, ajoutez du contenu au contrôle ActionBar qui n’est visible que dans cette vue. 4 (Facultatif) Ajoutez toutes les vues que vous souhaitez inclure dans votre application.
Pour plus d’informations sur les vues, voir « Définition de vues dans une application mobile » à la page 30. 5 (Facultatif) Ajoutez des rendus d’élément optimisés pour les applications mobiles pour les composants List.
Voir Using a mobile item renderer with a Spark list-based control. 6 Configurez les configurations de lancement pour exécuter et déboguer l’application.
Une configuration de lancement est requise pour exécuter ou déboguer une application à partir de Flash Builder. La première fois que vous exécutez ou déboguez une application mobile, Flash Builder vous invite à configurer une configuration de lancement. Lors de l’exécution ou du débogage d’une application mobile sur un périphérique, Flash Builder installe l’application sur le périphérique. Voir « Exécution et débogage des applications mobiles » à la page 111. 7 Exportez l’application en tant que package d’installation.
Brent Arnold, expert Flex certifié par Adobe, a conçu les didacticiels vidéos suivants pour vous permettre de :
1 Avant de commencer à créer l’application mobile ActionScript, suivez la procédure répertoriée dans la section
2 Dans Flash Builder, sélectionnez Fichier > Nouveau > Projet ActionScript Mobile.
Suivez les invites de l’assistant de nouveau projet comme vous le feriez dans tout autre assistant de création de projets dans Flash Builder. Pour plus d’informations, voir Création de projets mobiles ActionScript. 3 Rédigez le code de l’application dans le fichier d’application ActionScript principal. 4 Configurez les configurations de lancement pour exécuter et déboguer l’application. Vous pouvez exécuter ou
Pour plus d’informations, voir « Débogage d’une application sur un périphérique Apple iOS » à la page 115. 5 Exportez ou déployez l’application en tant qu’application de package iOS (IPA, iOS Package Application).
« Déploiement d’une application sur un périphérique Apple iOS » à la page 119.
Création d’une application mobile (vidéo) Le SDK BlackBerry Tablet OS pour AIR fournit des API qui permettent de créer des applications Flex et ActionScript basées sur AIR. Pour plus d’informations sur l’installation du SDK BlackBerry Tablet OS, voir le guide de prise en main BlackBerry Tablet OS.
Suivez les invites de l’assistant de nouveau projet comme vous le feriez pour tout autre projet AIR dans Flash Builder. Veillez à sélectionner BlackBerry Tablet OS comme plateforme cible. Pour plus d’informations, voir Création de projets mobiles ActionScript.
Pour plus d’informations sur la signature, le groupement et le déploiement de l’application, voir le guide de développement du SDK BlackBerry Tablet OS pour Adobe AIR par RIM. Lisez également l’article relatif à l’utilisation de Flash Builder afin de grouper des applications pour les périphériques BlackBerry Tablet OS par Andrew Shorten, chef de produit Adobe. Vous trouverez des ressources supplémentaires sur le développement BlackBerry Tablet OS provenant d’Adobe et de RIM sur la page Adobe Developer Connection.
Utilisez Flash Builder pour créer une application mobile ActionScript. L’application que vous créez est basée sur l’API d’Adobe AIR. 1 Sélectionnez Fichier > Nouveau > Projet mobile ActionScript. 2 Entrez un nom de projet et un emplacement. L’emplacement par défaut est l’espace de travail actuel. 3 Utilisez le SDK Flex 4.5 par défaut qui prend en charge le développement d’applications mobiles.
4 Sélectionnez les plateformes cibles pour votre application et spécifiez les paramètres de projet mobile pour chaque
Pour plus d’informations sur les paramètres de projet mobile, voir « Définition des préférences de projet mobile » à la page 12. 5 Cliquez sur Terminer ou sur Suivant pour indiquer d’autres options de configuration et chemins de génération.
Flash Builder utilise des configurations de périphériques pour afficher des aperçus des tailles d’écran des périphériques dans la vue Création, ou pour lancer des applications sur le bureau à l’aide d’AIR Debug Launcher (ADL). Voir « Gestion des configurations de lancement » à la page 111. Pour définir des configurations de périphériques, ouvrez la fenêtre Préférences et sélectionnez Flash Builder > Configuration des périphériques. Flash Builder fournit plusieurs configurations de périphérique par défaut. Vous pouvez ajouter, modifier ou supprimer des configurations de périphérique supplémentaires. Vous ne pouvez pas modifier les configurations par défaut fournies par Flash Builder. Cliquez sur le bouton Restaurer les valeurs par défaut pour rétablir les configurations de périphériques par défaut, sans supprimer les configurations que vous avez ajoutées. De plus, si vous avez ajouté une configuration de périphérique avec un nom correspondant à celui d’une configuration par défaut, Flash Builder remplace la configuration ajoutée par les paramètres par défaut. Les configurations de périphérique contiennent les propriétés suivantes : Propriété
Pixels par pouce sur l’écran du périphérique.
Flash Builder prend en charge les plateformes cibles en fonction du type d’application. Pour sélectionner une plateforme, ouvrez la fenêtre Préférences et sélectionnez Flash Builder > Plateformes cibles. Pour tous les plug-ins tiers, reportez-vous à la documentation correspondante.
Lorsque vous créez une application mobile, vous pouvez faire un choix parmi les modèles d’application suivants : Vide Utilise la balise Spark Application en tant qu’élément d’application de base.
Application basée sur une vue Utilise la balise Spark ViewNavigatorApplication en tant qu’élément d’application de base pour créer une application dotée d’une vue unique.
Pour ajouter un onglet, saisissez le nom de l’onglet et cliquez sur Ajouter. Vous pouvez modifier l’ordre des onglets en cliquant sur Haut et Bas. Pour supprimer un onglet d’une application, sélectionnez un onglet et cliquez sur Supprimer. Le nom de la vue correspond au nom de l’onglet auquel est ajouté le mot « View ». Par exemple, si vous nommez un onglet FirstTab, Flash Builder génère une vue nommée FirstTabView. Pour chaque onglet que vous créez, un nouveau fichier MXML est généré dans le package « Views ». Remarque : le nom du package n’est pas configurable à l’aide de l’assistant Projet Flex Mobile. Les fichiers MXML sont générés conformément aux règles suivantes :
Builder modifie le nom de fichier MXML en le remplaçant par « ViewN », où N correspond à la position de la vue, en commençant par N=1. Brent Arnold, expert Flex certifié par Adobe, a créé un didacticiel vidéo sur l’utilisation du modèle d’application à onglets.
Lorsque vous créez une application mobile, vous pouvez spécifier ou modifier les droits par défaut d’une plateforme cible. Les autorisations sont spécifiées au moment de la compilation et ne peuvent pas être modifiées dans l’environnement d’exécution. Commencez par sélectionner la plateforme cible, puis définissez les autorisations pour chaque plateforme, le cas échéant. Vous pourrez modifier les autorisations par la suite dans le fichier XML descripteur de l’application. Des plug-ins tiers fournissent une prise en charge de plateformes supplémentaires pour les projets Flex et ActionScript. Pour les autorisations spécifiques aux plateformes, reportez-vous à la documentation du périphérique. Autorisations pour la plateforme Google Android Pour la plateforme Google Android, vous pouvez définir les autorisations suivantes : INTERNET Autorise les demandes réseau et le débogage à distance.
WRITE_EXTERNAL_STORAGE Autorise l’écriture sur un périphérique externe.
READ_PHONE_STATE Coupe le son au cours d’un appel entrant.
ACCESS_FINE_LOCATION Autorise l’accès à un emplacement GPS.
DISABLE_KEYGUARD and WAKE_LOCK Interdit la mise en veille du périphérique.
CAMERA Permet d’accéder à une caméra.
RECORD_AUDIO Permet d’accéder à un microphone.
ACCESS_NETWORK_STATE and ACCESS_WIFI_STATE Autorise l’accès aux informations concernant les interfaces
Sélectionnez ce droit pour permettre à l’application d’accéder aux informations réseau à l’aide de la classe NetworkInfo. Pour plus d’informations sur la définition des propriétés des applications mobiles, voir la Documentation Adobe AIR. Autorisations pour la plateforme Apple iOS La plateforme Apple iOS utilise la validation dans l’environnement d’exécution pour les autorisations au lieu des autorisations prédéfinies. En d’autres termes, si une application souhaite accéder à une fonction spécifique de la plateforme Apple iOS qui requiert des droits d’utilisateur, une fenêtre contextuelle apparaît, demandant l’autorisation.
Les paramètres de plateforme vous permettent de sélectionner une gamme de périphériques cibles. Selon la plateforme sélectionnée, vous pouvez choisir le périphérique cible ou une gamme de périphériques cibles. Vous pouvez sélectionner un périphérique spécifique ou tous les périphériques pris en charge par la plateforme. Des plug-ins tiers fournissent une prise en charge de plateformes supplémentaires pour les projets Flex et ActionScript. Pour les autorisations spécifiques aux plateformes, reportez-vous à la documentation du périphérique. Paramètres de plateforme pour la plateforme Google Android il n’existe pas de paramètres spécifiques à la plateforme Google Android. Paramètres de plateforme pour la plateforme Apple iOS Pour un projet mobile Flex ou un projet mobile ActionScript, vous pouvez spécifier les périphériques cibles suivants pour la plateforme Apple iOS : iPhone/iPod Touch Les applications utilisant cette gamme cible sont répertoriées comme compatibles uniquement
Tous Les applications utilisant cette gamme cible sont répertoriées comme compatibles avec les périphériques iPhone/iPod Touch et iPad dans l’App Store d’Apple. Il s’agit de l’option par défaut.
Réorientation automatique Fait pivoter l’application lorsque l’utilisateur tourne le périphérique. Lorsque ce
Plein écran Affiche l’application en mode plein écran sur le périphérique. Lorsque ce paramètre est activé, la barre
Vous utilisez le redimensionnement d’application mobile pour créer une application mobile unique compatible avec des périphériques de taille d’écran et de densité différentes. Les écrans des périphériques mobiles possèdent des densités d’écran, ou valeurs PPP(points par pouce), variables. Vous pouvez spécifier une valeur de PPP de 160, 240 ou 320, selon la densité d’écran du périphérique cible. Lorsque vous activez le redimensionnement automatique, Flex optimise la façon dont il affiche l’application pour la densité d’écran de chaque périphérique. Par exemple, supposez que vous spécifiez une valeur PPP cible de 160 et activez le redimensionnement automatique. Lorsque vous exécutez l’application sur un périphérique doté d’une valeur PPP de 320, Flex redimensionne automatiquement l’application par un facteur 2. En d’autres termes, Flex agrandit tout de 200 %. Pour spécifier la valeur PPP cible, définissez-la comme propriété applicationDPI de la balise <s:ViewNavigatorApplication> ou <s:TabbedViewNavigatorApplication> dans le fichier de l’application principale : <s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" firstView="views.HomeView" applicationDPI="160">
Pour plus d’informations à propos de la création d’applications mobiles indépendamment de la densité, voir « Prise en charge de plusieurs tailles d’écran et valeurs PPP dans une application mobile » à la page 71.
Vous pouvez connecter un périphérique Google Android à votre ordinateur de développement pour visualiser ou déboguer l’application sur le périphérique Android.
Les projets mobiles Flex et les projets mobiles ActionScript requièrent AIR 2.6. Vous pouvez exécuter ou déboguer des projets mobiles seulement sur des périphériques physiques qui prennent en charge AIR 2.6. Vous pouvez installer AIR 2.6 sur des périphériques Android qui exécutent Android 2.2 ou version ultérieure.
1 Sur le périphérique, procédez comme suit pour vous assurer que le débogage USB est activé : a Appuyez sur le bouton Accueil pour afficher l’écran d’accueil. b Accédez à Paramètres, puis sélectionnez Applications > Développement. c Activez le débogage USB. 2 Connectez le périphérique à votre ordinateur à l’aide d’un câble USB. 3 Etendez vers le bas la zone de notification située en haut de l’écran. Vous devez voir une indication de type USB
4 (Windows uniquement) Installez le pilote USB approprié à votre périphérique. Voir « Installation de pilotes de
5 Etirez vers le bas la zone de notification situe en haut de l’écran.
Assurez-vous que le mode USB n’est pas défini sur Mode PC. Remarque : une configuration supplémentaire est nécessaire pour le débogage. Voir « Exécution et débogage d’une application mobile sur un périphérique » à la page 112.
(Windows) Pilotes de périphérique et configurations Les plateformes Windows requièrent l’installation d’un pilote USB pour connecter un périphérique Android à votre ordinateur de développement. Flash Builder fournit un pilote de périphérique et une configuration pour plusieurs périphériques Android. Ces configurations de pilotes de périphérique sont répertoriées dans le fichier android_winusb.inf. Windows Device Manager accède à ce fichier au cours de l’installation du pilote de périphérique. Flash Builder installe android_winusb.inf à l’emplacement suivant : <Adobe Flash Builder 4.5 Home>\utilities\drivers\android\android_winusb.inf
Installation d’un pilote de périphérique USB 1 Connectez votre périphérique Android au port USB de votre ordinateur. 2 Accédez à l’emplacement suivant :
Si vous avez un périphérique Android pris en charge qui ne figure pas dans la section « Installation de pilotes de périphérique USB pour les périphériques Android (Windows) » à la page 16, mettez à jour le fichier android_winusb.inf pour inclure le périphérique. 1 Branchez le périphérique à un port USB de votre ordinateur. Windows vous indique que le pilote est introuvable. 2 A l’aide du Gestionnaire de périphériques Windows, ouvrez l’onglet Détails des propriétés du périphérique. 3 Sélectionnez la propriété ID de matériel pour afficher l’ID du matériel. 4 Ouvrez le fichier android_winusb.inf dans un éditeur de texte. Recherchez android_winusb.inf à
<Adobe Flash Builder 4.5 Home>\utilities\drivers\android\android_winusb.inf Par exemple : . . . [Google.NTx86] Toutefois, le pilote permet à Flash Builder d’accéder à votre périphérique. Important : si Windows ne reconnaît toujours pas le périphérique, vous devez installer le pilote USB approprié disponible auprès du fabricant du périphérique. Voir la page relative aux fabricants de pilotes USB pour obtenir des liens vers les sites Web de plusieurs fabricants de périphériques depuis lesquels vous pouvez télécharger le pilote USB approprié pour votre périphérique. Brent Arnold, expert Flex certifié par Adobe, partage ses astuces qui permettent à votre périphérique Android d’être reconnu par Windows.
Ouvrez la fenêtre Préférences et sélectionnez Flash Builder > Configuration des périphériques pour afficher les configurations de périphérique pour tous les périphériques Apple pris en charge.
1 Créez un fichier de demande de signature de certificat. Ce fichier permet d’obtenir un certificat de développement
Pour plus d’informations, voir Génération d’une demande de signature de certificat. 2 Générez un certificat de développement Apple (extension de nom de fichier .cer) et un fichier de profil
Lors de la création du profil d’approvisionnement, répertoriez les ID des périphériques sur lesquels vous souhaitez installer l’application. Pour plus d’informations, voir la documentation Apple destinée aux développeurs. 3 Convertissez le certificat de développement Apple au format de certificat P12.
Conversion d’un certificat de développement en fichier P12.
1 Une vue d’accueil qui vous permet d’ajouter des coordonnées 2 Une vue de contacts contenant la liste des contacts existants 3 Une vue de recherche permettant d’effectuer des recherches dans votre liste de contacts
L’image suivante présente l’écran principal d’une application mobile simple créée dans Flex : Zone de contenu La zone de contenu affiche les écrans individuels, ou vues, qui constituent l’application. Les utilisateurs naviguent dans les vues de l’application en utilisant les composants intégrés à l’application et les contrôles d’entrée du périphérique mobile.
La figure ci-dessous présente une application mobile qui inclut une barre d’onglets au bas de la fenêtre de l’application :
à l’ensemble de l’application, alors que le contrôle ActionBar est spécifique à chaque section.
Remarque : ce schéma présente l’architecture de l’application, mais ne représente pas l’application en cours d’exécution. Lors de l’exécution, une seule vue est active et résidente dans la mémoire. Pour plus d’informations, voir « Navigation parmi les vues d’une application mobile » à la page 23. Classes utilisées dans une application mobile Utilisez les classes suivantes pour définir une application mobile : Classe
ViewNavigator pour l’ensemble de l’application. Utilisez les méthodes du conteneur ViewNavigator pour basculer entre les différentes vues.
Chaque application mobile comporte au moins une vue. Même si le fichier de l’application principale crée le conteneur ViewNavigator, il ne définit aucune des vues utilisées dans l’application.
Au moment de l’exécution, une seule vue est active et résidente dans la mémoire. Pour plus d’informations, voir « Navigation parmi les vues d’une application mobile » à la page 23. Classes utilisées dans une application mobile comprenant plusieurs sections Le tableau suivant répertorie les classes que vous utilisez pour créer une application mobile comprenant plusieurs sections :
ViewNavigator pour chaque section de l’application. TabbedViewNavigator
Le conteneur TabbedViewNavigatorApplication crée automatiquement un seul conteneur TabbedViewNavigator pour l’ensemble de l’application. Le conteneur TabbedViewNavigator crée la barre d’onglets que vous utilisez pour naviguer parmi les sections.
ViewNavigator contrôle la navigation parmi les vues qui constituent la section. Il crée également le contrôle Actionbar pour la section.
Utilisez le conteneur ViewNavigator pour naviguer parmi les vues de chaque section et pour définir le contrôle ActionBar pour la section. Utilisez la propriété ViewNavigator.firstView pour spécifier le fichier qui définit la première vue de la section. Utilisation de TabbedViewNavigator dans une application à plusieurs sections Le conteneur TabbedViewNavigatorApplication crée automatiquement un seul conteneur de type TabbedViewNavigator. Le conteneur TabbedViewNavigator crée alors une barre d’onglets au bas de l’application. Vous n’êtes pas tenu d’ajouter une logique à l’application pour naviguer parmi les sections.
Une pile d’objets View contrôle la navigation dans une application mobile. L’objet View supérieur de la pile définit la vue actuellement visible. Le conteneur ViewNavigator gère la pile. Pour changer de vue, poussez un nouvel objet View sur la pile ou retirez l’objet View actuel de la pile. Le fait de retirer de la pile l’objet View actuellement visible détruit l’objet View et ramène l’utilisateur à la vue précédente sur la pile.
Pour économiser la mémoire, par défaut, le conteneur ViewNavigator s’assure qu’une seule vue est en mémoire à la fois. Toutefois, il conserve les données des vues précédentes de la pile. Par conséquent, lorsque l’utilisateur revient à la vue précédente, celle-ci peut être réinstanciée avec les données appropriées. Remarque : le conteneur View définit la propriété destructionPolicy. S’il est défini sur auto, la valeur par défaut, le conteneur ViewNavigator détruit la vue lorsqu’elle n’est pas active. S’il est défini sur none, la vue est mise en mémoire cache. Le blogueur Mark Lochrie a communiqué sur Flash Builder 4.5 ViewNavigator. Méthodes de navigation ViewNavigator Utilisez les méthodes suivantes de la classe ViewNavigator pour contrôler la navigation : pushView() Poussez un objet View sur la pile. L’objet View communiqué en tant qu’argument à la méthode pushView() devient la vue actuelle.
ViewNavigator à basculer l’affichage vers le nouvel objet View.
ViewNavigator ramène l’affichage à l’objet View précédent sur la pile. Remarque : le périphérique mobile lui-même contrôle en grande partie la navigation dans une application mobile. Par exemple, les applications mobiles intégrées à Flex gèrent automatiquement le bouton retour sur les périphériques mobiles. Par conséquent, vous n’avez pas à ajouter la prise en charge du bouton retour dans l’application. Lorsque l’utilisateur appuie sur le bouton retour du périphérique mobile, Flex appelle automatiquement la méthode popView() pour restaurer la vue précédente. Le blogueur David Hassoun a communiqué surla gestion des données dans une vue.
Dans la figure suivante, les vues sont organisées en plusieurs sections. Un conteneur ViewNavigator différent définit chaque section. Chaque section contient une ou plusieurs vues :
Vous pouvez aussi programmer le changement de section à l’aide de la propriété TabbedViewNavigator.selectedIndex. Cette propriété contient l’index de base 0 du navigateur de vues
Gestion des saisies de l’utilisateur dans une application mobile La saisie utilisateur requiert une gestion différente dans une application mobile par rapport à une application de bureau ou de navigateur. Dans une application de bureau créée pour AIR ou dans une application de navigateur conçue pour Flash Player, les principaux dispositifs de saisie sont une souris et un clavier. Dans le cas de périphériques mobiles, le dispositif de série principal est un écran tactile. Un périphérique mobile possède souvent un type de clavier et certains périphériques disposent également d’une méthode de saisie à cinq directions (gauche, droite, haut, bas et sélection). La classe mx.core.UIComponent définit la propriété de style interactionMode que vous utilisez pour configurer des composants pour le type de saisie utilisé par l’application. Pour les thèmes Halo et Spark, la valeur par défaut est mouse, ce qui indique que la souris est le dispositif de saisie principal. Pour le thème Mobile, la valeur par défaut est touch, ce qui indique que l’écran tactile constitue le dispositif de saisie principal.
Les applications définies par les conteneurs ViewNavigatorApplication ou TabbedViewNavigatorApplication répondent aux touches matérielles Retour et Menu d’un périphérique. Lorsque l’utilisateur appuie sur la touche Retour, l’application revient à la vue précédente. S’il n’y a pas de vue précédente, l’application se ferme et l’écran d’accueil du périphérique apparaît. Lorsque l’utilisateur appuie sur le bouton Retour, la vue active de l’application reçoit un événement backKeyPressed. Vous pouvez annuler l’action de la touche Retour en appelant preventDefault() dans le gestionnaire d’événement pour l’événement backKeyPressed. Lorsque l’utilisateur appuie sur le bouton Menu, le conteneur ViewMenu de la vue actuelle apparaît, s’il est défini. Le conteneur ViewMenu définit un menu situé au bas du conteneur View. Chaque conteneur View définit son propre menu, spécifique à cette vue. Le contrôle View actif envoie un événement menuKeyPressed lorsque l’utilisateur appuie sur la touche Menu. Pour annuler l’action du bouton Menu et empêcher l’affichage de ViewMenu, appelez la méthode preventDefault() dans le gestionnaire d’événement pour l’événement menuKeyPressed. Pour plus d’informations, voir « Définition de menus dans une application mobile » à la page 53.
AIR génère différents événements pour indiquer différents types de saisie. Ces événements comprennent : Evénements de souris Evénements générés par une intervention de l’utilisateur effectuée au moyen d’une souris ou
Evénements tactiles Evénements générés sur des périphériques qui détectent les contacts de l’utilisateur avec le
Evénements de mouvement Evénements générés par des interactions tactiles multipoint, telles que la pression de
Prise en charge intégrée des événements de souris
événements tactiles ni de mouvement. Par exemple, l’utilisateur interagit avec les composants Flex dans une application mobile en utilisant l’écran tactile. Les composants répondent aux événements de souris, tels que mouseDown et mouseOver, mais pas aux événements tactiles ni de mouvement. Par exemple, l’utilisateur appuie sur l’écran tactile pour sélectionner le contrôle Flex Button. Le contrôle Button utilise les événements mouseUp et mouseDown pour signaler que l’utilisateur est intervenu sur le contrôle. Le contrôle Scroller utilise les événements mouseMove et mouseUp pour indiquer que l’utilisateur défile dans l’écran. Paul Trani, fameux développeur Adobe, explique la gestion des événements tactiles et gestuels dans le document Touch Events and Gesture on Mobile. Contrôle des événements générés par AIR La propriété flash.ui.Multitouch.inputMode contrôle les événements générés par AIR et Flash Player. La propriété flash.ui.Multitouch.inputMode peut posséder l’une des valeurs suivantes :
Comme le montre la liste, quelle que soit la valeur paramétrée de la propriété flash.ui.Multitouch.inputMode, AIR envoie toujours les événements de souris. Par conséquent, les composants Flex peuvent toujours répondre aux interactions de l’utilisateurs réalisées à l’aide d’un écran tactile. Flex vous permet d’utiliser n’importe quelle valeur pour la propriété flash.ui.Multitouch.inputMode dans votre application. Par conséquent, même si les composants Flex ne répondent pas aux événements tactiles ni de mouvement, vous pouvez ajouter une fonctionnalité à votre application pour répondre à tout événement. Par exemple, vous pouvez ajouter un gestionnaire d’événement au contrôle Button afin de gérer les événements tactiles, tels que touchTap, touchOver et touchMove. Le Guide du développeur ActionScript 3.0 présente une vue d’ensemble de la gestion de la saisie utilisateur sur différents périphériques et de l’utilisation de la saisie tactile, tactile multipoint et basée sur le mouvement. Pour plus de détails, voir:
• Saisie tactile, multitouch et gestes
Création d’un conteneur d’application mobile La première balise d’une application mobile est en général l’une des suivantes :
• La balise <s:TabbedViewNavigatorApplication> définit une application mobile comprenant plusieurs sections.
Application, même pour les téléphones. Toutefois, le conteneur Spark Application n’inclut pas de prise en charge pour la navigation entre vues, la persistance des données ni les boutons Retour et Menu du périphérique. Pour plus d’informations, voir « Différences entre les conteneurs d’application mobile et le conteneur d’application Spark » à la page 28. Les conteneurs d’application mobile présentent les caractéristiques suivantes par défaut : Caractéristiques
Présentation des enfants
Différences entre les conteneurs d’application mobile et le conteneur d’application Spark Les conteneurs d’application mobile Spark présentent la plupart des mêmes fonctionnalités que le conteneur de l’application Spark. Par exemple, vous appliquez des styles aux conteneurs d’application mobile de la même manière que vous les appliquez au conteneur Spark Application. Les conteneurs d’application mobile Spark présentent plusieurs caractéristiques qui diffèrent de celles du conteneur Spark Application :
Prise en charge du stockage des données sur un disque et de leur téléchargement à partir d’un disque. La persistance permet aux utilisateurs d’interrompre une application mobile, par exemple pour répondre à un appel téléphonique, puis de restaurer l’état de l’application à la fin de l’appel.
Le conteneur ViewNavigatorApplication crée automatiquement un seul conteneur ViewNavigator afin de contrôler la navigation entre les vues. Le conteneur TabbedViewNavigatorApplication crée automatiquement un conteneur TabbedViewNavigator individuel pour contrôler la navigation entre les sections.
Lorsque l’utilisateur appuie sur le bouton Retour, l’application revient à la vue précédente de la pile. Lorsque l’utilisateur appuie sur le bouton Menu, le conteneur ViewMenu de la vue actuelle apparaît, s’il est défini. Pour plus d’informations sur le conteneur Spark Application, voir A propos du conteneur Application.
Le conteneur Spark Application constitue une classe de base pour les conteneurs ViewNavigatorApplication et TabbedViewNavigatorApplication. S’il est utilisé avec le thème Spark, le conteneur Spark Application prend en charge un preloader d’application pour indiquer l’avancement du téléchargement et de l’initialisation du fichier SWF d’une application. S’il est utilisé avec le thème Mobile, vous pouvez afficher un écran de démarrage à la place. L’écran de démarrage apparaît au cours du démarrage de l’application. Pour configurer l’écran de démarrage, vous utilisez les propriétés splashScreenImage, splashScreenScaleMode et splashScreenMinimumDisplayTime de la classe d’application. L’exemple utilise un écran de démarrage au format Letterbox dans une application mobile :
Le blogueur Joseph Labrecque a communiqué sur AIR pour Android Splash Screen avec Flex 4.5. Le blogueur Brent Arnold a créé une vidéo sur l’ajout d’un écran de démarrage pour une application Android.
Une application mobile définit en général plusieurs écrans, ou vues. Lorsque les utilisateurs naviguent dans l’application, ils passent d’une vue à l’autre. Rendez la navigation intuitive pour l’utilisateur de l’application. Ainsi, lorsque l’utilisateur passe d’une vue à une autre, il s’attend à pouvoir revenir à la vue précédente. L’application peut définir un bouton Accueil ou d’autres aides à la navigation de niveau supérieur qui permettent à l’utilisateur d’accéder à différents emplacements de l’application depuis tout autre emplacement. Pour définir les vues d’une application mobile, utilisez le conteneur View. Pour contrôler la navigation entre les vues d’une application mobile, utilisez le conteneur ViewNavigator. Regardez cette vidéo de Peter Elst pour savoir comment créer une application gérée par les données avec plusieurs vues.
Utilisez la méthode ViewNavigator.pushView() pour placer une nouvelle vue sur la pile. Accédez au ViewNavigator à l’aide de la propriété ViewNavigatorApplication.navigator. La mise en place d’une vue modifie l’affichage de l’application en passant à la nouvelle vue. La méthode pushView() présente la syntaxe suivante : pushView(viewClass:Class, data:Object = null, context:Object = null, transition:spark.transitions:ViewTransitionBase = null):void
Utilisation de l’argument data pour faire passer un seul objet Utilisez l’argument data pour faire passer un seul objet contenant les éventuelles données requises par la nouvelle vue. La vue peut alors accéder à l’objet en utilisant la propriété View.data, comme le montre l’exemple suivant : <?xml version="1.0" encoding="utf-8"?> <!-- containers\mobile\views\EmployeeView.mxml --> <s:View xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" title="Employee View"> View » à la page 40. Communication de données à la première vue d’une application La propriété ViewNavigatorApplication.firstView et la propriété ViewNavigator.firstView définissent la première vue dans une application. Pour communiquer des données à la première vue, utilisez la propriété ViewNavigatorApplication.firstViewData ou la propriété ViewNavigator.firstViewData.
Dans l’exemple suivant, vous définissez une application mobile en utilisant le conteneur ViewNavigatorApplication. Le conteneur ViewNavigatorApplication crée automatiquement une seule instance de la classe ViewNavigator que vous utilisez pour naviguer parmi les vues définies par l’application.
Accueil élimine toutes les vues de la pile et revient à la première vue. La figure suivante illustre cette application :
à communiquer à la nouvelle vue. Dans cet exemple, vous communiquez l’objet de données correspondant à l’élément actuellement sélectionnée dans le contrôle List. L’exemple suivant illustre la définition de la vue EmployeeView :
La blogueuse Holly Schinsky a communiqué sur la persistance et la gestion des données dans la gestion des données mobiles de Flex 4.5.
La méthode ViewNavigator.popView() retourne le contrôle de la vue actuelle à la vue précédente de la pile. Lorsque la méthode popView() s’exécute, la vue actuelle est détruite et la vue précédente sur la pile est rétablie. La restauration du conteneur View précédent implique la réinitialisation de sa propriété data dans la pile, Pour obtenir une description complète du cycle de vie d’une vue, y compris des événements envoyés au cours de sa création, voir « Cycle de vie des conteneurs Spark ViewNavigator et View » à la page 40. La nouvelle vue est restaurée avec l’objet data original correspondant au moment où elle a été désactivée. Par conséquent, vous n’utilisez pas généralement l’objet data original pour transmettre en retour les données de l’ancienne vue à la nouvelle vue. A la place, remplacez la méthode createReturnObject() de l’ancienne vue. La méthode createReturnObject() retourne un seul objet. Retour du type d’objet L’objet retourné par la méthode createReturnObject() est écrit dans la propriété ViewNavigator.poppedViewReturnedObject. Le type de données de la propriété poppedViewReturnedObject est ViewReturnObject. ViewReturnObject définit deux propriétés, context et object. La propriété object contient l’objet retourné par la méthode createReturnObject(). La propriété context contient la valeur de l’argument context qui a été transmis à la vue lorsque la vue a été placée sur la pile de navigation à l’aide de pushView(). La propriété poppedViewReturnedObject est garantie comme étant définie dans la nouvelle vue avant que la vue ne reçoive l’événement ajout. Si la propriété poppedViewReturnedObject.object est nulle, aucune donnée n’a été retournée. Exemple : Communication de données à une vue L’exemple suivant, SelectFont.mxml, présente une vue qui vous permet de définir une taille de police. Le remplacement de la méthode createReturnObject() retourne la valeur sous forme de numéro. Le champ fontSize de la propriété data transmise à partir de la vue précédente définit la valeur initiale du contrôle TextInput :
• Un gestionnaire d’événement pour l’événement ajout qui détermine pour la première fois si la propriété View.data est nulle. Si la valeur est null, le gestionnaire d’événement ajoute le champ data.fontSize à la
Si la propriété data n’a pas la valeur null, le gestionnaire d’événement définit la taille de la police sur la valeur figurant dans le champ data.fontSize.
Vous pouvez définir une classe d’habillages personnalisée pour une application mobile. Si l’habillage prend en charge la présentation portrait et paysage, votre habillage doit gérer les états des vues portrait et paysage. Vous pouvez configurer une application de telle sorte qu’elle ne modifie pas l’orientation de la présentation lorsque l’utilisateur fait pivoter le périphérique. Pour ce faire, modifiez le fichier XML de l’application, celui qui se termine par -app.xml, afin de définir les propriétés suivantes :
Par défaut, la barre d’onglets et le contrôle ActionBar d’une application mobile définissent une zone qui ne peut pas être utilisée par les vues de l’application. Cela signifie que votre contenu ne peut pas utiliser toute la taille de l’écran du périphérique mobile. Vous pouvez toutefois utiliser la propriété ViewNavigator.overlayControls pour modifier la présentation par défaut de ces composants. Lorsque vous définissez la propriété overlayControls sur true, la zone de contenu de l’application couvre toute la largeur et toute la hauteur de l’écran. Le contrôle ActionBar et la barre d’onglets chevauchent la zone de contenu avec une valeur alpha qui les rend partiellement transparents.
Flex procède à une série d’opérations lorsque vous passez d’une vue à une autre dans une application mobile. A différents stades du processus de changement de vue, Flex envoie des événements. Vous pouvez surveiller ces événements pour effectuer des actions au cours du processus. Vous pouvez par exemple utiliser l’événement suppression pour annuler le passage d’une vue à une autre.
TabbedMobileNavigator. Le conteneur TabbedViewNavigator crée une barre d’onglets pour prendre en charge la navigation entre les sections de l’application.
ViewNavigator définit la première vue qui apparaît lorsque vous accédez à la section: <?xml version="1.0" encoding="utf-8"?> <!-- containers\mobile\SparkMultipleSections.mxml --> <s:TabbedViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark"> retourne le contrôle vers la vue précédente sur la pile du conteneur ViewNavigator actuel. Le changement de vue n’altère pas la section actuelle. Vous n’avez pas à ajouter une logique particulière à l’application pour la navigation dans les sections. Le conteneur TabbedViewNavigator crée automatiquement une barre d’onglets au bas de l’application afin de contrôler la navigation entre les sections. Même si cela n’est pas obligatoire, vous pouvez ajouter un contrôle programmatique de la section actuelle. Pour modifier les sections par programmation, définissez la propriété TabbedViewNavigator.selectedIndex sur l’index de la section désirée. Les index des sections sont de base 0, c’est-à-dire que la première section de l’application est à l’index 0, la deuxième à l’index 1, etc. Brent Arnold, expert Flex certifié par Adobe, a conçu une vidéo concernant l’utilisation d’une pile de navigation ViewNavigator.
Lorsque la section change, le conteneur TabbedViewNavigator envoie les événements suivants :
Un contrôle ActionBar est associé à un conteneur ViewNavigator. Par conséquent, vous pouvez configurer le contrôle ActionBar pour chaque section lorsque vous définissez le conteneur ViewNavigator de la section. Dans l’exemple suivant, vous configurez le contrôle ActionBar séparément pour chaque conteneur ViewNavigator qui définit les trois sections différentes de l’application :
Il est également possible de définir l’ActionBar dans chaque vue de l’application. De cette manière, chaque vue utilise le même contenu ActionBar, où que vous l’utilisiez dans l’application.
Masquage du contrôle de la barre d’onglets dans une vue N’importe quelle vue peut masquer la barre d’onglets si vous définissez la propriété View.tabBarVisible sur false. Par défaut, la propriété tabBarVisible a la valeur true pour afficher la barre d’onglets. Vous pouvez également faire appel aux méthodes TabbedViewNavigator.hideTabBar() et TabbedViewNavigator.showTabBar() pour contrôler la visibilité.
Vous pouvez modifier l’effet par défaut de la barre d’onglets pour un effet d’affichage ou de masquage en remplaçant les méthodes TabbedViewNavigator.createTabBarHideEffect() et TabbedViewNavigator.createTabBarShowEffect(). Après avoir masqué la barre d’onglets, pensez à définir les propriétés visible et includeInLayout de la barre d’onglets sur false.
Configuration du contrôle ActionBar Le conteneur ViewNavigator définit le contrôle ActionBar. Le contrôle ActionBar fournit une zone standard pour un titre et pour les contrôles de navigation et d’action. Il vous permet de définir des contrôles globaux auxquels les utilisateurs peuvent accéder en tout point de l’application ou dans une vue spécifique. Vous pouvez par exemple utiliser le contrôle ActionBar pour ajouter un bouton d’accueil, un bouton de recherche ou d’autres options. Pour une application mobile disposant d’une seule section, ce qui signifie un seul conteneur ViewNavigator, toutes les vues partagent la même barre d’action. Pour une application mobile comprenant plusieurs sections, et par conséquent, plusieurs conteneurs ViewNavigator, chaque section définit sa propre barre d’action. Utilisez le contrôle ActionBar pour définir la zone de la barre d’action. Le contrôle ActionBar définit trois zones distinctes, comme le montre la figure suivante :
Utilisez la propriété navigationContent pour définir les composants qui apparaissent dans la zone de navigation. Utilisez la propriété navigationLayout pour définir la présentation de la zone de navigation.
Contient soit une chaîne contenant le texte du titre, soit des composants. Si vous spécifiez des composants, vous ne pouvez pas spécifier une chaîne de titre. Utilisez la propriété title pour spécifier la chaîne qui doit apparaître dans la zone de titre. Utilisez la propriété titleContent pour définir les composants qui figurent dans la zone de titre. Utilisez la propriété titleLayout pour définir la présentation de la zone de titre. Si vous spécifiez une valeur pour la propriété titleContent, l’habillage ActionBar ignore la propriété title.
Utilisez la propriété actionContent pour définir les composants qui apparaissent dans la zone d’action. Utilisez la propriété actionLayout pour définir la présentation de la zone d’action. Même si Adobe recommande d’utiliser les zones de navigation, de titre et d’action décrites, il n’existe aucune restriction sur le type de composant que vous placez dans ces zones. Définition de propriétés ActionBar dans le conteneur ViewNavigatorApplication, ViewNavigator ou View Vous pouvez définir les propriétés qui définissent le contenu du contrôle ActionBar dans le conteneur ViewNavigatorApplication, dans le conteneur ViewNavigator ou dans des conteneurs View individuels. Le conteneur View possède la priorité la plus élevée, suivi du conteneur ViewNavigator, puis du conteneur ViewNavigatorApplication. Par conséquent, les propriétés que vous définissez dans le conteneur ViewNavigatorApplication s’appliquent à l’application entière, mais vous pouvez les remplacer dans le conteneur ViewNavigator ou View. Remarque : un contrôle ActionBar est associé à un conteneur ViewNavigator, de sorte qu’il est spécifique à une seule section d’une application mobile. Vous ne pouvez donc pas configurer un contrôle ActionBar à partir des conteneurs TabbedViewNavigatorApplication et TabbedViewNavigator. Le blogueur Brent Arnold a créé un didacticiel vidéo concernant l’utilisation d’ActionBar.
L’exemple suivant présente le fichier de l’application principale d’une application mobile : <?xml version="1.0" encoding="utf-8"?> Dernière mise à jour le 8/7/2011
Dans la mesure où la vue Recherche ne remplace pas la zone de navigation du contrôle ActionBar, la zone de navigation affiche toujours le bouton Accueil.
Vous pouvez masquer le contrôle ActionBar dans une vue quelconque en définissant la propriété View.actionBarVisible sur false. Par défaut, la propriété actionBarVisible est true pour afficher le contrôle ActionBar. Utilisez la méthode ViewNavigator.hideActionbar() pour masquer le contrôle ActionBar pour toutes les vues contrôlées par le conteneur ViewNavigator, comme l’indique l’exemple suivant :
ViewNavigator.createActionBarShowEffect(). Après avoir affiché un effet qui masque le contrôle ActionBar, définissez ses propriétés visible et includeInLayout sur false afin qu’il ne soit plus inclus dans la présentation de la vue.
Considérations liées à l’utilisation des barres de défilement dans une application mobile Généralement, si le contenu occupe plus que la zone visible à l’écran, l’application affiche des barres de défilement. Utilisez le contrôle Scroller pour ajouter des barres de défilement dans votre application. Pour plus d’informations, voir Scrolling Spark containers. La zone active d’une barre de défilement est la zone de l’écran dans laquelle vous placez le curseur de la souris pour effectuer un défilement. Dans une application de bureau ou de navigateur, la zone active correspond à la zone visible de la barre de défilement. Dans une application mobile, les barres de défilement sont masquées même lorsque le contenu est plus important que la zone visible de l’écran. Le masquage des barres de défilement permet à l’application d’utiliser toute la largeur et toute la hauteur de l’écran. Une application mobile doit faire une distinction entre le moment où l’utilisateur agit sur un contrôle, par exemple en sélectionnant un contrôle Button, et le moment où l’utilisateur souhaite faire défiler l’affichage. Pour ce qui est des barres de défilement dans une application mobile, il faut garder à l’esprit que les composants Flex changent souvent d’apparence en réaction à une intervention de l’utilisateur. Ainsi, lorsque l’utilisateur appuie sur un contrôle Button, le bouton change d’aspect pour indiquer qu’il est sélectionné. Lorsque l’utilisateur relâche le bouton, celui-ci reprend l’aspect correspondant à l’état désélectionné. Toutefois, lors du défilement, si l’utilisateur touche l’écran au niveau du bouton, vous ne souhaitez pas que le bouton change d’aspect.
Evénements et barres de défilement Les composants Flex s’appuient sur les événements pour indiquer qu’une intervention de l’utilisateur s’est produite. En réponse à l’intervention de l’utilisateur, le composant peut changer d’apparence ou effectuer une autre action. Les développeurs d’application utilisent les événements pour gérer les interventions de l’utilisateur. Par exemple, vous utilisez généralement l’événement click du contrôle Button pour exécuter un gestionnaire d’événement en réponse à la sélection du bouton par l’utilisateur. Utilisez l’événement change du contrôle List pour exécuter un gestionnaire d’événement lorsque l’utilisateur sélectionne un élément dans la liste. Le mécanisme de défilement Flex repose sur l’événement mouseDown. Cela signifie que le mécanisme de défilement écoute les événements mouseDown pour déterminer si une opération de défilement doit être lancée. Interprétation d’un geste utilisateur en tant qu’opération de défilement Par exemple, une application est composée de plusieurs contrôles Button dans un conteneur prenant en charge le défilement : 1 Utilisez votre doigt pour appuyer sur un contrôle Button. Le bouton envoie un événement mouseDown. 2 Flex diffère la réponse à l’intervention de l’utilisateur pendant une durée prédéfinie. Le délai permet de garantir que
Si, au cours de cette période, vous déplacez votre doigt sur une distance supérieure à celle qui est prédéfinie, Flex interprète ce geste comme une action de défilement. La distance sur laquelle vous devez déplacer votre doigt pour que le geste soit interprété comme un défilement est d’environ 0,08 pouce. Cette distance correspond à environ 20 pixels sur un périphérique de 252 PPP. Comme vous avez déplacé votre doigt avant l’expiration du délai, le contrôle Button ne reconnaît jamais l’intervention. Le bouton n’envoie pas d’événement et ne change jamais d’aspect. 3 Une fois le délai écoulé, le contrôle Button reconnaît l’intervention de l’utilisateur. Le bouton change d’aspect pour
Utilisez la propriété touchDelay du contrôle pour configurer la durée de ce délai. La valeur par défaut est de 100 ms. Si vous définissez la propriété touchDelay sur 0, il n’y a pas de délai et le défilement est immédiatement déclenché. 4 Après l’expiration du délai et lorsque Flex a envoyé les événements de souris, vous déplacez votre doigt sur une
Dans ce cas, le bouton a changé d’aspect car le délai a expiré. Toutefois, lorsque vous déplacez votre doigt sur une distance supérieure à 20 pixels, même au-delà du délai, Flex interprète ce geste comme un mouvement de défilement. Remarque : les composants Flex prennent en charge de nombreux types d’événement en plus des événements de souris. Lorsque vous travaillez avec des composants, vous décidez de la manière dont votre application réagit à ces événements. Au moment de l’événement mouseDown, l’intention exacte de l’utilisateur est ambiguë. L’utilisateur pouvait avoir l’intention d’interagir avec le composant ou d’effectuer un défilement. En raison de cette ambiguité, Adobe recommande d’écouter les événements click ou mouseUp au lieu de l’événement mouseDown.
Lorsqu’un composant détecte un événement touchInteractionStart, il ne doit pas tenter de répondre au geste utilisateur. Par exemple, lorsqu’un contrôle Button détecte un événement touchInteractionStart, il désactive tous les indicateurs visuels qu’il a définis en fonction de l’événement mouseDown initial. Si un composant ne souhaite pas autoriser le défilement à commencer, le composant peut appeler la méthode preventDefault() dans le gestionnaire d’événement pour l’événement touchInteractionStarting. Pour signaler le début d’une opération de défilement, le composant qui envoie l’événement mouseDown, lequel envoie un événement touchInteractionStarting de propagation.
Le tableau suivant décrit la manière dont le défilement est géré en fonction de l’emplacement du point de contact initial : Elément sélectionné
Scroller gère le mouvement, de la même manière que dans le cas du composant Button normal.
Le conteneur ViewMenu définit un menu au bas d’un conteneur View dans une application mobile. Chaque conteneur View définit son propre menu spécifique à cette vue.
Le conteneur ViewMenu définit un menu avec une seule hiérarchie de boutons de menu. En d’autres termes, il ne permet pas de créer des menus comprenant des sous-menus. Les enfants du conteneur ViewMenu sont définis comme des contrôles ViewMenuItem. Chaque contrôle ViewMenuItem représente un seul bouton dans le menu. Holly Schinsky, experte Flex certifiée par Adobe, a publié un article sur son blog concernant l’utilisation des menus dans une application mobile Flex 4.5. Brent Arnold, expert Flex certifié par Adobe, a créé une vidéo sur la création d’un menu pour une application mobile Flex.
Ouvrez le menu en utilisant la clé de menu matérielle sur le périphérique mobile. Vous pouvez également l’ouvrir par programmation.
Pendant que le menu est ouvert, appuyez sur le bouton retour ou de menu du périphérique pour fermer le menu. Le menu se ferme également si vous appuyez sur l’écran en dehors du menu. Le caret est le bouton de menu qui est actuellement actif. Utilisez le contrôle à cinq directions du périphérique ou les touches directionnelles pour modifier le caret. Appuyez sur la touche Entrée du périphérique ou sur le contrôle à cinq directions pour sélectionner l’élément de caret et fermer le menu.
Utilisez la propriété View.viewMenuItems pour définir le menu pour une vue. La propriété View.viewMenuItems utilise un vecteur de contrôles ViewMenuItem, comme le montre l’exemple suivant : <?xml version="1.0" encoding="utf-8"?> <!-- components\mobile\views\ViewMenuHome.mxml --> <s:View xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" title="Home"> Remarquez que vous ne définissez pas explicitement le conteneur ViewMenu. Le conteneur View crée automatiquement une instance du conteneur ViewMenu pour contenir les contrôles ViewMenuItem. Utilisez le style icône ducontrôle de ViewMenuItem. Le contrôle ViewMenuItem définit la propriété de style icône que vous pouvez utiliser pour inclure une image. Vous pouvez utiliser le style icône avec ou sans la propriété label. Gestion de l’événement clic du contrôle ViewMenuItem Chaque contrôle de ViewMenuItem définit également un gestionnaire d’événement pour l’événement clic. Le contrôle ViewMenuItem envoie l’événement clic lorsque l’utilisateur sélectionne l’événement. Dans cet exemple, tous les éléments de menu utilisent le même gestionnaire d’événement. Vous pouvez toutefois choisir de définir un gestionnaire d’événement distinct pour chaque événement clic. Ouverture du contrôle ViewMenuItem par programmation Vous ouvrez le menu en utilisant la touche de menu matérielle de votre périphérique. Cette application définit également deux contrôles Button pour ouvrir et fermer le menu par programmation. Pour ouvrir le menu par programmation, définissez la propriété viewMenuOpen du conteneur d’application sur true. Pour fermer le menu, définissez la propriété sur false. La propriété viewMenuOpen est définie dans la classe ViewNavigatorApplicationBase, la classe de base des conteneurs ViewNavigatorApplication et TabbedViewNavigatorApplication.
Utilisez les habillages pour contrôler l’aspect des composants ViewMenu et ViewMenuItem. La classe d’habillages par défaut de ViewMenu est spark.skins.mobile.ViewMenuSkin. La classe d’habillages par défaut de ViewMenuItem est spark.skins.mobile.ViewMenuItemSkin.
Pour plus d’informations, voir « Notions de base sur l’habillage mobile » à la page 96.
La classe ViewMenuLayout définit la présentation du menu des vues. Le menu peut contenir plusieurs lignes selon le nombre d’éléments de menu. Règles de présentation de ViewMenuItem La propriété requestedMaxColumnCount de la classe ViewMenuLayout définit le nombre maximum d’éléments de menu sur une ligne. Par défaut, la propriété requestedMaxColumnCount est définie sur trois. Les règles suivantes définissent la manière dont la classe ViewMenuLayout réalise la présentation :
Si vous définissez quatre éléments de menu ou plus, soit davantage d’éléments de menu que ceux spécifiés par la propriété requestedMaxColumnCount, le conteneur ViewMenu crée plusieurs lignes.
Par exemple, la propriété requestedMaxColumnCount est définie sur la valeur par défaut de trois et vous définissez six éléments de menu. Le menu affiche deux lignes, chacune contenant trois éléments de menu.
Par exemple, la propriété requestedMaxColumnCount est définie sur la valeur par défaut de trois et vous définissez huit éléments de menu. Le menu affiche trois lignes. La première ligne contient deux éléments de menu. Les deuxième et troisième lignes contiennent chacune trois éléments. Création d’une présentation ViewMenuItem personnalisée La classe ViewMenuLayout contient des propriétés permettant de modifier les espaces entre les éléments de menu et le nombre par défaut d’éléments de menu figurant sur chaque ligne. Vous pouvez aussi créer votre propre présentation personnalisée pour le menu en créant votre classe de présentations. Par défaut, la classe spark.skins.mobile.ViewMenuSkin définit l’habillage du conteneur ViewMenu. Pour appliquer une classe ViewMenuLayout personnalisée au conteneur ViewMenu, définissez une nouvelle classe d’habillages pour le conteneur ViewMenu. La classe ViewMenuSkin par défaut inclut une définition pour un conteneur Group nommé contentGroup, comme le montre l’exemple suivant :
Par exemple, vous pouvez créer une instance du contrôle BusyIndicator dans un gestionnaire d’événement, éventuellement le gestionnaire d’événement qui démarre le processus de longue durée. Dans le gestionnaire d’événement, appelez la méthode addElement() pour ajouter le contrôle à un conteneur. Une fois le processus terminé, appelez removeElement() pour supprimer le contrôle BusyIndicator du conteneur. Une autre option consiste à utiliser la propriété visible du contrôle pour l’afficher et le masquer. Dans l’exemple suivant, vous ajoutez le contrôle BusyIndicator à la zone de barre de contrôle d’un conteneur Spark Panel dans un conteneur View :
Remarque : la définition de la propriété visible sur false masque le contrôle, mais celui-ci est encore inclus dans la présentation de son conteneur parent. Pour exclure le contrôle de la présentation, définissez les propriétés visible et includeInLayout sur false. Le contrôle Spark BusyIndicator ne prend pas en charge les habillages. Vous pouvez cependant utiliser les styles pour définir la couleur et l’intervalle de rotation du bouton fléché. Dans l’exemple précédent, vous définissez la couleur de l’indicateur à l’aide de la propriété symbolColor.
Les transitions entre vues Spark définissent la manière dont le passage d’un conteneur View à un autre apparaît à l’écran. Les transitions fonctionnent en appliquant une animation au cours du changement de vue. Utilisez les transitions pour créer des interfaces attrayantes pour vos applications mobiles. Par défaut, le conteneur View existant glisse hors de l’écran tandis que la nouvelle vue glisse sur l’écran. Vous pouvez aussi personnaliser ces transitions. Par exemple, votre application définit un formulaire dans le conteneur View qui présente seulement quelques champs, mais un conteneur View suivant présente des champs supplémentaires. Au lieu de glisser d’une vue à l’autre, vous pouvez utiliser une transition par retournement ou fondu-enchaîné. Flex fournit les classes suivantes de transition entre vues que vous pouvez utiliser lorsque vous modifiez les conteneurs View :
Holly Schinsky, experte Flex certifiée par Adobe, a publié un article sur son blog concernant l’utilisation des transitions entre les vues mobiles dans Flex 4.5. Brent Arnold, expert Flex certifié par Adobe, a conçu un didacticiel vidéo sur l’utilisation des transitions entre les vues mobiles.
Vous appliquez une transition lorsque vous modifiez le conteneur View actif. Dans la mesure où les transitions entre vues interviennent lorsque vous changez de conteneur View, vous les contrôlez par le biais du conteneur ViewNavigator. Par exemple, vous pouvez utiliser les méthodes suivantes de la classe ViewNavigator pour changer la vue actuelle :
ViewNavigator.defaultPushTransition. Par défaut, ces propriétés spécifient l’utilisation de la classe SlideViewTransition. L’exemple suivant montre le fichier d’application principal qui initialise les propriétés defaultPopTransition et defaultPushTransition de façon à utiliser une transition FlipViewTransition :
L’amortissement permet de créer un rythme plus réaliste d’accélération et de décélération. Vous pouvez aussi utiliser une classe d’amortissement pour créer un effet de rebond ou contrôler d’autres types de mouvement. Flex fournit les classes d’amortissement Spark dans le package spark.effects.easing. Ce package comprend des classes pour les types d’amortissement les plus courants, parmi lesquels Bounce, Linear et Sine (Rebond, Linéaire et Sinusoïdal). Pour plus d’informations sur l’utilisation de ces classes, voir Utilisation de classes d’amortissement Spark. L’exemple suivant présente une modification de l’application définie dans la section précédente. Cette version ajoute une classe d’amortissement Bounce à la transition FlipView : <?xml version="1.0" encoding="utf-8"?> <!-- containers\mobile\SparkViewTransEasier.mxml --> <s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" firstView="views.EmployeeMainViewTransEaser" creationComplete="creationCompleteHandler(event);"> Une transition entre vues s’effectue en deux phases principales : la phase de préparation et la phase d’exécution. Trois méthodes de la classe de transition définissent la phase de préparation. Ces méthodes sont appelées dans l’ordre suivant : 1 captureStartValues()
2 captureEndValues() La phase d’exécution débute lorsque le conteneur ViewNavigator appelle la méthode play() de la transition. A ce stade, la nouvelle vue a été créée et validée, et le contrôle ActionBar et la barre d’onglets ont été initialisés. La transition envoie un événement start et les éventuelles instances d’effet créées au cours de la phase de préparation sont maintenant invoquées en appelant la méthode play() de l’effet.
Après l’appel de la méthode transitionComplete(), le conteneur ViewNavigator finalise le processus de changement de vue et réinitialise la transition à son état non initialisé.
Une application destinée à un périphérique mobile est souvent interrompue par d’autres actions, telles qu’un texto, un appel téléphonique ou d’autres applications mobiles. Généralement, lorsqu’une application interrompue est relancée, l’utilisateur s’attend à ce que l’état précédent de l’application soit restauré. Le mécanisme de persistance permet au périphérique de restaurer l’application dans son état antérieur. La structure Flex fournit deux types de persistance pour les applications mobiles. La persistance en mémoire conserve les données de la vue lorsque l’utilisateur navigue dans l’application. La persistance de session restaure les données si l’utilisateur quitte l’application, puis la redémarre. La persistance de session est importante dans les applications mobiles car un système d’exploitation mobile peut fermer des applications à tout moment (par exemple, lorsque la mémoire est insuffisante). Le blogueur Steve Mathews a créé une entrée de cookbook sur la persistance des données simples dans une application mobile Flex 4.5. La blogueuse Holly Schinsky a communiqué sur la persistance et la gestion des données dans la gestion des données mobiles de Flex 4.5.
Les conteneurs de type Vue prennent en charge la persistance en mémoire à travers la propriété View.data. La propriété data d’une vue existante est automatiquement enregistrée lorsque la section sélectionnée change ou qu’une nouvelle vue est placée sur la pile ViewNavigator, provoquant l’élimination de la vue existante. La propriété data de la vue est restaurée lorsque le contrôle revient à la vue et que celle-ci est réinstanciée et activée. Par conséquent, la persistance en mémoire permet de conserver les informations d’état d’une vue au moment de l’exécution.
La persistance de session conserve des informations d’état relatives à l’application entre deux exécutions de l’application. Les conteneurs ViewNavigatorApplication et TabbedViewNavigatorApplication définissent la propriété persistNavigatorState pour l’implémentation de la persistance de session. Définissez persistNavigatorState sur true pour activer la persistance de session. Par défaut, persistNavigatorState est défini sur false. Si elle est activée, la persistance de session enregistre l’état de l’application sur disque en utilisant un objet partagé local, nommé FxAppCache. L’application peut également faire appel à des méthodes du spark.managers.PersistenceManager pour enregistrer des informations supplémentaires dans l’objet partagé local. Persistance de session ViewNavigator Le conteneur ViewNavigator prend en charge la persistance de session en enregistrant l’état de sa pile de vues sur disque lors de l’arrêt de l’application. Cet enregistrement inclut la propriété data de la vue actuelle.
Persistance de session TabbedViewNavigator Pour le conteneur TabbedViewNavigator, la persistance de session enregistre l’onglet actuellement sélectionné dans la barre d’onglets à la fermeture de l’application. L’onglet correspond au conteneur ViewNavigator et à la pile de vues qui compose l’onglet. L’enregistrement comprend la propriété data de la vue actuelle. Ainsi, lors du redémarrage de l’application, l’onglet actif et le conteneur ViewNavigator associé sont restaurés à l’état auquel ils se trouvaient lors de l’arrêt de l’application. Remarque : dans le cas d’une application définie par le conteneur TabbedViewNavigatorApplication, seule la pile du conteneur ViewNavigator actif est enregistrée. Ainsi, lors du redémarrage de l’application, seul l’état du conteneur ViewNavigator actif est restauré. Représentation des données de persistance de session Le mécanisme de persistance utilisé par Flex n’est ni chiffré ni protégé. Par conséquent, les données conservées sont stockées dans un format qui peut facilement être interprété par un autre programme ou un autre utilisateur. N’utilisez pas ce mécanisme de persistance pour conserver des informations sensibles telles que les identifiants de connexion. Vous avez la possibilité de rédiger votre propre gestionnaire de persistance qui vous offre une meilleure protection. Pour plus d’informations, voir « Personnalisation du mécanisme de persistance » à la page 70.
L’exemple suivant définit la propriété persistNavigatorState sur true d’une application, ce qui permet d’activer la persistance de session : <?xml version="1.0" encoding="utf-8"?> <!-- containers\mobile\SparkSingleSectionPersist.mxml --> <s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" firstView="views.EmployeeMainView" persistNavigatorState="true"> Dernière mise à jour le 8/7/2011
PersistenceManager, par exemple setProperty() et getProperty(), reposent sur la clé permettant d’accéder à la valeur associée dans l’objet partagé local. Vous pouvez utiliser la méthode setProperty() permettant d’enregistrer vos propres paires clé:valeur dans l’objet partagé local. La méthode setProperty() présente la signature suivante : setProperty(key:String, value:Object):void
Si la propriété persistNavigatorState est définie sur true, Flex réalise automatiquement la persistance de session. Il vous est tout de même possible de conserver des données d’application lorsque la propriété persistNavigatorState est définie sur false. Dans ce cas, implémentez votre propre mécanisme de persistance en faisant appel aux méthodes du PersistenceManager. Utilisez les méthodes setProperty() et getProperty() pour enregistrer et lire les informations de l’objet partagé local. Appelez la méthode load() pour initialiser le PersistenceManager. Appelez les méthodes save() pour enregistrer des données sur disque. Remarque : si la propriété persistNavigatorState est définie sur false, Flex n’enregistre pas automatiquement la pile de vues du conteneur ViewNavigator actif lors de l’arrêt de l’application, ni ne la restaure lors du démarrage de l’application.
Vous pouvez utiliser les événements suivants des conteneurs d’application mobile pour développer un mécanisme de persistance personnalisé :
Types de données intégrées pris en charge pour la persistance de session Le mécanisme de persistance prend automatiquement en charge tous les types de données intégrées, y compris : Number, String, Array, Vector, Object, uint, int et Boolean. Ces types de données sont enregistrées automatiquement par le mécanisme de persistance. Classes personnalisées prises en charge pour la persistance de session De nombreuses applications font appel à des classes personnalisées pour définir les données. Si une classe personnalisée contient des propriétés définies par des types de données intégrées, le mécanisme de persistance peut automatiquement enregistrer et charger la classe. Toutefois, vous devez enregistrer la classe à l’aide du mécanisme de persistance en appelant la méthode flash.net.registerClassAlias(). Généralement, vous appelez cette méthode dans l’événement preinitialize de l’application, avant que le stockage de persistance ne soit initialisé ou que des données y soient enregistrées. Si vous définissez une classe complexe, une qui utilise des types de données autres que ceux des données intégrées, vous devez convertir ce type de données en type pris en charge, par exemple, String. De même, si la classe définit des variables privées, celles-ci ne sont pas automatiquement conservées. Pour prendre en charge la classe complexe dans le mécanisme de persistance, la classe doit implémenter l’interface flash.utils.IExternalizable. Cette interface nécessite que la classe implémente les méthodes writeExternal() et readExternal() permettant d’enregistrer et de restaurer une instance de la classe.
PPP dans une application mobile Consignes pour la prise en charge de plusieurs tailles d’écran et valeurs PPP Pour développer une application indépendante de la plateforme, soyez conscient des différents périphériques de sortie. Les périphériques peuvent avoir une taille, ou résolution, d’écran différente et une valeur PPP, ou densité, différente. L’ingénieur Flex Jason SJ présente deux approches différentes en termes de création d’applications mobiles indépendantes de la résolution sur son blog. Terminologie La résolution correspond au nombre de pixels en hauteur fois le nombre de pixels en largeur : à savoir le nombre total de pixels qu’un périphérique prend en charge. La valeur PPP est le nombre de points par pouce carré : à savoir la densité de pixels sur l’écran d’un périphérique. Le terme PPP peut également être interprété comme le nombre de pixels par pouce. Prise en charge des valeurs PPP par Flex Les fonctionnalités Flex ci-dessous simplifient le processus de création d’applications indépendantes de la résolution et de la valeur PPP : Habillages Habillages prenant en charge les valeurs PPP pour les composants mobiles. Les habillages mobiles par défaut n’ont pas besoin de codage supplémentaire pour être adaptés à la résolution de la plupart des écrans.
Les habillages mobiles par défaut sont dépendants des PPP, avec ou sans redimensionnement des PPP. En conséquence, si vous n’utilisez pas de composants présentant des tailles statiques ou des habillages personnalisés, vous n’avez généralement pas besoin de définir la propriété applicationDPI. Présentations dynamiques Les présentations dynamiques vous permettent de surmonter les différences de résolution. Par exemple, la définition de la largeur d’un contrôle sur 100 % remplit toujours toute la largeur de l’écran, que sa résolution soit de 480x854 ou de 480x800. Définition de la propriété applicationDPI Lorsque vous créez des applications indépendantes de la densité, vous pouvez définir la valeur PPP cible sur la balise d’application racine. (Pour les applications mobiles, la balise racine est <s:ViewNavigatorApplication>, <s:TabbedViewNavigatorApplication> ou <s:Application>.) Vous définissez la valeur de la propriété applicationDPI sur 160, 240 ou 320, selon la résolution approximative de votre périphérique cible. Par exemple : <s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" firstView="views.DensityView1" applicationDPI="320">
Dans certains cas, un redimensionnement par un facteur non entier peut générer des artefacts indésirables en raison de l’interpolation, comme par exemple des lignes floues. Désactivation du redimensionnement des PPP Pour désactiver le redimensionnement des PPP pour l’application, ne définissez pas la valeur de la propriété applicationDPI. Compréhension des propriétés applicationDPI et runtimeDPI Le tableau suivant décrit deux propriétés de la classe Application qui interviennent lors de l’utilisation d’applications à des résolutions différentes :
Le facteur d’échelle est calculé en comparant la valeur de cette propriété à la propriété runtimeDPI. Ce facteur d’échelle est appliqué à toute l’application, y compris les éléments de préchargement, les pop-ups et tous les composants de l’image. Lorsqu’elle n’est pas spécifiée, cette propriété retourne la même valeur que la propriété runtimeDPI. Cette propriété ne peut pas être définie dans ActionScript ; elle ne peut être définie que dans MXML. Vous ne pouvez pas modifier la valeur de cette propriété au moment de l’exécution.
Retourne la valeur de la propriété Capabilities.screenDPI, arrondie à l’une des constantes définies par la classe DPIClassification. Cette propriété est en lecture seule.
Images Les images vectorielles sont redimensionnées en toute transparence pour correspondre à la résolution réelle
Texte La taille de la police de texte (pas le texte lui-même) est redimensionnée pour correspondre à la résolution. Structures Utilisez des présentations dynamiques pour vous assurer que l’application présente un aspect correct une
Redimensionnement N’utilisez pas les propriétés scaleX et scaleY sur l’objet Application. Lorsque vous définissez
Styles Vous pouvez utiliser des feuilles de style pour personnaliser les propriétés de style pour le système d’exploitation du périphérique cible et les paramètres PPP de l’application. Habillages Les habillages Flex du thème mobile utilisent la valeur PPP de l’application pour déterminer les éléments
Taille de l’application Ne définissez pas explicitement la hauteur et la largeur de l’application. De même, lors du calcul
Utilisez de préférence la propriété SystemManager.screen.
Au démarrage de votre application, celle-ci obtient la valeur de la propriété runtimeDPI auprès de la propriété Flash Player Capabilities.screenDPI. Cette propriété est mappée sur l’une des constantes définies par la classe DPIClassification. Par exemple, un Droid s’exécutant à 232 PPP est mappé sur la valeur PPP 240 de l’environnement d’exécution. Les valeurs PPP des périphériques ne correspondent pas toujours exactement aux constantes DPIClassification (160, 240 ou 320). Ils sont plutôt mappés sur ces classifications, en fonction d’un certain nombre de valeurs cibles. Les mappages sont les suivants : Constante DPIClassification
Choisir d’utiliser la mise à l’échelle automatique (en définissant la valeur de la propriété applicationDPI) revient à trouver un compromis entre la commodité et le niveau de précision en termes de pixels. Si vous définissez la propriété applicationDPI de sorte que l’application soit automatiquement mise à l’échelle, Flex utilise les habillages destinés à la propriété applicationDPI. Flex adapte ces habillages à la densité réelle du périphérique. D’autres éléments de l’application et les positions de la présentation sont également adaptés. Si vous souhaitez utiliser la mise à l’échelle automatique et que vous créez vos propres habillages ou éléments destinés à une valeur PPP unique, généralement vous effectuez les opérations suivantes :
• testez l’application sur des périphériques de différentes densités pour vérifier si l’apparence de l’application mise à l’échelle est acceptable sur chaque périphérique ; En particulier, vérifiez les périphériques qui entraînent un redimensionnement par un facteur non entier. Par exemple, si applicationDPI a la valeur 160, testez l’application sur des périphériques dotés d’une valeur PPP de 240. Si vous choisissez de ne pas utiliser la mise à l’échelle automatique (en ne définissant pas la propriété applicationDPI), obtenez la valeur applicationDPI. Utilisez cette propriété pour déterminer la classification PPP réelle du périphérique et adaptez l’application au moment de l’exécution en procédant comme suit :
La règle @media fait partie de la spécification CSS ; Flex développe cette règle pour inclure des propriétés supplémentaires : application-dpi et os-platform. Vous utilisez ces propriétés pour appliquer de manière sélective les styles en fonction de la valeur PPP de l’application et de la plateforme sur laquelle l’application est exécutée. L’exemple suivant définit la propriété de style par défaut du contrôle Spark Button, fontSize, sur 12. Si le périphérique utilise 240 PPP et s’exécute sur le système d’exploitation Android, la propriété fontSize est 10. <?xml version="1.0" encoding="utf-8"?> <!-- mobile_skins/MediaQueryValuesMain.mxml --> <s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" applicationDPI="320"> La propriété CSS os-platform est mise en correspondance avec la valeur de la propriété flash.system.Capabilities.version de Flash Player. Les valeurs valides pour la propriété CSS os-platform sont
Valeurs par défaut des propriétés application-dpi et os-platform Si vous ne définissez pas explicitement une expression contenant les propriétés application-dpi ou os-platform, toutes les expressions sont supposées correspondre. Opérateurs dans la règle @media La règle @media prend en charge les opérateurs courants “and” et “not”. Elle prend également en charge les listes séparées par des virgules. La séparation des expressions par une virgule implique une condition “or”. Lorsque vous utilisez l’opérateur “not”, le mot “not” doit être le premier mot-clé dans l’expression. Cet opérateur nie l’expression entière et pas seulement la propriété qui suit le mot “not”. En raison du bogue SDK-29191, l’opérateur “not” doit être suivi d’un type de support, tel que “all”, avant une ou plusieurs expressions. L’exemple suivant présente l’utilisation de ces opérateurs courants : <?xml version="1.0" encoding="utf-8"?> <!-- mobile_skins/MediaQueryValuesMain.mxml --> MultiDPIBitmapSource pour mapper différentes sources, selon la valeur de la propriété runtimeDPI. L’exemple suivant charge une image différente, selon les PPP :
Dernière mise à jour le 8/7/2011
Sélection des éléments d’habillage en fonction des PPP La logique dans les constructeurs des habillages mobiles par défaut choisit les éléments en fonction de la valeur de la propriété applicationDPI. Ces classes sélectionnent les éléments qui correspondent le mieux à la valeur PPP cible. Lorsque vous créez des habillages personnalisés qui fonctionnent avec et sans redimensionnement des PPP, utilisez la propriété applicationDPI et non pas la propriété runtimeDPI. Par exemple, la classe spark.skins.mobile.ButtonSkin utilise une instruction switch/case qui sélectionne les éléments FXG conçus pour des valeurs PPP particulières, comme ci-après :
Lors de la création d’habillages personnalisés, vous pouvez choisir d’ignorer le paramètre applicationDPI. Cela produit un habillage toujours redimensionné pour correspondre à la valeur PPP du périphérique cible, mais son aspect risque de ne pas être parfait si ses éléments ne sont pas spécifiquement conçus pour cette valeur PPP. Utilisation de la propriété applicationDPI dans CSS Utilisez la valeur de la propriété applicationDPI dans le sélecteur CSS @media pour personnaliser les styles utilisés par votre application pour périphérique mobile ou tablette sans créer d’habillages personnalisés. Pour plus d’informations, voir « Sélection de styles en fonction des PPP » à la page 75.
Pour demander manuellement à une application de périphérique mobile ou de tablette de sélectionner des éléments en fonction de la valeur PPP du périphérique cible, vous pouvez calculer le facteur d’échelle au moment de l’exécution. Pour ce faire, vous divisez la valeur de la propriété runtimeDPI par celle de la propriété de style applicationDPI : import mx.core.FlexGlobals; var curDensity:Number = FlexGlobals.topLevelApplication.runtimeDPI; var curAppDPI:Number = FlexGlobals.topLevelApplication.applicationDPI; var currentScalingFactor:Number = curDensity / curAppDPI;
Vous pouvez remplacer le comportement de redimensionnement par défaut d’une application en remplaçant les mappages PPP par défaut. Par exemple, si un périphérique signale à tort être doté de 240 PPP au lieu de 160 PPP, vous pouvez créer un mappage personnalisé qui recherche ce périphérique et le classe comme doté de 160 PPP. Pour remplacer la valeur PPP d’un périphérique particulier, pointez la propriété runtimeDPIProvider de la classe Application sur une sous-classe de la classe RuntimeDPIProvider. Dans votre sous-classe, remplacez la méthode Get de runtimeDPI et ajoutez une logique fournissant un mappage de valeur PPP personnalisé. N’ajoutez pas de dépendances aux autres classes dans la structure, telles que UIComponent. Cette sous-classe ne peut appeler que les API Player. L’exemple suivant définit un mappage de valeur PPP personnalisé pour un périphérique dont la propriété Capabilities.os correspond à “Mac 10.6.5” :
Certains contrôles de texte Spark ont été optimisés pour être utilisés dans les applications mobiles. Dans la mesure du possible, utilisez les contrôles de texte suivants :
• Spark TextInput • Spark Label (sauf si vous devez utiliser une police intégrée ; dans ce cas, utilisez les contrôles Spark TextArea ou TLF dans une application mobile D’une manière générale, évitez les contrôles de texte qui utilisent la structure TLF (Text Layout Framework) dans les applications mobiles. Les habillages mobiles des contrôles TextArea et TextInput sont optimisés pour les applications mobiles et, à la différence de leurs équivalents de type bureau, ils n’utilisent pas TLF. TLF est utilisé dans les applications de bureau pour fournir un ensemble riche de contrôles sur le rendu de texte. Evitez d’utiliser les contrôles de texte suivants dans une application mobile, car ils utilisent TLF et leurs habillages ne sont pas optimisés pour les applications mobiles :
• Spark RichEditableText Habillages pour les contrôles de texte mobiles Lorsque vous créez une application mobile, Flex applique automatiquement le thème mobile. En conséquence, les contrôles basés sur le texte utilisent les habillages mobiles. Ces habillages sont optimisés pour les applications mobiles, mais ils ne prennent pas en charge les fonctions suivantes des habillages Spark standard :
• Bidirectionnalité et mise en miroir • Polices CFF (Compact Font Format) pour l’intégration • RichEditableText pour le rendu de texte (à la place, les habillages mobiles utilisent StyleableTextField) Saisie à l’aide d’un clavier logiciel Lorsqu’un utilisateur met l’accent sur un contrôle de texte qui accepte la saisie, les périphériques mobiles sans clavier affichent un clavier logiciel à l’écran. Les développeurs ne contrôlent pas actuellement la configuration de ce clavier logiciel.
Le contrôle Spark Label est idéalement adapté aux lignes uniques de texte non modifiable et non sélectionnable.
D’une manière générale, utilisez de manière limitée les contrôles Spark Label dans les applications mobiles. N’utilisez pas le contrôle Spark Label dans des habillages ou des rendus d’élément. N’utilisez pas le contrôle Label lorsque vous intégrez des polices dans une application mobile, car le contrôle Label utilise CFF. Utilisez le contrôle TextArea à la place. Pour plus d’informations, voir « Intégration de polices dans une application mobile » à la page 93.
Le contrôle Spark TextArea est un contrôle de saisie de texte qui permet aux utilisateurs de saisir et de modifier plusieurs lignes de texte. Le contrôle Spark TextArea a été optimisé pour les applications mobiles. Dans une application mobile, le contrôle TextArea utilise la classe spark.skins.mobile.TextAreaSkin pour son habillage. Cet habillage utilise la classe StyleableTextField plutôt que la classe RichEditableText pour le rendu de texte. En conséquence, le contrôle TextArea ne prend pas en charge TLF. Il prend en charge uniquement un sous-ensemble de styles disponibles sur le contrôle TextArea avec l’habillage Spark de bureau. Dans la mesure où le contrôle TextArea ne prend pas en charge TLF, vous ne pouvez pas utiliser le contenu textFlow, content, ni les propriétés selectionHighlighting. En outre, vous ne pouvez pas utiliser les méthodes suivantes :
En conséquence, le contrôle TextInput ne prend pas en charge TLF. Il prend en charge uniquement un sous-ensemble de styles disponibles sur le contrôle TextInput avec l’habillage Spark de bureau. Dans certains cas (par exemple, lorsque vous souhaitez utiliser une police intégrée), remplacez un contrôle Label par un contrôle TextIntput. Pour que le contrôle TextInput se comporte davantage comme un contrôle Label, définissez les propriétés editable et selectable sur false. Vous pouvez également supprimer la bordure autour d’un contrôle TextInput en créant un habillage personnalisé. Pour plus d’informations, voir « Notions de base sur l’habillage mobile » à la page 96.
Essayez d’éviter d’utiliser les contrôles RichText et RichEditableText dans les applications mobiles. Ces contrôles ne possèdent pas d’habillage mobile et ne sont pas optimisés pour les applications mobiles. Si vous utilisez ces contrôles, vous utilisez TLF, ce qui exige une importante puissance de traitement.
Utilisez les équivalents Spark à la place.
Les styles pris en charge par la classe StyleableTextField déterminent les styles qui sont pris en charge par les contrôles de texte dans le thème mobile. Les styles suivants sont les seuls pris en charge par les classes TextInput et TextArea dans une application mobile :
Par exemple, la classe TextAreaSkin mobile définit la propriété textDisplay comme suit : textDisplay = StyleableTextField(createInFontContext(StyleableTextField));
La classe StyleableTextField est une sous-classe légère de la classe Flash TextField. Elle implémente l’interface IEditableText (laquelle constitue elle-même une extension de IDisplayText). La classe StyleableTextField n’implémente pas les interfaces IUIComponent ou ILayoutElement, de sorte qu’elle n’est pas utilisable directement dans MXML. Elle est conçue pour être utilisée dans les habillages ActionScript et les rendus d’élément ActionScript. Pour plus d’informations sur l’habillage des composants mobiles, voir « Notions de base sur l’habillage mobile » à la page 96. Pour plus d’informations à propos des rendus d’élément ActionScript, voir Création d’un rendu d’élément Spark dans ActionScript.
Vous pouvez utiliser des gestes tels que le glissement avec les contrôles de texte. L’exemple suivant écoute un événement de glissement et vous indique la direction dans laquelle le glissement a été effectué : <?xml version="1.0" encoding="utf-8"?> <!-- mobile_text/views/TextAreaEventsView.mxml --> <s:View xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" title="TextArea swipe event" viewActivate="view1_viewActivateHandler(event)"> Dernière mise à jour le 8/7/2011
La figure suivante montre une application qui utilise le clavier à l’écran :
Le blogueur Peter Elst a communiqué sur le contrôle du clavier programmable dans les applications Flex Mobile.
Le clavier à l’écran s’ouvre automatiquement lorsqu’un contrôle de saisie de texte est utilisé. les contrôles de saisie de texte comprennent TextInput et TextArea. Vous pouvez configurer d’autres types de contrôles pour ouvrir le clavier, tels que les contrôles Button ou ButtonBar. Pour ouvrir le clavier lorsqu’un contrôle autre qu’un contrôle de saisie de texte est activé, définissez la propriété needsSoftKeyboard du contrôle sur true. Tous les composants Flex héritent cette propriété de la classe InteractiveObject. Remarque : les contrôles de saisie de texte ouvrent toujours le clavier lorsqu’ils sont activés. Ils ignorent la propriété needsSoftKeyboard et sa définition est sans effet sur les contrôles de saisie de texte. Le clavier reste ouvert jusqu’à ce que les actions suivantes soient réalisées :
Si l’utilisateur passe à un autre contrôle de saisie de texte ou à un contrôle dont la propriété needsSoftKeyboard est définie sur true, le clavier reste ouvert.
Pour prendre en charge le clavier à l’écran, l’application peut effectuer les actions suivantes à l’ouverture du clavier :
Configuration du système pour le clavier à l’écran Le clavier à l’écran n’est pas pris en charge dans les applications qui s’exécutent en mode plein écran. Par conséquent, dans le fichier app.xml, assurez-vous que l’attribut <fullScreen> est défini sur false, la valeur par défaut. Assurez-vous que le mode de rendu de l’application est défini sur le mode du processeur. Le mode de rendu est contrôlé dans le fichier descripteur app.xml de l’application par l’attribut <renderMode>. Assurez-vous que l’attribut <renderMode> est défini sur cpu, la valeur par défaut, et non sur gpu. Remarque : l’attribut <renderMode> n’est pas inclus par défaut dans le fichier app.xml. Pour modifier son paramètre, ajoutez-le en tant qu’entrée dans l’attribut <initialWindow>. S’il n’est pas inclus dans le fichier app.xml, il a la valeur par défaut de cpu. Redimensionnement de l’application à l’ouverture du clavier à l’écran La propriété resizeForSoftKeyboard du conteneur Application détermine le comportement de redimensionnement de l’application. Si elle est définie sur true, l’application se redimensionne pour s’adapter à la zone disponible de l’écran lorsque le clavier s’ouvre. L’application reprend sa taille normale à la fermeture du clavier. L’exemple ci-dessous montre le fichier d’application principal pour une application qui prend en charge le redimensionnement de l’application en définissant la propriété resizeForSoftKeyboard sur true :
Défilement dans le conteneur parent à l’ouverture du clavier à l’écran Pour prendre en charge le défilement, groupez le conteneur parent des éventuels contrôles de saisie de texte dans un composant Scroller. Lorsqu’un composant qui ouvre le clavier est activé, le composant Scroller fait automatiquement défiler le composant dans la vue. Le composant peut aussi être l’enfant de plusieurs conteneurs imbriqués du composant Scroller. Le conteneur parent doit être un conteneur GroupBase ou SkinnableContainer ou une sous-classe de GroupBase ou de SkinnableContainer. Le composant activé doit implémenter l’interface IVisualElement et doit être activable. En enveloppant le conteneur parent dans un composant Scroller, vous pouvez faire défiler le conteneur pendant que le clavier est ouvert. Par exemple, un conteneur détient plusieurs contrôles de saisie de texte. Vous défilez alors d’un contrôle de saisie de texte à un autre pour entrer des données. Le clavier reste ouvert tant que vous sélectionnez un contrôle de saisie de texte ou jusqu’à ce que vous sélectionniez un composant dont la propriété needsSoftKeyboard est définie sur true. Lorsque le clavier se ferme, le conteneur parent peut être plus petit que l’espace disponible à l’écran. Si le conteneur est plus petit que l’espace disponible à l’écran, le composant Scroller rétablit les positions à 0, c’est-à-dire en haut du conteneur. L’exemple suivant présente un conteneur View contenant plusieurs contrôles TextInput et un composant Scroller : <?xml version="1.0" encoding="utf-8"?> <!-- containers\mobile\views\SparkMobileKeyboardHomeView.mxml --> <s:View xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" title="Compose Email"> Pour plus d’informations à propos du composant Scroller, voir Scrolling Spark containers.
Le tableau ci-dessous décrit les événements associés au clavier : Evénement
Dans un gestionnaire d’événement, utilisez la propriétésoftKeyboardRect de la classe flash.display.Stage pour déterminer la taille et l’emplacement du clavier à l’écran. Sur Android, le clavier à l’écran envoie les événements KEY_UP et KEY_DOWN lorsqu’il est utilisé par l’utilisateur. Sur iOS, les événements KEY_UP et KEY_DOWN ne sont pas envoyés. Vous pouvez à la place écouter l’événement CHANGE du contrôle de texte associé pour répondre à l’entrée clavier.
Lorsque vous compilez une application mobile avec des polices intégrées, Flex utilise par défaut des polices non CFF. Les polices CFF utilisent FTE. En général, évitez d’utiliser FTE dans une application mobile. Dans la mesure où le contrôle Label utilise FTE (et par conséquent, des polices CFF), utilisez les contrôles TextArea ou TextInput lors de l’intégration de polices dans une application mobile. Dans votre CSS, définissez embedAsCFF sur false, comme le montre l’exemple suivant : <?xml version="1.0" encoding="utf-8"?> <!-- mobile_text/Main.mxml --> <s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" firstView="views.EmbeddingFontsView"> Utilisation de texte HTML dans des contrôles mobiles Pour utiliser la propriété htmlText dans des contrôles de texte mobiles, accédez à la propriété sur le sous-contrôle StyleableTextField. L’exemple suivant crée un contrôle TextInput et TextArea et ajoute un marquage HTML au contenu : <?xml version="1.0" encoding="utf-8"?> <!-- mobile_text/HTMLTextView.mxml --> <s:View xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" title="HTMLText View" creationComplete="initView()"> Les habillages mobiles sont plus légers que leurs homologues de bureau. En conséquence, ils présentent de nombreuses différences, par exemple :
UIComponent, comparée à la classe SparkSkin qui étend la classe Skin.
ActionScript, les états doivent être implémentés dans le cadre de procédures.
• Les habillages mobiles sont disposés manuellement. Comme les habillages mobiles n’étendent pas Group, ils ne prennent pas en charge les présentations Spark. Par conséquent, leurs enfants sont positionnés manuellement dans ActionScript.
Outre les différences liées aux performances, Flash Builder utilise également les fichiers d’habillage mobile de manière différente. Cela se vérifie tout spécialement pour les thèmes mobiles utilisés pour les projets de la bibliothèque. Le blogueur Jeffry Houser explique comment régler ce problème.
Les habillages mobiles déclarent généralement une propriété publique hostComponent. Cette propriété n’est pas obligatoire, mais elle est recommandée. La propriété hostComponent doit être du même type que le composant qui utilise l’habillage. Par exemple, l’habillage ActionBarSkin déclare hostComponent comme étant du type ActionBar : public var hostComponent:ActionBar;
Comme avec les habillages de bureau, vous pouvez utiliser le composant hôte pour accéder aux propriétés et aux méthodes du composant auxquelles l’habillage est attaché. Vous pouvez par exemple accéder aux propriétés publiques du composant hôte ou ajouter un écouteur d’événement au composant hôte depuis l’intérieur de la classe d’habillages.
Les habillages mobiles prennent en charge un sous-ensemble des propriétés de style que leurs homologues de bureau prennent en charge. Le thème mobile définit cet ensemble de styles.
« Utilisation de texte dans une application mobile » à la page 86. Le thème mobile ne prend pas en charge les propriétés de style rollOverColor, cornerRadius ni dropShadowVisible.
En ce qui concerne les parties de l’habillage, les habillages mobiles doivent respecter les mêmes normes que les habillages de bureau. Si un composant comporte une partie d’habillage obligatoire, l’habillage mobile doit déclarer une propriété publique du type approprié.
En outre, le type StyleableTextField n’est pas un composant UIComponent et ne possède donc pas de propriété id. La partie iconDisplay ne prend pas en charge les styles, de sorte qu’elle ne définit pas de propriété id. Définition de styles à l’aide des fonctionnalités CSS avancées Si vous souhaitez définir des styles sur la partie habillage avec le sélecteur avancé CSS id, l’habillage doit également définir la propriété id de la partie habillage. Par exemple, la partie d’habillage d’ActionBartitleDisplay définit une propriété id, de sorte qu’elle peut être stylée à l’aide des fonctionnalités CSS avancées ; par exemple : @namespace s "library://ns.adobe.com/flex/spark"; s|ActionBar #titleDisplay { color:red; }
Le fichier de thème mobile.swc est inclus par défaut dans les projets mobiles Flash Builder, mais le fichier SWC ne figure pas dans l’Explorateur de packages. Lorsque vous créez un nouveau projet mobile dans Flash Builder, ce thème est appliqué par défaut. Modification du thème Pour modifier le thème, utilisez l’argument de compilateur theme pour spécifier le nouveau thème ; par exemple : -theme+=myThemes/NewMobileTheme.swc
L’ingénieur Flex Jason SJ présente de quelle façon créer et incruster un thème dans une application sur son blog.
La classe MobileSkin remplace le mécanisme d’états de la classe UIComponent et n’utilise pas l’implémentation des états d’affichage des applications de bureau. En conséquence, les habillages mobiles déclarent seulement les états d’habillage du composant hôte qui sont implémentés par l’habillage. Ils modifient l’état dans le cadre de procédures, en fonction seulement du nom de l’état. A l’opposé, les habillages de bureau doivent déclarer tous les états, qu’ils soient utilisés ou non. Les habillages de bureau utilisent également les classes dans le package mx.states.* pour modifier les états.
Propriété currentState L’aspect d’un habillage dépend de la valeur de la propriété currentState. Par exemple, dans la classe mobile ButtonSkin, la valeur de la propriété currentState détermine la classe FXG qui est utilisée comme classe limitrophe : if (currentState == "down") return downBorderSkin; else return upBorderSkin;
Les habillages mobiles utilisent généralement le FXG compilé pour leurs éléments graphiques. Les habillages destinés aux applications de bureau, en revanche, utilisent généralement des graphiques MXML pour une grande partie de leurs dessins. Graphiques bitmap intégrés Vous pouvez utiliser des graphiques bitmap intégrés dans vos classes, car ils se comportent correctement en général. Toutefois, le redimensionnement des images bitmap pour plusieurs densités d’écran pose parfois problème. Le redimensionnement peut être plus efficace si vous créez plusieurs éléments différents, un pour chaque densité d’écran. Graphiques dans le thème mobile par défaut Les habillages mobiles dans le thème mobile par défaut utilisent les graphiques FXG qui sont optimisés pour la valeur PPP du périphérique cible. Les habillages chargent les graphiques en fonction de la valeur de la propriété applicationDPI de l’application racine. Par exemple, lorsqu’un contrôle CheckBox est chargé sur un périphérique doté d’une valeur PPP de 320, la classe CheckBoxSkin utilise le graphique spark.skins.mobile320.assets.CheckBox_up.fxg pour la propriété upIconClass. Pour une valeur PPP de 160, elle utilise le graphique spark.skins.mobile160.assets.CheckBox_up.fxg. L’exemple de bureau suivant monte les différents graphiques utilisés par l’habillage CheckBox pour différentes valeurs PPP :
Le seul inconvénient tient au fait que vous ne pouvez pas utiliser de transitions qui nécessitent la recréation des pixels, telles que les transitions alpha. Pour plus d’informations, voir www.adobe.com/devnet/air/flex/articles/writing_multiscreen_air_apps.html.
Lors de la personnalisation d’habillages mobiles, vous créez une classe d’habillages mobile personnalisée. Dans certains cas, vous modifiez également les éléments utilisés par une classe d’habillages mobiles. Lorsque vous modifiez une classe d’habillages mobiles, vous pouvez modifier les interactions basées sur l’état, implémenter la prise en charge de nouveaux styles ou ajouter ou supprimer des composants enfants de l’habillage. En général, vous commencez par le code source d’un habillage existant et l’enregistrez en tant que nouvelle classe. Vous pouvez également modifier les éléments utilisés par les habillages mobiles pour modifier les propriétés visuelles de l’habillage, telles que sa taille, sa couleur ou ses dégradés et arrière-plans. Dans ce cas, vous modifiez également les éléments FXG utilisés par les habillages. Les fichiers *.fxg utilisés par les habillages mobiles sont stockés dans le répertoire spark/skins/mobile/assets. Toutes les propriétés visuelles des habillages mobiles ne sont pas définies dans des fichiers *.fxg. Par exemple, la couleur d’arrière-plan de l’habillage Button est définie par la propriété de style chromeColor dans la classe ButtonSkin. Elle n’est pas définie dans un élément FXG. Dans ce cas, vous modifieriez la classe d’habillage pour changer la couleur d’arrière-plan. L’ingénieur Flex Jason SJ présente de quelle façon créer des habillages pour les applications mobiles sur son blog.
Lors de la création d’une classe d’habillages mobiles personnalisée, la solution la plus simple consiste à utiliser comme base une classe d’habillages mobiles existante. Modifiez ensuite cette classe et utilisez-la comme un habillage personnalisé. Pour créer une classe d’habillages personnalisés : 1 Créez un répertoire dans votre projet (par exemple, customSkins). Ce répertoire correspond au nom du package de
2 Créez une classe d’habillages personnalisés dans le nouveau répertoire. Donnez à cette nouvelle classe le nom de
3 Copiez le contenu de la classe d’habillages que vous utilisez comme base pour la nouvelle classe. Par exemple, si
4 Modifiez la nouvelle classe. Par exemple, apportez les modifications minimales suivantes à la classe
} private static var colorMatrix:Matrix = new Matrix(); private static const CHROME_COLOR_ALPHAS:Array = [1, 1]; private static const CHROME_COLOR_RATIOS:Array = [0, 127.5]; override protected function drawBackground(unscaledWidth:Number, unscaledHeight:Number):void { super.drawBackground(unscaledWidth, unscaledHeight); var chromeColor:uint = getStyle("chromeColor"); /*
Ces méthodes protégées héritées définissent les enfants et les membres d’un habillage et l’aident à interagir avec d’autres composants de la liste d’affichage.
Pour plus d’informations à propos de l’utilisation de ces méthodes, voir Implémentation du composant.
VerticalLayout. Présentez manuellement les enfants de l’habillage dans une méthode telle que layoutContents().
Lorsque vous créez un habillage personnalisé, vous pouvez procéder d’une des façons suivantes :
TabbedViewNavigator ne possèdent pas de versions pour des valeurs PPP spécifiques, si bien que tous leurs éléments FXG sont stockés dans ce répertoire. Personnalisation d’un fichier FXG Vous pouvez ouvrir un fichier FXG existant et le personnaliser, ou en créer un et l’exporter à partir d’un éditeur graphique tel qu’Adobe Illustrator. Après avoir modifié le fichier FXG, appliquez-le à votre classe d’habillages. Pour créer un habillage personnalisé en modifiant un fichier FXG : 1 Créez une classe d’habillages personnalisés et placez-la dans le répertoire customSkins, comme cela est décrit dans
2 Créez un sous-répertoire sous le répertoire customSkins, par exemple assets. La création d’un sous-répertoire est
3 Créez un fichier dans le répertoire assets et copiez à l’intérieur le contenu d’un fichier FXG existant. Par exemple,
4 Modifiez le nouveau fichier FXG. Par exemple, remplacez la logique permettant de tracer un symbole de coche par
<?xml version='1.0' encoding='UTF-8'?> <!-- mobile_skins/customSkins/assets/CustomCheckBox_upSymbol.fxg --> Dans la mesure où les fichiers FXG sont écrits en langage XML, il peut être difficile de visualiser l’aspect final du produit. Vous pouvez écrire une application Flex qui importe et rend les fichiers FXG en les ajoutant en tant que composants, puis en les enveloppant dans un conteneur Spark. Pour ajouter des fichiers FXG en tant que composants à votre application, ajoutez l’emplacement des fichiers source au chemin source de votre application. Par exemple, pour monter des éléments FXG mobiles dans une application Web, ajoutez le thème mobile à votre chemin source. Le compilateur peut alors trouver les fichiers FXG. L’exemple de bureau ci-dessous restitue les différents éléments FXG du composant CheckBox lorsque vous l’utilisez dans une application mobile. Ajoutez le répertoire frameworks\projects\mobiletheme\src\ à l’argument source-path du compilateur lorsque vous compilez cet exemple.
ISimpleStyleClient et IEditableText.
TLF dans les habillages mobiles Pour des raisons de performances, essayez d’éviter les classes qui utilisent TLF dans les habillages mobiles. Dans certains cas, comme par exemple avec le composant Spark Label, vous pouvez utiliser des classes qui utilisent FTE. Utilisation de htmlText dans les habillages mobiles Vous pouvez définir la propriété htmlText directement sur une instance de la classe StyleableTextField. Pour plus d’informations, voir « Utilisation de texte HTML dans des contrôles mobiles » à la page 94. Définition de StyleTextField Vous définissez généralement l’objet StyleableTextField dans la méthode createChildren() de l’habillage mobile. Pour instancier un objet StyleableTextField dans un habillage mobile, utilisez la méthode UIComponent.createInFontContext(), comme le montre l’exemple suivant : import spark.components.supportClasses.StyleableTextField; textDisplay = StyleableTextField(createInFontContext(StyleableTextField));
Dans la méthode createChildren(), vous appelez généralement la méthode getStyle() sur les propriétés de style que vous voulez que votre objet StyleableTextField prenne en charge dans l’habillage. Vous définissez également des propriétés sur l’habillage que vous voulez que l’objet StyleableTextField utilise ; par exemple : textDisplay.multiline = true; textDisplay.editable = true; textDisplay.lineBreak = getStyle("lineBreak");
Ajout de StyleableTextField à la liste d’affichage Après avoir défini l’objet StyleableTextField, vous l’ajoutez à la liste d’affichage à l’aide de la méthode addElement() : addElement(textDisplay);
Gestes avec du texte Les gestes de toucher-glisser sélectionnent toujours du texte (lorsque le texte est sélectionnable ou modifiable). Si le texte se trouve dans un composant Scroller, ce dernier n’effectue un défilement que si le geste est effectué en dehors du composant de texte. Ces gestes fonctionnent uniquement lorsque le texte est modifiable et sélectionnable. Modification du texte en texte modifiable et sélectionnable
La bidirectionnalité n’est pas prise en charge pour le texte dans la classe StyleableTextField.
Vous pouvez appliquer un habillage personnalisé à votre composant mobile de la même manière que vous appliquez un habillage personnalisé à un composant dans une application de bureau. Application d’un habillage dans ActionScript // Call the setStyle() method: myButton.setStyle("skinClass", "MyButtonSkin");
Dernière mise à jour le 8/7/2011
Vous pouvez spécifier s’il faut lancer l’application sur le bureau ou sur un périphérique connecté à votre ordinateur. Pour créer une configuration de lancement, procédez comme suit : 1 Sélectionnez Exécuter > Exécuter les configurations pour ouvrir la boîte de dialogue d’exécution des
Pour ouvrir la boîte de dialogue Configurations de débogage, sélectionner Exécuter > Configurations de débogage. Voir « Exécution et débogage d’une application mobile sur un périphérique » à la page 112. Vous pouvez également accéder à la commande Exécuter ou Déboguer les configurations dans la liste déroulante du bouton Exécuter ou Déboguer de la barre d’outils Flash Builder. 2 Développez le nœud des applications mobiles. Cliquez sur le bouton Crée une configuration de lancement dans la
3 Spécifiez une plateforme cible dans la liste déroulante. 4 Spécifiez une méthode de lancement :
Exécute l’application sur votre bureau à l’aide de AIR Debug Launcher (ADL), selon une configuration de périphérique que vous avez spécifiée. Cette méthode de lancement n’est pas une vraie émulation d’exécution de l’application sur un périphérique. Elle vous permet toutefois de voir la mise en forme de l’application et d’interagir avec l’application. Voir « Prévisualisation des applications avec ADL » à la page 112. Cliquez sur Configurer pour modifier les configurations du périphérique. Voir « Configuration des informations du périphérique pour un aperçu sur le bureau » à la page 112.
Installez et exécutez l’application sur le périphérique. Pour la plateforme Google Android, Flash Builder installe l’application sur votre périphérique et lance l’application. Flash Builder accède au périphérique connecté au port USB de l’ordinateur. Pour plus d’informations, voir « Exécution et débogage d’une application mobile sur un périphérique » à la page 112. Windows nécessite un pilote USB pour connecter un périphérique Android à l’ordinateur. Pour plus d’informations, voir « Installation de pilotes de périphérique USB pour les périphériques Android (Windows) » à la page 16. 5 Indiquez si vous souhaitez effacer les données de l’application à chaque lancement, le cas échéant.
Pour des tâches initiales de test ou de débogage, ou si vous ne possédez pas de périphérique mobile, Flash Builder vous permet d’exécuter et de déboguer les applications sur le bureau en utilisant AIR Debug Launcher (ADL). Avant d’exécuter ou de déboguer une application mobile pour la première fois, vous devez définir une configuration de lancement. Spécifiez la plateforme cible et Sur le bureau comme méthode de lancement. Voir « Gestion des configurations de lancement » à la page 111.
Les propriétés d’une configuration de périphérique déterminent la manière dont l’application apparaît dans ADL et dans le mode Création de Flash Builder. La fenêtre « Définition des configurations de périphériques » à la page 12 répertorie les configurations prises en charge. Les configurations des périphériques n’affectent pas l’aspect de l’application sur le périphérique.
Vous pouvez afficher votre application sur le bureau de développement ou afficher la présentation de l’application dans le mode Création de Flash Builder. Flash Builder utilise une densité d’écran de 240 PPP. L’aspect d’une application lors de sa prévisualisation diffère parfois de son aspect sur un périphérique qui prend en charge une densité de pixels différente.
Par exemple, pour émuler le bouton retour d’un périphérique, sélectionnez Périphérique > Retour. Sélectionnez Périphérique > Rotation gauche ou Périphérique > Rotation droite pour émuler la rotation du périphérique. Les options de rotation sont désactivées si vous n’avez pas sélectionné l’orientation automatique. Faites glisser le curseur dans une liste pour émuler le défilement de la liste sur un périphérique. Brent Arnold, expert Flex certifié par Adobe, a créé un didacticiel vidéo sur l’utilisation d’ADL pour obtenir un aperçu d’une application mobile sur le bureau.
Vous pouvez utiliser Flash Builder pour exécuter ou déboguer une application mobile à partir de votre bureau de développement ou d’un périphérique. Vous exécutez et déboguez les applications en fonction d’une configuration de lancement que vous définissez. Flash Builder partage la configuration de lancement entre l’exécution et le débogage de l’application. Lorsque vous utilisez Flash Builder pour déboguer une application sur un périphérique, Flash Builder installe une version de débogage de l’application sur le périphérique.
Pour plus d’informations, voir Gestion des configurations de lancement.
Sur un périphérique Android, le débogage requiert Android 2.2 ou version ultérieure. Vous pouvez effectuer le débogage dans l’un des scénarios suivants : Débogage via USB Pour déboguer une application via une connexion USB, connectez le périphérique à l’ordinateur
USB de l’ordinateur hôte au cours de la session de débogage complète. Débogage via un réseau Lorsque vous déboguez une application via le réseau, le périphérique et l’ordinateur hôte
Ethernet ou Bluetooth. Lors d’un débogage via un réseau, Flash Builder vous permet de déboguer une application qui est déjà installée sur un périphérique connecté, sans réinstaller l’application. Connectez le périphérique à l’ordinateur hôte via un port USB seulement au cours du groupement et au cours de l’installation de l’application sur le périphérique. Vous pouvez déconnecter le périphérique du port USB au cours du débogage. Toutefois, assurez-vous qu’il existe une connexion réseau entre le périphérique et l’ordinateur hôte tout au long de la session de débogage.
Avant de commencer le débogage via USB ou via un réseau, procédez comme suit : 1 (Windows) Vérifiez que le pilote USB approprié est installé.
SDK Android pour plus d’informations. Pour plus d’informations, voir « Installation de pilotes de périphérique USB pour les périphériques Android (Windows) » à la page 16. 2 Veillez à ce que le débogage USB soit activé sur le périphérique.
Lorsque vous exécutez ou déboguez une application mobile sur un périphérique, Flash Builder vérifie les périphériques connectés. Si Flash Builder détecte un seul périphérique connecté en ligne, il déploie et lance l’application. Dans le cas contraire, Flash Builder lance la boîte de dialogue Choisir un périphérique pour les scénarios suivants :
• Un seul périphérique déconnecté est trouvé ou sa version du système d’exploitation n’est pas prise en charge • Plusieurs périphériques connectés trouvés Si plusieurs périphériques sont détectés, la boîte de dialogue Choisir un périphérique répertorie les périphériques et leur état (en ligne ou hors connexion). Sélectionnez le périphérique à lancer. La boîte de dialogue Choisir un périphérique répertorie la version du système d’exploitation et la version d’AIR. Si Adobe AIR n’est pas installé sur le périphérique, Flash Builder l’installe automatiquement.
Préparation au débogage par le biais du réseau Avant de déboguer une application via le réseau, procédez comme suit : 1 Dans Windows, ouvrez le port 7935 (port du débogueur Flash Player) et le port 7 (port echo/ping).
Dans Windows Vista, désélectionnez la case Connexion réseau sans fil dans Pare-feu Windows > Modifier les paramètres > Avancés. 2 Sur le périphérique, configurez les paramètres sans fil dans Paramètres > Sans fil et Réseau.
Votre ordinateur hôte peut être connecté à plusieurs interfaces réseau simultanément. Toutefois, vous pouvez sélectionner une interface réseau principale à utiliser pour le débogage. Vous sélectionnez cette interface en ajoutant une adresse d’hôte dans le fichier de package Android APK. 1 Dans Flash Builder, ouvrez la fenêtre Préférences. 2 Sélectionnez Flash Builder > Plateformes cibles.
3 Sélectionnez l’interface réseau que vous souhaitez incorporer dans le package Android APK.
1 Connectez le périphérique par le biais d’un port USB ou via une connexion réseau. 2 Sélectionnez Exécuter > Déboguer les configurations pour mettre au point une configuration de lancement destinée
• Sélectionnez Déboguer via USB ou Déboguer par le biais du réseau. Lors du premier débogage de l’application via un réseau, vous pouvez installer l’application sur le périphérique via USB. Pour déboguer une application via connexion USB, connectez le périphérique à l’ordinateur hôte par le biais d’un port USB. Une fois l’application installé, si vous ne voulez pas vous connecter via USB pour des sessions de débogage suivantes, désélectionnez l’option Installer l’application sur le périphérique via USB.
Sélectionnez cette option pour conserver l’état de l’application pour chaque session de débogage. Cette option s’applique uniquement si l’occurrence sessionCachingEnabled est définie sur True dans votre application. 3 Sélectionnez Déboguer pour lancer une session de débogage.
Remarque : sur un réseau d’entreprise, le réseau d’un hôtel ou un autre réseau invité, parfois le périphérique ne peut pas se connecter à l’ordinateur, même si les deux sont sur le même réseau. Si vous effectuez un débogage via un réseau et que l’application a été installée auparavant sur le périphérique, démarrez le débogage en tapant l’adresse IP de l’ordinateur hôte. Brent Arnold, expert Flex certifié par Adobe, a conçu un didacticiel vidéo traitant du débogage d’une application sur USB pour un périphérique Android.
Débogage et applications groupées pour les périphériques (vidéo)
1 Connectez le périphérique Apple iOS à votre ordinateur de développement. 2 Lancez iTunes sur le périphérique iOS.
3 Dans Flash Builder, sélectionnez Exécuter > Configurations de débogage. 4 Dans la boîte de dialogue Configurations de débogage, procédez comme suit : a Sélectionnez l’application que vous souhaitez déboguer. b Sélectionnez la plateforme cible Apple iOS. c Sélectionnez la méthode de lancement Sur le périphérique. d Sélectionnez l’une des méthodes de groupement suivantes : Standard Utilisez cette méthode pour grouper une version de l’application de qualité analogue à une version
Toutefois, notez que cette méthode de création d’un fichier iOS de débogage (IPA) prend plusieurs minutes. Rapide Utilisez cette méthode pour créer rapidement un fichier IPA, puis exécutez et déboguez le fichier sur le
Store d’Apple. e Cliquez sur Configurer pour sélectionner le certificat de signature de code, le fichier de configuration et le
5 Sur le périphérique iOS, procédez comme suit : 1 (Facultatif) Dans iTunes, sélectionnez Fichier > Ajouter à la bibliothèque et recherchez dans l’arborescence le
2 Dans iTunes, sélectionnez Fichier > Ajouter à la bibliothèque et recherchez dans l’arborescence le fichier IPA de
3 Synchronisez le périphérique iOS avec iTunes en sélectionnant Fichier > Synchroniser. 4 Flash Builder essaie de se connecter à l’adresse d’hôte spécifiée dans le fichier IPA de débogage. Si l’application ne
IP de l’ordinateur hôte. Remarque : si vous n’avez pas modifié votre code ni vos ressources depuis la création du dernier package IPA de débogage, Flash Builder ignore le groupement et effectue le débogage de l’application. Cela signifie que vous pouvez lancer l’application installée sur le périphérique et cliquer sur Déboguer pour vous connecter au débogueur Flash Builder. De cette manière, vous pouvez effectuer plusieurs débogages successifs sans chaque fois grouper l’application.
Exportation de packages Android APK pour publication Avant d’exporter une application mobile, vous pouvez personnaliser les autorisations Android. Personnalisez manuellement les paramètres dans le fichier descripteur de l’application. Ces paramètres figurent dans le bloc <android> du fichier bin-debug/app_name-app.xml. Pour plus d’informations, voir Définition des propriétés d’une application AIR. Si vous exportez l’application pour l’installer ultérieurement sur un périphérique, installez le package d’application à l’aide des outils fournis par le fournisseur du système d’exploitation du périphérique. 1 Dans Flash Builder, sélectionnez Projet > Exporter vers une version validée. 2 Sélectionnez le projet et l’application que vous souhaitez exporter. 3 Sélectionnez les plateformes cibles et l’emplacement où exporter le projet. 4 Exportez et signez un package d’application spécifique à la plateforme.
Vous pouvez également exporter l’application en tant que fichier AIRI intermédiaire qui peut être signé ultérieurement. Si vous sélectionnez cette option, utilisez ultérieurement l’outil de ligne de commande AIR adt pour grouper le fichier AIRI en tant que fichier APK. Installez ensuite le fichier APK sur le périphérique à l’aide d’outils spécifiques à la plateforme (par exemple, avec le SDK Android, utilisez adb). Pour plus d’informations sur l’utilisation des outils de ligne de commande pour grouper votre application, voir « Développement et déploiement d’une application mobile sur la ligne de commande » à la page 120. 5 À partir de la page Paramètres de groupement, vous pouvez spécifier le certificat numérique, le contenu du
Signature numérique Cliquez sur l’onglet Signature numérique pour créer ou localiser un certificat numérique qui représente l’identité de l’éditeur de l’application. Vous pouvez aussi spécifier un mot de passe pour le certificat sélectionné.
Contenu du groupement (Facultatif) Cliquez sur l’onglet Contenu du groupement pour spécifier les fichiers à
6 Cliquez sur Terminer.
Builder installe l’application sur le périphérique. Brent Arnold, expert Flex certifié par Adobe, a créé un didacticiel vidéo sur l’exportation d’une application mobile pour la plateforme Android.
Vous pouvez créer et exporter un package iOS pour une distribution ponctuelle ou pour une soumission à l’App Store d’Apple. 1 Dans Flash Builder, sélectionnez Projet > Exporter vers une version validée. 2 Sélectionnez Apple iOS en tant que plateforme cible pour exporter et signer un package IPA.
3 Avant de sélectionner le type de package, assurez-vous d’avoir obtenu le certificat de signature de code, le mot de
Vous pouvez sélectionner l’un des types de packages suivants : Distribution ponctuelle pour une distribution limitée Pour une distribution limitée de l’application Package final de la version validée pour l’App Store d’Apple Pour soumettre l’application à l’App Store d’Apple.
5 Cliquez sur Terminer.
Serge Jespers, évangéliste Adobe, explique dans cette vidéo Adobe TV comment générer et exporter des applications iOS à l’aide de Flash Builder. Pour grouper le fichier IPA à l’aide de l’outil ADT (AIR Developer Tool), voir Packages iOS dans Création d’applications AIR.
Android. Lorsque vous installez un package sur un périphérique sur lequel Adobe AIR n’est pas installé, Flash Builder installe automatiquement AIR. 1 Connectez le périphérique Google Android à votre ordinateur de développement.
2 Dans Flash Builder, sélectionnez Exécuter > Exécuter les configurations. Dans la boîte de dialogue Exécuter les
3 Sélectionnez la méthode de configuration de lancement Sur le périphérique. 4 (Facultatif) Indiquez si vous souhaitez effacer les données de l’application à chaque lancement. 5 Cliquez sur Appliquer.
Brent Arnold, expert Flex certifié par Adobe, a conçu un didacticiel vidéo traitant de la configuration et de l’exécution de votre application sur un périphérique Android.
Avant de déployer une application sur un périphérique iOS, vous devez obtenir le certificat de signature de code, le mot de passe et le profil d’approvisionnement appropriés auprès d’Apple. Pour plus d’informations, voir « Connexion de périphériques Apple iOS » à la page 18. 1 Connectez le périphérique Apple iOS à votre ordinateur de développement. 2 Lancez iTunes sur votre ordinateur de développement.
(Unique Device Identifier) du périphérique iOS. 3 Dans Flash Builder, sélectionnez Exécuter > Exécuter les configurations. 4 Dans la boîte de dialogue Exécuter les configurations, procédez comme suit : a Sélectionnez l’application que vous souhaitez déployer. b Sélectionnez la plateforme cible Apple iOS. c Sélectionnez la méthode de lancement Sur le périphérique.
Standard Utilisez cette méthode pour grouper une version de l’application de qualité analogue à une version
La méthode standard de création de packages traduit le code en octets du fichier SWF de l’application en instructions ARM avant de créer le package. En raison de cette étape de traduction supplémentaire, cette méthode de création d’un fichier d’application (IPA) prend plusieurs minutes. La méthode standard prend plus de temps que la méthode rapide. Toutefois, l’application traitée de cette façon présente des performances dignes d’une version validée et peut donc être soumise à l’App Store d’Apple. Rapide Utilisez cette méthode pour créer rapidement un fichier IPA.
La méthode rapide de création de packages est plus rapide que la méthode standard. Toutefois, l’application traitée de cette façon présente des performances inférieures à celle d’une version validée et ne peut donc pas être soumise à l’App Store d’Apple. Remarque : entre les méthodes de création de packages standard et rapide, la différence réside dans l’environnement d’exécution ou le fonctionnement. e Cliquez sur Configurer pour sélectionner le certificat de signature de code, le fichier de configuration et le
5 Suivez les étapes ci-dessous sur votre ordinateur de développement : 1 Dans iTunes, sélectionnez Fichier > Ajouter à la bibliothèque et recherchez dans l’arborescence le fichier de
Vous pouvez également ajouter le fichier de profil d’approvisionnement mobile par glisser-déposer dans iTunes. 2 Dans iTunes, sélectionnez Fichier > Ajouter à la bibliothèque et recherchez dans l’arborescence le fichier IPA
Vous pouvez également ajouter le fichier IPA par glisser-déposer dans iTunes. 3 Synchronisez le périphérique iOS avec iTunes en sélectionnant Fichier > Synchroniser.
Holly Schinsky, experte Flex certifiée par Adobe, explique la procédure de développement iOS, y compris les étapes permettant d’obtenir des ID de périphérique, un certificat de signature de code, un mot de passe et un profil de configuration auprès d’Apple.
Vous pouvez créer une application mobile sans Flash Builder. Vous pouvez utiliser à la place les outils de ligne de commande mxmlc, adl et adt.
2 Testez l’application dans AIR Debug Launcher (ADL) à l’aide de l’outil adl. adl MyMobileApp-app.xml -profile mobileDevice
3 Groupez l’application à l’aide de l’outil adt. adt -package -target apk SIGN_OPTIONS MyMobileApp.apk MyMobileApp-app.xml MyMobileApp.swf
4 Déployez l’application sur votre périphérique mobile. Pour déployer l’application sur un périphérique Android,
• Supprime libs/air du chemin d’accès à la bibliothèque. Les applications mobiles ne prennent pas en charge les classes Window et WindowedApplication.
• Supprime les espaces de nom ns.adobe.com/flex/mx et www.adobe.com/2006/mxml. Les applications mobiles ne prennent pas en charge les composants MX (autres que les graphiques).
• Supprime les entrées RSL ; les applications mobiles ne prennent pas en charge les RSL. Le compilateur mxmlc génère un fichier SWF.
Débogage à l’aide de l’outil adl ADL imprime les instructions trace et les erreurs d’exécution au format de sortie standard, mais ne prend pas en charge les points d’arrêt ni d’autres fonctions de débogage. Vous pouvez utiliser un environnement de développement intégré tel que Flash Builder pour les problèmes complexes de débogage. Lancement de l’outil adl Pour lancer l’outil adl à partir de la ligne de commande, passez votre fichier descripteur d’application de l’application mobile et définissez le paramètre profile sur mobileDevice, comme le montre l’exemple suivant : adl MyMobileApp-app.xml -profile mobileDevice
Création d’un descripteur d’application Si vous n’avez pas utilisé Flash Builder pour compiler votre application, vous devez créer manuellement le fichier descripteur de l’application. Vous pouvez utiliser le fichier /sdk/samples/descriptor-sample.xml en tant que base. En général, au minimum, effectuez les modifications suivantes :
<initialWindow> <content>MyMobileApp.swf</content> Dernière mise à jour le 8/7/2011
Création du fichier de package Pour créer le fichier APK pour Android, passez les détails sur l’application à l’outil adt, y compris le certificat, comme l’illustre l’exemple suivant : adt -package -target apk -storetype pkcs12 -keystore newcert.p12 -keypass password MyMobileApp.apk MyMobileApp-app.xml MyMobileApp.swf
Groupement pour iOS Pour grouper des applications mobiles pour iOS, vous devez obtenir un certificat de développement d’Apple, ainsi qu’un fichier de configuration. Cela exige que vous rejoigniez le programme des développeurs Apple. Pour plus d’informations, voir « Préparation à l’installation et au déploiement d’une application sur un périphérique iOS » à la page 18. Piotr Walczyszyn, expert en programmation Flex, explique comment grouper l’application avec ADT en utilisant Ant pour les périphériques iOS. Dans son blog, Valentin Simonov fournit des informations supplémentaires sur la façon de publier votre application sur iOS.
Vous utilisez Android Debug Bridge (adb) pour déployer le fichier APK sur un périphérique mobile qui exécute Android. L’outil adb fait partie du SDK Android. Connexion du périphérique à un ordinateur Avant d’exécuter adb pour déployer le fichier APK sur votre périphérique mobile, connectez le périphérique à votre ordinateur. Sur les systèmes Windows et Linux, la connexion d’un périphérique requiert les pilotes USB. Pour plus d’informations sur l’installation des pilotes USB pour votre périphérique, voir Utilisation des périphériques matériels. Déploiement de l’application sur un périphérique local Après avoir connecté le périphérique à l’ordinateur, vous pouvez déployer l’application sur le périphérique. Pour déployer l’application à l’aide de l’outil adb, utilisez l’option install et affectez le nom de votre fichier APK, comme le montre l’exemple suivant :
Lee Brimlow montre comment déployer une nouvelle application AIR pour Android dans Android Market. Christian Cantrell explique comment déployer l’application sur Amazon Appstore pour Android.
Android Debug Bridge
Notice Facile