Découverte des Chrome Apps Mobiles

En Janvier, la mise à disposition d’une chaîne de développement permettant de créer ses applications  Chrome “natives” sur les plateformes mobiles a été annoncée par Google. Après avoir fait un premier tour d’horizon sur les Chrome Apps « Desktop », nous allons maintenant faire un tour des Chrome Apps sur Mobile.

(c) Chrome

(c) Chrome

 

Il est tentant de penser que les Chrome Apps mobile s’exécutent en s’appuyant sur l’application Chrome installée votre device (que ce soit sur Android ou sur IOS). Il s’agit en réalité d’une chaine de compilation – actuellement en mode Developer Preview (c’est-à-dire, pas encore stable) – qui s’appuie sur Apache Cordova pour créer des applications natives à partir du code d’applications Chrome. Nous allons faire un tour d’horizon sur ce toolkit et les particularités des applications Chrome pour mobile.

Quelques rappels sur Cordova

Créer des applications mobiles natives avec CordovaCordova permet de créer des applications natives pour plateformes mobiles (entre autres pour Android, IOS, BlackBerry, etc.) à partir d’application Web codées en HTML et JavaScript, tout en offrant un ensemble d’API plus puissantes permettant de tirer parti des fonctionnalités offertes par le matériel. Ainsi, avec une application Cordova, on pourra facilement accéder aux fonctionnalités de l’accéléromètre, la boussole, la géolocalisation, le stockage hors-ligne, la caméra, le système de notifications.

Quand Adobe a relâché PhoneGap à la communauté Open Source, il a été appelé Cordova et réversé à la fondation Apache. Google contribue activement au développement de Cordova. Notamment sous la forme de plugins Cordova qui implémentent les API Chrome. L’idée est de proposer les API « clés » de Chrome pour les utiliser au sein des plateformes Android et IOS. Cordova va créer une application « coquille » native autour de notre application Chrome codée en HTML et JavaScript. Pour les rappels sur l’utilisation de Cordova, n’hesitez pas à jeter un œil sur l’article « Créer des applications hybrides avec PhoneGap » publié dans Programmez n°164.

La Chrome App s’exécute au sein des Webviews d’applications natives créées avec Cordova. Sur IOS, c’est le UIWebControl. Sur Android, seul KitKat (Android 4.4) propose un WebView s’appuyant sur un moteur Chromium (l’implémentation Open Source de Chrome) et qui inclus donc les avancées du moteur Javascript V8 ainsi qu’un meilleur support des standards Web. Cependant, cette version de Chrome est pour l’instant limitée à la version 30 et vit indépendamment de la version « application » installée. L’implémentation de Chrome dans les Webviews comporte également donc encore quelques limitations. Pour les versions antérieures d’Android, on s’appuie sur le moteur de rendu du Android Browser (qui lui, est basé sur WebKit).

En savoir +

Limitations

Il y a plusieurs limitations à l’heure actuelle, car les outils sont encore en cours de développement, notamment, certaines fonctionnalités Web sont désactivées ; heureusement elles sont portées par Cordova. Ainsi une application Chrome peut ne pas fonctionner telle quelle sur Mobile. La plupart des problèmes ergonomiques sont également recensés, car une application Dekstop ne réagira par identiquement qu’une plateforme Mobile :

  • Problèmes de layout sur des petits écrans, notamment en orientation portrait. Utiliser les media-queries CSS permet d’optimiser l’affichage du contenu pour les plus petits écrans.
  • La taille des fenêtres indiquées via chrome.app.window sont ignorées et prennent la dimension de l’écran du mobile. Il est préférable de supprimer les dimensions codées en dur et de concevoir son application avec différentes tailles à l’esprit.
  • Les boutons de petite taille et les liens sont durs à taper avec les doigts. Il est recommandé de faire en sorte que les éléments à toucher soient au minimum en résolution 44×44 px.
  • Les événements de survol de souris ont un comportement incertain. Il est préférable d’ajouter des interactions également sur les événements tap (notamment pour l’affichage de menus déroulants par exemple).
  • Un délai de tap de 300 ms. Pour ce dernier point, certaines solutions techniques autour de librairies tierces FastClick, ou des mises à jour de Chrome (à partir de la version35) corrigent ce point.

Beaucoup d’API sont disponibles, parmi lesquelles : identity (OAuth2), Payments, pushMessaging, sockets, notifications (seulement Android), storage, syncFileSystem, alarms, idle, power. Cependant, toutes les API JavaScript de Chrome ne sont pas implémentées et toutes les fonctionnalités des applications Chrome « Desktop » ne sont pas disponibles : notamment, la balise webview, indexedDB, getUserMedia(), le code natif NaCL. Le tableau ci-dessous recense les fonctionnalités portées sur mobile par plateforme :

Fonctionnalités mobiles Chrome

1) Les alarmes ne se déclenchent que si l’application est au premier plan

2) Les méthodes JS (chrome.i18n) sont fonctionnelles mais pas les instructions CSS.

3)Qualité Bêta

4) Local storage only. Le sync storage fonctionne en mode dégradé (comme storage.local)

5) Qualité Alpha

Cette liste va évoluer au fur et à mesure de l’avancement, les détails sont disponibles ici.

Installation

Dans cette partie nous allons nous concentrer sur la création d’un nouveau projet pour la plateforme Android. L’installation et la création de projet pour la plateforme IOS sont similaires en adaptant à l’IDE  XCode.

Pour les deux plateformes

Il faut installer Node.js et le plugin Chrome-Cordova-Application (CCA).

Node.js est nécessaire pour les installations suivantes et la gestion de dépendances via NPM. Il suffit de récupérer l’installeur sur le site officiel  et de lancer l’installation standard.

Chrome-Cordova-Application intègre Cordova ainsi que les plugins nécessaires à la constitution de l’application Chrome mobile. L’installation se fait via npm en lançant la commande npm install –g cca.

Pour Android

Il faut commencer par installer Java JDK et le SDK Android sous C:\Development\android-sdk-windows par exemple.
La variable d’environnement PATH doit contenir le chemin vers les tools et platform-tools du SDK :
C:\Development\android-sdk-windows\platform-tools
C:\Development\android-sdk-windows\tools

Il faut également s’assurer de l’ajout du SDK cible (depuis le Android SDK Tools) ainsi que du driver du device. A cette étape, la commande android et tous les outils associés doivent être accessibles en ligne de commande et le device doit être reconnu par adb.

Pour IOS

Pour le développement IOS, il est nécessaire d’utiliser Mac OS, installer XCode 5. Nous utilisons également ios-deploy pour installer et déployer des applications depuis la ligne de commande. Ios-deploy s’installe en lançant la commande npm install –g ios-deploy, ainsi que ios-sim () pour nous permettre de lancer l’application sur le simulateur en ligne de commande. ios-sim s’installe depuis npm en lançant la commande npm install –g ios-sim.

Vérification

Vérifier si tout est bien installé en lançant la commande cca checkenv:


$ cca checkenv
cca v0.0.9
## Checking that tools are installed
Android SDK detected.

A noter que l’étape de checkenv sera effectuée à chaque fois que la commande cca est lancée. Pour utiliser Cordova avec une application Chrome existante, on utilisera l’outil cca (Cordova Chrome App) en ligne de commande.

Création d’un nouveau projet

Il est possible de créer un projet vide ou de créer un projet à partir des sources d’une application Chrome existante.

Pour la création d’un projet vide :

 $ cca create MonApp 

MonApp représente le nom de l’application.

Si les sources de l’application Chrome existent déjà, il est possible de les importer lors de la création du projet en utilisant la commande :

 $ cca create YourApp --copy-from=path/to/manifest.json 

Les ressources seront alors copiées dans le répertoire www. On obtient alors l’arborescence suivante :

Arborescence

Spécificité des développements Chrome App mobile

Cycle de vie et événements

Dans le modèle Chrome, les applications peuvent être notifiées par plusieurs évènements de cycle de vie applicatif. Ils sont notamment lancés lorsque l’application se lance et s’arrête ou en réponse à certaines actions utilisateur, comme l’installation de mise à jour. Comprendre ceci est crucial pour développer une application qui peut sauver et restaurer son état effectivement sur un desktop et mobile.

Cycle de vie des événements Chrome Apps

On compte parmi les évènements : onRestarted, onInstalled, onLaunched, onSuspend, onSuspendCancelled. Malgré le fait que ces événements soient disponibles sur les différentes plateformes, ils ne sont pas déclenchés au même moment et ils ont une sémantique différente entre l’environnement Desktop et l’environnement mobile dont il faut avoir conscience pour le développement de son application Chrome App Mobile.

Sur Desktop :

  • Au lancement, la page background est lancée ;
  • onRestarted peut être lancé si Chrome s’est arrêté inopinément ;
  • onInstalled peut être lancé si l’application vient juste d’être installée ou mise à jour ;
  • Quand l’application est lancée : onLaunched est déclenché ;
  • Quand toutes les fenêtres de l’application sont mises en arrière-plan, l’application peut être suspendue. Dans ce cas, onSuspend est déclenché.
  • Si l’application est remise au premier plan, avant d’être terminée, onSuspendCanceled est déclenché.

Sur Mobile :

En général, les utilisateurs ne ferment pas les fenêtres ni les applications directement. C’est l’OS qui s’occupe de fermer les applications (elles sont suspendues et peuvent être terminées à n’importe quel moment), mais l’utilisateur n’en a pas conscience, car les applications ne sont pas visibles en même temps. La plupart des applications ne démarrent pas sans l’intention d’être lancées et ne tournent pas en arrière-plan (dès qu’elles sont cachées, elles sont suspendues).

Cycle de vie des énéments Chrome Apps

Ainsi l’évènementiel du cycle de vie est différent, trois évènements peuvent apparaître lors du démarrage :

  • onRestarted : seulement si l’application s’est arrêtée prématurément. Cela signifie qu’un évènement précédant onSuspend n’a pas été exécuté jusqu’au bout.
  • onInstalled – quand la version indiquée dans le manifest.json a changé (et donc également lors de la première installation).
  • onLaunched – dans tous les cas au lancement de l’application étant donné que les applications sont immédiatement lancées au démarrage sur mobile.

Ces évènements seront lancés après que les scripts background aient été exécutés, il faut donc attacher des listeners pour ceux-ci. Si l’application n’est pas éteinte, et est seulement remise au premier plan, seul onSuspendCanceled sera déclenché.

Lors d’une reprise :

  • Chaque fois que l’utilisateur switche d’application, l’application Chrome devient suspendue. onSuspend est déclenché, parce que l’OS peut détruire l’application à n’importe quel moment.
  • Si l’utilisateur revient sur l’application avant que l’OS ne l’ait détruite, onSuspendCanceled est déclenché.
  • C’est la responsabilité de l’application de sauver son état quand onSuspend est appelé.
  • Si l’application est tuée par l’OS pendant que l’application est proprement suspendue, c’est un arrêt « propre ». Lors du prochain démarrage, onLaunched sera donc déclenché.
  • Si l’application est tuée par l’OS alors que la suspension est incomplète, alors, onSuspendCanceled ne sera déclenché, mais à la place onRestarted.

Manifest Mobile

Le fichier manifest.mobile.json est un complément au manifest.json qui permet d’indiquer les paramétrages spécifiques aux applications mobiles. Par exemple, les spécifications de version de Android (versionCode) ou IOS (CFBundleVersion), et qui n’apparaissent donc pas dans le Manifest générique.


{
"packageId": "com.your.company.HelloWorld",
"versionCode": 1,
"CFBundleVersion": "1.1.1"
}

La documentation des API indique si des propriétés doivent être ajoutées spécifiquement au fichier manifest.mobile.json. La commande cca prepare va ensuite constituer les fichiers natifs en récupérant les paramétrages issus des manifest.json et manifest.mobile.json. Par exemple, le Manifest Android (Manifest.xml nécessaire à la constitution de l’APK) : le champ android:versionName est déduit de la version de l’application renseignée dans le manifest.json et le champ android:versionCode est déduit du fichier manifest.mobile.json. La commande cca prepare est automatiquement ré-exécutée lors des commandes cca build, cca run ou cca emulate. Par contre, lors du développement depuis l’IDE, elle ne sera pas exécutée. Il faudra donc lancer la commande cca prepare manuellement pour s’assurer que les modifications des manifest Chrome soient correctement prises en compte.

Déploiement

Deux options sont envisageables pour le développement pour compiler, packager et tester l’application : utiliser l’outil en ligne de commande, ou alors les lancer depuis l’IDE. Dans les deux cas, vérifiez que le mobile est connecté en USB et reconnu par Eclipse ADT ou Xcode.

Lors de l’étape d’empaquetage, l’application native est créée (sous la forme d’un APK pour Android et d’un IPA pour IOS) et les ressources Web de l’application Chrome sont intégrées à l’application. A cette étape, il n’y a rien de spécifique à Chrome, ni à CCA. A noter que comme l’application native est créée, il faudra disposer des certificats disposer des certificats (et donc d’un compte développeur pour IOS).

Pour plus de détails sur ce point et sur le lancement d’application depuis l’IDE, n’hésitez pas à aller voir à cette adresse pour plus de détails sur le Github.

Le déploiement peut se faire comme une application native classique, à savoir sur un émulateur en lançant les commandes cca emulate android ou cca emulate ios respectivement pour les cibles Android et IOS, ou alors directement sur le device en lançant les commandes cca run android ou cca run ios.

Debugger avec Chrome Apps Developper Tools (Android only)

Le Chrome Apps Developer Tool (Chrome ADT) est une application Android qui permet de télécharger et exécuter une application Chrome sans utiliser l’outil cca. L’application est encore en cours de développement (pre-alpha) mais il est déjà disponible en version pré-packagé APK à cette adresse : https://github.com/MobileChromeApps/harness/releases/  (prendre la dernière version construite). Elle pourra être installée sur le mobile de tests. Cette application Chrome ADT offre deux facilités pour le développeur, pour exécuter des applications Chrome sans passer par la constitution d’une application native de la commande cca build.

Test à partir de CRX

Cette fonctionnalité permet d’avoir un aperçu rapide d’une application Chrome déjà packagée en CRX (issu d’une application empaquetée pour Chrome Desktop) sur le device Android, sans passer par une phase de packaging CCA.

Test à partir des sources statiques

Ici, on utilise seulement CCA pour « servir » les ressources web (HTML, CSS, JS, etc.) que l’application Chrome ADT pourra exécuter au sein d’un conteneur de test. Pour cette dernière option, on utilise la commande « cca serve » qui va créer un serveur web de ressources statiques (par défaut sur http://localhost:8000).

D:\projets\MonApp>cca serve
cca v0.0.9 …
Static file server running on port 8000 (i.e. http://localhost:8000)
CTRL + C to shut down

Depuis, l’application Chrome ADT, on indique l’URL sur laquelle cette application est servie, à savoir : http://<adresse_ip>:8000

Le gros avantage de l’outil est de supprimer les étapes d’empaquetage natif, qui peuvent être assez longues et répétitives, surtout pendant la phase de développement. Le cca serve offre en plus la possibilité de servir les ressources à chaud (dès qu’elles sont modifiées, elles sont disponibles), côté Chrome ADT, un simple « Update » permet d’avoir à disposition la dernière version de l’application. Un gain de temps considérable !

Supprimer les étapes d'empaquetage avec Chrome ADT

Exemple de l’application Chrome ADT (à gauche) – et l’application Calculator ‘servie’ et en test à droite.

Distribution

Les applications Chrome Desktop sont distribuées sur le Chrome Web Store (http://chrome.google.com/webstore), alors que CCA encapsule les applications Chrome mobiles dans une application native et sont donc, quant à elles, distribuées sur les Store mobile dédiés, à savoir Play Store pour Android, et l’App Store pour IOS.

La distribution sur le Chrome Web Store est minime (5$), mais augmente pour le Play Store (25$) et encore plus pour l’AppStore (99$/an). C’est un point à prendre en compte également si l’on souhaite ouvrir son application à plusieurs canaux !

Conclusion

Pour les développeurs qui cherchent un moyen rapide de développer une application sur du multi-device, les applications Chrome Cordova Mobile fournissent une des solutions les plus faciles à mettre en place. L’outillage basé sur Cordova permet d’avoir une base de commune ce qui permet aux développeurs d’avoir une application native et réellement portable sur tous les supports sans avoir à entrer trop en détails sur les spécificités de Android et IOS.

Pour l’instant les API disponibles sont encore limitées, mais gageons que les équipes de développement de Chrome sauront enrichir leur outil pour permettre l’accès à toutes les API et offrir des fonctionnalités équivalentes entre Desktop et Mobile.

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !