Référence...

Étant de ceux qui pensent que toute explication passe mieux quand elle est associée à un exemple, je vais attaquer ce semblant de doc par un exemple d'un descripteur d'application complet. =)

Ne vous étonnez pas si le contenu du descripteur est en anglais, je l'ai honteusement emprunté au répertoire du SDK contenant des exemples d'applications et de descripteurs.

Code : XML

Allez, au boulot :
Code : XML
À la racine du descripteur nous découvrons la balise application, et ses trois attributs (parmi lesquels un seul est obligatoire).
Tout ce qui se trouve compris dans la balise application affectera d'une manière ou d'une autre le comportement général de l'application. Elle est de ce fait obligatoire !

xmlns, tout comme en xHTML, sert à définir le NameSpace (ou espace de nom) du document, et dans ce cas particulier, il sert aussi à préciser la version du runtime que doit posséder le client (la version 1.0 dans cet exemple). Si la version du client n'est pas celle requise par l'application, AIR se charge d'afficher une boite de dialogue pour demander à l'utilisateur de remédier au problème (en mettant à jour le runtime par exemple).
Cet élément est obligatoire.

minimumPatchLevel, couplé avec xmlns, permet de définir de manière très précise la version d'AIR que doit posséder le client. Alors que xmlns ne permet de définir que la version du runtime, minimumPatchLevel permet d'exiger qu'un patch précis de cette version ait été appliqué. En cas d'absence du patch demandé, AIR demande au client de le télécharger.

Définition des informations élémentaires de l'application

Les lignes suivantes définissent l'ID, la version, le nom, le nom du fichier principal, la description, et le copyright de l'application :
Code : XML
id, c'est une chaîne d'un minimum d'un caractère et d'un maximum de 212 qui fait office d'identifiant unique, ce qui permet au runtime de pouvoir identifier cette application parmi les autres.
Cette chaîne est restreinte aux caractères suivants :

• 0-9
• a-zA-Z
• . (point)
• - (tiret)

Cet élément est obligatoire.

version, chaîne définissant le numéro de version de l'application. Cette information, bien qu'obligatoire, n'influe en rien sur le comportement du runtime ou du SDK et ne sera même pas interprétée par ces derniers.
Cet élément est obligatoire.

filename, nom du fichier HTML contenant l'application (sans l'extension). Sera utilisé comme nom d'application si name n'est pas défini.
Cet élément est obligatoire.

name, titre affiché lors de l'installation. S'il est défini, il sera aussi utilisé comme nom du raccourci créé par l'installation.
Bien que facultatif, cet élément est fortement recommandé.

description, description de l'application. Elle sera affichée lors de l'installation.

copyright, informations de copyright concernant l'application.

Définition des propriétés d'installation

Le dossier d'installation et le menu dans lequel on peut retrouver l'application peuvent être modifiés par ces deux balises :
Code : XML



installFolder définit le sous-dossier dans lequel l'application sera installée.
Si installFolder vaut "mon_appli", il sera installé :

• dans le répertoire C:\Program Files\mon_appli\ sous Windows ;
• dans le répertoire /Applications/mon_appli/ sous Mac OS.

programMenuFolder, définit à quel endroit du menu seront placés les raccourcis concernant l'application (sous Windows : "Tous les programmes"). Ce paramètre est ignoré pour les OS différents de Windows.

Définition des propriétés de la fenêtre principale

Quand une application AIR est lancée, le runtime utilise le contenu de la balise initialWindow pour créer la fenêtre principale de l'application :
Code : XML

content, URL relative du fichier (page HTML ou fichier SWF) à charger dans la fenêtre principale, à partir de la racine de l'application. Ce paramètre étant une URL, elle doit être encodée correctement.
Cet élément est obligatoire.

title, représente le titre de la fenêtre (le titre défini dans le fichier HTML écrasera cette valeur).

systemChrome, défini le chrome (thème des fenêtres) de l'application. La valeur par défaut, standard, utilise le chrome du système. La valeur none n'affichera pas de chrome.
Ce paramètre ne peut pas être modifié pendant le fonctionnement de l'application.

transparent, passez à true si vous voulez que la fenêtre supporte l'alpha blending (transparence). Cette option peut se révéler gourmande en ressources.

visible, booléen contrôlant l'affichage immédiat (s'il vaut true) ou retardé de la fenêtre principale (pour par exemple avoir le temps de déplacer la fenêtre, modifier sa taille, charger entièrement l'application, etc.). Si ce paramètre n'est pas renseigné, sa valeur par défaut étant false, vous pouvez afficher la fenêtre pendant le fonctionnement de l'appli en mettant la variable stage.nativeWindow.visible à true.

x, y, width, height, représentent respectivement l'abscisse, l'ordonnée, la largeur et la hauteur de la fenêtre. Si ces valeurs ne sont pas renseignées, la taille de la fenêtre dépendra de celle de son contenu (fichier SWF ou HTML).

minSize, maxSize, définissent la taille minimale et maximale de la fenêtre. Si ces valeurs sont vides, elles seront renseignées par l'OS.

minimizable, maximizable, resizable, définissent si la fenêtre peut être réduite, agrandie, et redimensionnée. Par défaut ces propriétés valent true.

Définition des icônes de l'application

Parce qu'avec une icône, c'est tout de suite plus joli.
Code : XML
L'adresse des icônes est l'URL relative vers ces dernières, à partir de la racine de l'application. Les images doivent être au format PNG.
Si vous donnez une image pour une taille précise, l'image doit impérativement être aux dimensions données ! Si toutes les tailles ne sont pas renseignées, l'OS choisira la taille la plus proche et l'adaptera selon ses besoins.

Permettre l'appel d'une application à partir du navigateur

En changeant le paramètre ci-dessous à true, il deviendra possible de lancer l'application à partir d'un navigateur (en cliquant sur un lien).
Code : XML

Par défaut, allowBrowserInvocation vaut false.