Como siempre, a última hora y con prisas, pero esperemos que al final salga bien. Ya iré escribiendo posts en los que informe sobre el estado de la documentación y publique lo que lleve (por si a alguien le interesa o le viene bien). Todo esto estará además en el repositorio.

El verano ha sido una mierda, en resumen. Mucho trabajar en cosas-no-de-mi-campo y poco hacer, tanto para Kora como para las asignaturas que tengo para septiembre. De todas formas, me ha dado tiempo a publicar una aplicacioncilla en el Market de Android sobre la que os hablaré un día de estos, y cuyo código fuente pienso liberar antes o después, junto con unos cuantos posts describiendo cómo he hecho las cosas.

Ya me enrollo más otro día.

Bajar el fichero .apk redistribuible e instalarlo en tu móvil Android

1. Antes que nada, asegúrate de que puedes instalar aplicaciones de fuera del Market. Para ello, ve a Ajustes->Aplicaciones y marca la casilla Orígenes desconocidos.
2. Descarga el último fichero .apk de esta carpeta (Kora-releases), cópialo a la tarjeta SD de tu móvil  e instálala con Astro, AppMonster o la aplicación que prefieras.
3. Ejecútala .

Descargar el código fuente del proyecto y ejecutarlo en un emulador o en un teléfono (código más reciente)

1. Si no tienes Eclipse y el SDK de Android instalados, hazlo siguiendo estas instrucciones.
2. Abre Eclipse e indícale al plugin subclipse la localización del repositorio: Ve a Window->Open perspective->Other..., y en el diálogo que se abre, SVN Repository Exploring. En la vista que se abre, en la vista superior izquierda (pestaña SVN Repositories), pincha con el botón derecho y elige New->Repository Location. En el diálogo que se abre, introduce en el campo URL:
   https://forja.rediris.es/svn/cusl4-kora/trunk y pulsa Finish.
3. En la entrada que se ha creado, pulsa con el botón derecho y elige Checkout . Pulsa Finish en la ventana que se abre.
   
4. Ve a la perspectiva de Java (se elige arriba a la derecha), elige el proyecto y pulsa el botón de Play para ejecutar el proyecto. Te aparecerá una ventana para elegir cómo ejecutarlo. Elige Android application y pulsa OK.
5. Si todo está bien configurado, se abrirá una ventana con el emulador y a continuación se cargará el proyecto. La primera vez tarda bastante en cargar porque tiene que iniciar la máquina virtual, el sistema operativo y la interfaz de usuario. Además, tiene que instalar la aplicación, así que conviene no cerrar esa ventana mientras se trastea el proyecto, para que sucesivas ejecuciones no tarden apenas.

1. Instala la JDK versión 1.6. En GNU/Linux puedes hacerlo fácilmente desde el gestor de paquetes, para MacOS y Windows puedes bajarla de aquí: http://java.sun.com/javase/downloads/widget/jdk6.jsp
2. Descarga la versión del SDK de Android correspondiente para tu Sistema Operativo.
   • GNU/Linux:
     • Para cualquier distribución: te recomiendo que sea sobre una de 32 bits,  pues para una distro compilada para x86_64 es posible que tengas que instalar las bibliotecas para 32 bits. Descomprime el fichero y mueve la carpeta resultante a tu carpeta personal: /home/<tu_usuario>.
     • Para Arch Linux es suficiente con instalar desde el AUR los paquetes android-sdk, eclipse-android y todas sus dependencias. Esto puede hacerse de forma muy fácil y automática mediante yaourt:
       yaourt -S  android-sdk eclipse-android eclipse-subclipse subversion --noconfirm
       El paquete se instala bajo /opt/android-sdk y hay que cambiarle el propietario:
       sudo chown -R <usuario>:users /opt/android-sdk-linux
       Si has seguido este procedimiento puedes pasar directamente al paso  5, pues el resto de dependencias se instalan automáticamente.
   • Windows: descomprime el fichero en C: de forma que la carpeta resultante sea C:\android-sdk-windows.
   • MacOS X: descarga este fichero y descomprímelo en tu carpeta de usuario.
3. Descarga Eclipse. Estas son versiones preparadas, descargadas desde yoxos.com (y modificadas por mí) que incluyen Subclipse y el plugin de Android.
   • Para GNU/Linux: 32 bits, 64 bits.
   • Para Windows.
   • Para OSX.
4. Descomprime el fichero de Eclipse.
5. Abre el ejecutable de Eclipse, que está dentro de la carpeta descomprimida. Si instalaste desde repositorios, simplemente abre Eclipse desde el menú de aplicaciones.
6. Una vez abierto Eclipse, ve a Window->Preferences, y en el diálogo que abre, en el apartado Android, rellena el campo SDK Location. Ya sea introduciendo la ruta a mano o mediante el botón Browse, introduce la ruta donde hayas descomprimido el fichero del paso 1 (por tanto, depende de tu sistema operativo).
   
7. Descarga los paquetes necesarios para poder compilar y ejecutar el proyecto. Para ello, ve a Window->Android SDK and AVD Manager, en el diálogo que se abre, elige Installed Packages a la izquierda, y pulsa el botón Update all. En el diálogo que se abre, marca los que necesites. Para Kora solamente es necesario instalar “SDK Platform Android 1.6″ y “Documentation for Android SDK, API 7, revision 1″. Si estás en Windows puede ser interesante instalar el driver USB para probar sobre dispositivos físicos.
   
8. Crea un dispositivo virtual en el que probar las aplicaciones. En esta misma ventana (Android SDK and AVD Manager), elige el apartado Virtual Devices y pulsa New para crear uno nuevo. Ponle un nombre, elige la versión de Android que soportará y ponle un tamaño de al menos 256 megas de almacenamiento a la tarjeta SD. El resto de opciones pueden quedarse por defecto.
9. Ya puedes comenzar un proyecto nuevo o cargar uno existente.

El maldito Eclipse se instaló correctamente pero comenzó a dar problemas al intentar instalar el SDK de Android, sobre todo por temas de dependencias. Creo que he encontrado una solución a esto y lo publicaré en el próximo post, que consistirá en una guía para poder descargar y probar Kora fácilmente (y por extensión, comenzar cualquier otro proyecto para Android).

Por la tarde, al cabo de casi dos horas, conseguimos echarlo a andar y comenzamos a trabajar con el pequeño ejemplo que tenía pensado, aunque no nos dio tiempo a terminarlo. Aproveché para comentar unas dudas con una muchacha psicóloga que vino, relacionadas con la paginación cuando hay más elementos de los que quepan en pantalla. Decidimos posponer la explicación de cómo funciona Kora para el día siguiente. Durante el fin de semana Dani se iba a quedar en un albergue, pero no tenían plazas para el sábado y al final pasó el fin de semana en mi casa.

El sábado quedamos por la tarde para reunirnos en alguna biblioteca, pero todas a las que fuimos estaban cerradas: de Arquitectura Técnica, de Andalucía, de la Facultad de Física y Matemáticas, Biosanitaria… Al final terminamos reuniéndonos en un bar, con lo que solo pudimos ver la aplicación un poco por encima. El sábado por la noche le expliqué a Dani la arquitectura de la aplicación un poco más profundamente, pero no escribimos ningún código.

La mala suerte no se acabó ahí. El domingo, en mi casa, se estuvo yendo la luz constantemente porque saltaban los plomos, sin saber por qué. Al final terminó produciéndose un pico de tensión y murieron el congelador, el microondas y el brasero. El amplificador de la antena de televisión sufrió quemaduras de tercer grado aunque ya está bien tras haber pasado por la UCI, donde se le reimplantó un condensador quemado. La fuente de alimentación de mi ordenador explotó (literalmente), y mi Wii tiene pronóstico reservado hasta que pueda ver si el problema está en el transformador de corriente o en la propia consola. Los saltos de los plomos los estaba provocando la tele de la buhardilla, a la que le estaba cayendo una gotera. Ha muerto también.

Esa tarde Dani y yo acabamos en casa de una tía mía, y durante las tres horas que estuvimos, acabamos implementando varias cosas. Draxus implementó la cuenta atrás de la pantalla de inicio, y Alejandro y David implementaron el diálogo de información. Los chicos de traducción me mandaron los ficheros de cadenas para el alemán, el francés, y corregidas para el inglés.

En definitiva, a pesar de la MALA suerte que hemos tenido, estoy contento. No tenía grandes expectativas para avanzar el proyecto este fin de semana, pues en tan poco tiempo es imposible que la gente aprendiera a programar para Android ágilmente, y además se enterasen del funcionamiento de Kora, a pesar del retraso que acumula. Se ha cumplido todo lo que propuse el viernes excepto la implementación de la vista de los perfiles de usuario.

De todas formas esto no es lo importante. En realidad lo es el haber visto los (interesantes) proyectos de algunos de mis compañeros, habérmelo pasado bien, el haberme forzado a volver a meterle caña de verdad al proyecto, haberme echado un buen amigo como Dani, etcétera.

Por último, me gustaría agradecer a la OSL la organización de estas jornadas, aunque si me permiten la sugerencia, deberían proporcionar algún lugar para reunirse durante el fin de semana. También a los compañeros que decidieron echarme una mano, y al dueño del bar que tan amablemente nos invitó a irnos el sábado, cuando empezaba el fútbol.

La presentación del lunes es esta: Presentación final Hackathón.

Hasta el momento, he estado probando el gestor de usuarios y funciona correctamente. El resto de gestores son muy similares, pues al igual que el de usuarios (UserManager) se limitan a heredar la clase abstracta ProfileManager que es la que implementa la mayor parte de la funcionalidad.

La ventana inicial del programa. Es fea. Por ahora. Pero le he encargado un icono reshulón a un colegui artista.

En este momento me encuentro con dos problemas que me están frenando bastante. El primero es la gestión de los perfiles de usuario y las preferencias. Android provee un mecanismo de gestión de preferencias que permite cargarlas desde un fichero XML, generar la interfaz de usuario para las mismas automáticamente y almacenarlas. Todo muy sencillo y muy chachi, pero (aparentemente) no permite manejar un fichero XML que no sea el de las preferencias generales del programa. Es decir, no permite elegir la ubicación de dichos ajustes, por tanto, no puedo utilizarlo para crear la interfaz de administración de los perfiles de una forma bastante automatizada. Esto significa que tendré que implementar yo mismo los parsers y la interfaz de administración para los ajustes de los perfiles, lo cual puede ser bastante trabajo, corriendo además el riesgo de que la apariencia de los ajustes no sea la típica de una aplicación Android. No obstante, parece ser que la clase Preferences y sus derivadas pueden serme útiles a la hora de crear la interfaz de usuario.

Esto es lo que se ve al entrar en ajustes. Ahora mismo solo he creado dos usuarios por defecto.

Añadir usuario.

El usuario HauriHauri ha sido añadido. El problema es que para ver esto actualizado hay que salir y volver a entrar.

El diálogo de selección permite elegir un usuario, editarlo y eliminarlo (estas dos últimas acciones, solo para perfiles personalizados)

El segundo problema es el típico que no debería suceder, aparece y te amarga la existencia. Bueno, tanto no, pero sí que me está jodiendo bien. Tengo implementada al 90% la interfaz de gestión de usuarios (todo excepto algunas cadenas que están metidas a pelo y la selección de perfiles), pero hay un fallo que no sé ya por dónde cogerlo: no se me actualizan las vistas al añadir un usuario o elegir uno distinto. Hay que volver atrás y abrir de nuevo la ventana para que se actualice la vista.

En general, el SDK de Android me está gustando. Se nota que está todo pensado para obtener un gran rendimiento (véase por ejemplo la reutilización de vistas en las ListViews, que es bastante elegante), aunque algunas cosas están un poco confusas y sobre todo, los nombres de algunas clases y ciertas jerarquías no me parecen consistentes. Qt me gusta más, primero por su diseño (que me encanta), y segundo por ser una biblioteca para C++ (al menos nativamente), que me parece un lenguaje mucho más potente que Java, aunque también más peligroso.

Por otra parte, cada vez odio más al Eclipse. Es el IDE más sobrecargado, lento y lleno de fallos que he usado. Además, debe haber algún fallo en Eclipse, Java, Gtk+, en Gtk-Qt o en el propio servidor gráfico X.org que provoca que cuando estoy usando Eclipse se dispare el consumo de memoria de  Xorg. Tanto, que al cabo de unas horas se me completa la RAM (4GB) y tengo que terminar reiniciando el servidor gráfico. Ojalá continúe el progreso de Wayland y podamos deshacernos del monstruo en el que se está convirtiendo X11.

Y esto es todo por ahora.

• La pantalla inicial del programa (no es definitiva, ni mucho menos).
• Algunas traducciones al español, más que nada por probar (seguramente no las termine hasta que el programa esté muuuucho más avanzado). En principio quiero que la aplicación esté en inglés, y que luego sea fácil de traducir mediante ficheros XML (que se meten en la carpeta res/values-IDIOMA).
• Iconos, principalmente para la interfaz de administración. Están tomados del proyecto Oxygen (los de KDE4), con algunas modificaciones. ¿Debería incluir alguna referencia a la procedencia y licencia de los mismos en un fichero de texto en la carpeta de recursos, o basta con decirlo en el léeme de la aplicación?
• Pruebas en la interfaz de administración, que no es definitiva, ni mucho menos. En ninguno de los aspectos.
• He implementado una vista personalizada para elementos de listas, así como una lista con cabeceras. Esto me ha servido para aprender bastantes cosas de disposiciones (layouts), vistas y demás.
• Experimentos con diálogos.

Y poco más. A partir de ahora, ya que estoy cogiéndole el manejo a Android y más o menos he probado casi toda la base que necesito, el proyecto debería avanzar mucho más rápidamente, pues tengo clara la arquitectura (de la que hablaré por aquí algún día) y tengo buenos bocetos de prácticamente toda la interfaz de usuario.

No obstante, aún tengo que aprender a manejar ficheros XML “propios”, tengo que seguir investigando sobre las enormes posibilidades que tienen las vistas (y animaciones) y también sobre el soporte de carga y manejo de preferencias de Android, que puede quitarme bastante trabajo, además de permitirme tener un código mucho más limpio y manejable.

He tenido varios problemas con el repositorio por temas de borrado y adición de ficheros, pero ya están solventados. A partir de ahora voy a utilizar el plugin Subclipse, que integra Subversion en Eclipse (¡oh!), y espero no tener los problemas de versionado roto que he tenido hasta ahora.

Nos leemos el año que viene, ¡un saludo y suerte!

Aparte de esto, esta última semana ha sido bastante movidita con el tema del Concurso de Software Libre. El viernes, cuando se revisaron los proyectos, me dijeron que no podían aceptar mi proyecto por requerir una plataforma no libre. Aunque protesté un poco, terminaron por decirme que no, que no y que no, a no ser que cambiara a una plataforma libre como Android, Symbian o Maemo. Ante la aparente imposibilidad de hacer un cambio de plataforma de desarrollo, me di por vencido.

En general le he cogido un poco de manía al iPhone y a su entorno de de desarrollo, y Android me ha parecido mejor desde el primer momento, principalmente porque:

• Es libre.
• Hay más terminales, y más baratos que el iPhone, que lo soportan. Y no solo hay dispositivos móviles, también ultraportátiles.
• Puedo programar en Linux.
• MacOS X no me gusta. Sí, es todo muy guay, estable y fácil, y además tiene una terminal muy potente (bash) pero le falla algo que me parece básico: la personalización. Me quedo con mi Arch+KDE, que puede llegar a ser tan bonito como el OSX, o más aún, y puedo hacer lo que me dé la gana con él. Además, el Amarok no funciona bien sobre OSX, y iTunes…
• El lenguaje de desarrollo (Java) es más conocido que Objective-C (aunque no me disguste). Como el proyecto es libre, si a alguien le llama la atención, tendrá más fácil el adaptarlo o modificarlo.
• No es necesaria ninguna firma para introducir las aplicaciones en el dispositivo (para el iPhone sí, y Apple cobra 99$ al año por ello).
• No es necesario usar programas pestosos como iTunes para manejar el dispositivo.

Aunque había varios factores que obligaban a desarrollar para iPhone o iPod Touch, principalmente:

• Otros proyectos del Sc@ut, como Pic@, están desarrollados sobre iPhone, y sería deseable que se integraran.
• El iPhone es megachachiguay que te cagas.
• La interfaz multitáctil es interesante. Aunque últimamente, varios modelos de Android también lo soportan.

Pero el lunes me mandó JJ Merelo (a quien estoy muy agradecido por todo lo que me ha apoyado) un correo con información sobre el premio especial de Vodafone y volví a escribir correos al hombre que se puso en contacto conmigo para informarme de mi no-aceptación. Ayer fui a hablar con uno de los profesores que coordinan el proyecto y le comenté las razones de un hipotético cambio… Y estuvo de acuerdo conmigo. Así que esta mañana he ido a hablar con María José, mi tutora, y hemos decidido abandonar el iPhone en favor de Android. Los mayores inconvenientes que tiene esto son la pérdida de casi un mes de formación con el SDK del iPhone, algunos reajustes que tendré que hacer a los bocetos, y sobre todo, la no integración con el Pic@. Aunque la única condición que me han “impuesto” es hacer un buen diseño con una buena abstracción, para que portar la aplicación al iPhone/iPod sea sencillo.

Nada más saber esto les he mandado un correo a los del CUSL, y finalmente me han aceptado . Así que a ver cómo sigue el tema, esta semana la ocuparé en aprender a usar el SDK de Android, sobre el que he escuchado muy buenas opiniones, y en ir reformando un poco los bocetos que tenía.