Paramètres standard

Divers paramètres de descripteur d’application jouent un rôle important dans toutes les applications pour périphériques mobiles.

Version du moteur d’exécution d’AIR requise

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.

Remarque : (AIR 3.7 et versions ultérieures) Par défaut, ADT compresse le moteur d’exécution pour les applications Android.

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">
Remarque : la prise en charge des périphériques iOS 3 est assurée par le kit SDK de Packager for iPhone, basé sur le kit SDK d’AIR 2.0. Pour plus d’informations sur la création d’applications AIR pour iOS 3, voir Création d’applications iPhone. Le kit SDK d’AIR 2.6 (et versions ultérieures) prend en charge iOS 4 et les versions ultérieures sur les dispositifs iPhone 3G, iPhone 4 et iPad.

Identité d’une application

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

ID d’une application Android

Sous Android, l’ID est converti en nom de package AIR en ajoutant le préfixe « air » à l’ID AIR. Par conséquent, si l’AID AIR est com.exemple.MonApp, le nom du package Android correspond à air.com.exemple.MonApp.

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

En outre, si l’ID n’est pas un nom de package géré par le système d’exploitation Android, il est converti en nom valide. Les tirets sont remplacés par des traits de soulignement et les chiffres de début de tout composant ID sont précédés d’un « A » majuscule. Exemple : l’ID 3-goats.1-boat est converti comme suit : air.A3_goats.A1_boat.

Remarque : le préfixe ajouté à l’ID d’application permet d’identifier les applications AIR dans Android Market. Si vous ne souhaitez pas que l’application soit identifiée comme une application AIR en raison du préfixe, vous devez extraire du package le fichier APK, modifier l’ID de l’application, puis remettre celle-ci en package comme indiqué dans Opt-out of AIR application analytics for Android (disponible en anglais uniquement).

ID d’une application iOS

Définissez l’ID de l’application AIR sur l’ID d’application créée dans le portail iOS Provisioning Portal d’Apple.

Les ID d’application iOS contiennent un identifiant d’application (préfixe), suivi d’un identifiant d’application (suffixe). L’identifiant d’application (préfixe) est une chaîne de caractères, telle que 5RM86Z4DJM, affectée par Apple à l’ID d’application. L’identifiant d’application (suffixe) contient un nom de type domaine inversé que vous sélectionnez. Il se termine parfois par un astérisque (*), qui représente un ID d’application à caractère générique. S’il se termine par un caractère générique, vous pouvez remplacer ce dernier par toute chaîne valide.

Exemple :

  • Si l’ID de l’application Apple est 5RM86Z4DJM.com.example.helloWorld, vous devez utiliser com.example.helloWorld dans le descripteur d’application.

  • Si l’ID d’application Apple est 96LPVWEASL.com.example.* (ID d’application à caractère générique), vous pourriez utiliser com.example.helloWorld, com.example.anotherApp ou tout autre ID qui commence par com.example.

  • Enfin, si l’ID de l’application Apple ne contient qu’un identifiant d’application (préfixe) et un caractère générique, tel que : 38JE93KJL.*, vous pouvez utiliser tout ID d’application dans AIR.

Lorsque vous spécifiez l’ID de l’application, ignorez la partie identifiant d’application (préfixe) de l’ID d’application.

Version d’une application

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.

Fichier SWF principal d’une application

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.

Propriétés de l’écran principal

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.

Profils pris en charge

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>

Extensions natives requises

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.

Comportement du clavier virtuel

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>
Etant donné que pan est la valeur par défaut, omettre l’élément softKeyboardBehavior active également le comportement automatique du clavier.
Remarque : si le mode de rendu sur GPU est également activé, le comportement d’exécution du panoramique n’est pas pris en charge.