Non standard
Cette fonctionnalité n'est pas en voie de standardisation au W3C, mais elle est supportée par la plateforme Firefox OS. Bien que son implémentation puisse changer dans le futur et qu'elle n'est pas largement supportée par les différents navigateurs, elle est utilisable pour du code dédié aux applications Firefox OS.

Important : Ce document concerne le format du manifeste de l'OS propriétaire de Firefox, et non des   spécifications de manifeste W3C conçues pour les applications Web progressives multi-navigateurs.

Le manifeste d'une application, pour l'OS de Firefox, contient des informations sur l'application (telles que le nom, l'auteur, l'icône et une description) dans un simple document utilisable par les utilisateurs et les boutiques d'applications. L'aspect fondamental d'un manifeste est qu'il contient la liste des API Web dont l'application a besoin. Cela permet aux utilisateurs de prendre des décisions éclairées sur les applications avant de les installer. C'est l'un des éléments-clés qui distingue une application Firefox OS d'un site Web.

Note : Les navigateurs qui gèrent les manifestes et permettent d'installer des applications web ont un environnement d'exécution web. Parmi ces systèmes, on trouve Firefox OS, les versions récentes de Firefox pour Android ainsi que Firefox (pour bureau).

Note : Vous pouvez trouver des réponses aux questions courantes sur les manifestes d'application dans notre FAQ Manifeste d'application.

Création d'un manifeste d'application

Cette section détaille les étapes nécessaires pour créer et utiliser un manifeste d'application.

Conventions : nom de fichier, emplacement et format

  • Nom : mon_manifeste.webapp (il est nécessaire d'utiliser l'extension .webapp)
  • Emplacement : à la racine du répertoire de l'application
  • Format : JSON (le JSON du manifeste doit être valide)

Gestion des chemins

  • Les chemins utilisés de façon interne pour les manifestes, les icônes et autres doivent être absolus à partir de l'origine de l'application et non depuis la racine de l'application. Par exemple, si votre manifeste se situe à l'URL : http://www.monsite.com/monapp/manifest.webapp, le chemin d'installation sera /monapp/manifest.webapp et pas /manifest.webapp.
  • Les chemins internes doivent être servis depuis la même origine que l'application
  • Les chemins externes doivent être entièrement qualifiés. Par exemple, avec une application empaquetée sur le Firefox Marketplace, mais une icône hébergée sur votre propre serveur, le chemin à utiliser pour l'icône serait : http://monappliweb/images/icon.png.

Conditions à respecter pour soumettre une application au Firefox Marketplace

Si vous souhaitez que votre application soit publiée sur le Firefox Marketplace, le manifeste de votre application doit contenir les champs suivants :

  • name
  • description
  • launch_path (pour les applications empaquetées)
  • icons (1 icône 128x128 nécessaire, 1 icône 512x512 recommandée)
  • developer
  • default_locale (si locales est défini)
  • type (pour les applications privilégiées et internes (certifiées))

Conditions à respecter pour un application web générique

Si vous créez une application hébergée générique, non publiée sur le Firefox Marketplace, le manifeste de votre application devra contenir les champs suivants :

  • name
  • description
  • icons (1 icône 128x128 nécessaire, 1 icône 512x512 recommandée)

Note : pour auto-publier une application à partir d'une page que vous contrôlez, vous devez fournir un mécanisme pour déclencher l'installation de l'application pour les utilisateurs. Pour une application hébergée, cela se fait généralement avec un appel à navigator.Apps.install() lors d'un clic sur un bouton ; pour les applications empaquetées,  navigator.Apps.installPackage()peut être utilisé.

Validation d'un manifeste

Si vous soumettez votre application pour le Firefox Marketplace, le manifeste de votre application devra passer des tests de validations.

Vous pouvez utiliser le validateur d'application pour identifier d'éventuelles erreurs. Vous pouvez également utiliser cette API pour le valider.

Mettre à jour les manifestes

Pour plus de détails sur les mises à jour des applications, voir la section à ce sujet.

Un exemple de manifeste

Les lignes de code suivantes représentent un manifeste minimal. Vous pouvez le copier dans un fichier texte et remplacer les valeurs par vos informations.

{
  "name": "Mon application",
  "description": "Le pitch vendeur de ma très belle application",
  "launch_path": "/index.html",
  "icons": {
    "512": "/img/icon-512.png",
    "128": "/img/icon-128.png"
  },
  "developer": {
    "name": "Mon nom ou celui de mon organisation",
    "url": "http://ma-pageaccueil-ici.fr"
  },
  "default_locale": "fr",
  "chrome": { "navigation": true }
}

Les champs nécessaires du manifeste

Les champs peuvent apparaître dans n'importe quel ordre. Tout champ du manifeste n'appartenant pas à la liste ci-dessous est ignoré.

name (nom)

Note : Obligatoire pour tous les manifestes d'application.

Le nom de l'application doit être lisible par un être humain. Sa longueur maximum est de 128 caractères.

Si vous changez le nom de votre application après sa diffusion, le nom ne sera pas mis-à-jour pour les installations existantes.

"name": "Le web ouvert !"

description

Note : Obligatoire pour tous les manifestes d'application

La description doit être lisible par un être humain. Sa longueur maximum est de 1024 caractères.

"description": "Une application passionnante ouverte sur le Web !"

launch_path (chemin de départ)

Note : Obligatoire pour tous les manifestes d'application.

Le chemin d'accès à l'origine de l'application qui est chargé quand l'application démarre.

Dans une application empaquetée (packaged app), ce champ spécifie le point de départ du contenu local du fichier zip contenant l'application. Par exemple, si launch_path a pour valeur /monApp/index.html, alors l'application empaquetée sera lancée en ouvrant le fichier /monApp/index.html.

  • Si votre application est stockée à la racine d'un serveur web, par exemple monappliweb.github.com/, alors  launch_path doit être défini à  /.
  • Si votre application est stockée dans un sous-répertoire, par exemple monmarche.github.com/monappliweb/ alors launch_path doit être défini à  monappliweb/
Conseils :
"launch_path": "/index.html"

icons (icônes)

Note : 1 icône de taille 128 × 128 est requise pour tous les manifestes d'application ; et 1 icône 512*512 est recommandée.

Un objet contenant les tailles d'icône et leurs URI.

Rappelez-vous que le chemin interne d'une icône doit être un chemin absolu, partant de l'origine de l'application. Alors que le chemin d'une icône hébergée doit être entièrement qualifié.

Les icônes doivent être carrées et en format .png. Elles ne doivent pas avoir des arrière-plans solides qui s'étendent aux quatre coins de l'icône.

Attention : Si vous soumettez votre application au Marketplace de Firefox, vos icônes doivent aussi suivre les règles pour les icônes des applications pour Firefox Marketplace.

Taille requise pour les icônes

128*128
Pour afficher sur le Marketplace de Firefox et les périphériques

Taille recommandée pour les icônes

512-*512
À partir de Firefox 2.0, des icônes plus importantes sont nécessaires pour un affichage adaptable à toutes les combinaisons possibles de tailles et de résolution d'écran avec mises en page de 3 et 4 colonnes. Nous acceptons une icône 512 × 512, qui est ensuite mise à l'échelle pour les différentes utilisations à travers les périphériques. Cette taille est également utile pour l'affichage sur d'autres plates-formes, sur lesquelles les applications peuvent être installées, comme Android.

Autres tailles d'icônes pouvant être utiles

60*60
Pour la taille exacte de l'icône sur le périphérique pour les anciennes versions de l'OS Firefox.
16×16, 32×32, 48×48, 64×64, 90×90, 128×128 et 256×256
Ces tailles d'icône sont utilisées sur les différentes plateformes où votre application peut être installée comme Windows 7, OS X et Android :
"icons": {
  "128": "/img/icon-1.png",
  "512": "/img/icon-2.jpg"
}

Vous pouvez lire les recommandations sur le design d'icônes pour Firefox OS.

Pour une explication approfondie sur les raisons du choix de la taille de l'icône 512 × 512, lisez notre guide d'implémentation des icônes.

developer (développeur)

Note : Seul le nom est requis pour tous les manifestes d'application.

  • name : Le nom du développeur
  • url : L'URL d'un site contenant plus d'informations sur le développeur de l'application. Facultatif
"developer": {
    "name": "The Open Web!",
    "url": "http://www.mywebapp.com"
}

default_locale (langue par défaut)

Note : Si locales est défini, default_locale est obligatoire pour votre manifeste d'application.

Un identifiant de langue (RFC 4646) qui indique le langage utilisé dans les valeurs de champ de votre manifeste.

Bien que default_locale ne soit pas nécessaire pour les applications qui n'ont pas de paramètres régionaux, il est recommandé de l'inclure. Si vous ne définissez pas de default_locale, le Marketplace de Firefox devra deviner la langue de votre application.

Exemple pour le français :

"default_locale": "fr"

type

Note : Si votre application est privilégiée ou interne (certifiée), le type est requis pour votre manifeste d'application.

Le type de l'application définit son niveau d'accès aux périphériques sensibles  WebAPIs ; si vous ne définissez pas le type, il sera par défaut web.

  • web - Une application normale.Ce type a le plus petit accès aux WebAPI.
  • privileged - (privilégiée) Une application authentifiée qui a été approuvée par une boutique d'applications telle que le Marketplace de Firefox. Ce type a un plus large accès aux WebAPI.
  • certified - (certifiée) Une application authentifiée qui est destinée à des fonctions système critiques comme le composeur par défaut ou l'application de paramètres système sur un smartphone. Il n'est pas destiné à des applications tierces dans un magasin d'applications. Ce type d'application possède le plus haut niveau d'accès aux WebAPI.

Note : Pour plus d'informations sur les types, voir Packaged apps.

"type": "certified"

Les champs facultatifs du manifeste

Les champs suivants sont facultatifs

activities (activités)

Un ensemble d'activités que votre application prend en charge  (liste entière) . Elles sont structurées ainsi :

  • chaque propriété dans ce champ est une activité,
  • les noms de l'activité sont du texte dont la forme est libre,
  • chaque activité est représentée par un objet.

Par exemple, ici une entrée avec une activité nommée "share"

"activities": {
  "share": {
    "filters": {
      "type": [ "image/png", "image/gif" ]
    },
    "href": "foo.html",
    "disposition": "window",
    "returnValue": true
  }
}

L'objet de l'activité share de l'exemple possède trois propriétés : filters, href, et disposition. Elles sont décrites dans Activity handler description (en). .

appcache_path

Le chemin absolu vers le manifeste de cache pour l'application (AppCache). Quand une application de l'OS Firefox est installée, le manifeste AppCache est récupéré et interprété, et les éléments statiques sous l'en-tête CACHE sont mis en cache.

Note : Les fonctionnalités de cache des applications empaquetées sur le périphérique sont installées. Vous n'avez pas besoin de définir un AppCache pour les applications empaquetées.

Note : AppCache est une technologie défectueuse et sera bientôt remplacée par plus efficace Service Workers.

"appcache_path": "/cache.manifest"

chrome

Firefox OS 1.1+ Only

Un ensemble de contrôles de navigation en bas de l'écran.qui consiste en Back (retour en arrière), Forward (avancer), Reload (recharger) and Favorite (favori).

chrome navigation

Note :  Nous vous recommandons de concevoir un bouton arrière pour l'interface de votre application, au lieu de vous fier à cette option

"chrome": { "navigation": true }

csp (politique de sécurité)

Note : facultatif,  s'applique à toutes les applications empaquetées installées sur Firefox OS, Firefox Desktop ou Firefox pour Android.

Ce champ peut être utilisé pour définir une politique de sécurité  pour toutes les pages de l'application. Les politiques que vous pouvez ajouter sont listées dans  Politique de sécurité (en) (Content Security Policy), et pour une application, vous pourrez les inclure dans une ligne comme :

"csp" : "default-src *; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline'"

Les règles par défaut affectées aux applications privilégiées et internes / certifiées Firefox OS sont les suivantes:

Privilégiée
default-src *; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline'
Certifiée
default-src *; script-src 'self'; object-src 'none'; style-src 'self'

Ces valeurs par défaut ne peuvent pas être remplacées, les règles définies peuvent seulement y être ajoutées, c'est-à-dire que la stratégie CSP dans le manifeste ne peut que rendre le CSP réel appliqué plus restrictif dans le cas d'applications privilégiées / internes.

Note : voir Apps CSP page   pour plus de détails sur les restrictions particulières de la CSP pour les applications.

datastores-owned (propriété du magasin de données)

Note : appliqué seulement aux applications privilégiées qui sont installées sur Firefox OS

Lors de l'utilisation de  Data Store API,  l'application qui possède le magasin de données DOIT inclure le domaine appartenant au magasin de données dans son manifeste pour revendiquer la propriété, par exemple :

"datastores-owned": {
  "myData": {
    "access": "readwrite",
    "description": "my data store"

Vous pouvez inclure plusieurs propriétés pour représenter différents magasins de données et chacun peut utiliser un access (accès)    readonly / readwrite (lecture seule / lecture et écriture) pour spécifier si le magasin de données peut être lu / modifié par d'autres applications. Une description est également incluse pour décrire le but du magasin de données.

datastores-access (accès au magasin de données)

 Note : Appliqué seulement aux applications certifiées qui sont installées sur Firefox OS.

Lors de l'utilisation de Data Store API , toute application non propriétaire qui veut accéder au magasin de données DOIT inclure le champ datastores-access dans son manifeste, par exemple :

"datastores-access": {
  "myData": {
    "access": "readwrite",
    "description": "Read and modify my data store"
  }

Sans que ce champ soit spécifié, le comportement par défaut est "sans accès". Encore une fois, plusieurs propriétés peuvent être incluses si vous souhaitez accéder à plusieurs magasins de données, et un accès readonly(lecture seule)  ou readwrite (lecture/écriture) peut être configuré pour déclarer quel type d'accès est nécessaire pour l'application.

fullscreen

Un contrôle qui indique à l'exécutable de lancer l'application en mode plein écran ou non.

Comme la plupart des applications s'exécutent en plein écran, nous vous recommandons de le définir true (vrai).

"fullscreen": "true"

inputs (entrées)

Spécifie les mises en page prises en charge pour le clavier de l'application. Chaque mise en page est décrite à l'aide d'une paire clé-valeur, où la clé représente le nom de la mise en page (qui sera affiché dans l'application Paramètres) et la valeur décrit les informations détaillées sur la mise en page, y compris le chemin de lancement et les types d'entrées pris en charge.

La valeur autorisée dans le champ types  est un sous-ensemble de l'élément <input> qui contient les valeurs de l'attribut type . Couramment, les valeurs autorisées sont text, search, tel, number, url, email.

Exemple :

"inputs": {
   "en": {
     "launch_path": "/index.html#en",
     "name": "English",
     "description": "English layout",
     "types": ["url", "text"],
     "locales": {
       "en-US": {
         "name": "English",
         "description": "English layout"
       },
       "zh-TW": {
         "name": "英文",
         "description": "英文鍵盤"
       }
     }
   },
   "en-Dvorak": {
     "launch_path": "/index.html#en-Dvorak",
     "name": "English (Dvorak)",
     "description": "Dvorak layout",
     "types": ["url", "text"]
   },
   "es": {
     "launch_path": "/index.html#es",
     "name": "Spanish",
     "description": "Spanish layout",
     "types": ["url", "text"]
   },

  ...

}

installs_allowed_from (installations autorisées venant de)

Une URL (ou plus) du domaine à partir duquel votre application peut être installée.

Ce champ est destiné aux applications que les utilisateurs finaux peuvent acheter. Le champ identifie les magasins d'applications avec lesquels vous avez une relation commerciale. S'il est laissé vide, votre application peut être installée à partir de n'importe où.

Attention : Ne placez pas une barre oblique (/) à la fin des URL, car l'installation échouera.

Par exemple, si votre application peut être installée depuis le Marketplace de Firefox, installs_allowed_from ressemblera à cela :

"installs_allowed_from": [
  "https://marketplace.firefox.com"
]

Note : Le tableau ["*"] indique que l'installation de l'application est autorisée depuis n'importe quel site. Il s'agit de la valeur par défaut. Notez que [] désactiverait l'installation depuis tout site, le vôtre inclus.

locales (langues)

Une carte spécifiant une ou plusieurs langues contenues dans le manifeste de l'application.

Chaque entrée  locales  contient une liste de champs du manifeste de l'application à remplacer par une  langue spécifique. Les Keys de locales utilisent les mêmes balises linguistiques que default_locale (RFC 4646). .

Attention :

  • Si vous avez défini locales , n'oubliez pas de définir également default_locale.
  • Ne définissez pas la valeur de default_locale à nouveau dans locales.
  • Vous ne pouvez pas remplacer ces champs : default_locale, locales et installs_allowed_from.

Par exemple, le langage par défaut de votre application est français, donc son default_locale doit être "fr". Mais vous voulez que le nom et la description soient traduits pour vos utilisateurs italiens et allemands. Vos entrées  locales ressembleront à ceci :

"locales": {
  "it": {
    "name": "L'Open Web",
    "description": "Eccitante azione di sviluppo web open!"
  },
  "de": {
    "name": "Der Open Web",
    "description": "Spannende offene Web-Entwicklung-Action!"
  }
}

messages

Note : concerne seulement les applications qui sont installées sur Firefox OS

Indique les messages système que l'application peut capturer et les pages de votre application qui peuvent les afficher quand ils apparaissent.

Ci-dessous, un exemple pour l'application composeur de Firefox OS. Chaque fois qu'une entrée "appel entrant" est réalisée, (message système telephony-new-call (téléphone nouvel appel)), l'appareil affiche le clavier du composeur (URL: /dialer/index.html#keyboard-view)  :

"messages": [
  { "alarm": "/index.html" }
  { "notification": "/index.html" }
  { "telephony-new-call": "/dialer/index.html#keyboard-view" }
]

orientation

Note : Utilisé seulement pour les applications AndroId ou Firefox OS.

Le positionnement sur lequel votre application restera verrouillée.

Illustration des valeurs possibles :

valeur l'application restera verrouillée sur
portrait-primary (portrait primaire) Phone upright in portrait orientation
portrait-secondary (portrait secondaire) Phone upsidedown in portrait orientation
portrait
si vous l'utilisez, vous n'avez pas besoin de spécifier les valeurs -primary et -secondary
Phone upright in portrait orientationPhone upsidedown in portrait orientation
landscape-primary (paysage primaire) Phone lying on its left hand side in landscape orientation
landscape-secondary (paysage secondaire) Phone lying on its right hand side in landscape orientation
landscape (paysage)
si vous l'utilisez, vous n'avez pas besoin de spécifier les valeurs -primary et -secondary

Phone lying on its left hand side in landscape orientation

Phone lying on its right hand side in landscape orientation

"orientation": [ "landscape-primary" ]

origin

Firefox OS 1.1+ Only

Note : Applications empaquetées privilégiées ou certifiées seulement.

Il y a un protocole spécial au sein d'une application empaquetée, qui est app://<UUID><UUID> est une chaîne de caractères unique pour chaque appareil où l'application est installée. Cette URL est difficilement accessible pour le moment. Le champ origin vous permet de remplacer la valeur de cet UUID par un seul nom de domaine qui sera utilisé par chaque application d'installation,

Rappelez-vous : le nom de domaine doit être précédé de app:// , et vous devez en être le propriétaire.

"origin": "app://mon-application-web.com"

permissions

L'ensemble des permissions dont l'application a besoin, par exemple, l'accès aux contacts de l'utilisateur Voir la  liste complète des permissions/fonctionnalités des WebAPI.

Chaque permission requière :

  • name: le nom de la permission.
  • description: la raison pour laquelle l'application a besoin de la permission.
  • access: le niveau d'accès demandé. Les options sont readonly (lecture seule), readwrite (lecture/écriture), readcreate (lecture/création), and createonly (création seule). Quelques API seulement en ont besoin, par exemple Data Store.

Note : Si une application essaye d'utiliser l'une de ces API sans l'entrée correspondante dans le champ permissions , son exécution échouera

Il existe de nombreuses API, dont certaines requièrent le type  pour être privilégiées ou certifiées. Par exemple, systemXHR impose que le champ type soit privileged  pour fonctionner.

"type": "privileged",
  "permissions": {
    "systemXHR": {
      "description": "Nécessaire pour télécharger des fichiers sons."
    }
  }

precompile (précompilation)

Firefox OS 1.4+ Only

Note : Uniquement pour les applications empaquetées.

Le chemin des fichiers javascript qui contiennent le code asm.js avec lequel vous voulez compiler lors de l'installation.

La compilation au moment de l'installation rend le processus plus long mais réduit le temps nécessaire au démarrage de l'application.

"precompile": [
  "game.js",
  "database.js"
]

redirects (redirections)

Note : Uniquement pour les applications privilégiées et certifiées qui sont installées sur Firefox OS.

Les URL internes que votre application utilise pour gérer les processus externes.

Par exemple, votre application peut utiliser l'authentification Facebook OAuth pour obtenir les contacts d'un utilisateur. Lorsque l'authentification est terminée, le serveur redirige en général vers une URL que vous contrôlez. Étant donné que les applications empaquetées ne sont pas hébergées sur le Web, elle n'a pas d'URL valide pour la redirection. Vous utilisez donc le champ de redirections pour rediriger une URL externe vers une URL d'application interne.

Dans le scénario ci-dessus, le champ de redirections ressemblera à ceci :

redirects": [
  {"from": "http://facebook.com/authentication/success.html",
    "to": "/app/main_interface.html"}
]

La portée des redirections déclarées par redirects est limitée à l'application qui les déclare. Cela permet que plusieurs applications puissent rediriger la même URL publique vers leurs propres ressources locales, et elles empêchent également le détournement global d'URL publiques par une application.

role (rôle)

 Le champ de rôle est principalement destiné à l'usage interne par l'équipe d'ingénierie de Gaia; il vous permet de spécifier comment une application doit être utilisée par B2G, son rôle dans le système. Par exemple, est-ce un clavier ou un remplacement d'écran d'accueil ?

"role": "system",

Les options comprennent :

  • system : (système) N'affiche pas l'application sur l'écran d'accueil, et était initialement conçu pour remplacer une application système. Notez cependant qu'en pratique, ce n'est pas vraiment une application système, mais ça permet de cacher des applications qui ne doivent pas être directement accessibles à l'utilisateur (l'application Bluetooth, par exemple).
  • Input : (entrée) affiche dans l'application Paramètres un clavier de remplacement et ne s'affiche pas sur l'écran d'accueil.
  • homescreen : (écran d'accueil) affiche dans l'application Paramètres un écran d'accueil de remplacement, mais ne s'affiche pas sur l'écran d'accueil lui-même.
  • addon : (ajout) c'est une application Firefox OS Add-on. Firefox OS 2.5 Only
  • keyboard : (clavier) définit l'application comme une application IME. Cela apparaîtra dans l'application Paramètres comme un autre clavier, mais ne s'affichera pas sur l'écran d'accueil lui-même. Firefox OS 1.2+ Only

version

Note : requis pour les manifestes des applications empaquetées

Une chaîne de caractères représentant la version de l'application, affiché sur le Marketplace et lors de l'installation de l'application.

Dans les applications empaquetées, la version utilisée permet de déterminer si une mise à jour doit être installée. Le champ doit être incrémenté lorsque vous téléchargez une mise à jour de votre application sur Marketplace.

Pour les applications hébergées, l’exécutable web n'utilise pas du tout cette valeur, mais elle peut être commode pour vous et sa forme est donc libre. Son utilisation est recommandée.

"version": "2.1"

Le service des manifestes

Le manifeste de l'application doit être servi depuis la même origine que l'application.

il devrait être stocké avec une extension de fichier .webapp. Les manifestes d'applications doivent être servis avec un en-tête Content-Type : application/x-web-app-manifest+json. Ce n'est pas actuellement forcé par Firefox mais ça l'est par le Marketplace. Firefox OS vérifie si l' origin de la page dans laquelle l'utilisateur déclenche l'installation est différente de l' origin de l'application elle-même. Vous n'avez pas besoin d'autres en-têtes tels que  Content-Security-Policy et X-UA-Compatible .

Les manifestes peuvent être servis par SSL pour limiter certains types d’attaques avec HTTP compression. Le manifeste ne doit pas être mis en cache.

Le manifeste doit être en UTF-8 si l'application doit être soumise au Firefox Marketplace. Il est recommandé d’omettre le byte order mark (BOM). D'autres encodages de caractères peuvent être renseignés avec un paramètre charset(police de caractères) sur l'en-tête Content-Type (par exemple Content-Type: application/x-web-app-manifest+json; charset=ISO-8859-4), mais ne sera pas pris en compte par le Marketplace.

Les agents utilisateurs doivent, lorsque c'est possible, offrir un message compréhensible à l'utilisateur sur l'identité du site et le statut TLS, lors de l'installation d'une application.

Le service depuis Apache

Dans votre fichier .htaccess, vous devez ajouter la ligne suivante :

AddType application/x-web-app-manifest+json .webapp

Si l'ajout d'un fichier  .htaccess ne fonctionnait pas pour vous, vous pouvez ajouter la même ligne dans votre fichier de configuration Apache. Votre fichier de configuration peut être appelé httpd.conf ou 000-default.conf , selon votre système d'exploitation et votre configuration.

Le service à partir d'Apache, en utilisant un extrait PHP

Il se peut que, sur un plan d'hébergement partagé, la modification de l'en-tête Content-Type avec un fichier .htaccess ne fonctionne pas car il est rejeté globalement. Si cet hébergement prend en charge PHP, l'utilisation du script court suivant peut permettre d'aboutir :

<?php
// Serving the manifest file 'manifest.webapp' with the appropriate header
header('Content-type: application/x-web-app-manifest+json');
readfile('manifest.webapp');
?>

Ce code doit être placé dans le même répertoire que le manifeste, et être nommé manifest.webapp.php par exemple.

Le service depuis Tomcat

Dans votre fichier web.xml , vous avez besoin de définir le "mime-mapping"

<mime-mapping>
    <extension>webapp</extension>
    <mime-type>application/x-web-app-manifest+json</mime-type>
</mime-mapping>

Le service depuis IIS

Nécessaire pour éditer votre fichierweb.config . Il est probablement situé dans le répertoire racine d'un site web.

Vous devrez ajouter une nouvelle entrée dans les sections <configuration>, <system.webServer> et <staticContent>

remove fileExtension=".webapp" />
<mimeMap fileExtension=".webapp" mimeType="application/x-web-app-manifest+json; charset=UTF-8"

Note : Pour plus d'informations, lire Adding Static Content MIME Mappings <mimeMap>.

Le service depuis nginx

Vous devez éditer votre fichier mime.types dans le répertoire conf. Il sera probablement situé dans /etc/nginx/ ou /opt/nginx/.

Vous devriez avoir quelque chose de similaire au code ci-dessous. Ajoutez la dernière ligne .

types {
  text/html   html htm shtml;
  text/css    css;
  text/xml    xml;
  application/x-web-app-manifest+json   webapp;
}
Note : Ce bout de code part du principe que vous utilisez l'extension .web-app. Si vous utilisez .json ou une autre extension, il vous faudra modifier cette ligne en conséquence.

Le service depuis GitHub

Si vous servez votre fichier manifeste depuis GitHub Pages, GitHub le servira avec l'entête Content-Type : application/x-web-app-manifest+json.

Le service depuis Python

Si vous avez installé Python, vous pouvez facilement faire tourner un serveur depuis un répertoire local, en utilisant le code suivant :

import SimpleHTTPServer
import SocketServer
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map['.webapp'] = 'application/x-web-app-manifest+json'
httpd = SocketServer.TCPServer(("", 3000), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.serve_forever()

Le service depuis Flask (Python)

Si vous avez un projet Flask, vous n'avez pas besoin de créer un fichier manifest.webapp mais vous pouvez utiliser le décorateur route () pour indiquer à Flask quelle URL devrait déclencher notre fonction. D'abord, vous devez importer la réponse de Flask

from flask import Response

Dans votre application flask, ajoutez le décorateur route() comme indiqué ci-dessous :

@app.route('/manifest.webapp')
def manifest():
        data = json.dumps({
            "name": "Flask Application",
            "version": "1.0",
            "description": "Example of manifest.webapp",
            "launch_path": "/",
            "icons": {
                    "256": "/img/256.png",
                    "128": "/img/128.png",
                    "120": "/img/120.png",
                    "90": "/img/90.png",
                    "60": "/img/60.png",
                    "32": "/img/32.png"
                },
            "developer": {
            "name": "Rizky Ariestiyansyah",
            "url": "http://oonlab.com"
            },
            "orientation": ["portrait"],
            "default_locale": "en"
        })
        return Response(data, mimetype='application/x-web-app-manifest+json')

Le service depuis Rack (Ruby)

Dans config/initializers/mime_types.rb , ajoutez

Rack::Mime::MIME_TYPES['.webapp'] = 'application/x-web-app-manifest+json'

Spécifications

Ne fait partie d'aucune spécification - ce document se réfère au format du manifeste du système propriétaire Firefox OS, et non à  W3C manifest spec Nous espérons documenter cela à un endroit différent, bientôt.

Compatibilité des navigateurs

Pour des raisons évidentes, le support est principalement prévu sur les navigateurs mobiles.

Fonctionnalité Chrome Firefox (Gecko) Internet Explorer Opera Safari
Basic support Pas de support Pas de support Pas de support Pas de support Pas de support
 
Fonctionnalité Android Firefox Mobile (Gecko) Firefox OS (Gecko) IE Mobile Opera Mobile Safari Mobile
Basic support Pas de support Pas de support 1.0.1 Pas de support Pas de support Pas de support
 

 

Étiquettes et contributeurs liés au document

Étiquettes : 
 Contributeurs à cette page : loella16, wordsbybird, SphinxKnight, gudoy, teoli, tregagnon, nhoizey, Goofy
 Dernière mise à jour par : loella16,