Archivo

Archive for the ‘Honeycomb’ Category

Google, tenemos un problema!

Hoy lo he intentado. Tras dejar de lado un rato el desarrollo de LocalizaTodo para iPad para refrescar las ideas y ver cómo soluciono una molesta “característica” de los servicios de mapas de iOS, hoy me decidí a implementar un par de detalles a la versión de Android.

No había vuelto a abrir Eclipse prácticamente desde un par de días después de subir la versión de Android al MarketPlace. Me he centrado sobre todo en sacar la versión de iPhone y darle algo de funcionalidad básica a la versión web. La última actualización importante fue poder por fin usar la última versión de Eclipse y ya me daba por satisfecho. La visita habitual cuando me pongo con un proyecto a developer.android.com me hizo cambiar durante un rato mis planes de la mañana.

Ahí estaba. Por fin! El SDK de Android 3.0, conocido en el mundillo como Honeycomb. Había visto (si, pecado mío) solamente un par de vídeos del nuevo sistema operativo de Google y mi posición era la de “perfecto, la demo genial, ahora quiero tocarlo”. Y montar el SDK me daba la oportunidad de hacerlo gracias al emulador.

Ni que decir tiene que ya tengo experiencia con el emulador de Android. Primero fue WayTRKR, ahora era LocalizaTodo. Ya me había llevado la sorpresa con las últimas versiones de Android: son prácticamente inutilizables en el emulador, a no ser que dispongas de la paciencia (y tiempo!) del mismísimo Santo Job. Pero intentar (ojo: “intentar”) arrancar la nueva bestia de Google me ha hecho pensar. Es totalmente imposible utilizar Honeycomb en el emulador y mucho me temo que muchísimo menos plantearlo como herramienta para el desarrollo de aplicaciones. Es inutilizable.

Imagino que cuando nació el emulador de Android para desarrollo lo más importante era tener una plataforma lo más parecida a un dispositivo real que se pudiese. Lo mismo que pensó Microsoft con sus entornos de desarrollo para Windows Mobile:  emular un hardware de dispositivo completo, con la CPU incluida.

Cuando las PDAs y los teléfonos móviles empleaban procesadores que muchas veces apenas pasaban de los 200Mhz, con 16 MB de memoria y nula aceleración hardware para los gráficos, emular un entorno completo con CPU ARM incluida era fantástico: el mismo binario que probabas en el emulador funcionaba finalmente en el dispositivo real. Lo malo es ahora, cuando las nuevas generaciones de procesadores y sistemas operativos móviles realmente exprimen cada componente de los dispositivos hasta límites ahora ahora desconocidos.

Apple siempre lo ha sabido. Microsoft se dio cuenta de que un emulador hardware completo para su nueva plataforma sería un completo desastre. Los gráficos, las animaciones, los interfaces de usuario modernos exigen una velocidad de proceso que requiere tambien de aceleración en los emuladores.

Tanto Apple como Microsoft ahora lo que yo llamo “emuladores ligeros”: ejecutan una copia del sistema operativo deseado pero compilado para el procesador nativo de la máquina (x86 en nuestro caso). Para Apple implica incorporar dos compiladores diferentes en XCode, uno que genera código máquina x86 y otro ARM. Para el desarrollo se compila código nativo que no es necesario emular: es ejecutado directamente por el procesador de la estación de trabajo para desarrollo, actuando el emulador como una fina capa que traduce los APIs de la plataforma emulada en APIs nativos del sistema de desarrollo. Cuando el proyecto está listo, se compila para el procesador ARM de los dispositivos en los que se va a ejecutar.

En el caso de Microsoft, el uso exclusivo para el desarrollo de aplicaciones “de terceros” de la plataforma .NET + Silverlight tiene una inmensa ventaja: las aplicaciones desarrolladas para Windows Phone 7 (y .NET en general) son totalmente “agnósticas” del procesador en el que corren, al igual que Java. Con lo cual los binarios siguen siendo los mismos, con las ventajas que ello conlleva. Mañana podríamos fabricar un móvil con WIndows Phone 7 con un procesador x86, o MIPS y las mismas aplicaciones .NET correrán sobre ellos sin modificación.

El caso de Google es diferente: el 99% de las aplicaciones Android se desarrollan en Java que tambien es una plataforma agnóstica de procesador. Correrían felizmente en una máquina virtual Dalvik compilada para x86 o cualquier otra plataforma. Pero Google insiste en obligarnos a utilizar un emulador ARM V5 corriendo un sistema operativo diseñado para un procesador ARM11/Cortex A8 de doble nucleo recompilado para que funcione en ese procesador insuficiente, emulado por un procesador x86. Para colmo, el emulador no tiene el menor tipo de aceleración hardware para gráficos, así que las animaciones en pantalla tiene que hacerlas “por software” el procesador ARM emulado. De traca.

Señores de Google, por favor: es hora de tirar el emulador actual y empezar uno nuevo. Pero los que desarrollamos software necesitamos probar nuestros programas en plataformas variadas, con tamaños de pantalla diferentes, varias versiones de Android… Actualmente ni me planteo intentar desarrollar algo para Honeycomb si tengo que hacerlo con ese emulador.