Développement d’une solution de stockage en mode hors connexion de HTML5 pour iOS/Android en 2011

Question

Le problème:

J'ai besoin d'un agnostique appareil (par exemple, HTML5) solution pour le stockage et l'interrogation de plus de 250 000 lignes de données en mode hors connexion sur un téléphone ou une tablette type de périphérique (iOS/Android). L'idée étant, j'ai des gens qui travaillent dans des régions éloignées, sans aucune connexion de données cellulaires, et ils ont besoin pour exécuter des requêtes sur ces données et de les modifier en mode hors connexion. En partie, il sera de la géo-localisation, de sorte s'il existe des biens dans la région, ils sont en (utilise le GPS), alors il sera de montrer à ces actifs et de leur permettre d'être édité. Une fois de retour au bureau, ils peuvent synchroniser les données en arrière à l'office de serveur.

La raison que j'aborde ce à partir d'un standard du web point de vue est essentiellement à économiser temps et argent en écrivant une fois en HTML5 et puis, il fonctionne à travers de multiples plates-formes plutôt que de l'écrire deux fois en Objective C et Java. Aussi, si vous écrivez quelque chose qui est plate-forme agnostique, alors vous n'êtes pas enfermés et ne pas couler avec le navire quand tout le monde se déplace à un autre plus récent. Nous avons eu la même application écrite pour Windows Mobile 5, maintenant, il est inutile que cette plate-forme est mort.

Le mode hors connexion de la base de données sur le périphérique doit être:

• rapide (réponses en moins de 2 secondes)
• potentiellement effectuer des jointures et avoir des relations avec d'autres tables de pouvoir interroger la base de données
• sélectionnez les données à l'intérieur d'une certaine plage ou de critères, par exemple en x et en y pour coordonner basé sur le GPS de la lecture.

Options:

Le stockage local HTML5:

Amende pour de petites quantités de données <5,000 clés/valeurs, vous pouvez même stocker des tableaux/objets, si vous le convertir en JSON.

Inconvénients:

• Pour plus de 10 000 lignes, même sur un haut de gamme de la machine, le navigateur va ralentir à une exploration.
• Ne peut pas faire de requêtes complexes sur les données à extraire les données que vous voulez que vous avez à parcourir l'ensemble de stockage et rechercher manuellement.
• Les limites à la quantité de stockage qui peuvent être stockées

Web Base de données SQL:

• Répond aux exigences.
• Rapide pour exécuter une requête sur de 250 000 lignes (1-2secs)
• Pouvez créer des requêtes complexes, joint etc
• Pris en charge par Safari, Android et Opera donc fonctionne sur iOS et Android

Inconvénients:

• Obsolète depuis novembre 2010
• Faille de sécurité avec la croix-répertoire des attaques. Pas vraiment un problème qu'on ne sera pas sur l'hébergement mutualisé

IndexedDB:

Clé/valeur magasin d'objets similaires pour le stockage local, sauf avec l'index.

Inconvénients:

• Lent à l'exécution d'une requête sur 200 000 lignes (15-18secs)
• Ne peut pas exécuter des requêtes complexes
• Ne peut pas faire des jointures avec d'autres tables
• Non pris en charge par téléphone principal ou les tablettes par exemple iPad/Android
• Standard ne sont pas complètes

Cela laisse à la seule option de la mise en œuvre de l'obsolète Web SQL méthode qui ne peuvent travailler que pour une autre année. IndexedDB et locaux de stockage sont inutilisable à l'heure actuelle.

Je ne suis pas sûr de savoir comment Mozilla et Microsoft a obtenu le Web, Base de données SQL standard obsolète et pourquoi le W3C laisser faire. Soi-disant entre eux, ils ont 77% de la navigateur de bureau marché. Sur les appareils mobiles avancés Mozilla et Microsoft ont presque zéro influence comme Safari, Opera et Android ont plus de 90% de part de marché. Comment Mozilla Et Microsoft peuvent dicter la norme devrait être utilisé dans le marché de la téléphonie mobile qui est l'endroit où le stockage hors ligne est plus susceptible d'être utilisé n'a pas de sens.

Dans les commentaires de Mozilla sur le pourquoi ils ont voulu aller avec IndexedDB au lieu de cela sont principalement sur "développeur de l'esthétique", et ils n'aiment pas l'idée de l'exécution de SQL dans le code JavaScript. Je ne suis pas de l'acheter.

1. Actuellement, la norme proposée est de qualité inférieure et un très de base NoSQL mise en œuvre est lente et ne prend même pas en charge les fonctionnalités avancées que les gens ont besoin dans une base de données. Il y a beaucoup de code réutilisable pour établir la base de données et obtenir les données, mais ils le prétendent les gens vont écrire quelques belles abstraction des bibliothèques sur le dessus de lui fournir davantage de fonctionnalités avancées. Dès Oct 2011 ils sont nulle part pour être vu.

2. Ils ont désapprouvé le Web existante de SQL standard qui fonctionne réellement et est mis en œuvre dans le principal mobile/tablette navigateurs. Alors que leur "nouveau" et "mieux" standard n'est pas disponible dans les principaux navigateurs mobiles.

3. Que sommes-nous en tant que développeurs censé utiliser pour les 3-5 prochaines années, ce qui est quand la IndexedDB spécification peut s'en cours de standardisation, d'avoir plus de fonctionnalités, mises en œuvre dans le principal mobile/tablette navigateurs et il y a quelques belles bibliothèques pour rendre les choses plus faciles?

Le W3C devrait garder le Web, Base de données SQL standard qui s'exécutent en parallèle et simplement corriger les problèmes. Il a déjà le support pour les principales plates-formes mobiles et cela fonctionne assez bien. Le fait que Mozilla et Microsoft en tant que les deux joueurs avec le plus de navigateur de bureau de l'action ont été en mesure d'obtenir ce standard mis au rebut est assez douteux, et pourrait être vu comme une tentative d'entraver les progrès sur le web mobile plates-formes jusqu'à ce qu'ils sont en mesure de rattraper et d'offrir des solutions concurrentes contre iOS/Safari et Android.

En conclusion, quelqu'un aurait-il une solution à mon problème qui va travailler pour iOS/Android pour téléphone/tablette. Peut-être une belle API wrapper qui peut utiliser plusieurs bases de données mises en œuvre dans le fond à interroger la capacité et il vous permet de choisir la base de données qui a la priorité. J'ai vu des choses comme lawnchair mais je suis assez sûr qu'il ne vous permet d'utiliser le stockage local par défaut et retombe à la pour les autres. Je crois que je préfère c'Web SQL (par défaut), puis le ralentissement des options.

Toute l'aide pour une solution beaucoup apprécié, merci!

Answer 1

Je voudrais vous recommandons de vérifier la JayData de la bibliothèque, qui en fait a la fin exacte de la création d'un stockage agnostique couche d'accès aux données pour les appareils mobiles. JayData fournit une couche d'abstraction avec JavaScript Langage de Requête (JSLQ) et JavaScript CRUD soutien et vous permet de travailler sur de la même façon avec les différents en ligne et hors ligne magasin de données de types différents. JayData prend en charge de traiter avec des entités complexes et aussi des entités-relations, soit localement ou à distance.

Au moment de la rédaction JayData prend en charge les magasins ou les protocoles: webSQL(sqLite)/IndexedDB/OData/YQL/FBQL.

Votre problème particulier avec les différents systèmes de mise à disposition de différents moteurs de stockage peuvent être facilement traitées avec le secours fournisseur fonctionnalité de JayData: il va utiliser quelle que soit la couche de stockage, il peut se trouver tout en fournit toujours la même API vers le code de la consommation.

Concernant l'WebSQL être obsolète d'ici à 2012: au moment de la rédaction, il est WebSQL qui a toujours 95% de l'appareil de la couverture, y compris Samsung SmartTV et amazon Kindle. Découvrez kindle exécution WebSQL tests unitaires avec JayData.

Answer 2

Je voudrais caisse CouchBase Lite. C'est une quasi-complet de la mise en œuvre de CouchDB qui fonctionne sur Android et iOS.

iOS

Android

Si vous avez enveloppé de votre Application dans quelque chose comme PhoneGap vous pourriez créer des indigènes HTML 5 apps pour les deux plates-formes et vous n'avez qu'à faire un petit peu de Android/iOS programmation spécifique pour mettre en œuvre CouchDB.

Pour:

• Vue rapide moteur pour l'interrogation sur le nombre de lignes de données.
• La saleté simple et puissant support de réplication cuit.

Inconvénients:

• Key-Value Store - Ça va prendre un certain temps pour s'y habituer.

Answer 3

J’ai fait quelques recherches plus tout en recherchant une solution pour mon propre projet. Il semble que cette bibliothèque est plutôt prometteuse : http://nparashuram.com/IndexedDBShim/

Cela permet d’utiliser l’API IndexedDB ayant WebSQL dans les coulisses.

C' est les tests transmettent récent iPad, iPhone 5, Android 4.2.2.

Espérons que cela aide quelqu'un.

Answer 4

Je voudrais vous dire d'utiliser Corona . C'est un privé Plate-forme utilisée pour la croisée des applications mobiles qui a le support de SQLite .

Pros

• Il est facile et dispose d'un grand soutien pour SQLite , et n'ont pas besoin de faire des choses bizarres avec Html5 de stockage

Cons

• vous devez payer pour cela si vous voulez l'utiliser dans le Market Android ou iOS de Marché.

Je colle ici ce qu'ils en disent:

Corona inclut le support pour les bases de données SQLite sur toutes les plateformes. C'est basé sur le intégré le support sqlite sur l'iPhone, et compilé la version de SQLite sous Android. Notez que ceci augmente la taille de la Android binaire par 300K.

SQLite est disponible dans toutes les versions d'Android, iPhone, et iPad, comme bien que dans la Couronne Simulateur...

Answer 5

"J'ai vu des choses comme lawnchair mais je suis assez sûr qu'il ne vous permet d'utiliser le stockage local par défaut et retombe à la pour les autres. Je crois que je préfère c'Web SQL (par défaut), puis le ralentissement des options."

C'est configurable, chacun des "adaptateurs" pour les moteurs de stockage est autonome, vous pouvez passer d'une carte à l'Lawnchair constructeur, ou, vous pouvez également modifier l'ordre dans lequel il revient à d'autres options de stockage en concaténant les fichiers javascript différemment lors de la création de la bibliothèque. par exemple, pour indexées db avant de redescendre à sqlite alors 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 suggèrent, vous pouvez envelopper votre html5 dans une application native à l'aide de phonegap etc. ensuite, vous aurez beaucoup d'options, mais si vous voulez coller aux standards du web, cela peut être un bon moyen d'aller jusqu'à ce que nous avons obtenu une large adoption de IndexedDB.