Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Guardar / cargar el estado del documento de forma rápida y robusta para el editor de imágenes

Estoy buscando alguna crítica sobre mi enfoque para almacenar el estado de un editor de mapas de bits para teléfonos móviles de Android y iPhone. Incluso un "se ve bien para mí!" Respuesta sería genial!

En la aplicación, el documento de usuario actual contiene varias capas de mapa de bits (cada una puede ser de 1024 por 768 píxeles) que pueden ser pintadas cada una. Los requisitos básicos para la aplicación son:

  1. Necesito poder guardar y restaurar el estado del documento.

  2. Cuando el usuario abandona la aplicación o recibe una llamada telefónica, necesito poder guardar el estado del documento rápidamente (dentro de unos 2 segundos).

  3. Si la aplicación se bloquea, necesito poder restaurar el estado del documento (está bien si el usuario pierde quizá 30 segundos de trabajo).

Para 1, no encuentro ningún formato de archivo abierto que admita capas. Iba a ir con la siguiente estructura de archivos para almacenar mi documento:

document_folder/ layer1.png layer2.png ... metadata.xml 

Las capas se almacenan simplemente como archivos .png y el archivo .xml contiene datos tales como qué capas están actualmente visibles. La carpeta de documentos se puede abrir como está por la aplicación o la carpeta se puede almacenar en un archivo .zip. Esto parece un buen formato simple para otras aplicaciones con las que trabajar.

Además de los archivos .png, también permitiré que las capas se guarden en un formato de archivo .raw personalizado que contenga datos de píxeles crudos no procesados ​​de bitmaps. Puedo guardar éstos 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 fue, al iniciar, para crear una carpeta llamada / autosave, y guardar las versiones .raw de todas las capas allí. Después de unos comandos de edición en una capa, actualizaría el archivo .raw para esa capa en un subproceso de fondo. Para la robustez al ahorrar, ahorraría la capa como eg layer1_tmp.raw y cuando he confirmado que el archivo se ha escrito completamente, substituyo layer1.raw con este archivo.

Si la aplicación se bloquea durante el uso, solo reabriré la carpeta / autosave. Cuando la aplicación se cierra o el usuario recibe una llamada telefónica, sólo tengo que actualizar la última capa modificada para guardar automáticamente. Cuando el usuario quiere guardar, sólo convierto todos los archivos .raw a archivos .png y, a continuación, cierre la carpeta.

¿Qué piensas? ¿Hay algún defecto obvio? ¿Hay alguna forma más simple? ¿Estoy reinventando la rueda de alguna manera? Gracias.

  • ¿Cómo puedo serializar un RealmObject a JSON en Realm for Java?
  • Java.lang.RuntimeException: Paralleable encontró IOException escribiendo objeto serializable en Android que pasa el objeto ArrayList
  • Serializador personalizado - deserializador utilizando GSON para una lista de BasicNameValuePairs
  • Problemas de serialización de RealmList (Realm / Gson / Intent)
  • Parcelable encontrado IOException writing serializable object getactivity ()
  • ¿Se limpia la actividad de Android instanceState durante la actualización de la aplicación?
  • ¿Cómo puedo conservar un objeto complejo a través de Reiniciar actividades?
  • ¿Cómo puedo serializar un objeto y guardarlo en un archivo de Android?
  • 2 Solutions collect form web for “Guardar / cargar el estado del documento de forma rápida y robusta para el editor de imágenes”

    Su idea me suena bien: guarde las capas en el fondo, como usted va. Cualquier capa que el usuario no esté editando en ese momento debe estar en cola para ser guardada tan pronto como cambie de ella a una capa diferente. Si la aplicación se interrumpe, sólo tiene que guardar la capa de trabajo actual, que como usted dice se puede hacer en 0.5s.

    ¿Por qué molestarse con el formato png de todos modos? Sólo lo necesita si la exportación de datos a otra máquina / sistema, ¿verdad?

    Creo que tienes un gran plan allí. Yo probablemente iría de la misma manera (pero que en sí no significa nada 🙂

    Lo que estaba pensando es que si pudieras tener no sólo un hilo de trabajo guardando el archivo, sino un servicio de fondo completo (con un hilo de trabajo, por supuesto, ya que un servicio también se ejecuta en el hilo principal).

    De esta manera tendrías garantizado que siempre hay algo vivo que puede manejar tus deltas de capa, sin importar si la actividad de dibujo se ha estrellado o si alguien te está llamando. De repente no tiene las mismas restricciones de tiempo (la operación de escritura puede tardar 10 segundos si lo desea, su actividad no está bloqueada ni depende de la operación de escritura). Por supuesto, su servicio se suicida cuando ha vaciado su cola de ahorro (para ahorrar recursos del sistema).

    Lo que no sé con el fin de promover aún más esta idea es la cantidad de datos que está escribiendo en el archivo raw? ¿Escribes la capa completa 1024×768 cada vez o solo reescribes las partes modificadas? También estoy inseguro de cómo los datos serían realmente transmitidos al servicio (de la actividad). No sé si hay un tamaño máximo de un byte-array-extra que un Intent puede manejar.

    Espero que esto le da más ideas.

    ¡Aclamaciones!

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.