Paramètres standard

Indiquez la version du moteur d’exécution d’AIR requise par l’application à l’aide de l’espace de noms du fichier descripteur de l’application.

Assigné dans l’élément application , l’espace de noms détermine globalement les fonctionnalités dont dispose l’application. Si, par exemple, l’application utilise l’espace de noms AIR 2.7 et que l’utilisateur a installé une version ultérieure, elle continue à assimiler le comportement d’AIR à celui de la version 2.7, même si celui-ci a été modifié dans la version ultérieure. Pour que l’application accède au nouveau comportement et aux nouvelles fonctionnalités, vous devez au préalable modifier l’espace de noms et publier une mise à jour. Les correctifs de sécurité constituent une exception notable à la règle.

Sur les périphériques qui utilisent un moteur d’exécution distinct de l’application, tel Android sur AIR 3.6 et versions antérieures, l’utilisateur est invité à installer ou mettre à niveau AIR s’il ne dispose pas de la version requise. Sur les périphériques qui intègrent le moteur d’exécution, tel iPhone, ce cas de figure ne se produit pas, étant donné que la version requise est mise en package avec l’application.

Spécifiez l’espace de noms à l’aide de l’attribut xmlns de l’élément racine application . Les espaces de noms suivants sont adaptés aux applications mobiles (selon la plate-forme mobile ciblée) :

iOS 4+ and iPhone 3Gs+ or Android: 
                            <application xmlns="http://ns.adobe.com/air/application/2.7"> 
                            iOS only: 
                            <application xmlns="http://ns.adobe.com/air/application/2.0">

Plusieurs paramètres devraient être propres à chaque application publiée, à savoir l’ID, le nom et le nom de fichier.

<id>com.example.MyApp</id> 
                                <name>My Application</name> 
                                <filename>MyApplication</filename>

Dans AIR 2.5 et ultérieur, spécifiez la version de l’application dans l’élément versionNumber . L’élément version est à présent obsolète. Si vous définissez une valeur dans versionNumber , vous devez utiliser une séquence de trois nombres au plus, séparés par un point (« 0.1.2 », par exemple). Chaque segment du numéro de la version se compose de trois chiffres au plus. (En d’autres termes, la version la plus longue autorisée correspond à « 999.999.999 ».) Vous ne devez pas obligatoirement inclure trois segments dans le nombre. Les numéros de version « 1 » et « 1.0 » sont également valides.

Vous pouvez aussi définir le libellé de la version à l’aide de l’élément versionLabel . Si vous ajoutez un libellé de version, il remplace le numéro de version dans l’écran d’information de l’application Android, par exemple. Vous devez stipuler un libellé de version si une application est distribuée via Android Market. Si vous ne spécifiez pas de valeur versionLabel dans le descripteur de l’application AIR, la valeur versionNumber est affectée au champ du libellé de version Android.

<!-- AIR 2.5 and later --> 
                            <versionNumber>1.23.7<versionNumber> 
                            <versionLabel>1.23 Beta 7</versionLabel>

Sous Android, l’élément versionNumber AIR est converti en entier Android versionCode à l’aide de la formule : a*1000000 + b*1000 + c , où a, b et c correspondent aux composants du numéro de version AIR : a.b.c .

Spécifiez le fichier SWF principal de l’application dans l’élément enfant content de l’élément initalWindow . Si vous ciblez des périphériques associés au profil mobile, vous devez utiliser un fichier SWF (les applications de type HTML n’étant pas prises en charge).

<initialWindow> 
                            <content>MyApplication.swf</content> 
                            </initialWindow>

Vous devez inclure ce fichier dans le package AIR (à l’aide de l’outil ADT ou de l’IDE). Se contenter de faire référence au nom dans le descripteur d’application n’entraîne pas l’inclusion automatique du fichier dans le package.

Plusieurs éléments enfants de l’élément initialWindow contrôlent le comportement et l’aspect initiaux du principal écran de l’application.

• aspectRatio : indique si l’application doit initialement s’afficher au format portrait (hauteur supérieure à la largeur), au format landscape (hauteur inférieure à la largeur) ou au format any (la scène s’oriente automatiquement dans toutes les orientations).

  <aspectRatio>landscape</aspectRatio>

• autoOrients : indique si la scène doit changer automatiquement d’orientation lorsque l’utilisateur fait pivoter le périphérique ou effectue un autre geste d’orientation tel que l’ouverture ou la fermeture d’un clavier coulissant. Si cet élément est défini sur false (valeur par défaut), la scène ne change pas d’orientation en conjonction avec le périphérique.

  <autoOrients>true</autoOrients>

• depthAndStencil : indique s’il est nécessaire d’utiliser le tampon de profondeur ou le tampon de modèle. Ces tampons s’utilisent normalement avec du contenu 3D.

  <depthAndStencil>true</depthAndStencil>

• fullScreen : indique si l’application doit occuper la totalité de l’écran du périphérique ou le partager avec le chrome standard du système d’exploitation, tel qu’une barre d’état système.

  <fullScreen>true</fullScreen>

• renderMode : indique si le moteur d’exécution doit effectuer le rendu de l’application via le processeur graphique (GPU) ou l’unité centrale principale (UC). En règle générale, le rendu sur GPU augmente la vitesse de rendu, mais diverses fonctionnalités, telles que certains modes de fusion et filtres PixelBender, ne sont pas disponibles en mode GPU. Par ailleurs, les fonctionnalités et restrictions du processeur graphique varient selon le périphérique et le pilote de périphérique. Veillez à tester l’application sur un éventail aussi large que possible de périphériques, en particulier en mode GPU.

  Vous pouvez définir le mode de rendu sur gpu , cpu , direct ou auto . La valeur par défaut est auto , qui active actuellement le mode UC.

  Remarque : pour tirer profit de l’accélération par processeur graphique du contenu Flash sur les plates-formes AIR mobiles, Adobe recommande d’utiliser renderMode="direct" (c’est-à-dire, Stage3D) plutôt que renderMode="gpu". Adobe prend officiellement en charge les structures d’application basées sur Stage3D suivantes et recommande leur utilisation : Starling (2D) et Away3D (3D). Pour plus d’informations sur Stage3D et Starling/Away3D, voir http://gaming.adobe.com/getstarted/ .

  <renderMode>direct</renderMode>

  Remarque : vous ne pouvez pas utiliser renderMode=”direct” pour les applications qui s’exécutent en arrière-plan.

  Le mode de rendu sur GPU est soumis aux restrictions suivantes :

  • La structure d’application de Flex ne prend pas en charge le mode de rendu sur GPU.

  • Les filtres ne sont pas pris en charge.

  • Les remplissages et fusions PixelBender ne sont pas pris en charge.

  • Les modes de fusion suivants ne sont pas pris en charge : Calque, Alpha, Effacement, Superposition, Lumière crue, Eclaircir et Obscurcir.

  • Il n’est pas recommandé d’activer le mode de rendu sur GPU dans une application qui lit la vidéo.

  • En mode de rendu sur GPU, les champs de texte ne sont pas correctement déplacés vers un emplacement visible lors de l’ouverture du clavier virtuel. Pour assurer la visibilité du champ de texte lorsque l’utilisateur saisit du texte, déplacez-le vers la zone visible par le biais de la propriété softKeyboardRect de la scène et des événements de clavier logiciel.

  • S’il est impossible d’effectuer le rendu d’un objet d’affichage sur le GPU, il n’est pas affiché du tout. Ainsi, si un filtre est appliqué à un objet d’affichage, ce dernier n’est pas affiché.

  Remarque : l’implémentation GPU pour iOS dans AIR 2.6 et les versions ultérieure est très différente de l’implémentation utilisée dans la version précédente, AIR 2.0. Des considérations d’optimisation différentes sont prises en compte.

Vous pouvez ajouter l’élément supportedProfiles pour stipuler les profils de périphérique pris en charge par l’application. Réservez le profil mobileDevice aux périphériques mobiles. Lorsque vous exécutez l’application avec l’application de débogage du lanceur AIR (ADL), celle-ci active le premier profil de la liste. Vous disposez également de l’indicateur -profile lorsque vous exécutez l’application ADL pour sélectionner un profil donné dans la liste de profils pris en charge. Si l’application s’exécute sous tous les profils, vous pouvez omettre complètement l’élément supportedProfiles . Dans ce cas de figure, le profil actif par défaut de l’application ADL correspond au profil de bureau.

Pour spécifier que l’application prend en charge le profil de périphérique mobile et le profil de bureau et que vous souhaitez normalement tester l’application avec le profil mobile, ajoutez l’élément suivant :

<supportedProfiles>mobileDevice desktop</supportedProfiles>

Les applications qui prennent en charge le profil mobileDevice peuvent recourir aux extensions natives.

Déclarez toutes les extensions natives auxquelles fait appel l’application AIR dans le descripteur de l’application. L’exemple suivant illustre la syntaxe permettant de spécifier deux extensions natives requises :

<extensions> 
                            <extensionID>com.example.extendedFeature</extensionID> 
                            <extensionID>com.example.anotherFeature</extensionID> 
                            </extensions>

La valeur de l’élément extensionID est identique à celle de l’élément id dans le fichier descripteur de l’extension. Le fichier descripteur de l’extension est un fichier XML appelé extension.xml. Il est mis en package dans le fichier ANE fourni par le développeur de l’extension native.

Définissez l’élément softKeyboardBehavior sur none pour désactiver le comportement d’exécution d’un panoramique et de redimensionnement automatique utilisé par le moteur d’exécution pour s’assurer que le champ de texte de saisie correspondant à la cible d’action est visible après l’affichage du clavier virtuel. Si vous désactivez le comportement automatique, il incombe à l’application de s’assurer que la zone de texte de saisie ou tout autre contenu approprié est visible une fois le clavier affiché. Vous pouvez utiliser la propriété softKeyboardRect de la scène en conjonction avec l’élément SoftKeyboardEvent pour détecter l’ouverture du clavier et déterminer la zone masquée par ce dernier.

Pour activer le comportement automatique, définissez la valeur de l’élément sur pan :

<softKeyboardBehavior>pan</softKeyboardBehavior>