Introduction à Firefox OS

• Depuis 20 ans, les navigateurs évoluent
• 1991: Ce sont des liseuses de document
• Aujourd'hui: Ce sont des « runtimes » applicatifs

• L'accès à une fonctionnalité matérielle passe toujours par une API
• L'appel à cette API peut être autorisée ou non, au cas par cas
• Différentes règles sont appliquées : accord de l'utilisateur, accord implicite, application installée ou non
• Une API non standardisée (donc expérimentale) va être limitée aux applications installées

        {
          "name": "My App",
          "description": "My elevator pitch goes here",
          "launch_path": "/",
          "icons": { "128": "/img/icon-128.png" },
          "developer": {
            "name": "Your name or organization",
            "url": "http://your-homepage-here.org"
          }
        }
      

App manifest

• Contenu Web - sans privilèges particuliers, mais permet tout de même l'accès à certaines APIs (ex: géolocalisation)
• Applications hébergées - stockées et servies par un serveur web. Facile à mettre à jour, mais a un accès limité aux APIs.
• Applications packagées - packagées dans des fichiers ZIP, elles peuvent être installées depuis n'importe quel site.
• Applications privilégiées - revues par la Marketplace, packagées, et signées par une clé identifiant la Marketplace.
• Applications certifiers - ces applications font partie du système et ne peuvent pas être installées autrement.

App permissions

        var installapp = navigator.mozApps.install(manifestURL);
        installapp.onsuccess = function(data) {
          // L'app est installée
        };
        installapp.onerror = function() {
         // L'app n'est pas installée, et l'erreur est:
         // installapp.error.name
        };
        

• Des API ouvertes et standards pour accéder au materiel
• Créées, proposées et discutées avec les autres contructeurs de navigateur via les organismes de standardisation.
• Une bonne façon d'interagir avec le matériel via JavaScript
• Asynchrone — Tous les accès sont gérés via un gestionnaire de succès et d'erreur expliquant ce qui s'est passé de manière claire
• Chapoté par un modèle de sécurité à 3 niveaux permettant de donner des pouvoirs plus ou moins étendus aux applications selon leur mode de distribution.

WebAPIs on MDN

• Vibration API
• Screen Orientation
• Geolocation API
• Pointer Lock API
• Open WebApps
• Network Information API
• Battery Status API
• Alarm API
• Push Notifications API
• WebFM API / FMRadio
• WebPayment
• IndexedDB
• Ambient light sensor
• Proximity sensor
• Notification
• etc

Using WebAPIs to make the web layer more capable

• Gérer le cache et la latence: Application Cache, Storage, IndexedDB, Offline.
• Accéder au materiel: Sensor/Device API (devicemotion, deviceorientation, etc.)
• Sortir du navigateur: Notifications
• Travailler avec le réseau: Web Socket
• Optimiser vos applications: Page Visibility API

• Une base de données de type « index »
• Attention, ce n'est pas du SQL
• On stocke des paires clé/valeur
• Le moindre changement repose sur le concept de transaction
• L'API est totalement asynchrone

IndexedDB on MDN

• Les applications peuvent s'abonner à des messages système.
• Le principe, c'est que l'application peut être lancée pour recevoir ce message.
• Beaucoup de fonctions sont implémentées avec ce principe: push notifications, téléphonie, sms, activités

• Vitesse de lancement
• Listes infinies
• Mises à jour
• Applications packagées
• "Janks" dans les animations et les rendus
• Gestion de la mémoire dans une "one-page webapp"
• Utilisation des multiples coeurs

• Les Workers s'exécutent dans un thread séparé.
• Ils n'ont pas un accès direct au DOM.
• La communication se fait par messages asynchrones.
• On n'a pas accès à toutes les APIs (mais accès à IndexedDB !).
• Shared Workers: workers partagés pour une même origine.
• Idée 1: utiliser les Shared Workers pour le modèle de l'application et les contrôleurs.

• La nouvelle manière de faire du cache offline dans le navigateur
• Se pose en coupure des requêtes
• Idée 2: conserver un cache de la page dynamique
• Idée 3: gérer une mise à jour incrémentale d'une application
• Idée 3bis: pouvoir faire de l'A/B testing
• Idée 4: servir toutes les applications (même préinstallées) en HTTP(S): permet aussi la mise à jour incrémentale de toutes les applications.

• Pour rappel, les iframes insèrent un contexte de navigation à l'intérieur d'une page Web.
• Idée 5: utiliser des documents séparés pour les différentes vues, utiliser les iframes pour les insérer.
• Idée 6: supprimer une iframe permet de libérer la mémoire.
• Idée 7: on peut facilement afficher des vues différemment sur des devices différents.
• Idée 8: dans la page maître, récupérer des données automatiquement (mémoire, vitesse, etc) pour faire de la télémétrie
• Aucune obligation: les Single-Page Apps fonctionneront toujours !

• Julien Wajsberg
• (avec des bouts de Jérémie Patonnier)
• Introduction à Firefox OS