El uso de Kindle Cloud Reader del almacenamiento local html5 no es técnicamente revolucionario. Sin embargo, debido a su alto perfil, puede alentar a otros desarrolladores a hacer un mayor uso del almacenamiento local de html5, lo que desencadena una “revolución”.
Primero, no creo la afirmación de que el lector en la nube sea la primera [aplicación que haga un uso importante del almacenamiento local html5]. La tecnología ha estado ahí afuera durante bastante tiempo. Marcos como http://www.sencha.com/products/io/ resumen. Pero no puedo encontrar ningún ejemplo de alto perfil de almacenamiento local html5 que se use en la naturaleza. Puede ser que esté equivocado.
¿Por qué es difícil para los desarrolladores de aplicaciones hacer uso del almacenamiento local?
- ¿Qué es la minería en la nube? ¿Puede nombrar algunas compañías que brindan ganancias y cobran razonablemente que proporcionan minería en la nube?
- ¿Usar Firebase en lugar de MongoDB haría que mi aplicación Meteor sea más escalable?
- ¿Cuáles son los pros y los contras de usar un back-end como servicio?
- ¿Cómo se crea la lluvia artificial?
- Suponiendo que ha creado una aplicación utilizando un marco web (RoR, Django, etc.), ¿qué criterios ha utilizado para elegir un proveedor de servicios en la nube? ¿A quién elegiste y por qué?
La API de almacenamiento local es en realidad bastante simple de usar, el desafío está en diseñar su aplicación para que funcione sin problemas tanto desde datos en caché como en vivo.
Para las aplicaciones existentes, el desafío es que no fueron diseñadas teniendo en cuenta el acceso fuera de línea. Las opciones probables para ellos es reescribir gran parte de su modelo de datos (desalentador) o rociar el conocimiento del almacenamiento local en toda la aplicación (más fácil, pero hace que el código sea frágil)
Para las nuevas aplicaciones, el desafío es construir un modelo de datos que tenga en cuenta el almacenamiento local. En lugar de la solicitud estándar -> proceso de visualización que utilizan las aplicaciones web ahora, los datos fluirían (probablemente) al almacenamiento local, que luego gestiona la activación de los eventos adecuados para el código de visualización. Es un cambio en la forma en que la mayoría de los desarrolladores piensan sobre el problema.
En ambos casos, pueden surgir muchos problemas:
- El usuario puede desconectarse en cualquier momento, pero la aplicación aún debe responder
- ¿Cómo debe lidiar la aplicación con poco espacio o sin espacio de almacenamiento?
- ¿Qué sucede si solicitamos espacio adicional y el usuario lo niega?
- ¿Qué sucede si los datos almacenados en caché están obsoletos, cómo deben actualizarse?
- Y más
Para hacerlo bien, el desarrollador sería prudente pasar mucho tiempo por adelantado diseñando una base de código robusta para abordarlos. La mayoría de los desarrolladores no lo harán; Probablemente serán los desarrolladores de framework quienes asuman el desafío
Sospecho que comenzaremos a ver más marcos que abstraen los desafíos de almacenamiento de datos para que la mayoría de los desarrolladores no tengan que preocuparse. Una vez que los desarrolladores de framework abren el camino, el desarrollo de aplicaciones fuera de línea se vuelve mucho menos desalentador (y tendremos otra nueva palabra de moda de Silicon Valley).
Esté atento a los próximos frameworks de Sencha, Backbone.js y SproutCore como frameworks que están evolucionando en esta dirección.
