Error generating final archive: Debug certificate expired

Si tenemos un poco abandonado el tema de programar con Android, y después de un tiempo queremos retomarlo, es muy probable que al intentar ejecutar un proyecto antiguo nos encontremos con que Eclipse nos larga este error:

Error generating final archive: Debug certificate expired ...

Tal como indica el mensaje, el problema es que el certificado de depuración de Android ha expirado. En esta url podemos ver que los de Google ya lo tienen registrado como bug, y que la solución temporal que se propone es la eliminación del fichero /.android/debug.keystore, para obligar a Android a regenerarlo.

Eso sí, dentro de un año, a repetir el proceso...

Uno de los errores que me he encontrado habitualmente desarrollando para Android con el plugin de Eclipse ADT es el siguiente:

emulator: ERROR: the user data image is used by another emulator. aborting

Cuando esto pasa resulta imposible desplegar una aplicación por más que reiniciemos el emulador, el eclipse, o lo que queramos. El porqué empieza a aparecer este error la verdad es que no he conseguido averiguarlo, pero sí que he encontrado una solución satisfactoria en los foros de stackoverflow.

Como ahí se explica, para solucionar el problema basta con eliminar dos carpetas ubicadas en la ruta C:\Documents and Settings\%user%\.android\avd\%nombreTelefono%.avd, cache.img.lock y userdata-qemu.img.lock.

En mi caso funcionó perfectamente, aunque en un principio obtuve un comportamiento extraño: cada vez que arrancaba la aplicación se lanzaba una nueva instancia del emulador. No duró mucho.

Otras alternativa que parece algo más limpia es la de reiniciar el servidor ADB. La he probado y funciona igualmente. Se puede hacer yendo a la vista DDMS, a la pestaña Devices, y al View Menu (la flecha blanca que apunta hacia abajo). Ahí tenemos la opción Reset ADB.

Configurar barras de progreso en Android

En estas primeras horas de mi andadura con Android me he encontrado un gran problema a la hora de trabajar con las barras de progreso.

Como ya comenté, la idea que tengo entre manos es desarrollar un juego para foguearme con la tecnología, y necesito mostrar en pantalla varias barras de progreso. Lógicamente interesa que no sean todas iguales, para que se pueda identificar cada una de ellas con lo que expresa. El caso más típico es el de mostrar la vida con una barra roja, por ejemplo.

El primer paso es definir el tipo de barra de progreso. Por defecto Android trabaja con barras circulares (o barras paradójicas). Para utilizar barras de verdad, tenemos que indicar explícitamente el valor del atributo style del elemento ProgressBar del fichero de layout que estemos utilizando (main.xml, o el que corresponda).

Sí, el valor es así de raro, y agradezco enormemente a Daniel Yankowsky el aporte.

Lo siguiente que nos plantearemos normalmente, ahora que tenemos la barra, es cómo cambiarle el color. El amarillo sobre gris está muy bien, pero hay todo un mundo más allá. En este caso vamos a necesitar crear un nuevo fichero, que ubicaremos en la carpeta res/drawable, y llamaremos progress.xml (por poner). El fichero tendremos que crearlo directamente desde el sistema operativo, y en él podemos definir con mayor detalle el estilo de la barra de progreso, mediante el siguiente código:

En este caso tenemos dos items, que se corresponden con el fondo y el progreso de la barra. Se podría añadir otro elemento secondaryProgress si lo necesitásemos. Para cada elemento se configura el radio de las esquinas, para que queden redondeadas, y se añade un gradiente, para que el color no sea uniforme, sino una degradación de los tres indicados. El ángulo indica cómo se aplica el gradiente (0 para hacerlo en horizontal, y 270 para vertical). Respecto al color, se identifica mediante ocho dígitos hexadecimales, donde los dos primeros indican la transparencia.

Existen otras opciones como poner relleno, y están bastante bien descritas aquí.

El último detalle que puede ayudar a personalizar la barra es el tamaño. En mi caso me interesaba presentar barras más finas para determinada información. Para conseguir este resultado nos vamos de nuevo al fichero de layout, y añadimos los atributos maxHeight y minHeight.

De esta forma conseguimos barras con distintas presentaciones. Como muestra, una captura (botones no me quedan ahora mismo).

Hope this helps!

Android TIP: refrescar recursos

En las últimas semanas he empezado a meterme en el mundo de Android con la idea de hacer algunas pequeñas aplicaciones, y poder publicarlas en el market.

Como punto de partida me he marcado el objetivo de crear un juego, y aprender así a manejarme con el entorno y herramientas de desarrollo. En futuros posts iré dando más detalles sobre el proyecto (si puede llegar a tener esa categoría). De momento, simplemente una pequeña ayuda para reducir tiempos de espera al trabajar.

Uno de los principales problemas que le veo al desarrollo para Android con Eclipse, mediante el plugin ADT, es que el emulador es bastante lento, sobre todo a la hora de arrancar, y en ocasiones puede hacerte perder la paciencia.

Si estás desarrollando una aplicación, y especialmente si es un juego, es normal que manejes ficheros de recursos, y concretamente imágenes. Y también es normal que las modifiques a menudo para ir metiendo mejoras en el apartado gráfico. Ante una situación de cambio en cualquier fuente del proyecto durante el desarrollo, siempre surge la duda de qué hay que hacer para que ésta se refleje en nuestra ejecución. ¿Compilo? ¿Redespliego? ¿Simplemente guardo? ¿Reinicio el ordenador?

Depende de con qué estés desarrollando. En el caso de Android, hasta donde sé, si haces un cambio en el código, simplemente tienes que volver a ejecutar la aplicación, pero no el emulador. Sin embargo, esto no es suficiente cuando el cambio se hace en un fichero de recursos. No vale ejecutar la aplicación, ni tampoco reiniciar el emulador, si no has refrescado antes la carpeta de recursos. Esto lo hacemos desde el explorador de paquetes, con el menú contextual.

Tras el refresco sí que podemos ejecutar de nuevo sobre el emulador que tengamos arrancado, y veremos que los cambios han sido aplicados.