Discussion :

[zecreator]

Bonjour,

En parcourant différentes discussions sur le sujet, j'ai constater une réticence envers les applications Android embarquant un site web. Petite explication : il s'agit d'application s'installant comme n'importe quelle autre à l'aide d'un APK, qui encapsule une page de navigation web et affiche un site précis. Cela permet d'utiliser de la technologie HTML/Javascript pour développer une appli.

Alors ma question est : pourquoi est-ce mal de développer des applis de cette façon ? Est-ce par un manque de performance du composant webview ? Un soucis de sécurité ? Une consommation des ressources plus grande ?

Je dois dire que, même si j'imagine que l'on ne fera pas des merveilles en HTML/Javascript (quoique j'ai vu des réalisations en HTML5 qui étaient de véritables bijoux techniques et qui étaient bien meilleures que certains dev natifs), il me semble bien de pouvoir profiter d'un seul développement et de le déployer sur plusieurs plateforme sans avoir à recoder à chaque fois (en Java pour Android, en Objective-C pour Apple...).

Qu'en pensez-vous ?

Baptiste.

[Hizin]

Le bon point est justement d'avoir un seul socle de code, maintenance et évolutions sont ainsi plus aisées.

Les mauvais points :
- la WebView a un comportement à elle et n'est pas un navigateur : elle ne permettra pas de faire certaines choses (voir la doc' de la WebView, les balises supportées, tout ça)
- les fonctionnalités : moins de fonctionnalités possibles, mais ce n'est pas forcément un problème. Ne pas pouvoir jouer avec X alors que l'application n'en a pas besoin n'est pas un frein
- performances : une WebView est généralement moins performante que du code natif. Avec la montée en puissance des terminaux, c'est de moins en moins visible. De plus, pour une application qui n'a pas besoin d'une très grande réactivité, ce n'est pas forcément un problème. Pour le côté mémoire, je ne sais pas par contre.
- interface : les utilisateurs détestent les applications iPhone-like sur Android et vice-versa. Il faut donc gérer X vues dépendant de la cible. Des IDE permettent de faire ces séparations, mais cela complexifie clairement le travail.

Personnellement, je n'ai jamais essayé d'en faire une (le fait que je sois une buse en techno web y est pour beaucoup). Je pense que c'est ce vers quoi je me tournerai pour des applications X-platform simples.

[zecreator]

Avec la derniere version d'Android 4.4 (KitKat), la vieille webview est remplacée par une version Chomium, ce qui semble améliorer les performances des applications web embarquées.

Voici un site qui a fait plusieurs études de performances :
https://www.timroes.de/2013/11/23/ol...omium-webview/

Le résultat est sans appel, Chromium améliore vraiment la réactivité et les performances. Mais le message en fin d'article reste le même : "Pitié, arrêtez de proposer des applications web embarquées dans Google Play!". Je ne comprends toujours pas pourquoi, si l'application fonctionne et fait le boulot, ppourquoi la blamer juste parce qu'elle n'est pas développé et code natif ?

D'ailleurs, beaucoup d'applications (Android et IOS) sont faites avec Phone Gap, qui est justement un système de développement permettant d'embarquer du web comme des applis. Et Phone Gap est plutôt populaire. Il y a donc une contradiction non ?

Faisons un essai voulez-vous ? Voici un jeu que j'ai développez en HTML5/Javascript :
http://www.freetalent.fr/demos/ringtris/index.html

et voici le même site, mais embarqué dans un APK (les fichiers du site sont directement intégrés dans l'appli) :
http://www.freetalent.fr/demos/ringtris/WebBox.apk

Quelles sont les différences que vous constatées entre ces 2 versions ?

Merci.

[nicroman]

Je ne vois toujours pas l'intérêt de proposer du html statique à l'utilisateur (puisque cela revient à cela: faire sur son terminal une copie statique d'un site web distant).
Mais en même temps, je ne vois pas l'intérêt de proposer une application "native" (sous forme APK) qui n'utilise pas les fonctionnalités du téléphone:
* Notifications (push?)
* Synchronisation
* Consultation "offline"
* Utilisation d'énormément de ressources (par exemple 300Mo de textures).
* Accès aux données de l'utilisateur (images, contacts, calendriers, ...).
* Traitement continu d'une information (par ex. localisation).

Pour le reste (caméra, localisation instantanée, sons, OpenGL, ...) tout est dispo en HTML5, et un simple site web (donc pas d'APK à downloader) suffit.


Après, c'est une question d'utilisation j'imagine....

[Hephaistos007]

Pour ma part, j'avais isolé 4 critères dans cet article, Section 2. Je ne suis pas un grand fan des applis web empaquetées, mais je ne suis pas fondamentalement contre non plus

[zecreator]

Je ne vois toujours pas l'intérêt de proposer du html statique à l'utilisateur (puisque cela revient à cela: faire sur son terminal une copie statique d'un site web distant).
Mais en même temps, je ne vois pas l'intérêt de proposer une application "native" (sous forme APK) qui n'utilise pas les fonctionnalités du téléphone:
* Notifications (push?)
* Synchronisation
* Consultation "offline"
* Utilisation d'énormément de ressources (par exemple 300Mo de textures).
* Accès aux données de l'utilisateur (images, contacts, calendriers, ...).
* Traitement continu d'une information (par ex. localisation).

Au contraire, on peut faire tout cela. Il est possible d'établir une communication entre du code natif et des fonctions Javascript. Par exemple, pour mon jeu je souhaitais utiliser des effets sonores + des musiques de fond. En HTML 5, c'est assez difficile car une seule balise AUDIO est acceptée et jouable. Pire, sous IOS la webview ne lira pas automatiquement le son, il faut une action de l'utilisateur pour ça (bouton PLAY). De plus, mes musiques sont au vieux format XM (FastTracker), et il n'y a aucun moyen de lire ce format depuis Javascript. Donc, j'ai codé des fonctions en code natif, que j'ai rendu accessibles depuis mon javascript. Et le tour est joué, ça fonctionne nickel. Pareil pour l'accès au stockage du téléphone, impossible depuis javascript directement. J'ai donc écris 2 petites fonctions en code natif pour ça.

Je préfère utiliser du code natif lorsque c'est nécessaire, et utiliser HTML/Javascript pour le display. Le display en code natif, c'est assez lourding et cela demande du temps (recompilation du code, installation dans l'émulateur, déboggage...), alors qu'avec le web on peut le tester quasi immédiat.

L'utilisation de la webview ne me semble pas "farfelue". Je pense que c'est un problème de puriste du code natif. Car au final, l'utilisateur lambda ne fera pas la différence si l'application fait le job.