Desarrolladores: Buenas prácticas para iCloud Backup

Apple nos invita a que revisemos nuestras aplicaciones, para que estén alineadas con la nueva funcionalidad de iCloud backup/restore.

iCloud Backup es una nueva funcionalidad, similar a los backups de iTunes, pero que en vez de realizarse sobre nuestro ordenador, se hace sobre la nube (los servidores de Apple).

Las principales diferencias con los actuales backups cableados de iTunes, son dos:

Ambos puntos nos llevan a la misma consideración: debemos respaldar la menor cantidad de información por aplicación. Esta será la garantía de que el backup no sea muy prolongado y que el espacio utilizado no sea elevado.

iClound Backup no incluye ninguna librería de desarrollo. No hay API. No tenemos que instalar XCode 4.2, ni iOS 5 para poner nuestra app a punto. Es un proceso totalmente automático realizado por el Sistema operativo, que consiste en respaldar algunos directorios de cada aplicación, a saber:

Esto es eso todo lo que se hace copia de seguridad. La app en si misma (bundle) no se copia (en caso de una restauración se vuelve a descargar a la última versión). Por lo tanto, si nos aseguramos que en los directorios mencionados no existe información innecesaria, habremos hecho los deberes.

Analicemos nuestros datos

Primero organicemos la información que manejan las aplicaciones según el tipo de uso:

Sobre los primeros, la mejor opción es mantenerlos en el bundle. Allí están inicialmente y allí podrán quedarse. Esta carpeta no se guarda en la copia de seguridad.

Sobre los segundos es donde tenemos que tener cuidado. Lo normal es tenerlos en Documents. Pero… ¿hay otras carpetas donde pueden alojarse?. La respuesta es si:

Ambas carpetas no se guardan en la copia de seguridad, por lo tanto, pueden ser la opción adecuada que estamos necesitando.

Luego, nuestra revisión se reduce a comprobar si todo lo que está en Documents es correcto que esté allí.

Como un ejemplo es mejor que mil palabras, analicemos una app ficticia que nos muestre que no es necesario tener todo en Documents.

Supongamos que hacemos una app que visualiza información de películas y series. En la primer versión, implementamos una enorme base de datos sqlite (de solo lectura, porque todo es para leer) con la info de cada película. Por lo que venimos viendo, esta DB se alojará en el bundle de la aplicación. En Documents solo tendremos un pequeño archivo plist con la última película visitada, para que en la siguiente sesión recordemos y abramos la app tal cual la dejo el usuario. Hasta aquí, todo alineado a iCloud Backup.

En una segunda versión incorporamos la posibilidad de marcar películas favoritas, función que les encantará a los usuarios. Una forma de implementarlo es agregar a la DB una tabla o campo para los favoritos. Pero ¡cuidado!: la DB que era de solo-lectura pasa a ser de lectura-escritura. Ya no podemos tenerla en el bundle: la implementación inmediata es copiarla a la carpeta Documents. Funcionalmente esto es correcto, la app se ejecutará sin errores. Pero ¿ésta forma de trabajo cumple con los criterios de iCloud Backup? Y… puede que no. Si la DB es muy grande, estamos forzando un backup de información inútil a iCloud y esto tenemos que evitarlo.

¿Como solucionarlo?. Una posibilidad es mantener la DB en el bundle y persistir solo los favoritos en Documents. Tendremos que reimplementar las consultas SQL de favoritos. A menos que además copiemos la DB a cachés y consolidemos los favoritos en ella. Allí la DB seguirá como hasta hoy, y solo tendremos que asegurarnos de sincronizar los favoritos (persistidos en Documents) en ella.

Mas de uno estará pensando… ¡a quien le gusta modificar una app que esta andando!. Pero bueno, si algunas de estas cuestiones están para mejorar, hagámoslo ahora que falta un mes aproximadamente para la salida de iOS 5 (apreciación mía, no hay nada oficial al respecto).

Un artículo de Angel Traversi