CHAPTER 2. OPTIMIZATION OF TRADITIONAL PERMITTING
2.2 Framework 20
2.2.1 Advantages and Disadvantages 24
Google impone un limite de tamaño máximo de 50mb para el archivo APK que contiene a la aplicación. El motivo principal es minimizar el riesgo de que el usuario incurra en una descar- ga corrupta o incompleta.
Para las aplicaciones que superen este limite se ofrece el uso de los llamados archivos de ex- pansión. Son archivos con extensión .obb de los que Google permite añadir dos ficheros de hasta 2GB cada uno y se dividirán en dos clases:
1. El archivo de expansión principal (main) que incluirá los archivos necesarios para ejecutar la aplicación.
2. El archivo de expansión secundario (patch) que contendrá los archivos no imprescin- dibles para ejecutar la aplicación. Es válido por ejemplo como uso para incluir imágenes optimizadas para distintos tipos de pantallas. Su uso es opcional y se recomienda utilizar-
Google proporciona una herramienta en su SDK para crear específicamente archivos de ex- pansión. Se trata de la herramienta JOBB. Es una herramienta basada en lineas de comandos que permite crear ficheros .obb encriptados a través del uso de constraseñas para posterior- mente ser montados de forma virtual en la App con el fin de preservar los derechos de propie- dad intelectual.
Mundus4D Complutum tiene un tamaño total de 59mb, superando el limite máximo impuesto por Google, se hace necesario entonces el uso de un archivo de expansión. Se intentó la im- plementación de ficheros .obb creados por JOBB con decepcionante resultado por dos moti- vos principales:
1. Existe un bug introducido en las últimas versiones de Android por el cual el archivo obb no puede ser montado virtualmente. Este error ha sido subsanado en las últimas revi- siones.
2. MetaioSDK exige que los archivos se encuentren de forma física descomprimidos en el dispositivo.
Se hace inviable por tanto esta opción para la versión final de la aplicación. En su lugar se optó por crear un archivo .zip con todos los recursos necesarios que sería renombrado con ex- tensión .obb. Para simplificarlo se tomó la carpeta assets y se creó un .zip sin compresión ni uso de contraseñas.
Además es necesario escribir un método que se encargue de descomprimir el archivo .zip y guarde los resultados en la carpeta elegida. En Mundus4D Complutum se encarga de ello el método descomprimir_Zip().
El método crea el directorio de la carpeta destino, posteriormente se crea un objeto del tipo ZipInputStream del fichero .obb existente en la ruta marcada y se recorre el objeto tomando cada entrada. De estas entradas que hacen referencia a cada archivo contenido en el .obb debe comprobarse su existencia en el dispositivo para no volver a sobrescribir el fichero, con la perdida de rendimiento que ello supone. Si no existen se descomprimen de igual forma que se crea el directorio si no existiese.
El formato del nombre de este fichero debe ser:
main|patch.version_de_la_App.package_de_la_App.obb
Para la aplicación Mundus4D el nombre del archivo quedó conformado de la siguiente forma:
main.1.pfc.mundus4d.complutum.obb
De acuerdo con la documentación de Google se deben implementar dos librerías encargadas de administrar la descarga y el sistema de licencias con el fin de verificar la aplicación y su archivo de expansión. También se entrega un proyecto de ejemplo donde se implementan es- tos aspectos. Por mi parte se intentó seguir este ejemplo modificando los mínimos aspectos posibles dada la poca mi poca experiencia empleando este sistema de descarga y el hecho de que Google no permite testear la descarga hasta que la App haya sido publicada. El proceso se resume en el siguiente esquema:
Primeramente se comprueba que existe el archivo de expansión en el dispositivo, si existe se comprueba si coincide en versión, extensión y tipo con el requerido por la aplicación. En caso afirmativo se pasa a descomprimir el archivo y lanzar el menú principal. Tanto en el caso de que no exista este archivo como que sus parámetros no coincidan con los requeridos se inicia el asistente de descarga.
Se implementó en la activity launcher el interface IDownloaderClient encargado de simplifi- car y administrar el sistema de descarga. Cuando se crea la activity comprobamos si existe el archivo .obb e iniciamos el gestor de descarga si fuese necesario:
El método expansionFilesDelivered() se encarga de comprobar los datos del fichero obb como método de comprobación para determinar si es necesaria la descarga.
Reseñar tres métodos autogenerados al implementar IDownloaderClient:
onServiceConnected() - Se recibe una llamada a este método tras instanciar Istub en la activi- ty.
onDownloadStateChanged() – Permite manipular las acciones a realizar en cada estado de la descar- ga.
onDownloadProgress()- En este método se manipula el progreso de la descarga, de tal forma que se puede crear una barra de progreso, un texto con el porcentaje de descarga completado, etc...
Adicionalmente se creó la clase auxiliar Asist_Descarga que extiende la clase Downloader- Service encargada de descargar el archivo .obb desde Google Play y la clase
Monitorizar_Descarga que extiende BroadcastReceiver() y trata de monitorizar el estado de la descarga, así como reiniciarla si fuese necesario.
Es necesario decir que la experiencia obtenida tras la publicación hace entender que el proce- dimiento empleado por Google para la descarga de la App difiere en ciertos aspectos del pro- cedimiento descrito en la documentación proporcionada.
Google explica el proceso estipulando que en un primer momento solo se descarga el archivo APK que contiene a la aplicación y una vez instalada sería en la primera ejecución cuando se empezase la descarga del archivo de expansión. En cambio, la experiencia ha demostrado
posteriormente que al descargar Mundus4D Complutum desde Google Play, se descarga tanto el archivo APK como el de expansión OBB de manera simultanea.