Estoy buscando alguna crítica sobre mi enfoque para almacenar el estado de un editor de mapas de bits para teléfonos móviles con Android e iPhone. Incluso un "¡Me parece bien!" la respuesta sería genial!Guardar/cargar el estado del documento de forma rápida y robusta para el editor de imágenes
En la aplicación, el documento de usuario actual contiene varias capas de mapa de bits (cada una tal vez 1024 por 768 píxeles) que pueden pintarse. Los requisitos básicos para la aplicación son:
Necesito poder guardar y restaurar el estado del documento.
Cuando el usuario sale de la aplicación o recibe una llamada telefónica, necesito poder guardar el estado del documento rápidamente (en aproximadamente 2 segundos).
Si la aplicación falla, necesito poder restaurar el estado del documento (está bien si el usuario pierde quizás 30 segundos de trabajo).
Para 1, no puedo encontrar ningún formato de archivo abierto que admita capas. Iba a ir con la estructura siguiente archivo para almacenar mi documento:
document_folder/
layer1.png
layer2.png
...
metadata.xml
Las capas son sólo almacenan como archivos .png y el archivo .xml contiene datos tales como las capas que están visibles. La carpeta del documento puede abrirse tal cual o la carpeta puede almacenarse en un archivo .zip. Esto parece un buen formato simple para que otras aplicaciones también funcionen.
Además de los archivos .png, también permitiré que las capas se guarden en un formato de archivo .raw personalizado que contenga datos en bruto de píxel no procesados de mapas de bits. Puedo guardar estos muy rápidamente en el teléfono (< 0.5s) mientras que los archivos .png toman uno o dos segundos.
Mi plan para guardar rápidamente el documento era, en el inicio, crear una carpeta llamada/autoguardar y guardar las versiones .raw de todas las capas allí. Después de unos pocos comandos de edición en una capa, actualizaría el archivo .raw para esa capa en una cadena de fondo. Para mayor robustez al guardar, guardaría la capa como p. layer1_tmp.raw y cuando confirme que el archivo se ha escrito completamente, reemplace layer1.raw con este archivo.
En caso de que la aplicación falle durante el uso, simplemente volvería a abrir la carpeta/autoguardar. Cuando la aplicación se cierra o el usuario recibe una llamada telefónica, solo tengo que actualizar la última capa modificada para guardar automáticamente. Cuando el usuario quiere guardar, simplemente convierto todos los archivos .raw en archivos .png y luego comprime la carpeta.
¿Qué opinas? ¿Hay algún defecto obvio? ¿Hay alguna forma más simple? ¿Estoy reinventando la rueda de alguna manera? Gracias.
@tifftuff: "Cuando el usuario sale de la aplicación o recibe una llamada telefónica, necesito poder guardar el estado del documento rápidamente (en unos 2 segundos)" - eso puede no ser posible solo debido a la velocidad de escribiendo para flashear. Flash es muy impredecible en términos de escritura, ya que depende de cosas como la nivelación del desgaste. De lo contrario, no veo nada particularmente malo con su estrategia, al menos * vis a vis * Android. – CommonsWare
@CommonsWare: en Android, puedo copiar 1.5Mb de bytes de píxeles de un objeto Bitmap en un archivo a través de RandomAccessFile.write y luego cerrar el archivo dentro de ~ 0.1s. Si llamo a .sync() en el descriptor de archivo (para forzar que la escritura se realice ahora), lleva algo así como 1 a 3 segundos. No tendré tiempo suficiente para esperar .sync() en el método activity onPause(), pero podría esperar a que termine .close(). ¿No es esto suficiente para tener una buena posibilidad de que el archivo haya sido escrito? ¿Alguna sugerencia sobre lo que puedo hacer si este no es el caso? Solo necesito guardar una capa (~ 1.5Mb). – memcom
@tifftuff: Todo lo que digo es que el flash es lento. En la conferencia 2010 de Google I/O, Brad Fitzpatrick citó algunos experimentos que ejecutó, donde escribir un solo byte esporádicamente tomaría 200ms, aunque típicamente era de menos de milisegundos. Asegúrese de que sus pruebas de tiempo se realicen en el hardware, ya que tienen características tan diferentes como el disco duro que probablemente tenga en su máquina de desarrollo. Cuantos menos datos escribas, más rápido será. Por ejemplo, tal vez lo que está pensando como una "capa" debería ser simplemente los píxeles que se dibujan, no cualquier fondo, para tratar de reducir ese 1,5 MB hacia abajo. – CommonsWare