Hace tres años escribí sobre El lamentable estado de las herramientas de desarrollo Android. En aquella época, lo que existía para desarrollo Android (oficial) era el plugin ADT para Eclipse. Y, como relato en el post, no funcionaba algo que era un simple ZIP. Eclipse, Java 6, fallos en las herramientas, un Android Studio que estaba en Alpha, una documentación horrorosa, una API discutible (ver p.ej. el método isUserAGoat en UserManager), la lentitud de Gradle si probabas AS… Esto era la muerte por mil cortes, comparado con el mundo iOS, con esas APIs Cocoa tan consistentes, un Xcode tan bonito y que entonces no fallaba tanto…

Y encima Apple presentó Swift en Junio de 2014. La promesa de un nuevo lenguaje, compatible con Objective-C, con C, C++, pero funcional, con inmutabilidad, Opcionales, genéricos, … Todo se veía de color de rosa desde el mundo iOS, comparado con el cenagal que era el desarrollo Android.

Apple: Non-Pro Macs

Apple ya no hace ordenadores para desarrolladores. Y me parece muy bien, si así gana más dinero. Pero debe entonces afrontar las cosecuencias, que van a ser (porque esto ya ha lo he visto antes en otras plataformas):

• los desarrolladores se compran otras máquinas y se montan un Hackintosh para seguir desarrollando en iOS / Mac. MacOS se convierte en «ese sistema operativo que te ves obligado a usar por el trabajo». Apple no gana dinero con las máquinas. Tienes dual-boot y cada vez usas más Windows. Peligro.
• los desarrolladores directamente se pasan a Windows 10 / Linux con mejores portátiles (y a mejores precios, que no todos tenemos una mina de oro en el sótano de casa) y usan MacOS en una máquina virtual (cosa que prohíbe la licencia, como el Hackintosh, pero ponle puertas a ese campo…). Goto 1
• algunos desarrolladores se cabrean tanto con el poco aprecio que sienten desde Apple que directamente abandonan la plataforma, algo que a dia de hoy se puede hacer ya que el mercado de trabajo tiene ofertas casi para todo tipo de perfiles de desarrollo.

Si los programadores se van de una plataforma, esta se muere. Lo he visto con OS/2, con Amiga, con Linux (¿este es el año de Linux en el escritorio? Y sí, ya se que se usa mucho Linux en Android, que es Linux, y en la RaspberryPi, y que llevo usando Linux desde el 93, que no me cuentes de qué va eso que yo voté porque Tux fuera la mascota de Linux y tú no).

Casi le pasa a Microsoft. El rechazo que generó con sus Internet Explorers le ha llevado a ceder casi toda la cuota de mercado a Chrome. Y no hablemos del patinazo Vista, que enmendó con Windows 7. Es por eso el titánico esfuerzo que está haciendo ahora mismo Microsoft, permitiéndote ejecutar Linux en Windows de forma nativa, o dándote la bash. Atraer programadores que son los que riegan este campo con sus aplicaciones.

2017

Es 2017. Swift va a sacar la versión 4, con nuevos cambios que te obliguen a actualizar tu código, o no compila. Con ese asistente que tiene Xcode tan bueno. Si no tenías listo el lenguaje en 2014… ¿para qué sacarlo? ¿Porque Chris Latter estaba harto y se quería ir? Pero bueno, era 2014 y podíamos entenderlo, Apple. Pasamos por Swift 1, 1.1, 1.2, y los cambios a Swift 2. Y Swift 3. Contínuamente cambiando una base de código que funciona para hacer que siga funcionando. Es decir, gastar horas para seguir en el mismo punto. No añadir nuevas funcionalidades. Que compile. Coding is fun.

Al menos el compilador de Swift es rápido. Tanto, que cuando ejecuto Gradle en Android me parece instantáneo. Gradle, quiero decir. Pero en cada WWDC nos dicen que «ahora el compilador de Swift es un 20% más rápido». Con tantos avances en velocidad mi código debería terminar de compilar… en 1984. De lo rápido que compila. Pero la realidad es la realidad, y Swift es horriblemente más lento compilando que su equivalente en Objective C. Y es una pena, porque el lenguaje es muy bonito. Apple ha hecho un Sherlock de Kotlin con Swift, lo que está bien. Si ahora hiciese un Sherlock de IntelliJ, todos contentos.

Porque cansa ver cómo se arrastra el compilador. Cómo haces Cmd+click en un símbolo y no lo encuentra (es una función de ámbito global y no la encuentra). O cómo el autocompletado es totalmente random. O cómo pones un punto de ruptura dentro de una clausura y no puedes depurar el valor de las variables de la clausura. Bueno, sí puedes… usando println. NSlog oriented debugging FTW!

Al menos podemos refactorizar nuestro código. Esto significa que puedes cambiar el nombre a una clase. Fin de los refactors. Y en Objective-C. En Swift nada. Zero. Nil. Y de generar código ni hablamos. Últimamente Xcode no es capaz ni de comentar líneas de código con Cmd + / o acertar y autocompletarte los nombres de las librerías en los imports.

O cómo la comunidad ha tenido que solucionar problemas básicos que Apple se niega a ver. ¿Resolución de dependencias y librerías de terceros? En Android: Gradle. Soportado. En iOS: CocoaPods, Carthage, o a mano. Todos proyectos de la comunidad. ¿Plugins? En Android: Android Studio tiene de todo. En iOS: han metido un sistema de plugins tan restringido que, la verdad, no conozco a nadie que esté usando algún plugin que merezca la pena (indicadme por Twitter los mejores, por favor). Y de paso se han cargado un proyecto como Alcatraz, que sí que ofrecía un montón de plugins, temas y plantillas de ficheros porque, ¿quién quiere algo mejor cuando mi versión inferior patentada por Apple ya viene con Xcode? Y sí, entiendo los problemas de seguridad de los plugins, y que Xcode viene firmado y todo eso. Pero digo yo que habrá alguna solución intermedia colocando los plugins en otro proceso fuera del sandbox de Xcode…

WWDC

Así que, en esta próxima Developers Conference, vamos a abrir la Keynote hablando de lo mucho que vendemos, de lo buenos que son los portátiles con la ToyBar, de lo chulos que son los auriculares Beats, de todas esas cosas que nos interesan muchísimo a los programadores, que es a los que debe ir dirigida la Keynote. Nuevos colores para las correas del reloj. Nuevas animaciones en macOS para organizar tus ventanas en 15 espacios para que nadie lo use nunca, porque todos usamos un monitor externo. Y Apple Music, que todo programador necesita música de fondo y eso. Pagando.

Pues no. Este año no renové mi Apple Membership por primera vez en 6 años. Y cada vez me cuesta más y me duele más abrir Xcode. Porque veo lo que podría ser, lo comparo con un excelente IDE (con sus problemas, pero mucho mejor para escribir código) como IntelliJ y me sangra el corazón. Quiero seguir programando en un Mac en 2027. No me eches de tu jardín, Apple.

Toda la info está en la web: http://desarrollaapps.com/

Y tras la pausa, la nota de prensa. ¡Nos vemos!

Curso intensivo de ANDROID para programadores en El Puerto de Santa María

• Aprende a programar en una semana (38 horas) en Android con el especialista Diego Freniche en el CEEI Bahía de Cádiz (El Puerto de Santa María)
• El curso intensivo tendrá un horario de lunes a viernes por las tardes (16:00 a 22:00) y sábado de 9 a 18:00
• El curso cuenta con la financiación del BBVA de Máster Blue e incluye además formación de Marketing para Apps y Preparación de proyectos para potenciales inversores

El Puerto Santa María, Cádiz, 8 Octubre 2014. El CEEI y Comunicación Plus lanzan el curso intensivo de Android de 38 horas con el especialista Diego Freniche, que se celebrará del 10 al 15 de noviembre 2014 en horario de tarde en El Puerto de Santa María (www.desarrollaapps.com)

El curso ofrecerá una formación integral y muy práctica para crear aplicaciones que puedan cubrir la creciente demanda del mercado en este sector empresarial. Según la Comunidad Europea, se necesitarán 4.8 millones de puestos de trabajo relacionados con estas tecnologías hasta el 2018.

Las clases tendrán lugar en las instalaciones del CEEI Bahía de Cádiz en El Puerto de Santa María, con una duración de 33 horas de desarrollo Android y 3 horas de marketing móvil que permitirá conocer cuál es la mejor estrategia para posicionar las apps de los asistentes al curso. Asimismo se ofrecerán 2 horas de asesoramiento para presentar proyectos a potenciales inversores para la captación de socios o capital, y que permitirá a los asistentes completar una formación orientada a un desarrollo eficaz de negocios de aplicaciones móviles.

El curso es uno de los módulos dentro del I Máster en Desarrollo de Aplicaciones Móviles, que ha completado ya la primera edición de iOS y Apps multiplataforma (HTML5) con excelentes valoraciones por parte de los asistentes. Los módulos se pueden realizar individualmente o completar el Máster con el resto de plataformas. Se abrirán nuevas convocatorias para 2015 de iOS y HTML5.

Financiación

Además del CEEI y la Cámara de Comercio de Cádiz, participan como colaboradores del Máster la entidad bancaria BBVA que pondrá a disposición de los alumnos excelentes ventajas financieras.

Los asistentes podrán adquirir los conocimientos a través de su producto Master Blue, que permitirá contratar financiación con la posibilidad de no abonar ninguna cuota durante los dos primeros años y financiar hasta un plazo máximo de 8 años adicionales que les permita aprender y formarse para poder desarrollar su carrera profesional con los conocimientos adquiridos.

Profesorado

Todo el profesorado del Máster en Desarrollo de Aplicaciones Móviles está en activo desarrollando las materias que imparten:

Diego Freniche: Especialista en iOS y Android (33 horas) Marian Burgos: Profesora de Marketing móvil (3 horas) Carmen Carpintero: Presenta tu proyecto a inversores (2 horas)

HORAS: 38 horas semanales presenciales

FECHAS: Del 10 al 15 de Noviembre 2014

HORARIOS: De Lunes a Viernes (16:00 a 22:00) y sábado de 9 a 18:00

DÓNDE: CEEI Bahía de Cádiz. Calle del Manantial, 13 (Las Salinas). 11500 El Puerto Santa María (A 5 minutos de estación de tren)

PRECIO: 700 euros (incluye formación, coffee-breaks y almuerzo del sábado)

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.

• uno sobre cómo crear tu primera App con iOS
• lo mismo, pero con Android

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

Una pequeña actualización a la información del Máster de Comunicación Plus para aprender a desarrollar Apps en Chiclana, a todo confort, con unos bañitos en la playa que ya van haciendo falta:

• tuvimos la suerte de ser entrevistados por Javier Oliva en el programa de Canal Sur Conectados en RAI.
• Javier Suárez Ruiz, el profesor del Máster encargado de Windows Phone (genuflexión y respeto al crack) ha escrito en su blog (que, por cierto, para los que quieran aprender Windows Phone es el sitio a donde ir) una entrada sobre el Máster y su visión del mismo.
• he rectificado en el post que escribí sobre el Máster las horas totales del mismo. Son 240 h, ya que cada semana son 60 h de formación: 50 h de la plataforma de la semana (iOS, WP, Android) y 10 de otras cosas (prototipado, UX, etc.)
• el Máster empieza el próximo Domingo 18. Muchas ganas de irme a Chiclana y huir del pólen y las alergias del campo.
• durante el Máster, esperad fotos y recochineo desde la playa y piscina. He avisado.

Me voy a la playa a enseñar iOS y Android. Si no vienes, puedes sentir envidia. Es normal.

El Máster

Pues sí. Este es el panorama al que se enfrentan los alumnos del I Máster en Desarrollo de Aplicaciones Móviles en Andalucía de Comunicación Plus. Retirarse del mundanal ruido junto a las playas de Chiclana, en Cádiz. En un apartahotel de 4 llaves. Y una vez allí, darle a la tecla 50 h por plataforma, en formato ultra-intensivo, empezando un Domingo y acabando un Sábado.

Si echáis cuentas, 50 h seguidas de Domingo a Sábado queman a cualquiera. Por eso nos han prometido actividades “extraescolares” con las que recuperar cuerpo y mente en tiempo récord. Algo he oído de masajes, paseos en bici de montaña por la playa, clases de Pádel o salir al mar a hacer Paddle Surf. Y claro, además tenemos las piscinas y la playa de Chiclana. Mal no vamos a estar.

Pero volviendo al contenido del Máster, me parece muy interesante que se traten cuatro plataformas distintas (luego se puede escoger la que te guste más, o de la que te ofrezca trabajo). Además de aprender mucho, puedes comparar y ver lo que tienen de mejor unas sobre otras. Por ejemplo, en Windows Phone tienen bindings (en iOS no tenemos Cocoa Bindings, sólo en OS X). O puedes ver que la forma de internacionalizar proyectos de Android probablemente sea la más limpia (en mi opinión). O por qué Eclipse necesita ya la jubilación (después de ver Visual Studio y Xcode). Y además, habrá unas horas dedicadas a Márketing Online o a pensar en la Experiencia de Usuario. Esto último lo dará el gran Jorge Galindo de 47 Degrees con el que organicé en Febrero pasado el curso gratuito para parados y estudiantes de iOS.

Yo me voy a encargar de las partes de iOS y Android. Vamos, de las que se algo, porque de las otras dos flojito, flojito. Creo que 50 h dan para mucho y podremos ver de todo: herramientas, código, patrones de diseño, frameworks, … y apps. Muchas apps. Cosas aplicables directamente (o eso espero).

Hay muchas cosas buenas en este Máster, pero el alejarte del trabajo para enfocarte en aprender, la intensidad de la formación (un poco a la Big Nerd Ranch, pero en Cádiz, que lo mejora todo) y el apoyo del Director del Máster, Pablo Gª Trespalacios (que sabe de lo que habla porque para eso ha sido alumno mío) me parecen lo mejor. Y los alumnos, claro, que no saben dónde se meten

El vil metal

Como he leído por ahí es muy caro. Bueno, para empezar puedes buscarte el alojamiento y ahorrarte algo, o escoger semanas sueltas. Si vamos a lo más “caro”, son 5000 Eur., que es un dinero. Pero eso incluye:

• un mes alojado en un complejo de apartamentos con pensión completa
• todas las pausas de cafés
• las actividades extra académicas
• y 200 h, al menos, de formación. Si valoras en 1000 Eur todo lo anterior, cada hora de formación te sale a 20 Eur.

UPDATE 12 Mayo No son 200 h. Son 240 h, ya que cada semana tiene otras horas dedicadas a prototipado, UX, márketing… sólo había incluido mis 50 h e ignorado al resto

• y hay una financiación muy interesante (los dos primeros años no pagas nada).

Si te interesa esto, tienes toda la información en la web de Comunicación Plus.

Yo ya estoy buscando las chanclas de la playa para echar en la mochila junto con el portátil. Lo dicho: puedes sentir envidia

Como el año pasado, me quedé en casa de Rafa. Y he pasado la semana con Luis Ascorbe, Pedro Muñoz y el resto de cracks del capítulo Cocoa de Barcelona (lo siento, sois muchos ) y de otras partes de España que estaban allí para el MWC.

Del MWC en sí he visto poco. Cada vez me interesa menos: mucho móvil, mucha tableta, ves cosas muy chulas pero tienen poco impacto en mi día a día. En cambio, en la WIPJam he podido aprender sobre desarrollo con Google Glass, trucos de Android e iOS, … Creo que prefiero las conferencias de desarrollo, y cuanto más hardcore mejor.

Es esto, la WIPJam debe mejorar. Creo que a todos nos gustó que fueran más días, pero hacía falta más contenido, y si hay que vender los productos de los espónsors, siempre se puede hacer de forma que de rebote aprendas cosas. Es decir, eché en falta más talleres de remangarse y hacer cosas. He enviado mis sugerencias al personal de la WIPJam (que, por cierto, son tan buena gente que parecen de Cádiz) y espero que a) me dejen aplicar algún cambio el año que viene y b) me dejen entrar el año que viene, pese a las críticas

El caso es que estuve de Lunes a Miércoles en la WIPJam (en Plaza de España, no en la Nou Fira, que es donde está el MWC de verdad) y el Jueves me eché un paseo por el MWC. Que duelen los pies un montón: es muy grande y las moquetas del suelo muy duras, o algo pasa. Y vi cosas chulas, como el Galaxy Note 3 de Samsung, o los Nokia X, o los teléfonos Firefox OS. Pero poco más.

Lo mejor: las cervezas, las charlas con @Pepito, las cenas, el humor de Carles, las Google Glass, los iBeacons…

Material del taller de Core Data de la WIPJam

En la charla de Core Data

Lo más importante para mi fue el poder impartir la charla sobre Core Data del Lunes y luego poder programar con un grupito una pequeña App usando mogenerator y Magical Record. Como prometí poner todo el material online, aquí está:

• la presentación sobre Core Data, en SlideShare
• un ejemplo de código, usando mi Core Data Stack
• un segundo ejemplo, con mogenerator y Magical Record

Soy un fanboy de Apple, pese a tener (y usar) un Lumia 800 con Windows Phone, un Nexus 4 con Android 4.3 o una Blackberry Z10 con BB10. Sin contar la Touchpad de HP con webOS, la BB PlayBook con Qnx, el N900 de Nokia o mi primer smartphone, un Windows Mobile 5. Creo que soy un fanboy de la tecnología en general, y de la tecnología móvil en particular. Me gusta todo aquello que caliente silicio (1ª Ley Freniche de cómo la tecnología te pone Palote)

Soy un fanboy de Apple, pero llevo casi dos meses usando como teléfono principal, sin descanso, un Nexus 4. Y lo complemento muchas veces con mi tableta Nexus 7 primera edición. Y ambos me gustan. Mucho.

Cómo comprar un Nexus

El Nexus 4 lo compré por necesidad. En Diciembre del año pasado vendí mi iPhone 4 y estuve tirando con el 3Gs, al que, por desgracia, se le notaba cada vez más la edad. El Lumia 800 me rescataba a veces, pero a la plataforma Windows Phone le faltaba el empuje que probablemente le de el nuevo Lumia 1020. Y no tenía la Z10 en esas fechas. Un día, desesperado por la lentitud del 3Gs con los mapas (y gracias a que estaba de suerte) pude comprar el Nexus 4 más pequeño, el de 8GB.

Digo estar de suerte, porque esta fue la primera cosa que me chocó. No había stock en la página de Google del Nexus 4. A veces había, otras no. Y lo único que te recomendaba Google era que «volvieras a mirar pasado un tiempo». ¿Perdón?. ¿Volver luego?. Esto te pasa en una tienda online y no vuelves nunca. De aficionados. Nunca como entonces vi claro la diferencia entre Apple y Google.

El negocio de Apple está claro: venderte el dispositivo, y es muy raro que te dejen salir «vivo» de su tienda online si entras con la tarjeta de crédito en la mano. Cuando lanzan nuevos productos puedes «reservar» el producto. Cuando se agotan la cosa es aún más astuta e insidiosa: te dejan comprar, pero el plazo de entrega «aproximado» es de 4 semanas. Es decir, que tú pagas por adelantado y con ese dinero (que ya tienen), fabrican el iPhone que te venden. Como probablemente paguen con retraso a sus proveedores, es el negocio redondo, la genialidad a la que todo el mundo aspira: ganar montañas de pasta sin arriesgar un euro, sabiendo de antemano el número de dispositivos que tengo que fabricar y a dónde enviarlos, con lo que optimizo los envíos, etc. Lo dicho: perfecto.

Frente a esto, Google es una vendedora de anuncios on line, pero poco más. Decir que «se me han acabado», que no se cuándo tendré más, ni garantizarte una reserva, es lamentable. Se puede dar el caso de que alguien mire, vuelva a las dos semanas justo después de que yo compre, se quede sin su teléfono y tenga que volver a mirar. Algo a todas luces injusto. Casi parece que no quieren que se vendan estos teléfonos. Y yo estoy convencido de eso: Google no quiere que se vendan los Nexus. Los sacan casi obligados en las Google I/O, para demostrar las nuevas capacidades del S.O., pero no lo tratan como un producto que en sí mismo les genere beneficio. Además, en el caso del Nexus 4 si venden muchos le hacen la competencia a LG, que es su fabricante. Sólo pregúntate: ¿cuántos anuncios has visto en televisión de los Nexus (tabletas y teléfonos)?. Cero, ¿cierto?. Claro que puedes pensar: «es que la tele es cara». Aunque hablamos de Google, que no son precisamente pobres. Segunda prueba: ¿cuántos anuncios has visto en Youtube?.

Y eso que el teléfono se vende solo. Una pantalla increíble, un diseño precioso, muy sólido. Un teléfono libre, con las últimas actualizaciones del S.O. Android por debajo de los 300 Eur. Perfecto. Quizás demasiado, y por eso Google no quiere venderlo (para no molestar a sus fabricantes). El caso es que es el teléfono de los que se enteran (Geeks, seguidores de Google y gente que está atenta a la evolución tecnológica). Pero no el de las masas, cuando debería serlo por muchas razones: precio, ser un terminal libre, características, software…

Hard

No voy a hacer ninguna review del Nexus 4 ni de la tableta Nexus 7. Hay montones en Internet. Sólo quiero llamar la atención sobre cosas que me hacen gracia, sobre todo porque fueron enormemente criticadas cuando se lanzó el primer (y segundo, y tercer) iPhone:

• ¡no tienen un conector USB para ponerles un pincho USB!. Eso, al parecer, era uno de los pecados del iPad. Se ve que con el tiempo ha quedado demostrado que con Wifi y servicios en la nube (Dropbox, Skydrive, iCloud, etc.) no es necesario cargar con un pendrive. El pendrive es la WiFi de los torpes.
• siguiendo con el USB, vale, que no tengan entrada USB «gorda». Pero podrían soportar el modo USB On The Go con adaptadores microUSB-USB. Google es muy open con Android, pero para hacer esto necesitas hacerle root al teléfono. Fail.
• la batería de ambos es fija. No es intercambiable. Veo algunas similitudes con los dispositivos iOS. Aunque no puede ser ¿no?: las baterías fijas son algo del Averno.
• ídem con la tarjeta SD. Vamos, que no tienen. Curioso. Será para ahorrar costes, pero es que cada vez se parecen más al estándar que marca el iPhone.
• soporte para Flash. ¿Recuerda el Flash, abuela? Pues eso.

Ahora sí, tienen algunas cosas muy innovadoras:

• NFC. Perdón, Android Beam. No sirve para nada, pero está bonito tenerlo, para amontonarlo en listas de características inútiles. Si las fotos se suben automáticamente a Dropbox y G+ ¿para qué voy a tocar un dispositivo con otro para emparejarlos y pasarla por Wifi? ¡Si la foto ya está en Dropbox/Google +!. La marcas allí y se la mandas a quien quieras por correo, Twitter, Facebook… En fin, que hasta ahora NFC es una promesa pero no he visto un solo uso útil de esta tecnología en el mundo real. Usado por personas normales. Por cierto, cuando tocas el teléfono con la tableta por detrás, tienes que apuntar bien hasta que se activa el NFC. Lo que lleva a estar frotando los dispositivos, algo que no me gusta demasiado…
• cargador inalámbrico. Algo que excita mucho al que no ha tenido una tableta HP WouchPad con webOS y el cargador sin contacto TouchStone. Y el problema es que estos cargadores por inducción son lentos, muy lentos. Son muy chulos, la primera semana, y para hacer una demo de lo que es capaz mi teléfono y no el tuyo. Pero al final la base de carga debe estar enchufada, luego el momento sin cables se viene un poco abajo. Probadlo y me contáis.

Las cosas realmente innovadoras para mí ya no son el hardware. Defender que iOS es mejor que Android, que Android es mejor que iOS o cualquier otra postura basándose en el hardware es absurda. Salvo raras excepciones, cualquier smartphone hoy en día tiene un hardware impresionante. Tanto, que por desgracia ya no nos maravillan. Por eso la gente dice que Samsung no innova con su S4, o que el próximo iPhone va a ser un fracaso. No es que no avancen: es que los avances no impactan tanto en nuestro uso diario. Una batería de una semana de duración sí sería un avance notable, por ejemplo. O un cristal a prueba de balas que no se rompa en la primera caída.

Apps

La clave es el ecosistema: Apps y mantenimiento del S.O.

Y en el tema de las Apps la cosa ha cambiado mucho. Atentos, haters de iOS con lo que voy a decir: sólo me falta tener Things en el Nexus 4 (App de GTD) para poder prescindir de iOS y el iPhone. En mi caso, para lo que hago con el teléfono, tengo de todo. Repito, para que se vea bien lo fanboy que soy: uso un Nexus y me hace feliz, tanto que me planteo incluso cambiarme. Las Apps en Android no están tan bien acabadas como las de iOS, pero han mejorado en general mucho.

Un inciso para que nadie olvide que soy un Fanboy. Las Apps de iOS son mejores que las Android. Esto es un hecho indiscutible, sólo hay que tener dos dispositivos iOS y Android y usarlos. Apple hace aplicaciones, como Pages, Garage Band o iPhoto / iMovie para iOS que son las mejores, no en iOS, sino en cualquier plataforma móvil. Google hace buenas Apps, pero creo que salvo Maps no tiene ninguna que sea tan alucinante como las anteriores de iOS. Y las que tiene buenas (Maps, G+, Gmail, Youtube) son iguales en iOS y en muchos casos, son mejores en este último (caso de Google Now).

Por cierto, la aplicación de Mapas es muy chula. Además de ser un GPS casi perfecto, el detalle de ponerse en modo Street View al terminar un viaje es bastante chulo. También se equivoca a veces con las rutas, pero en general es una App que uso mucho y es muy buena. Google Now también me alucina, aunque es muy creepy y te sientes espiado cuando empieza a proponerte viajes basado en todo lo que ha recopilado de tu experiencia anterior. Por supuesto, Google nunca usará esos datos para venderte mejores anuncios (sabe si vives en un barrio con mayor o menor renta per capita, ve las veces que vas al cine, o de vacaciones, pero ellos nunca lo harán). Don’t be evil. My ass.

Dicho todo esto, la cantidad y calidad de las aplicaciones son suficientes para que me plantee seriamente el cambio permanente a la plataforma Android. Bueno ¿permanente?. Llevo sin usar un iPhone desde Febrero, creo… Menudo Fanboy…

Las actualizaciones.

Esto es de lo que más me gusta. Es decir, estoy agradecido por tener un comportamiento normal en el resto de plataformas: que cuando salga una actualización pueda disponer de esas mejoras en mi teléfono o tableta inmediatamente.

Pero por desgracia (para los desarrolladores) en el mundo Android esto es la excepción, no la norma. Incluso con un Nexus, tienes que esperar una cola que no entiendo (cuando hay actualizaciones de Apple llegan instantáneamente a todos los teléfonos, no hay que esperar dos semanas). Y no es que Google no sepa de infraestructuras de servidor grandes, que aguanten mucha carga. Es desidia, pura y dura. Si te venden los Nexus libres, y no hay un operador de telefonía por medio ¿cuál es la razón de que no se actualicen todos a la vez? Que no se le dedican los recursos necesarios porque estos cuatro frikis que ya han sido maltratados cuando compraron el teléfono están domesticados y acostumbrados a esperar las migas que se caen de nuestro plato. Al menos, esta es la sensación que se me quedó tras el I/O, esperando día tras día la actualización. O eso, o tienen un único Pentium III como servidor para las actualizaciones de Android.

Además de tener la última versión, la respuesta y fluidez del teléfono y las Apps que uso (Evernote, la cámara, el correo, los navegadores: Firefox, Chrome y Opera, Swiftkey, los fondos animados, algún widget interesante, Dropbox, etc.) convierten este teléfono en una alternativa total a los Samsung Galaxy S4 de turno. Una persona normal le sacaría más partido (y le saldría más barato) si se comprara libre uno de estos. Pero se ve que no interesa: ni la operadora de turno te cuela un contrato de permanencia de 24 meses ni el fabricante saca un margen adecuado. Y por eso Google no lo publicita. Google fabrica los Nexus para su legión de adoradores, lo cual es triste. Porque deberían de estar al alcance de todos. Búscalos en El Corte Inglés. Suerte.

Ahora vendrán los típicos comentarios: «Es que tú no sabes usar bien Android», «es que tienes que hacerle root al teléfono», «es que con el S.O. oficial no, pero con tal ROM cocinada puedes hacer tal o cual», «es que eres un fanboy». He usado Android desde la versión 1.6 (HTC Magic) y desarrollo para Android. Creo que tengo cierto conocimiento de causa. Los argumentos que escucho muchas veces no están basados en las ventajas que tenga Android de cara a los usuarios, sino al partido que pueden sacarle cuatro geeks al teléfono. Algo no al alcance de todos.

Nuevos precios y conclusión

Mientras escribía esto Google bajó los precios del Nexus 4 hasta los 200 Eur. A este precio, pese a cualquier molestia que puedas tener, no hay otro smartphone que le haga sombra. Por 200 Eur es imposible encontrar mejor hardware, con el S.O. siempre actualizado y la oferta de Apps de Android. Para mí, es la opción evidente. Porque además, es libre.

Lo que me dejará un poso aún más amargo, ya que no se va a vender masivamente. Lo verás en las manos de muchos Geeks. Pero no en la de gente normal. Y la gente normal se merece este teléfono.

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

El caso es que la semana que viene me voy al Mobile World Congress 2013 que tiene lugar en Barcelona. El año pasado estuve y me lo pasé bien, pese a que llegué enfermo y me tuve que curar una gripe «en pie» para no perderme el espectáculo. Este año, además de pasarlo bien, como ya se de qué va esto del MWC voy a procurar no pagar la novatada. Por ejemplo, este año no voy a estar allí a las 9 de la mañana, que está todo cerrado y te miran como lo que eres: un friki ansioso. Y voy a enfocarme más en las reuniones y en los contactos. Fem negoci, que dicen los locales.

Y claro, puestos a ir, surge la pregunta de todo geek bien equipado: ¿qué me llevo?. Esta pregunta es el equivalente del «¿Qué me pongo?» de nuestras novias / esposas, pero trasladado a cacharros. Porque, ya que tengo una serie de chismes, quiero aprovecharlos y sacarlos a que les de el aire.

La primera cuestión es si llevar el portátil o no. Y creo que va a ser no. Pese a que me encanta mi MBP 13″, del que ya escribí hace no mucho, no acabo de ver el sentido de llevármelo. Salgo de Sevilla el Lunes a las 8:30 en AVE y llego a BCN a las 14:30. Y dudo que me ponga a programar al llegar. Y una vez te metes en la locura del MWC, no creo que escriba una línea de código. Dentro del recinto, es seguro que no voy a hacer nada de eso. Y fuera, siempre habrá alguna reunión a la que ir, un rato para dormir o comer, o estar con gente. Y el Jueves a las 16:00 me vuelvo. Vamos, que no me lo llevo. Ya escribiré código el Viernes. El problema es que veré a otra gente con sus portátiles y me entrará morriña

Luego viene el asunto de la cámara. Teniendo una flamante Nikon D5100, quiero llevármela. Pero el chisme pesa lo suyo, y no voy como periodista (al final no pude conseguir una entrada de prensa por detalles sin importancia, como el cierre de MacWorld ). Así que estoy pensando en usar los móviles / tabletas y una compacta Sony que apenas uso (no la uso porque hace fotos aceptables a la luz del sol, pero en interiores es directamente una basura, la compré con los puntos de la gasolina). Venga, segundo tema liquidado: la compacta y el resto de móviles / tabletas harán de cámaras oficiales.

Siendo el Mobile World Congress, hay que llevarse móviles y tabletas. En este apartado lo tengo casi claro. El iPhone 3Gs (que hasta ahora está siendo mi móvil principal) se viene conmigo, sin SIM, o con una de repuesto que tengo por ahí. Mi BlackBerry Alpha Device se viene, probablemente con la microSIM que tiene ahora el iPhone. Y la duda es si llevarme o no el Lumia 800, para ir cambiando. El iPad 3 en el que estoy escribiendo ahora mismo esto con iAWriter se viene seguro, junto con un teclado Apple BT inalábrico. Será mi portátil de guardia, en el que leer el correo, consultar Evernote, escribir, subir posts a WordPress. Vamos, que va a llevarse la parte importante de la paliza. Y claro, hablando de tabletas, me llevo también la Nexus 7, mi ojito derecho que me acabo de comprar, por si pruebo cosas de NFC. No me había dado cuenta hasta ahora, pero voy a llevar un dispositivo de cada S.O. principal: iOS, BlanckBerry 10, Windows Phone y Android. Geek Achievement Unlocked

Además de esto me llevaré cargadores y cables varios, algún pendrive por si hay que transferir un fichero en el último momento y creo que nada más. Ya tengo pensada la bolsa que me voy a llevar, una muy ligera que me regaló Migue Terrón y que él define «de los chinos» pero que parece cortada para este evento. O eso, o me llevo una que tengo por ahí de BlackBerry.

Y ahora paso a preguntar ¿qué te llevarías tú?. ¿Hago bien dejando el portátil detrás?. ¿Me llevo la cámara? Me gustaría contrastar opiniones en los comentarios.

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).

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.

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…

Si tenéis dudas comentad allí y aquí, que si no no os puedo responder

Este pasado Miércoles 12, estuve en Sevilla impartiendo una charla sobre cómo está ahora mismo el mundo móvil, de la mano de Avante. Fueron cuatro horas (con un pequeño descanso) en el que apenas tuve tiempo de hablar de iOS y Android, y algunas cuestiones generales. Me lo pasé muy bien, relatando mis batallitas. Supongo que los asistentes (que me tenían que aguantar), no tanto.

Es increíble lo mucho que cambia esta parte del sector informático en meses. En Julio estuve en Zafra realizando este taller, pero con más profundidad, para ayudar a una empresa a elegir su estrategia móvil para desarrollo. Como eran programas in house y ya sabían Java finalmente vimos que lo mejor era la ruta Android. Pero desde entonces Samsung ha sido condenada por copiona, ha salido el Kindle Fire HD, el Nexus 7, se han anunciado los nuevos Lumias… Esto va a velocidad de vértigo y son tantas las plataformas y hay tanto ruido que es normal que el que no esté al tanto quiera alguna indicación.

La pena es que no pudimos hacer casi ni un hola mundo con Xcode. Quería hacer algo también con Android, pero fue imposible. O haber enseñado alguna aplicación webOS, o Windows Phone. Pero cuatro horas se van volando, cuando hablas de algo que te apasiona

P.D.: Avante ha convocado un máster de desarrollo iOS, Android y Windows Phone. Tienes la oportunidad de aguantarme enseñando a programar en  iOS y Android si te apuntas

P.P.D.: ya a finales de 2010 estuve hablando en un encuentro e-Tic de Avante sobre iOS. Hay vídeo para recordarlo.

No voy a dar instrucciones, ni a contar nada. Creo que después de los vídeos del Reverendo Kyle hay poco más que añadir. Os dejo con el que he usado para instalar CM9 en la TP. Yo tenía ventaja, porque ya estaba instalado MoBoot y ClockModWork Recovery, pero aún así es fácil.

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)

• ¡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.

<

div class=»mceTemp mceIEcenter»>

<

dl id=»attachment_1707″ class=»wp-caption aligncenter» style=»width: 470px;»>

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

]]> /2012/05/23/como-crear-un-entorno-de-desarrollo-android-portable/feed/ 11