BlackBerry10 et Ajax

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, si l’on avait l’idée de faire de l’hybride et d’avoir, par exemple, la navigation en natif et l’affichage du contenu en web avec une webview, une bien âpre surprise nous attend : 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.

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).

Or, côté applications mobiles les pages web peuvent être embarquées dans l’application (en local sur le terminal) et faire appel à des scripts JavaScript distants. Un OS ne peut donc idéalement ni bloquer tous les sites distants (trop contraignant, on ne pourrait plus développer d’application HTML5), ni les autoriser tous (trop risqué).

C’est pourquoi, 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. Ce niveau de sécurité a été ajouté par Cordova.

Côté WebWorks, un fichier XML permet de configurer cette whitelist des domaines autorisés pour de l’AJAX. Par contre 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é.

Pourquoi BlackBerry n’a pas permis à la webview de Cascades d’avoir la même richesse que la webview de WebWorks ? Etaient-ils pressés ? N’avaient ils pas prévu que certains essayeraient de combiner web et natif ?

Un des avantages de Cascades est son langage, le QML : un mélange de Javascript et de langage clé/valeur tout simple. Si vous savez coder en Javascript et que vous avez déjà fait vos armes sur des frameworks comme Sencha Touch ou Enyo.js, vous savez coder en QML et vous pouvez faire une application BlackBerry10 !

Et 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. Ni une ni deux, nous voici donc embarqués dans un palliatif à l’ancienne : une passerelle entre web et natif afin de pouvoir communiquer avec le monde extérieur via Ajax.

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 jQueryUne 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 !

Vous trouverez un code d’exemple de tout cela sur Gist ici. Ce « fix » fonctionne pour jQuery et Zepto mais vous pourrez sûrement l’adapter à d’autres frameworks.

Même si nous n’utilisons pas tel quel ce bout de code (nous l’avons un peu mieux empaqueté que ça, un jour on vous montrera) l’essentiel est là. Nous utilisons cette technique avec succès sur plusieurs applications BlackBerry en cours de développement.

Nous sommes d’accord qu’il s’agit d’une solution pas très belle, mais sur ce coup là, BlackBerry aurait pu mieux anticiper les besoins de ses développeurs.