El lamentable estado de las herramientas de desarrollo Android

Advertencia: si le tienes mucho cariño a Google, mejor que no sigas leyendo. Si desarrollas Apps como es mi caso (para iOS y Android) y no tomas como dogma de fe todo lo que dice Google (ni Apple, ni Microsoft, ni nadie), adelante.

Segunda advertencia: leed el update de abajo del todo, por favor. Para que os hagáis una idea de lo grave que es este asunto…

Ahora mismo estamos en pleno Google I/O, la conferencia para desarrolladores de Google. Se están presentando muchas novedades de consumo, lo que me parecen muy bien. Hay incluso un nuevo lenguaje visual llamado Material (que, por desgracia no veremos mas que en los Nexus, ya que los fabricantes se lo van a cargar; y aún así habrá que ver en qué Nexus y cuándo).

Todo muy bien, pero ¿qué pasa con las herramientas de verdad para desarrolladores?

Estas herramientas, no nos engañemos, son: el compilador, el lenguaje y el IDE. Eso es lo que usamos el 90% del tiempo mientras desarrollamos Apps. Pues parece que, en 2014, todo sigue como en 2013. En la edad de la piedra. En el más absoluto desprecio de Google hacia sus desarrolladores.

Sí señores: desprecio. No es de recibo las herramientas que proporciona Google, insisto, en 2014. Revisemos.

El lenguaje de programación

Es Java. Ni creado ni controlado por Google. Conste que no odio Java (he invertido mucho tiempo en aprenderlo y certificarme como para no tomarle cariño). Pero seguir en Java 6 cuando ha salido Java 8 con un montón de novedades interesantes me escuece. Mucho. Quiero esos tipos opcionales, clausuras y funciones de primer orden. En Android. Y lo quiero ya. Llámame caprichoso, pero creo que ya toca avanzar.

Seguir con esta versión de Java se debe seguramente al litigio que Oracle le está ganando a Google sobre la copia de Java para la máquina virtual Dalvik. Es ese el motivo de aguantar mientras puedan con Dalvik, cambiar a ART (el runtime que se va a usar a partir de ahora) y en cuanto puedan (probablemente la I/O de 2015) presentar el desarrollo de Android con Go. Que es un lenguaje creado por Google. Lo cual, por cierto, tampoco me disgustaría.

El cambio de Dalvik por ART no se debe a que incorpore 64 bits. Ni a que sea más óptimo. Si Dalvik es ya abierto ¿por qué no incorporar esas novedades y mejoras en la máquina virtual que ya tienen todos los Android? Probablemente por huir de un barco que se hunde. Y además: ¿para qué darle a todos los que están haciendo clones de Android (Nokia X, Amazon, Barnes & Noble Nook, Aliyun) estas mejoras? Me juego algo a que al final ART sólo lo podrán usar los miembros de la Open Handset Alliance. ¿Open?

IDE

Controlar el lenguaje es algo importante para crear un buen ecosistema de desarrollo. Microsoft creó C#, escribe su runtime, compilador y tiene el que probablemente sea el mejor IDE de todos: Visual Studio. Apple escribe su propio IDE, Xcode, que es una maravilla (como editor es mejorable y le faltan refactors, pero en Xcode se pueden hacer cosas que Eclipse no hará en la vida y Android Studio dentro de 100 años; ante las dudas ver un Storyboard, el diseñador de efectos de partículas con SpriteKit, los PlayGrounds de Xcode 6 o los Gauges). Apple influye poderosamente en el compilador, llvm, hasta el punto de haber creado un nuevo lenguaje de programación (Swift) para avanzar tras usar casi en exclusiva Objective-C los últimos 20 años.

Google, por contra, empezó creando un plugin de Eclipse para añadir algunos refactors, un asistente aquí y allá, un visualizador del XML de los layouts y poco más. Eclipse ni es de Google, ni Google puede influir en su desarrollo para hacerlo más Android. Luego, esperaron a que la comunidad demostrase que IntelliJ Idea era una alternativa viable para el desarrollo Android y propusieron Android Studio con mucho bombo y platillo… en Mayo de 2013. Es casi Julio de 2014 y seguimos con una herramienta en versión Alpha, que no ha alcanzado aún la versión 1.0.

Excusas

No, no me valen excusas sobre “es que Google ya se sabe, pone las cosas en Beta y tal”. Google no es una startup montada por cuatro chavales. Es la compañía más valiosa del planeta. Tienen pasta y tienen cerebros. Lo que no tienen es ningún interés en mejorar las herramientas de desarrollo.

Google sólo se preocupa de aquellos productos en los que puede vender su publicidad. Todo lo que no sirva para imprimir anuncios, sigue el camino de Google Reader y del Dodo. Y como no pueden imprimir anuncios mientras compilas, tenemos lo que tenemos.

Modelos de negocio distintos

Hay que entender el modelo de negocio de cada una de estas tres empresas para comprender cómo actúan:

  • Microsoft quiere venderte licencias. Por eso hacen el software que hacen, sólo para Windows, porque quieren venderte las licencias de Visual Studio, Team Foundation Server y Windows. Lo tomas o lo dejas, pero son claros.
  • Apple quiere meterte en su ecosistema y venderte chismes, que es donde ganan pasta, no con software (que ahora lo dan gratis, desde el S.O. hasta Xcode pasando por la suite ofimática). Ellos quieren que te compres un iPad, un iPhone, un MacBook Pro retina con AppleCare y que sigas y sigas comprando sus productos. Hacen buen software para apoyar la venta de sus productos hardware.
  • Google vende publicidad. Es con lo que gana dinero. No es nada innoble ni lo de que avengonzarse, pero todo esto de ir de salvapatrias de los open y darse aires de ir curando el cáncer cuando lo que hacen es espiarte para vender mejores anuncios me resulta muy gracioso. Google nunca ha sido pro software libre.

Open no es Libre

Open no significa nada y me molesta el uso torticero que Google hace de este término. No dicen libre porque se le echaría encima todo el mundo del Software ídem, dicen open como en voy a tirarte las migajas de los repositorios de código fuente de Android para que veas lo bueno que soy.

Eso no es libre.

En un proyecto Software Libre se puede ver el código mientras se desarrolla, y no después. Se puede aportar código. Es una meritocracia.

Aquí tenemos un desarrollo totalmente propietario y cerrado creado por una compañía que libera código al terminar. Y, por cierto, sólo parte de ese código. Google Maps o Gmail no lo liberan. Ahí lo open no entra, que eso es parte de mi maquinaria de vender anuncios… Llevo usando, aportando y tratando de comprender a la comunidad del Software Libre desde el 94. Me molesta que la gente se confunda y crea que Google nos defiende de las “Megacorporaciones” como Microsoft o Apple. Como si ellos fueran Teresa de Calcuta.

Las tres son iguales: compañías que tratan de imponer sus productos en el mercado. Ninguna tiene como misión salvar al mundo. No le demos más vueltas.

Gradle

Así que para poner la guinda al pastel, tras usar un lenguaje que no es suyo y ofrecerte dos IDEs que tampoco hacen, han cambiado a Gradle, un sistema de construcción que tiene muy buena pinta, pero que de salida es muuuucho más lento que Ant. Es decir: tu proyecto en Eclipse compila más rápido que en Android Studio. Que sí, que se puede acelerar Gradle. Entonces ¿por qué no viene de salida ya configurado correctamente? ¿Por qué machacar a los devs que ya tenemos bastante al migrar un proyecto de Eclipse a AS? Es en estas cosas donde veo la desidia de Google.

Y ese es el meollo de la cuestión. Que el equipo de desarrollo de AS en Google deben ser un programador y un becario. Y el becario a tiempo parcial. Sólo así se puede explicar el ritmo de no-avance de la herramienta. De nuevo, sin excusas: si Apple puede en un año sacar una nueva versión de Xcode, digo yo que Google podrá. Pero claro, si pierdes el foco creando gafas, relojes, coches, drones y mil cosas más pero no vas a lo fundamental pasan estas cosas.

Costes

Y ahora es cuando alguien pensará: “ya, pero es que en Apple hay que pagar 80 € anuales y en Microsoft el Visual Studio de verdad cuesta pasta, mientras que en Google pagas una vez en la vida 25 dólares y ya”.

Efectivamente: ¿ves una tendencia?. Pagas por un producto == calidad. No pagas y no pueden ponerte publicidad == Google Reader, digo herramientas de desarrollo.

Tú es que eres un Fanboy de Apple

Vaaaale, venga, sí, soy un Fanboy de Apple. Los tiempos de compilación de Gradle me los invento. Y tener un IDE más de un año en Alpha es de lo más normal. O que para lanzar el emulador tengamos que andar con trucos como la aceleración Intel o usar Genymotion (de nuevo, nada de esto de Google). De paso, que nada de lo que usa Google Play Services (que cada vez son más cosas) no funcione en el emulador y tengamos que tirar de dispositivo también es un triunfo.

Quizá tu problema es que no has tratado de desarrollar con otro entorno que no sea Android Studio. En mi caso, sí. Uso Xcode, Eclipse y Android Studio a diario. Y antes usé Visual Studio, Aptana, Delphi, Turbo C y vim. ¡Hasta Blackberry ha hecho un mejor trabajo con Eclipse para BB10 que Google!

Creo que hablo con cierto conocimiento de causa. Pero si tienes argumentos en contra de algo que lo que digo (que no sean es que a mi me gusta más X en lugar de Y) sino cosas como “resulta que el roadmap de Gradle muestra que Z y Android Studio se puede mejorar de tal y cual forma” bienvenidos sean. Si quieres ponerme a parir, no comentes: escribe un post en tu propio blog. Gracias.

Y, por cierto ¿en qué parte de I/O se está hablando de las mejoras del lenguaje, IDE o compilador, más allá de ART?

Pues eso.

Actualización del 1 de Julio, 2014

Escribí esta entrada en el avión, mientras me dirigía al GCTIC a impartir unos talleres, uno de ellos de Android. El día antes tuve la precaución de copiarme el ADT Bundle que proporciona Google para todas las plataformas, por si alguien no lo tenía instalado. Tuve que usarlo: algunos de los asistentes no lo tenían instalado, y se lo proporcioné. Total, es descomprimir un ZIP en el que va Eclipse y el SDK. Es tan sencillo, que incluso escribí en este blog cómo crearte tu propio entorno de desarrollo Android portable con Eclipse.

Pues no. No era tan sencillo. Nada funcionaba. Lo instalé en mi máquina con cierta sonrisa de desdén pensando “novatillos…”. Y no. No funcionaba. Ningún ADT Bundle funcionaba. Ni en Mac, ni en Windows, ni en Linux. Pensé que estarían mal descargados y empezamos a bajarlos de nuevo. Hasta que nos dimos cuenta de que la culpa era de Google:

En la página oficial de descargas del ADT Bundle han colgado versiones que no funcionan

Y no avisan. A día de hoy puedes seguir bajándote una versión rota de ADT Bundle de la página de Google. Y sabiéndolo, no la quitan de en medio ni ponen un aviso. No. Juegan con tu tiempo. ¿Tienes una entrega de una App? Me da igual. ¿Vas a impartir un taller? No me importa. Soy Google, la prepotencia con patas, y me importa [inserta aquí un adjetivo colorido] mi comunidad de desarrolladores. Ellos son muy listos, que se busquen la vida. Total, la culpa es suya por fiarse de mi página oficial de descargas.

Eso sí, en su bug tracker sí que parece que lo saben. Y dicen que lo arreglarán en uno o dos días. Después de una semana.

Estoy harto.

j j j

Imparto dos talleres en el GCTIC: iOS y Android

El #CGTIC es el Foro de Nuevas Tecnologías de la Información y la Comunicación que va a tener lugar en Las Palmas de Gran Canaria este próximo fin de semana (del 26 al 29 de Junio). Y tengo la enorme suerte de poder asistir e impartir un par de talleres:

Esta es mi tercera visita a las Islas Canarias, y la tercera isla en la que voy a estar, tras Tenerife y Lanzarote. Muchas ganas no sólo de ir al GCTIC, sino de estar por Las Palmas al menos el Jueves y echar un paseo en condiciones. No tendré tiempo de mucho más (recordemos que voy a trabajar, no de vacaciones) pero la verdad es no que se puede ir a mejor sitio. Se puede estar igual de bien, pero mejor es complicado.

Ambos talleres son gratuitos, y el Foro ha tenido la amabilidad de hacerse cargo de los gastos de transporte. Aparte de esto, yo voy “de gratis” porque creo que hay que apoyar a la comunidad de desarrollo. Este año ya he participado en dos iniciativas similares: el Curso de iOS en Cádiz con el inimitable Jorge Galindo y el taller que hice con la ayuda del Ironhack en Madrid.

Si me ves, saluda. Y te invitas a algo. Si pongo cara rara, es que no estoy acostumbrado a que me saluden gente que no conozco ;-)

j j j

Notación Húngara: contrapost

¿A quién no le gusta una buena polémica?

Polémica Tuitera

Esta semana en Twitter Sendoa Portuondo planteó una conversación bastante interesante sobre si era conveniente (o estaba de moda) usar prefijos en las variables de nuestros programas Objective-C. Mi respuesta fue que, a veces los usaba. Especialmente uso los prefijos para los IBOutlets, de forma que puedo completar el código rápidamente (o encontrar un Outlet sin tener que hacer un viaje al@interface correspondiente.

Fernando Rodríguez (Cocoa Mental, Big Nerd Ranch, super Bad-Ass Master of the Universe) argumentaba totalmente en contra y ha escrito un artículo en Cocoa Mental al respecto. Normalmente estoy de acuerdo con las cosas que publica Fernando, más que nada porque voy al blog a leer para aprender y puedo aportar poco. Pero en este tema concreto (el uso o no de prefijos para identificar qué es una variable), no estoy de acuerdo.

Sus argumentos, que he visto esgrimidos en muchos sitios, se basan en la horrenda interpretación que se hizo de la Notación Húngara propuesta por Charles Simonyi. Nadie lo explica mejor que Joel Spolsky en el artículo Doing it wrong, pero por si no tenéis ganas de leerlo (mal!, dejad en este momento todo esto y leed el blog de Joel de cabo a rabo), voy a intentar explicarlo.

Notación Húngara

Si lees el paper original de Simonyi, encontrarás que la idea que presenta es: “pongamos el qué es de una variable en el prefijo, de forma que sepamos de qué estamos hablando al usarlo luego”. Probablemente por no ser el Inglés su lengua materna Simonyi usó la palabra type. Pero no se refiere al tipo que el compilador asigna a una variable, sino a su forma, características, esencia, chi o como lo llames. Su Kind. En un párrafo hablando de cómo prefijar cantidades (índices, filas, etc.) podemos leer:

Quantities are named by their type possibly followed by a qualifier. A convenient (and legal) punctuation is recommended to separate the type and qualifier part of a name. (In C, we use a capital initial for the qualifier as in rowFirst: row is the type; First is the qualifier.)

Si os fijáis atentamente, para dar nombre aquí a una variable que representa una fila, la llama *row_First, y no longFirst o intFirst. Es decir, usa _qué_ es esa variable y no el _tipo_ de nuestro lenguaje elegido para representar a ese elemento. Los grandes detractores de la notación húngara han visto código escritos por otros que no la han entendido y que les obligaban a hacer tonterías como:

int *ptrFirstNumber;        // ¡ya sabemos que el tipo es un puntero a int!
char *strName;              // con leer la declaración, basta...
NSString stringAddress;     // esto es de nota

Apple Will Never Do That

Por cierto y como nota inocente. Dado que esto lo extendió Microsoft y dado que Apple nunca se equivoca, Cocoa es elegante, etc. etc. en Cocoa no encontraremos nunca esta horrible notación, ¿no?. Bueno, no esta, sino notación húngara a la inversa (HungarianNotation^-1): usando sufijos en los tipos. Por ejemplo estas cositas:

AboutViewController *vc;    // ¡ejem! Ya sabemos que vc es de tipo "Pantalla About". 

¿Pero realmente es necesario poner “ViewController” al final de un tipo que extiende de UIViewController? Ya puesto así, que se llame AboutViewControllerUIResponderNSObject, y vemos todas las clases de las que hereda, ¿no?. ¡Error!.

Aquí Apple está marcando en el nombre de la clase qué es, y no su tipo. Para Apple, un ViewController es una pantalla en un programa iOS. Fijáos que el sufijo no es UIViewController, que sería el tipo. Además, sólo leyendo AboutViewController no sabes si es un UIViewController, un UITableViewController, … lo que sí entiendes es que es una pantalla.

Hungarian Notation at its best!

Un ejemplo, que me duermo

Quiero cerrar con un pequeño ejemplo. Supongamos que tenemos una clase que nos devuelve Usuarios (de un servicio web o una BD). Es la clase Users. Esta clase dispone de dos métodos:

+ (NSDictionary *)allUsers;
+ (NSDictionary *)allUsersOrderedByName;

Los nombres de los métodos son autoexplicativos. Usamos un diccionario en el que buscaremos usando una clave (en este caso, el nº de usuario).

Si en mi código, más adelante, quiero guardar estos dos diccionarios (uno está ordenado por los valores de sus claves, que ya que estamos es la forma de ordenar un diccionario, el otro no) podría usar Hungarian Notation Dark Side Style, la criticada por Fernando:

NSDictionary *dictionaryAllUsers = [Users allUsers];
NSDictionary *dictionaryAllUsersOrdered = [Users allUsersOrderedByName];

Aquí, el ver que son un NSDictionary no me aporta nada. Es una tontería redundante poner estos prefijos. Mucho mejor usando Hungarian Notation Luke Style:

NSDictionary *listUsers;
NSDictionary *orderedListUsers;

Aquí usamos qué es para nosotros estas variables, qué representan en el flujo del programa. Son listas de usuarios. Que utilizaremos para mostrar en pantalla, buscar o lo que sea. Me da igual su tipo. Pueden ser NSDictionary, NSArray, un tipo propio, un B-Tree… Lo que me interesa es comprender de un vistazo que a) son listas y b) una de ellas viene ordenada.

Conclusión

Así que, sí, estoy de acuerdo con Fernando en que poner el tipo del compilador al identificador de una variable es una chorrada. Pero eso no es Notación Húngara. Es la mala interpretación que se hizo de ella. La Notación Húngara tal y como se definió es valiosa.

Vale, pero al final, ¿tú lo usas?

Pues creo que sí. Pero no de una manera consciente. Este tipo de discusiones, que algunos obsesionados por “hacer que funcione” verán como una pérdida de tiempo son las que nos permiten aprender y entender por qué hacemos las cosas como las hacemos. Es lo que nos hace Informáticos. Que no Ingenieros. Los Ingenieros no entenderían esto :-D. Pero esta polémica la dejo para otro post.

j j j

Borrar un AVD que se niega a morir

Al intentar borrar un AVD (la configuración de un emulador de Android, conocido como Android Virtual Device) me he encontrado con este mensaje:

AVD no se puede borrar

En este caso, he tenido claro desde el principio cual era el problema sin consultar con StackOverflow. Había lanzado ese AVD antes y se había colgado. Y pensé que seguramente había dejado algún fichero indicando que el emulador estaba en marcha, y por eso ahora al intentar borrarlo pensaba que seguía encendido.

Nada que un poco de Terminal no pueda arreglar. Debemos ir, en una terminal, a la carpeta .android/avd que está dentro de nuestra carpeta $HOME. En mi caso, como mi usuario es dfreniche, la carpeta está en la ruta:

/Users/dfreniche/.android/avd/

Para llegar a ella, usamos a nuestro viejo amigo cd:

cd /Users/dfreniche/.android/avd

Una vez allí, veremos una carpeta por cada AVD que tengamos creado en Eclipse. Si hacemos ls:

Tesla:avd dfreniche$ ls -al
total 24
drwxr-xr-x   8 dfreniche  staff  272 22 ago 12:58 .
drwxr-xr-x  17 dfreniche  staff  578 19 ago 19:41 ..
drwxr-xr-x  12 dfreniche  staff  408 22 ago 12:58 Intel.avd
-rw-r--r--   1 dfreniche  staff  114 22 ago 12:58 Intel.ini
drwxr-xr-x  11 dfreniche  staff  374 20 ago 06:48 Nexus4.avd
-rw-r--r--   1 dfreniche  staff  116 19 ago 19:32 Nexus4.ini
drwxr-xr-x  10 dfreniche  staff  340 22 ago 11:22 Nexus4_API4.3.avd
-rw-r--r--   1 dfreniche  staff  130 20 ago 06:47 Nexus4_API4.3.ini

Podemos ver que los terminados en .avd son carpetas (en los atributos empiezan con una d de directory) mientras que los .ini son ficheros normales.

Si entramos en el AVD problemático (en este caso, Intel.avd) con un cd Intel.avd y hacemos ls veremos unos cuantos ficheros sospechosos acabados en .lock.

Tesla:Intel.avd dfreniche$ ls
cache.img       hardware-qemu.ini.lock  userdata-qemu.img.lock
cache.img.lock  sdcard.img      userdata.img
config.ini      sdcard.img.lock
hardware-qemu.ini   userdata-qemu.img

Con borrar estos ficheros, basta: rm *.lock

Tras esto, Eclipse nos dejará borrar tranquilamente el AVD desde su interfaz:

AVD arreglado para ser borrado

AVD arreglado para ser borrado

j j j

La NSSpain

La NSSpain es una conferencia dirigida a programadores Cocoa, tanto iOS como Mac. Al final, todo lo que empieza por NS* viene a ser un aviso del estilo de esto va de programar con el lenguaje ese raro de los corchetes. Por cierto, la insistencia en el prefijo NS (como las NSCoder Night) viene del S.O. NextStep donde se gestó el framework Cocoa y donde estuvo mantenido en crio sueño hasta su popularización, primero en el mundo Mac y luego definitivamente gracias al iPhone.

La NSSpain va a tener lugar en Logroño (La Rioja – España), aunque es una conferencia internacional. Viene gente de diferentes países y los ponentes son nacionales (los menos) y muchos extranjeros. La lista de ponentes es excepcional (dado que yo soy la excepción que confirma la regla) y van maestros como Fernando Rodríguez, de AGBO (el gran Jedi Master Cocoa) o Alfonso Alba (mi maestro Git, que me hizo abrir los ojos y cuyo curso de Git no deberías perderte si en 12 h quieres enterarte al fin de qué va Git). Por el precio que tiene la NSSpain es un regalo, viendo la gente que viene.

Se desarrolla íntegra en Inglés (por aquello de que es internacional).

<English-fear-rant>

Acabo de sentir una conmoción en la parte cateta de la fuerza “¡oh, Dios, mi Inglés no es lo suficientemente bueno para enterarme de las ponencias! Es más, todos se van a dar cuenta y se van reír de mi. Me sacarán al escenario desnudo a leer trabalenguas, y finalmente vendrá Godzilla y me arrancará la cabeza”. Vamos a ver, que se va a estar hablando de punteros, bucles, bloques, objetos… que nadie se va a poner a declamar a Shakespeare. Que con un vocabulario mínimo puedes perfectamente seguir una de estas charlas. Hay que perderle definitivamente el miedo al Inglés: es el primer lenguaje que debes aprender si quieres programar.

</English-fear-rant>

Así que este Septiembre nos veremos allí (del 16 al 19). Yo acudo como ponente (tras varios intercambios de correo, logré engañarles y hacerles creer que podía impartir una charla con cierto criterio; ahora lo malo es que hay que impartirla). En mi caso, voy a actuar dos veces: el día previo a la conferencia, con un taller de Core Data fundamentos, para explicar lo necesario (y algo más) para funcionar con Core Data. El primer día de la conferencia, vuelvo hablando de Core Data con algunos trucos avanzados, librerías y utilidades que suelo usar para mis proyectos.

Y claro, como en toda conferencia, además de los ponentes lo mejor suele ser la gente, la comunidad Cocoa. Gente que conozco físicamente o sólo por Twitter, pero que aprecio y respeto, de la que siempre aprendes y con la que quieres estar. No me voy a poner a nombrarlos uno a uno, porque sería una pesadez y de todas formas les voy a ver allí.

Lo que me lleva al último punto: que nunca he estado en Logroño. Así que este viaje me va a permitir ver algo (supongo que no mucho, que yo se cómo son estas cosas luego) pero al menos darme un paseo por la ciudad y tomarme un café en el centro, que es lo que me gusta.

Ya sabes: Logroño está cerca de todos lados (al menos, más cerca que Cupertino para muchos), el precio es de risa comparado con lo que vas a aprender, conocerás a gente alucinante y te lo pasarás pipa con personas que te entienden cuando les hablas excitado de programación. No como tu pareja, que te escucha y asiente, pero que realmente no sabe de qué le hablas.

Nos vemos en la NSSpain.

j j j

Volver a empezar

No, no me refiero al hecho de que dijera que tenía que escribir más y leer menos, y luego no he escrito desde hace meses. Me refiero a que tengo que volver a empezar a programar, después de tres semanas largas de vacaciones totalmente desconectado de un teclado. Y me cuesta.

Programar es como cualquier otro trabajo / afición. Es igual que correr, o escribir en tu blog (si lo haces, claro, no como yo ahora) y supongo que será como tocar un instrumento. Cuanto más practiques, mejor sabes hacerlo. Y más sencillo te resulta, con lo que tienes más ganas de volver a ello. Y practicas otro montón. Se crea ese círculo virtuoso que habrá sentido todo el que, tras tres semanas de correr de forma regular, siente la adicción a las endorfinas. Por cierto, que esa es otra cosa que tengo que volver a empezar a hacer…

Recientemente he leído varios artículos sobre cómo aprender a hacer cosas mucho más rápido. Todos estos artículos tienen una idea común: practica mucho, “comprime” en el mínimo tiempo posible la práctica de un año de formación normal y obtendrás los resultados de un año de experiencia. Siempre he sido reacio a esta idea, y he pensado que aprender las cosas lleva su tiempo. Pero, ¿y si estoy equivocado, y con una forma distinta de ver las cosas puedo aprender un lenguaje nuevo de programación, tocar un instrumento, correr mejor o aprender un idioma más rápido? Este verano, voy a hacer algunos experimentos sobre la forma en que hasta ahora he tratado de aprender las cosas. A ver cómo me va.

Y eso me devuelve a la idea inicial: que tengo que ponerme de nuevo a programar. Pese a lo que puedan pensar los que quieren aprender a programar, a todos nos cuesta, a los que empiezan o a los que llevamos algo más de tiempo. Siempre cuesta empezar. Lo bueno, es que como dijo Pitágoras de Samos, “el principio es la mitad del todo”.

¡Así que, menos llorar, y más programar! (Empecemos procastrinando viendo vídeos de la WWDC 2013, cuando vuelva a estar operativo el portal de Apple para Desarrolladores, claro :-) )

j j j

Acelera el emulador de Android

“El Emulador de Android es lento”. Mucho. Es una de las quejas recurrentes que tenemos los que tenemos que desarrollar para Android, bien sea por afición, devoción u obligación. Comparado con el simulador de iOS, el Emulador de Android es una tortuga. Pero claro, la comparación no es justa: Android emula un teléfono completo, con su CPU, GPU, memoria, tarjeta SD, etc. Está ejecutando código real que podríamos instalar en un teléfono, compilado para una CPU de una arquitectura que no tenemos en el escritorio (como es ARM p.ej.). El simulador de iOS crea un ejecutable x86 que “simula” comportarse dentro de un teléfono, pero realmente es un programa de Mac “travesti”. La fidelidad no es la misma.

Por eso, en teoría el desarrollo con el Emulador de Android debe ser más sencillo, al tener una mejor herramienta con la que probar. Eso, si eres capaz de aguantar el tiempo insoportable que tarda en arrancar. Y si no se desconecta de adb (Android Debugger Bridge) y tienes que reiniciarlo.

HAXM

Para mejorar esto, Intel pone a nuestra disposición HAXM (Hardware Accelerated Execution Manager). Gracias a este programa, instalaremos una capa de aceleración para el Emulador de Android, que realmente se ejecuta en como una máquina virtual qEmu. qEmu es un emulador de CPUs, es decir, nos permite ejecutar en nuestros equipos basados en Intel x86 (como un Core i5 por ejemplo) S.O. que corren en Intel (como Windows, Linux, Mac) o bien otros S.O. que necesitan otras CPUs y arquitecturas (como es el caso de Android con ARM).

HAXM es un driver (o un módulo del kernel en Linux / extensión del kernel en Mac) que concede a qEmu acceso directo al hardware en el que se ejecuta. Eso sí, como es un programa de Intel, sólo funciona con las CPUs Intel. Vamos, que si tu máquina tiene una CPU AMD ya puedes ir cerrando el post. Además, la CPU debe soportar VT-x (las modernas lo soportan, no pruebes con un Pentium II). Puedes consultar los requisitos en la página detallada de Intel sobre cómo instalar HAXM.

Instalación de HAXM

Si estás usando el nuevo ADT Bundle (es decir, el Eclipse + plugin ADT + SDK Android que ha sacado hace poco Google, que ya era hora por cierto) y abres el Android SDK Manager, al final encontrarás un grupo llamado “Extras” en el que está el Intel x86 HAXM Emulator Accelerator. Si estás en Windows / Linux, bájatelo desde aquí. Si estás en OS X Mountain Lion 10.8.2 no te lo bajes desde aquí, debes ir a la página de descargas de HAXM, ya que existe un bug que hará que tu querido Mac se cuelgue. Sí, has leído bien: los Macs también se cuelgan. Cuando te lo bajes, ya sea desde el SDK Manager o a mano (por cierto, en el enlace anterior están las versiones de Linux y Windows de HAXM) debes instalarlo.

En el caso del Mac, bajas un DMG que al montar te muestra un programa de instalación. Tras instalarlo (no exige reiniciar) podemos confirmar que está en funcionamiento escribiendo en una Terminal:

$ kextstat | grep haxm

Debe aparecer algo como esto:

Tesla:~ dfreniche$ kextstat | grep haxm
115  0 0xffffff7f81e29000 0x13000 0x13000  com.intel.kext.intelhaxm (1.0.4)

Si te has bajado el paquete usando el SDK manager, puedes encontrar el programa de instalación en $SDK_HOME/extras/intel/

Uso de HAXM

Una vez instalado HAXM, debemos descargar las imágenes de Android que también nos proporciona Intel. La idea es que en lugar de acelerar un emulador ARM (que sería muy complicado) Intel nos da Android para Intel Atom. De esta manera, cuando qEmu ejecuta instrucciones en el Intel Atom emulado realmente se pasan a nuestra CPU directamente, con la consiguiente mejora en rendimiento.

Estas imágenes aparecen como “Intel x86 Atom System Image” en el SDK Manager. A bajarlas. No las tenemos para todos los API levels, pero sí para los más usados (API 10, 15 y 17 y supongo que en breve sacarán para el 18).

SDK Manager mostrando las imágenes Intel ya instaladas

Ahora tendremos que crear una definición de AVD que utilice esta imagen de Intel. En lugar de un emulador con CPU ARM, vamos a escoger uno con CPU Intel Atom. De cara a nuestros programas da igual, ya que a fin de cuentas se van a ejecutar en la máquina virtual Dalvik. Si vamos a probar código Android nativo (escrito en C con el NDK) entonces lo mejor es leer la documentación de HAXM.

Creando un AVD con CPU Intel seleccionada

Cuando arranquemos nuestro AVD notaremos dos cosas. En la consola debe aparecer un mensaje que indique que “HAX is working” y casi sin darnos cuenta nuestro Emulador estará operativo. Se acabó el arrastrarse. Yo ni marco que arranque de un snapshot porque es tan rápido que no me merece la pena.

Bonus level

Si usas API level 15 ó 17 puedes usar la aceleración de hardware de la GPU, lo que hará que todavía sea más rápido. Avisado quedas de que puede no funcionar (el emulador se vería en negro y tendrías que cerrarlo). Consulta el apartado de aceleración de la GPU de la documentación Emulador para más detalles. Para activarla, marca el checkbox “Use host GPU” en la definición del AVD.

Ultra bonus level

Y si necesitas un emulador de Android “en la nube”, para probar algo o mostrar en una visita a un cliente, y no tienes tu máquina pero te puedes bajar el APK de Dropbox, mira Manymo. Si con esto no te pones palote

j j j

BlackBerry Jam en Barcelona

El pasado Jueves 31 de Mayo estuve en la BlackBerry Jam que se celebró en Barcelona. Un evento en el que RIM está mostrando a los desarrolladores de todo el mundo su nueva plataforma, BlackBerry 10. Me invitaron a ir y no pude evitar aparecer. Encima, como bonus a todo un día viendo esta nueva tecnología, a los desarrolladores que nos registrábamos nos entregaban un dispositivo para hacer pruebas, un prototipo. El BlackBerry 10 Alpha Device.

Entre lo poco que dormí la noche anterior, el viaje ida y vuelta desde Sevilla a Barcelona, la alergia y alimentarme casi exclusivamente de azúcar y cafeína (dieta sana) la experiencia fue extenuante, pero muy, muy interesante. En el MWC acudí a las presentaciones del App Planet, que estuvieron bien. Pero aquí pude ver y probar código. Y preguntar cosas. Y eso sube el nivel de adicción de la sesión muchos puntos (al menos para mí).

Estuve con un montón de gente muy interesante. A algunos, como a Serantes, ya lo conocía del EBE. Con Hernán, de Aecomo he trabajado y da gusto tener un jefe que sabe tanto de programar como tú. Pude conocer fugazmente a NeuroFlip. La rabia es que, con el atontamiento que tenía encima no pude hablar con él de lo que de verdad me interesa: los Amiga :-).  Y otro montón de gente como @rallat, @jorgecasar, @ClaraCorretge, Pilar Bernat…

Reunión de cracks

Reunión de cracks

El día comenzó con las típicas charlas para mostrarte lo comprometida que está RIM, y cómo se está volcando con los desarrolladores. Y debo decir que me ha sorprendido mucho su cambio de actitud. Cualquiera que me halla escuchado en los últimos años sabe que no tengo demasiado cariño por BB7. Incluso me mofé de la PlayBook antes de que saliera, llamándola en el evento eTic “PlaySmoke”. No me gusta que se hable de algo que no se puede tocar, y compararlo con un producto que se puede comprar en una tienda me parece ridículo. Toda idea que no se ha llevado a cabo tiene una posibilidad no finita de no hacerse nunca. Y luego estaba la actitud de RIM hacia los desarrolladores: o eras una gran empresa, o eras escoria. Ningún cariño hacia los desarrolladores indies e independientes. ¿Quieres un certificado para subir Apps a su tienda? ¡Paga 20 $ por él!. ¿Lo pierdes?. Pagas otros 20 $. Y el SDK ni te cuento… Muchas barreras puestas a los programadores. La guinda es que encima sólo se podía programar en Java… No demasiado excitante, vamos.

Pero el 2007 lo cambió todo. Y ahora lo importante de una plataforma no es su hardware, ni la marca. Lo importante es lo que las personas pueden hacer con ella. Y para ello, se usan Apps. Luego es algo central en la estrategia de cualquier plataforma el tener a cuantos más desarrolladores de tu parte, en tu ecosistema. Cierto es que todas quieren a los Rovio (Angry Birds) de turno, a los desarrolladores RockStar. Pero también hace falta crear comunidad, y tener a los menos importantes y torpes como yo, porque hacemos preguntas en StackOverflow, o subimos código a GitHub, o usamos la plataforma porque nos gusta y hablamos de ella. Todas las gotas cuentan para llenar un vaso.

Y debo decir que RIM se ha dado cuenta. Y ha creado una plataforma, usando QNX como base, que tiene una pinta increíble, tanto para el usuario como para el programador. Para el usuario, espero que BB10 sea la primera plataforma móvil mainstream que lleve los gestos de webOS o Meego a las masas. La multitarea real de QNX funciona muy bien, y el cambio de tareas mediante gestos (copiado de webOS) hace que sea muy sencillo e intuitivo. Y es algo que engancha, además de ser algo distinto: al final acabas haciendo gestos en el iPad. Al que esté aburrido de iOS o Android y de ver las filas de iconos típicas en la pantalla, BB10 le va a encantar. Luego está el teclado predictivo, que te permite rellenar las palabras según escribes con un swipe del dedo. O las notificaciones, implementadas de manera muy visual y sencilla de usar.

Y para los programadores, BB10 es una maravilla. Es la plataforma para el desarrollador inquieto. Puedes hacer aplicaciones nativas con C/C++. Si quieres construir los interfaces de usuario de manera más rápida, puedes usar Qt y Qml/Cascades, una implementación propia de RIM de Qt. O puedes desarrollar en HTML5 usando WebWorks, el framework HTML5 de BB10. Yo, por ejemplo, he portado las Apps que hice para webOS de manera muy rápida y sencilla. O si vienes de Android puedes empaquetar tu App para BB10 sin tocar una línea de código. Lo que va a permitir que muchas Apps de Android aparezcan en BB10. RIM se ha volcado y ha puesto los diferentes SDKs al alcance de la mano. Ya no te cobra por nada. Y hay montones de ejemplos de código fuente en su repositorio de GitHub.

Pero todo no puede ser de color de rosa, por desgracia. Como programador y geek, la plataforma me atrae y me tiene genuinamente excitado ante las cosas que se pueden hacer. Eso de volver a C++ para el desarrollo nativo, y poder escribir JavaScript dentro de los ficheros Qml que describen las vistas de los programas me encanta. Pero aprender cualquier plataforma supone una inversión. En tiempo, esfuerzo y, lo más importante, en ilusión. El año pasado empecé con webOS y, gracias a mi aura gafe, la plataforma se hundió, por mucho que Enyo siga avanzando como proyecto Software Libre. Ahora RIM dispone de la tecnología adecuada, y la usabilidad correcta. Y puede disponer de aplicaciones para su ecosistema, ya que BB10 va a correr casi cualquier cosa. La pregunta es ¿demasiado tarde?. Los primeros dispositivos BB10 aparecerán en el mercado probablemente para la campaña navideña. Y se van a encontrar con nuevos Android Nexus, creados por Google y Motorola mobile, ahora que ya autorizaron la compra. Y con Windows Phone 8 y las nuevas tabletas con Windows 8. Y, claro, el nuevo iPhone con iOS 6… Va a ser muy duro. Muy, muy complicado. Por eso mismo me gusta. Por lo mismo que sigo usando un Amiga 1200 o intento programar para MorphOS.

Porque me gustan las causas perdidas.

Aquí o consigues triunfar, o te hundes. Sin riesgo no hay gloria. Steve tampoco lo tenía fácil en el 97 cuando volvió a Apple, ¿no?. Nadie daba un duro por Apple. Así que yo voy a usar las plataformas que más me atraigan. Porque esto es cuestión de conocimiento y vocación. Y porque soy gilipollas.

 Actualización 4 de Junio

Otras reacciones a la BBJam que he leído son las de Serantes y Pilar Bernat.  Y en el lado más técnico, las de Android.es y Jorge del Casar.

j j j

Cómo crear un entorno de desarrollo Android portable

Logo de Android

Logo de Android

Algún día me tenía que pasar. Después de ver tanto backend Java en cursos de todos los colores y de coleccionar certificaciones Java, después de desarrollar para iOS y webOS, alguna vez me tenía que poner en serio con Android. De hecho, siempre me han preguntado que por qué no era esta mi plataforma de desarrollo móvil “de cabecera”. Quizás porque estaba saturado de Java. O porque, como comentaba en We.Developers, Java es un lenguaje que no me genera excesivas alegrías (sobre todo cuando lees la mayoría del código que hay por ahí, que es bastante feo, fruto del desconocimiento del lenguaje).

El caso es que estoy actualmente desarrollando una App para Android (de la que daré más datos cuando se suba a Google Play) y me ha surgido la oportunidad de impartir un curso a los programadores de RTVA. Como en todo curso, me gusta instalar el entorno de desarrollo. Y si vas a desarrollar para Android, sabes que tienes que instalarte:

  • un JDK para poder compilar todo el código Java que escribimos como parte de nuestras Apps Android
  • un JRE, necesario para ejecutar Eclipse
  • Eclipse, como IDE para escribir nuestros programas
  • el SDK de Android, que pone a nuestra disposición las bibliotecas necesarias para crear los programas Android, así como el Emulador, herramientas e imágenes para ejecutar ese emulador.
  • el plug-in ADT para Eclipse, que nos permite gestionar el SDK cómodamente desde Eclipse

Este curso se imparte en dos semanas, dejando varios días por medio. Y el tiempo que se tarda en descargar las distintas partes del SDK de Android y el plugin ADT (ambos hay que descargarlos para instalarlos) no es despreciable cuando lo intentamos hacer con 10 portátiles todos conectados a la misma Wifi. Además de la limitación inherente a compartir la conexión HTTP, el medio físico (el canal de radio usado por el punto de acceso WiFi) es el mismo para todos los portátiles. Luego hay colisiones. Y cuantos más portátiles, peor para todos.

En una primera opción, llevaba el JDK, Eclipse y el paquete de instalación del SDK en un pendrive, para irlo instalando todo. Pero de estas dos últimas descargas no me podía librar… ¿o si? Y mi miedo es volver la segunda semana y encontrarme los portátiles formateados…

Cómo crear un entorno de desarrollo Android Portable

En este caso, me centro en cómo crear el entorno portable para Windows 32 bits, que corre en XP y Windows 7. Al final comento las diferencias con Mac.

  • Lo primero es bajar todo lo que necesitamos a una carpeta:
  • Java JDK para Windows es un ejecutable, y escogeremos, de la versión 6, el saber que nos interese: 32 bits (i586) o 64 (x64).
  • De Eclipse nos interesa la última versión de la distribución Eclipse IDE for Java developers. No la versión para Java EE, ya que no vamos a usar servets ni nada de eso. A fecha de escritura de este post, la última versión es la Indigo.
  • La última versión del SDK de Android. Nos bajamos la versión en ZIP, no la instalable.
  • Una vez que tenemos todo esto bajado, debemos instalar el JDK en la máquina. Realmente queremos las carpetas que van dentro, pero al no disponer de un ZIP no tenemos más remedio que instalar. Lo dejará en C:\Archivos de Programa\Java
  • Una vez termine la instalación del JDK, nos crearemos una carpeta en el escritorio que podemos llamar Android-Portable, o como más nos guste.
  • Debemos descomprimir dentro de esta carpeta el ZIP de Eclipse.
  • Ahora, copiaremos la carpeta JRE que está en C:\Archivos de Programa\Java\Jre6\ dentro de la carpeta de Eclipse, justo donde está Elipse.exe. Así, al arrancar Eclipse usará ese JRE que le hemos instalado “tan a mano”
  • Igualmente descomprimiremos el SDK de Android dentro de Android-Portable.
  • Como necesitaremos el JDK para compilar, vamos a copiarnos en Android-portable la carpeta C:\Archivos de programa\Java\jdk1.6.0_31
  • Ahora debemos tener dentro de Android-Portable: una carpeta con Eclipse, otra con el JDK y el SDK de Android.
  • Ya podemos arrancar Eclipse. Necesitamos instalar el plugin ADT, para lo cual iremos a Help > Install Software e instalaremos ADT indicando como repositorio https://dl-ssl.google.com/android/eclipse/
  • Tras reiniciar Eclipse, nos pedirá que instalemos un SDK de Android, o que le indiquemos dónde tenemos uno instalado. Le indicamos que dentro de Android-Portable tenemos uno. Nos muestra el Android SDK Manager para descargar las imágenes de los emuladores para las versiones de Android que nos interesen, así como los SDKs propiamente dichos. Yo me los bajaría todos.
Eclipse nos pide un SDK de Android (click para agrandar)

Eclipse nos pide un SDK de Android (click para agrandar)

  • ¡Listo! Ahora podemos copiar la carpeta Android-Portable y todo lo que necesitamos lo llevamos dentro. Para arrancar Eclipse bastará con entrar en su carpeta y hacer doble click en Eclipse.exe. Si quieres, siempre te puedes crear un acceso directo, pero que sepas que al mover la carpeta tendrás que volver a crearlo.
Así debe quedar la carpeta Android-Portable

Así debe quedar la carpeta Android-Portable

Esta carpeta ya la podemos poner en un pendrive, comprimirla, copiarla de un equipo a otro, etc. Funcionará con los distintos Windows.

Si tienes un Mac el proceso es el mismo, salvo que:

  • no tienes que instalarte Java, ya que el JDK viene instalado con OS X (es una instalación opcional del S.O.). No puedes “bajarlo” de la página de Oracle.
  • debes bajar el Eclipse de Mac
  • debes bajar el SDK de Android de Mac

Ahora, a ver alguien compra las Apps que hagamos :-)

j j j