ECT

Etoile Cercle Triangle - Blog de Damien

Applications HTML5 sur Android : la solution Geckoview de Mozilla

| Comments

Les applications HTML5 sur mobile ont pour principal avantage une portabilité élevée et donc potentiellement des coûts de développement plus réduits à mesure que le nombre de plateformes à supporter grandit. Comme la présence de ces applications dans les “stores” est un prérequis, une application HTML5 doit donc être “packagée”, c’est-à-dire encapsulée dans un lanceur écrit en code natif. Elle est alors exécutée dans ce que l’on appelle une webview, dont on peut paramétrer finement le comportement : activer ou non le zoom, taille du cache HTML5, gestion particulière de la sécurité, …

Voici une synthèse des webviews disponibles selon les plateformes :

  • Windows 8.x Pro : IE 10/11 dans un mode d’exécution adapté à une application HTML5
  • iOS : Safari, amputé de son moteur d’exécution Javascript performant
  • Firefox OS : Firefox dans un mode d’exécution adapté à une application HTML5
  • Android <= 4.3.x : un “truc” vaguement basé sur Chromium, le moteur partagé avec Chrome, peu compatible avec HTML5 : WebGL, WebRTC, Websockets, SSE, … sont manquants
  • Android >= 4.4 : une image de Chrome pour Android, mais qui, a priori, se met à jour uniquement avec Android lui-même

Que valent ces navigateurs ?

Prenez une application HTML5 qui a été conçue pour se faire passer pour du natif, c’est-à-dire reposant massivement sur des animations, des rotations, des effets de fondus, d’apparition avec dégradés, du défilement infini … comme j’ai pu en voir une récemment.

Sur iPad 4, les performances du HTML5 sont très proches de celles du natif. Il faut pratiquer longuement les deux versions pour les différencier et se rendre compte petit à petit que la version HTML5 est un peu moins fluide, un peu moins réactive, que quelques animations saccadent, … Pour cette application, inutile de faire du natif sur cette plateforme. Sur l’iPad 5 Air que je viens de tester, il n’y a plus de différence.

Sur une vraie tablette Windows 8 Lenovo, j’ai été très, mais vraiment très surpris des excellentes performances d’IE10. Elles sont du niveau de celles d’iOS. Les résultats du travail de Microsoft sont là, HTML5 est une plateforme de développement crédible sur Windows 8.

Enfin sur des tablettes Android (Nexus 10, Notes 10.1), ce fut la douche froide : saccades, blocages, disparitions purement et simplement de certaines animations (trop lentes pour être affichées ?), malgré de nombreux efforts pour ajouter des optimisations, des accélérations matérielles, … sans succès notable. L’application est inutilisable, son ergonomie doit être revue à la baisse pour cette plateforme.

Voici un extrait d’un rapport de bug Android qui résume bien la problématique :

Webview for Android is the Internet Explorer of the mobile world.

La *webview* d’Android est l’Internet Explorer du monde mobile.

En effet, comme Android est aujourd’hui la plateforme mobile dominante sur le marché, une stratégie de développement d’applications “sexies” basée sur HTML5 vous expose donc à l’ire et aux complaintes de vos utilisateurs équipés de terminaux Android. Et même si le moteur de la webview a été mis à jour dans Android 4.4 (très proche de Chrome pour Android), des fonctionnalités importantes de HTML5 ne sont pas encore disponibles (WebGL, WebRTC, … Websockets ?) et il faudra des années à cette nouvelle version pour être suffisamment déployée.

En 2013, résoudre ce problème sur Android se résume donc très simplement : embarquer un moteur HTML performant directement dans les applications HTML5, sous forme d’une librairie statique. Le moteur HTML5 fourni avec la version d’Android livrée avec votre tablette ou votre smartphone ne serait ainsi plus utilisé, remplacé par un Chrome ou un Firefox performant.

Voyons donc les travaux proposées qui me paraissent les plus prometteurs :

C’est surtout le deuxième qui me semble le plus prometteur, parce qu’il ne se restreint pas à la seule plateforme Android. L’ambition de ce projet est de fournir une webview basée sur Firefox pour toutes les plateformes, d’aujourd’hui ou à venir, mobiles ou non : Android, Windows, Linux, … Seul iOS fait exception car les restrictions imposées par Apple ne permettent pas de déployer Firefox dans de bonnes conditions. Mais c’est sans conséquence pour une application HTML5, iOS étant une plateforme de choix pour exécuter du HTML5 comme nous l’avons déjà évoqué plus haut. Au prix de 25Mo (!), Geckoview est compatible avec les versions Android 2.x / 3.x / 4.x et avec toutes les fonctionnalités HTML5 avancées : à vous SSE, websockets, WebGL, …

Le projet est très actif et il est d’ores et déjà possible de monter des prototypes avec le code mis à disposition par l’équipe de développement, qui propose notamment un navigateur basé sur Geckoview. Pour l’avoir déjà mis en oeuvre sur un projet à titre de démonstration, c’est très, très prometteur : sur la fameuse application qui veut se faire passer pour du natif dont je vous ai parlé plus haut, les performances du HTML5 sont très proches de celles du natif !

Geckoview est-il l’avenir du HTML5 sur Android ?

Compte-tenu du fait qu’Android 4.4 ne résout que partiellement la problématique, la solution qui consiste à embarquer un nouveau moteur de webview directement dans nos applications HTML5 à de l’avenir. Et sur ce point, Mozilla est bien parti.

Configurer Play Framework 2.x avec un repository Artifactory

| Comments

[Play Framework[(play2] utilise Scala SBT comme outil de build depuis la version 2.0. A la Maven, il télécharge les dépendances de votre projet Play Framework depuis des dépôts centralisés, comme Maven Central.

Cette technique est très intéressante, mais il faut bien tenir compte des inconvénients induits :

  1. Pas de maîtrise des dépendances ou des dépôts configurés par les développeurs : on télécharge n’importe quoi depuis n’importe où

  2. Gâchi de bande passante / latence : chaque développeur télécharge chaque dépendance depuis Internet, là où une mutualisation depuis un serveur localisé dans le réseau de l’entreprise ferait économiser de la bande passante et gagner en réactivité (latence réduite)

  3. Vous ne pouvez pas dépendre d’artifacts uniquement internes à votre entreprise (sans les publier sur Internet)

En entreprise, 1/ est généralement résolu par “blocage naturel” : on ne peut pas télécharger depuis Internet. 2/ et 3/ peuvent se résoudre à l’aide d’un serveur proxy dédié à Maven, SBT, … comme Sonatype Nexus ou JFrog Artifactory.

Comment paramétrer Play Framework pour utiliser Artifactory ?

[J’ai déjà expliqué comment configurer SBT pour utiliser Artifactory][/configurer-scala-sbt-repository-artifactory/], mais, bien que Play Framework utilise SBT, ces explications ne s’y appliquent pas (pour le moment). SBT étant embarqué dans Play Framework, il ne lit pas les instructions de configuration fournies en ligne de commande.

Pas de différence du côté d’Artifactory en revanche.

Par la suite, je suppose que la variable PLAY_HOME pointe vers votre installation de Play Framework 2.x.

Configurer SBT pour lire les dépôts “miroirs”

Créez le fichier ~/sbt/.repositories avec le contenu suivant :

~/sbt/.repositories
1
2
3
4
5
[repositories]
  local
  maven-local
  ivy-proxy-releases: http://localhost:8180/artifactory/ivy-remote-repos/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
  maven-proxy-releases: http://localhost:8180/artifactory/maven-remote-repos/

Ce fichier indique à SBT l’ensemble des dépôts qu’il peut consulter pour résoudre les dépendances :

  • local : dépôt Ivy local par défaut, localisé dans ~/.ivy2/

  • maven-local : dépôt Maven local par défaut, localisé dans ~/.m2/repository/

  • ivy-proxy-releases : suivi d’une URL et d’un pattern, on indique à SBT qu’il pourra trouver les artifacts qui respectent ce pattern dans ce dépôts (pattern Ivy)

  • maven-proxy-releases : suivi d’une URL, le dépôt au format Maven pour les autres dépendances

Forcer Play Framework à lire le fichier ~/sbt/.repositories

Éditez le fichier $PLAY_HOME/framework/sbt/sbt.boot.properties et complétez le bloc suivant :

$PLAY_HOME/framework/sbt/sbt.boot.properties
1
2
3
...
[ivy]
  ivy-home: ${play.home}/../repository

De cette manière :

$PLAY_HOME/framework/sbt/sbt.boot.properties
1
2
3
4
5
...
[ivy]
  ivy-home: ${play.home}/../repository
  override-build-repos: ${sbt.override.build.repos-true}
  repository-config: ${sbt.global.base-${user.home}/.sbt}/repositories

Avec ces deux instructions, on force Play Framework à utiliser uniquement les dépôts configurés dans le fichier ~/sbt/.repositories.

Tester

Commencez par nettoyer votre dépôt local de cache de Play Framework (par précaution, je vous propose de simplement le déplacer) :

1
mv $PLAY_HOME/repository/cache $PLAY_HOME/repository/cache.old

Postionnez-vous dans un projet Play, et testez :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
dlecan@portable:~/dev/projet_test$ play
[info] Loading global plugins from /home/dlecan/.sbt/plugins
[info] Updating {file:/home/dlecan/.sbt/plugins/}default-ccfcd1...
[info] Resolving org.scala-sbt#precompiled-2_10_0;0.12.2 ...
[info] downloading http://localhost:8180/artifactory/ivy-remote-repos/com.typesafe.sbt/sbt-pgp/scala_2.9.2/sbt_0.12/0.8/jars/sbt-pgp.jar ...
[info]  [SUCCESSFUL ] com.typesafe.sbt#sbt-pgp;0.8!sbt-pgp.jar (50ms)
[info] downloading http://localhost:8180/artifactory/maven-remote-repos/com/github/mpeltonen/sbt-idea_2.9.2_0.12/1.4.0/sbt-idea-1.4.0.jar ...
[info]  [SUCCESSFUL ] com.github.mpeltonen#sbt-idea;1.4.0!sbt-idea.jar (37ms)
[info] downloading http://localhost:8180/artifactory/maven-remote-repos/com/jsuereth/gpg-library_2.9.2/0.8/gpg-library_2.9.2-0.8.jar ...
[info]  [SUCCESSFUL ] com.jsuereth#gpg-library_2.9.2;0.8!gpg-library_2.9.2.jar (29ms)
[info] downloading http://localhost:8180/artifactory/maven-remote-repos/org/bouncycastle/bcpg-jdk16/1.46/bcpg-jdk16-1.46.jar ...
[info]  [SUCCESSFUL ] org.bouncycastle#bcpg-jdk16;1.46!bcpg-jdk16.jar (21ms)
[info] downloading http://localhost:8180/artifactory/maven-remote-repos/org/bouncycastle/bcprov-jdk16/1.46/bcprov-jdk16-1.46.jar ...
[info]  [SUCCESSFUL ] org.bouncycastle#bcprov-jdk16;1.46!bcprov-jdk16.jar (41ms)
[info] Done updating.
[info] Loading project definition from /home/dlecan/dev/truc/project
[info] Set current project to truc (in build file:/home/dlecan/dev/truc/)
       _            _
 _ __ | | __ _ _  _| |
| '_ \| |/ _' | || |_|
|  __/|_|\____|\__ (_)
|_|            |__/

play! 2.1.1 (using Java 1.7.0_21 and Scala 2.10.0), http://www.playframework.org

> Type "help play" or "license" for more information.
> Type "exit" or use Ctrl+D to leave this console.

[projet_test] $

Les dépendances sont téléchargées depuis http://localhost:8180/..., comme voulu.

Note : l’affichage obtenu peut varier selon vos dépendances paramétrées.