Développement d'une solution de stockage hors ligne HTML5 pour iOS / Android en 2011
Le problème:
J'ai besoin d'une solution indépendante des appareils (par exemple HTML5) pour stocker et interroger plus de 250 000 lignes de données hors ligne sur un appareil de type téléphone ou tablette (par exemple, iOS/Android). L'idée étant que j'ai des gens qui travaillent dans des régions éloignées sans aucune connexion de données cellulaires et ils doivent exécuter des requêtes sur ces données et les modifier hors ligne. En partie, il sera basé sur la géolocalisation, donc s'il y a des actifs dans la zone dans laquelle ils se trouvent (utilise le GPS), il affichera ces actifs et les laissera être modifiés. À leur retour au bureau, ils peuvent synchroniser les données avec le serveur de bureau.
La raison pour laquelle j'aborde cela d'un point de vue standard du Web est essentiellement de gagner du temps et de l'argent en l'écrivant une fois en HTML5, puis cela fonctionne sur plusieurs plateformes plutôt que de l'écrire deux fois en Objective C et Java. De plus, si vous écrivez quelque chose qui est indépendant de la plate-forme, vous n'êtes pas enfermé et ne descendez pas avec le navire lorsque tout le monde passe à un nouveau. Nous avions une application similaire écrite pour Windows Mobile 5, maintenant elle est inutile car cette plate-forme est morte.
La base de données hors ligne sur l'appareil doit être:
- rapide (réponses sous 2 secondes)
- effectuer potentiellement des jointures et entretenir des relations avec d'autres tables capables d'interroger la base de données
- sélectionner des données dans une certaine plage ou certains critères, par exemple par coordonnée x & y basée sur la lecture GPS.
Options:
Stockage local HTML5:
Très bien pour de petites quantités de données <5 000 clés/valeurs, vous pouvez même y stocker des tableaux/objets si vous les convertissez en JSON.
Contre:
- Pour plus de 10 000 lignes, même sur une machine haut de gamme, le navigateur ralentit jusqu'à une analyse.
- Impossible d'effectuer des requêtes complexes sur les données pour extraire les données que vous souhaitez car vous devez parcourir tout le stockage et les rechercher manuellement.
- Limitations de la quantité de stockage pouvant être stockée
Base de données Web SQL:
- Répond aux exigences.
- Rapide pour exécuter une requête sur 250 000 lignes (1-2 secondes)
- Peut créer des requêtes complexes, des jointures, etc.
- Pris en charge par Safari, Android et Opera fonctionnera donc sur iOS et Android appareils
Contre:
- Obsolète depuis novembre 2010
- Faille de sécurité avec les attaques inter-répertoires. Pas vraiment un problème car nous ne serons pas sur l'hébergement mutualisé
IndexedDB:
Magasin d'objets clé/valeur similaire au stockage local, sauf avec les index.
Contre:
- Lent pour exécuter une requête sur 200 000 lignes (15-18 secondes)
- Impossible d'exécuter des requêtes complexes
- Impossible de faire des jointures avec d'autres tables
- Non pris en charge par les principaux téléphones ou tablettes, par exemple iPad/Android
- Norme non terminée
Cela laisse la seule option d'implémentation de la méthode Web SQL obsolète qui ne peut fonctionner que pendant une autre année environ. La base de données indexée et le stockage local sont actuellement inutilisables.
Je ne sais pas comment Mozilla et Microsoft ont rendu la norme Web SQL Database obsolète et pourquoi le W3C l'a laissé se produire. Censément entre eux, ils détiennent 77% du marché des navigateurs de bureau. Sur les appareils mobiles avancés, Mozilla et Microsoft ont une influence presque nulle car Safari, Opera et Android a plus de 90% de part de marché La façon dont Mozilla et Microsoft peuvent dicter la norme à utiliser sur le marché mobile, qui est l'endroit où le stockage hors ligne est le plus susceptible d'être utilisé, n'a aucun sens.
Dans le commentaires de Mozilla pourquoi ils voulaient aller avec IndexedDB à la place sont principalement sur "l'esthétique du développeur" et ils n'aiment pas l'idée d'exécuter SQL en JavaScript. Je ne l'achète pas.
Actuellement, la norme proposée est inférieure et une implémentation NoSQL extrêmement basique qui est lente et ne prend même pas en charge les fonctionnalités avancées dont les gens ont besoin dans une base de données. Il y a beaucoup de code standard pour établir la base de données et extraire les données, mais ils prétendent que les gens écriront des bibliothèques d'abstraction Nice par-dessus qui fourniront des fonctionnalités plus avancées. Depuis octobre 2011, ils ne sont plus visibles.
Ils ont déconseillé la norme Web SQL existante qui fonctionne réellement et est implémentée dans les principaux navigateurs mobiles/tablettes. Alors que leur "nouveau" et "meilleur" standard n'est pas disponible dans les principaux navigateurs mobiles.
Que sommes-nous, en tant que développeurs, censés utiliser au cours des 3 à 5 prochaines années, lorsque la spécification IndexedDB pourrait être normalisée, avoir plus de fonctionnalités, implémentée dans les principaux navigateurs mobiles/tablettes et il y a quelques bibliothèques Nice pour faciliter les choses?
Le W3C devrait maintenir la norme Web SQL Database en parallèle et corriger les problèmes. Il prend déjà en charge les principales plates-formes mobiles et cela fonctionne plutôt bien. Le fait que Mozilla et Microsoft en tant que deux joueurs avec le plus grand nombre de partages de navigateurs de bureau aient pu supprimer cette norme est assez douteux et pourrait être considéré comme une tentative d'entraver les progrès sur les plates-formes Web mobiles jusqu'à ce qu'ils soient en mesure de rattraper leur retard et d'offrir solutions concurrentes contre iOS/Safari et Android.
En conclusion, quelqu'un a-t-il une solution à mon problème qui fonctionnera pour iOS/Android pour les téléphones/tablettes. Peut-être une API Nice wrapper qui peut utiliser plusieurs implémentations de base de données en arrière-plan avec une capacité d'interrogation et vous permet de choisir la base de données prioritaire. J'ai vu des choses comme lawnchair mais je suis sûr que cela ne vous permet d'utiliser le stockage local que par défaut et revient aux autres. Je pense que je préférerais qu'il utilise Web SQL (par défaut) puis les options plus lentes.
Toute aide pour une solution très appréciée, merci!
Je recommanderais de consulter la bibliothèque JayData , qui a en fait exactement pour but de créer une couche d'accès aux données indépendante du stockage pour les appareils mobiles. JayData fournit une couche d'abstraction avec JavaScript Language Query (JSLQ) et JavaScript CRUD et vous permet de travailler exactement de la même manière avec différents types de magasins de données hors ligne et en ligne. JayData prend en charge le traitement d'entités complexes ainsi que les relations d'entités, localement ou à distance.
Au moment de l'écriture, JayData prend en charge les magasins ou protocoles suivants: webSQL (sqLite)/IndexedDB/OData/YQL/FBQL.
Votre problème particulier avec différents systèmes fournissant différents moteurs de stockage peut être facilement résolu avec la fonction de secours du fournisseur de JayData: il utilisera la couche de stockage qu'il peut trouver tout en fournissant la même API vers le code consommateur.
En ce qui concerne la dépréciation de WebSQL d'ici 2012: au moment de la rédaction, c'est WebSQL qui a toujours une couverture de 95%, y compris Samsung SmartTV et Amazon Kindle. Consultez le Kindle exécutant les tests unitaires WebSQL avec JayData .
Je vérifierais CouchBase Lite. Il s'agit d'une implémentation presque complète de CouchDB qui fonctionne sur Android et iOS.
Si vous avez enveloppé votre application dans quelque chose comme PhoneGap vous pouvez créer des applications HTML 5 natives pour les deux plates-formes et vous n'auriez qu'à faire un tout petit peu de programmation spécifique Android/iOS pour implémenter CouchDB.
Avantages:
- Moteur Fast View pour interroger de nombreuses lignes de données.
- Prise en charge de la réplication simple et puissante.
Les inconvénients:
- Magasin de valeurs-clés - Il faudra un certain temps pour s'y habituer.
J'ai fait plus de recherches en recherchant une solution pour mon propre projet. Il semble que cette bibliothèque soit plutôt prometteuse: http://nparashuram.com/IndexedDBShim/
Il permet d'utiliser l'API IndexedDB ayant WebSQL en arrière-plan.
Ses tests réussissent sur iPad récent, iPhone 5, Android 4.2.2.
J'espère que cela aide quelqu'un.
"J'ai vu des choses comme des chaises longues, mais je suis sûr que cela ne vous permet d'utiliser le stockage local que par défaut et revient aux autres. Je pense que je préférerais qu'il utilise Web SQL (par défaut) puis les options plus lentes . "
Ceci est configurable, chacun des `` adaptateurs '' pour les moteurs de stockage est autonome, vous pouvez passer un adaptateur au constructeur Lawnchair, ou, alternativement, changer l'ordre dans lequel il revient à d'autres options de stockage en concaténant les fichiers javascript différemment lorsque création de la bibliothèque. par exemple. pour db indexé puis retombant sur sqlite puis engrenages sqlite:
git clone https://github.com/brianleroux/lawnchair.git
cd lawnchair
cat src/Lawnchair.js src/adapters/indexed-db.js src/adapters/webkit-sqlite.js src/adapters/gears-sqlite.js > my_lawnchair.js
Bien sûr, comme les autres réponses le suggèrent, vous pouvez envelopper votre html5 dans une application native en utilisant phonegap etc. alors vous aurez beaucoup d'options, mais si vous voulez vous en tenir aux normes web, cela peut être une bonne façon d'aller jusqu'à nous avons une large adoption d'IndexedDB.
Je vous dirais d'utiliser Corona pour cela. Il s'agit d'une plate-forme privée utilisée pour les applications mobiles croisées qui prend en charge SQLite.
Avantages
- C'est facile et a un grand support pour SQLite, et n'a pas besoin de faire des choses étranges avec le stockage Html5
Les inconvénients
- vous devez le payer si vous souhaitez l'utiliser sur le marché Android ou iOS Market.
Je colle ici ce qu'ils en disent:
Corona inclut la prise en charge des bases de données SQLite sur toutes les plateformes. Ceci est basé sur le support sqlite intégré sur l'iPhone et une version compilée de SQLite sur Android. Notez que cela augmente la taille du binaire Android de 300 Ko.
SQLite est disponible dans toutes les versions d'Android, iPhone et iPad, ainsi que dans Corona Simulator ...
Cela vaut la peine de consulter ma bibliothèque open source https://bitbucket.org/ytkyaw/ydn-db/wiki/Home
Module de base de données Javascript pour les mécanismes de stockage Indexeddb, WebDatabase (WebSQL) et WebStorage (localStorage) prenant en charge la migration de version, la requête et la transaction avancées.
Étant une bibliothèque NoSQL, la jointure est manuelle, mais pas impossible. Il existe déjà des algorithmes de jonction de clés intégrés dans la bibliothèque.
Pourquoi ne pas écrire un simple moteur de stockage en javascript (qui couvre la partie "normalisée")? Apparemment, vous n'avez besoin de rien de très sophistiqué, donc cela ne devrait pas prendre trop d'efforts pour le faire fonctionner.
Je ferais ce qui suit:
- Stockez tout dans bson ou dans un format binaire similaire.
- Analyser et créer des index dans des fichiers et lire au démarrage.
- Recherchez à l'aide de javascript et lisez le gros fichier de votre application Web (hors ligne évidemment).
- Stockez les objets mis à jour séparément.
Cette solution n'est possible que si la base de données est suffisamment simple. Mais je pense que cela pourrait fonctionner - le support javascript est bon sur les appareils mobiles.
Pour l'inspiration ici est une implémentation de Btree + en javascript.
Pour lire les fichiers locaux, vous aurez besoin de fichier API , qui peut être utilisé pour accéder aux fichiers locaux . Il est pris en charge dans la plupart des navigateurs modernes, même Safari 6 . Je n'ai pas été en mesure de déterminer si les navigateurs iPhone actuels prennent en charge cette API.