Options de stockage des données sur les plateformes mobiles

Publié par Vincent Crépin le mercredi 10 avril 2013 à 07:09

Lors d’un récent article sur les plateformes mobiles, je décrivais une approche technologique permettant de développer une application HTML5 et de l’exécuter en mode natif sur Android ou iOS à l’aide d’un outil nommé Apache Cordova (anciennement PhoneGap). Au cours de mon exploration, j’ai été amené à identifier plusieurs stratégies de stockage des données persistantes sur l'appareil mobile. Mon objectif principal était d'identifier les stratégies qui me permettraient de rendre l'application la plus autonome possible en terme de stockage de ses propres données et de trouver la plus optimale parmi celles-ci.

Voici les options que j'ai explorées:

  • Stockage sur un serveur et accès en utilisant des services web (SOAP ou REST)
  • Stockage sur l’appareil avec HTML5 LocalStorage
  • Stockage sur l’appareil en utilisant une base de données relationnelle (WebSQL)
  • Stockage sur l’appareil en utilisant une base de données NO-SQL, telle que IndexedDB

Chacune d'elles comporte ses avantages et inconvénients et elles peuvent même être complémentaires. C'est d'ailleurs ce que je vais décrire dans cet article.

Stockage sur un serveur et accès en utilisant des services web

Cette approche est assez conventionnelle et consiste à héberger une base de données sur un serveur et à exposer les fonctionnalités d’accès aux données (et souvent aussi de logique d’affaires) en utilisant des services Web.

Avantages: Il s'agit d'un terrain connu pour la plupart d’entre nous. Permet la centralisation et donc le contrôle des données avec une base de données SQL. Elle offre un plus grand potentiel de réutilisation des services d’accès aux données et d’affaires.

Désavantages: Nécessite de créer et d’entretenir un serveur applicatif. Cette dépendance de l’application mobile sur un serveur requiert de mettre en place une infrastructure assez robuste pour supporter tous les utilisateurs de l'application (ce qui peut entraîner des coûts importants). Nécessité d’avoir accès réseau pour que l’application fonctionne. Performance affectée par les appels distants.

Stockage sur l’appareil avec HTML5 LocalStorage

LocalStorage est une fonctionnalité de HTML5 qui permet de stocker des données persistantes dans le navigateur.

Avantages: Très simple d’utilisation (utilise une simple combinaison clé-valeur). Indépendance par rapport à toute ressource externe.

Désavantages: La capacité de stockage est limitée (5 MB). Le stockage par clé-valeur est trop simpliste pour des scénarios élaborés.

Stockage en utilisant une base de données relationnelle

Il s'agit d'un ancien standard HTML5 nommé WebSQL qui permet d’exploiter une base de données relationnelle complète dans le navigateur. La base de données utilisée est en fait SQLite.

Avantages: Offre la puissance d’un SGBD. La connaissances de SQL est très répandues, ce qui en facilite la prise en main. Modèle presqu’identique à ce que l’option serveur offre, ce qui permet de supporter les deux modèles en même temps. Possibilité de synchronisation entre la bd locale et la bd distante.

Désavantages: Ce standard a été abandonné par le W3C et donc on n’a aucune garantie que ce sera supporté dans le futur, même si actuellement la grande majorité des navigateurs le supportent.

Stockage en utilisant une base de données NO-SQL

IndexedDB est le standard que le W3C a décidé de supporter. Il s’agit d’une base de données non relationnelle qui permet de stocker directement des objets en fonction d’une clé.

Avantages: L'approche est standardisée, donc éventuellement supportée par tous les navigateurs. Il s'agit d'un concept très simple de stockage d’objets en fonction d’une clé. Les performances sont surprenantes.

Désavantages: Le standard n'est pas encore supporté dans la majorité des navigateurs, surtout sur les plateformes mobiles. Le modèle d’accès aux données est différent de celui des bd relationnelles, ce qui nécessite un certain apprentissage. L'API est assez complexe et très verbeux.

Observations

Dans les expérimentations que j’ai effectuées, j’ai implémenté les 4 modèles. Je me suis attardé à pouvoir changer d’implémentation sans avoir à modifier le code existant en fournissant le « provider » approprié. Cela faisait partie de mes objectifs.

Considérant que je souhaite rendre mes applications disponibles dans les magasins applicatifs, j’ai écarté l’option 1 qui nécessite la mise en place d’un serveur applicatif. Je la conserve cependant pour un scénario en « entreprise » qui nécessiterait ce genre de centralisation. J’ai aussi rapidement éliminé la deuxième à cause de sa capacité de stockage limitée et sa trop grande simplicité. Reste donc les 2 dernières (WebSQL et IndexedDB).

J’ai réussi à faire fonctionner entièrement mon application en utilisant WebSQL avec une assez grande facilité. Les performances sont excellentes et mon application s’exécute sans problème sur tous les navigateurs que j’ai testés. Mais, le standard n’étant plus supporté, j’ai dû me tourner vers la quatrième option.

Après avoir perdu quelques heures à essayer de comprendre les API trop verbeux d’IndexedDB, j’ai découvert que JQuery fournissait une extension pour IndexedDB qui simplifie de façon spectaculaire l’utilisation des API (il faut toujours regarder d’abord le formidable projet JQuery...). Armé de celle-ci, j’ai réussi à reconduire toutes mes fonctionnalités d’accès aux données en quelques lignes de code.

Mais comme je le mentionnais précédemment, le standard n’est pas encore supporté dans les navigateurs que je cible (plateformes mobiles). Après quelques recherches, j’ai découvert un polyfill qui permet de convertir des appels IndexedDB en WebSQL. Ce polyfill, qui est simplement un fichier Javascript, permet d’abstraire complètement le stockage réel (WebSQL) et de n’utiliser que les API d’IndexedDB. Le meilleur des deux mondes!!! Quand le standard sera supporté, il s’agira simplement de retirer le polyfill et tout devrait continuer à fonctionner normalement. Ceci constitue d’ailleurs un autre exemple éloquent que d’abstraire la technologie et les cadres applicatifs utilisés constitue toujours une stratégie gagnante et garante d’une certaine longévité.

Dans un prochain article, je m’attarderai à décrire les particularités de l’utilisation du GPS sur les plateformes mobiles. D’ici là, bon développement HTML5!!!

Références utiles

Voici quelques références utilisées dans le cadre de cette expérimentation:

Mots-Clés :
blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.