tutorial sesion react iniciar gratis goodbarber javascript html5 web-sql indexeddb jaydata

javascript - sesion - Desarrollar una solución de almacenamiento sin conexión HTML5 para iOS/Android en 2011



nativescript vs ionic (7)

"He visto cosas como la silla de jardín, pero estoy bastante seguro de que solo te permite usar el almacenamiento local de manera predeterminada y volver a los demás. Creo que prefiero utilizar Web SQL (de forma predeterminada) y luego las opciones más lentas "

Esto es configurable, cada uno de los ''adaptadores'' para motores de almacenamiento es autónomo, puede pasar un adaptador al constructor Lawnchair o, alternativamente, cambiar el orden en el que vuelve a caer a otras opciones de almacenamiento al concatenar los archivos javascript de forma diferente cuando creando la biblioteca. por ejemplo, para indexed-db luego volver a caer en sqlite, luego engrana 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

Por supuesto, como sugieren las otras respuestas, puede envolver su html5 en una aplicación nativa usando phonegap, etc., entonces tendrá muchas opciones, pero si desea cumplir con los estándares web, esta puede ser una buena manera de hacerlo tenemos amplia adopción de IndexedDB.

El problema:

Necesito una solución independiente del dispositivo (por ejemplo, HTML5) para almacenar y consultar más de 250,000 filas de datos sin conexión en un dispositivo de tipo teléfono o tableta (por ejemplo, iOS / Android). La idea es que tengo personas que trabajan en áreas remotas sin ninguna conexión de datos móviles y que necesitan ejecutar consultas sobre estos datos y editarlos sin conexión. En parte, se basará en la ubicación geográfica, por lo que si hay activos en el área en la que se encuentran (usa GPS), entonces mostrará esos activos y los editará. Cuando vuelven a la oficina, pueden sincronizar los datos con el servidor de la oficina.

La razón por la que me estoy acercando a esto desde el punto de vista del estándar web es básicamente ahorrar dinero y tiempo al escribirlo una vez en HTML5 y luego funciona en múltiples plataformas en lugar de escribirlo dos veces en Objective C y Java. Además, si escribes algo que es independiente de la plataforma, entonces no estás bloqueado y no te hundes con la nave cuando todos se mueven a uno más nuevo. Tuvimos una aplicación similar escrita para Windows Mobile 5, ahora es inútil ya que esa plataforma está muerta.

La base de datos fuera de línea en el dispositivo debe ser:

  • rápido (respuestas por debajo de 2 segundos)
  • potencialmente realizar uniones y tener relaciones con otras tablas capaces de consultar la base de datos
  • seleccione los datos dentro de un cierto rango o criterio, por ejemplo, mediante una coordenada x y y basada en la lectura del GPS.

Opciones:

Almacenamiento local HTML5:

Perfecto para pequeñas cantidades de datos <5,000 claves / valores, incluso puede almacenar matrices / objetos en él si lo convierte a JSON.

Contras:

  • Para más de 10.000 filas, incluso en una máquina de alta gama, el navegador se ralentizará.
  • No se pueden realizar consultas complejas en los datos para extraer los datos que desea, ya que tiene que recorrer el almacenamiento completo y buscarlo manualmente.
  • Limitaciones con la cantidad de almacenamiento que se puede almacenar

Base de datos web SQL:

  • Cumple los requerimientos.
  • Rápido para ejecutar una consulta en 250,000 filas (1-2secs)
  • Puede crear consultas complejas, combinaciones, etc.
  • Compatible con Safari, Android y Opera, por lo que funcionará en dispositivos iOS y Android

Contras:

  • Obsoleto a partir de noviembre de 2010
  • Fallo de seguridad con ataques de directorios cruzados. No es realmente un problema ya que no estaremos en hosting compartido

IndexedDB:

Almacén de objetos clave / valor similar al almacenamiento local excepto con índices.

Contras:

  • Lento para ejecutar una consulta en 200,000 filas (15-18secs)
  • No se pueden ejecutar consultas complejas
  • No se puede hacer uniones con otras tablas
  • No compatible con dispositivos principales de teléfonos o tabletas, por ejemplo, iPad / Android
  • Estándar no completo

Esto deja la única opción de implementar el método Web SQL obsoleto, que solo puede funcionar durante un año más o menos. IndexedDB y el almacenamiento local no se pueden usar en este momento.

No estoy seguro de cómo Mozilla y Microsoft obtuvieron el estándar de la base de datos web SQL en desuso y por qué el W3C lo permitió. Supuestamente entre ellos tienen el 77% del mercado de navegadores de escritorio. En dispositivos móviles avanzados, Mozilla y Microsoft tienen una influencia casi nula ya que Safari, Opera y Android tienen más del 90% de la cuota de mercado . No tiene sentido cómo Mozilla y Microsoft pueden dictar qué estándar se debe usar en el mercado móvil, que es donde es más probable que se use el almacenamiento fuera de línea.

En los comentarios de Mozilla sobre por qué querían ir con IndexedDB, en cambio, se trata principalmente de "estética del desarrollador" y no les gusta la idea de ejecutar SQL en JavaScript. No lo estoy comprando.

  1. Actualmente el estándar propuesto es inferior y una implementación NoSQL extremadamente básica que es lenta y ni siquiera admite las funciones avanzadas que las personas necesitan en una base de datos. Existe una gran cantidad de código repetitivo para establecer la base de datos y extraer datos, pero afirman que las personas escribirán algunas bonitas bibliotecas de abstracción sobre la parte superior que proporcionarán características más avanzadas. A partir de octubre de 2011 no están a la vista.

  2. Desaprobaron el estándar Web SQL existente que realmente funciona y se implementa en los principales navegadores de dispositivos móviles y tabletas. Mientras que su estándar ''nuevo'' y ''mejor'' no está disponible en los principales navegadores móviles.

  3. ¿Qué se supone que debemos usar los desarrolladores durante los próximos 3-5 años, que es cuando la especificación IndexedDB podría estandarizarse, tener más funciones, implementarse en los principales navegadores de dispositivos móviles y tabletas y hay algunas bibliotecas interesantes para facilitar las cosas?

El W3C debería mantener el estándar Web SQL Database ejecutándose en paralelo y simplemente solucionar los problemas. Ya tiene soporte para las principales plataformas móviles y funciona bastante bien. El hecho de que Mozilla y Microsoft como los dos jugadores con el mayor número de navegadores de escritorio pudieron desmantelar este estándar es bastante dudoso y podría verse como un intento de obstaculizar el progreso en las plataformas web móviles hasta que puedan ponerse al día y ofrecer soluciones de la competencia contra iOS / Safari y Android.

En conclusión, ¿alguien tiene una solución para mi problema que funcione para iOS / Android para dispositivos de teléfono / tableta? Tal vez una API agradable que puede usar múltiples implementaciones de bases de datos en segundo plano con capacidad de consulta y le permite elegir qué base de datos tiene prioridad. He visto cosas como la lawnchair pero estoy bastante seguro de que solo te permite usar el almacenamiento local de manera predeterminada y recurrir a los demás. Creo que prefiero usar Web SQL (por defecto) y luego las opciones más lentas.

Cualquier ayuda para una solución muy apreciada, ¡gracias!


¿Por qué no escribir un motor de almacenamiento simple en javascript (que cubre la parte "basada en estándares")? Aparentemente no necesitas nada muy elegante, por lo que no debería requerir demasiado esfuerzo para que funcione.

Yo haría lo siguiente:

  • Almacene todo en bson o en un formato binario similar.
  • Analice y cree índices en archivos, y lea al inicio.
  • Consulta usando javascript y lee desde el gran archivo de tu aplicación web (obviamente fuera de línea).
  • Almacenar objetos actualizados por separado.

Esta solución solo es factible si la base de datos es lo suficientemente simple. Pero creo que podría funcionar: la compatibilidad con JavaScript es buena en los dispositivos móviles.

Para obtener inspiración here hay una implementación de Btree + en javascript.

Para leer los archivos locales, necesitará la API del archivo , que se puede usar para acceder a los archivos locales . Es compatible con la mayoría de los navegadores modernos, incluso Safari 6 . Sin embargo, no he podido determinar si los navegadores actuales de iPhone son compatibles con esta API.


Investigué un poco más mientras buscaba una solución para mi propio proyecto. Parece que esta biblioteca es bastante prometedora: http://nparashuram.com/IndexedDBShim/

Permite usar IndexedDB API con WebSQL detrás de escena.

Se trata de pruebas de iPad reciente, iPhone 5, Android 4.2.2.

Espero que esto ayude a alguien.


Me gustaría pagar por CouchBase Lite. Se trata de una implementación casi completa de CouchDB que se ejecuta en Android e iOS.

iOS

Android

Si envolvieras tu aplicación en algo como PhoneGap , podrías crear aplicaciones HTML 5 nativas para ambas plataformas y solo tendrías que hacer un poco de programación específica de Android / iOS para implementar CouchDB.

Pros:

  • Motor de vista rápida para consultas en muchas filas de datos.
  • Suciedad simple y potente soporte de replicación horneado.

Contras:

  • Tienda de valores clave: le tomará un tiempo acostumbrarse.

Recomiendo consultar la biblioteca JayData , que en realidad tiene el objetivo exacto de crear una capa de acceso a datos independiente del almacenamiento para dispositivos móviles. JayData proporciona una capa de abstracción con JavaScript Language Query (JSLQ) y compatibilidad con JavaScript CRUD y le permite trabajar de la misma manera con diferentes tipos de tiendas de datos en línea y fuera de línea. JayData admite el tratamiento de entidades complejas y también relaciones de entidades localmente o de forma remota.

En el momento de redactar este documento, JayData admite las siguientes tiendas o protocolos: webSQL (sqLite) / IndexedDB / OData / YQL / FBQL.

Su problema particular con los diferentes sistemas que ofrecen diferentes motores de almacenamiento puede abordarse fácilmente con la función de respaldo del proveedor de JayData: utilizará cualquier capa de almacenamiento que pueda encontrar mientras todavía proporciona la misma API para el código del consumidor.

Con respecto a que WebSQL está en desuso en 2012: en el momento de escribir esto, es WebSQL que todavía tiene una cobertura del 95% del dispositivo, incluyendo Samsung SmartTV y amazon Kindle. Consulte kindle ejecutando pruebas de la unidad WebSQL con JayData .


Te diría que uses Corona para eso. Es una plataforma privada utilizada para aplicaciones móviles cruzadas que tiene soporte para SQLite.

Pros

  • Es fácil y tiene un gran soporte para SQLite, y no necesita hacer cosas extrañas con el almacenamiento Html5

Contras

  • debes pagarlo si quieres usarlo en Android Market o iOS Market.

Pego aquí lo que dicen al respecto:

Corona incluye soporte para bases de datos SQLite en todas las plataformas. Esto se basa en la compatibilidad incorporada de sqlite en el iPhone y una versión compilada de SQLite en Android. Tenga en cuenta que esto aumenta el tamaño del binario de Android en 300K.

SQLite está disponible en todas las versiones de Android, iPhone y iPad, así como en el simulador Corona ...


Vale la pena revisar mi biblioteca de código abierto https://bitbucket.org/ytkyaw/ydn-db/wiki/Home

Módulo de base de datos de Javascript para Indexeddb, WebDatabase (WebSQL) y WebStorage (localStorage) mecanismos de almacenamiento compatibles con migración de versión, consulta avanzada y transacción.

Siendo la biblioteca NoSQL, join es manual, pero no imposible. Ya hay algoritmos de unión de claves incorporados en la biblioteca.