Pour tester des applications web à destination des terminaux mobiles on test souvent dans son navigateur avec une url file://
Si vous chargez d'autres pages en ajax depuis celle-ci vous aurez une jolie erreur de Chrome.
Pour l'éviter il fallait lancer Chrome avec un flag particulier.
open -a Google\ Chrome --args --disable-web-security
En fait, celui-ci est + sûr, car il autorise uniquement ce que vous voulez, sans autoriser tous les onglets à charger joyeusement n'importe quoi en cross-domain :
open -a Google\ Chrome --args --allow-file-access-from-files --allow-file-access --allow-cross-origin-auth-prompt
Dans ces slides, Patrick Hamann nous rappelle que :
Cela ne veut pas dire que vous avez une seconde pour votre page, non non...
A vrai dire en enlevant tout l'overhead du réseau et du serveur... vous n'en avez que 200ms !
Et parce que parfois, entre "application qui rame" et "application réactive" il n'y a pas grand chose, il conseille d'utiliser les CSS inline (entre autre) pour afficher le début de la page ASAP
En bref, je vous conseille de regarder ses slides, très intéressants :)
J'ai publié sur le blog d'haploid un article pour aider a choisir son framework JavaScript pour le développement d'applications HTML5 sur mobile
Voici un petit résumé.
SenchaTouch est tellement « ios-like » que vous devrez la plupart du temps tout casser pour tout reconstruire lorsque vous passerez à la version Android de votre application. Le scrolling rame, et apprendre les subtilités de la doc va vous prendre tout votre temps.
jQueryMobile est presque bien, mais si vous visez de vieux terminaux votre application risque tout de même de commencer à ramer. Il faiut jQuery pour utiliser jQueryMobile et même après un custom build (en bêta), le total est assez lourd. Bien qu’ils aient récemment réduit la quantité de manipulations de ce type, jQueryMobile manipule aussi pas mal le DOM lorsqu’il « améliore » votre HTML pour le rendu des différents composants. Cette opération peut s'avérer coûteuse en performances sur un smartphone.
Go Zepto !
Zepto.js par contre est pas mal ! C'est une librairie JavaScript qui reprend les principales fonctionnalités de jQuery mais avec juste ce qu’il faut pour les mobiles. Il a l’énorme avantage d’être tout petit (25ko) et de ne pas vous dépayser si vous venez de jQuery.
Complétez Zepto par un système de templating JavaScript comme mustache.js ou mieux Handlebars :
Handlebars est un système de templates évolutif à base d’accolade. Il permet de générer du code HTML à partir de données. Il peut gérer les listes, les conditions et permet même de définir ses propres tags.
Ce couple de librairies, Zepto et Handlebars, pèse 30ko au total, de quoi garder de la place pour votre code métier!
Dans le monde de BlackBerry 10 on a le choix de développer nos applications en web pur (HTML5, javascript, CSS) avec WebWorks, ou en natif (c++ et QML) avec le framework Cascades.
Dans WebWorks, la webview proposée est géniale : Elle contient toutes les features HTML5 que l'on veut, de la vidéo à la liste des contacts en passant par le localStorage ou les différents capteurs du terminal.
Par contre, côté Cascades, la webview est minimaliste, ne contient pas toutes les API disponibles sous WebWorks et est même lamentablement buggée sur certains points.
L'un de ces points est l'AJAX, mais une solution existe, voici comment s'en sortir.
Un problème de sécurité
L'Ajax, fonctionnalité qui permet d'aller charger dynamiquement des données sur un serveur, en javascript, sans quitter la page en cours, pose des problèmes de sécurité : Théoriquement, rien n'empêche un code javascript bienveillant d'insérer un script malveillant qui irait publier sur un serveur inconnu l'ensemble de vos données personnelles. Du coup, la plupart du temps, sur un site web classique, les scripts doivent venir du serveur qui a servi la page web ou d'un CDN connu (Google, Yahoo, etc).
Sur iOS ou Android, si l'on utilise Apache Cordova, on trouve une "whitelist" : chaque application défini une liste des serveurs autorisés à lui fournir du code JavaScript.
Hélas, côté Cascades, rien n'est prévu : tous les appels AJAX sont bloqués et renvoient l'erreur 0 : signe qu'ils ont été bloqués pour des raisons de sécurité.
Le QML à la rescousse
La bonne nouvelle c'est qu'en Javascript, côté QML, les appels Ajax ne sont pas bloqués! Et que la webview et le natif peuvent relativement facilement communiquer entre eux.
Voici donc un palliatif à l'ancienne : une passerelle entre web et natif afin de pouvoir communiquer avec le monde extérieur via Ajax.
Le principe est le suivant :
Côté web, on écrase la fonction $.ajax utilisée par jQuery ou Zepto par la notre.
Celle ci envoie l'ensemble des paramètres et options de l'appel AJAX au natif.
Elle stocke côté web au passage une fonction qui va traiter le résultat et envoie l'identifiant de cette fonction au natif.
Le natif fait l'appel Ajax en respectant au maximum les options (type POST ou GET, les paramètres, etc) du $.ajax de jQuery
Une fois le résultat obtenu, le natif envoie au web le résultat en lui redonnant l'identifiant de fonction préalablement reçu.
Le web appelle la fonction identifiée en lui passant les résultats reçus de la requête ajax.
Le web appelle la callback "success" ou "error" initialement passée à $.ajax afin de traiter le résultat.
Ainsi, aucun besoin de changer vos habitudes, appelez vos fonctions $.ajax, $.post ou $.get comme avant !
Attention voici le code :
https://gist.github.com/ggendre/6507448
Ce "fix" fonctionne pour jQuery et Zepto mais vous pourrez sûrement l'adapter à d'autres frameworks.
Même si je n'utilise pas tel quel ce bout de code l'essentiel est là.
Le LocalStorage est cassé sur Android, il ne marche que dans la webview courante. Pour notre framework hybride à Haploid, nous avons du le réparer afin de pouvoir utiliser le même localStorage dans toutes nos webview et pouvoir se baser sur les même données.
il est de 2009 et, au début, je l'aimais pas. Seulement à force de le voir j'en suis venu a aimer son bazar de courbes ratées. J'ai fini par lui donner un nom et le signer un an et demi plus tard.
le premier grand format vraiment réussi. il date de 2006 ou 2007, il fait 50*90cm, dessiné au posca sur... du revêtement toile pour mur. ça lui donne un effet poilu redoutable! ;)
stormborns
izzy806
romaincrisis
origamiaround
turnnoffyourmind
snowghoul
dededos