Me enamoré de un robot Hola. Me llamo Juan Alonso, y soy Director Técnico en Tecnilógica. Es una empresa de desarrollo, que incluye un departamento de aplicaciones móviles, formado hace cuatro años. A lo largo del último año, en Tecnilógica estamos viendo cambiar el mercado de las aplicaciones móviles. Los clientes demandan cada vez más aplicaciones Android, para desarrollar a la vez o en vez de la correspondiente aplicación iOS. “Me enamoré de un robot” no pretende ser una charla técnica. No voy a hablar de frameworks, metodologías, librerías, stacks, fragmentos ni nada por el estilo. Simplemente quiero hablar de la situación actual y exponer algunos argumentos que os pueden ayudar a la hora de convencer a ese ser mitológico del que habéis oído hablar y que alguno de vosotros incluso habéis llegado a ver - el cliente - para animarle a desarrollar primero una aplicación Android o, al menos, poder desarrollar las diferentes versiones simultáneamente. No pretendo avivar el fuego entre ambas plataformas. Tanto iOS como Android tienen unos aspectos que las hacen muy atractivas, así como reconozco que en otros campos se quedan un poco cojas y hay campo para la mejora. Curiosamente, parte de las ventajas y desventajas de cada plataforma viene de la filosofía “sistema abierto / sistema cerrado” que aplican a rajatabla, hasta las últimas consecuencias. Primero para iOS Hasta hace unos meses, cuando un cliente nos solicitaba desarrollar una aplicación, siempre empezaba por la versión iOS y si la cosa iba bien o le quedaba algo de presupuesto, a veces se animaba a hacer la aplicación Android. No es habitual que el cliente conozca de primera mano el mercado, y en muchas ocasiones se rige por un conocimiento que puede resultar incompleto o sesgado. Así, el cliente escucha afirmaciones como que “el dinero está en iOS” o que “desarrollar una aplicación para Android es mucho más complicado” y no va más allá. Es cierto que hay más dinero en iTunes: se calcula que cerca de dos veces y media más, pero, por otro lado Google Play está creciendo mucho más rápido. Y, respecto a las herramientas, es verdad que hasta hace muy poco tiempo el desarrollo en Android era bastante infernal, pero las herramientas han madurado mucho, facilitando las tareas de desarrollo y testing. Otro factor a tener en cuenta, y que desarrollaré posteriormente es el tipo de mercado en el que estamos. El cliente, cuando se informa, no siempre se da cuenta de que la información que le llega no tiene porqué servir para el mercado europeo o español, donde las condiciones son diferentes. Estadísticas Está claro que las empresas, los clientes, quieren apostar sobre seguro y para ello, lo primero que hacen es consultar cifras. Lamentablemente, hay una guerra tremenda de cifras así como multitud de estudios con resultados dispares: unos comparan el market share,; otros, el número de teléfonos en uso, lo que nos lleva a preguntarnos si sirven de algo estos datos. Como referencia son útiles, pero conviene manejarlos con precaución, ya que es frecuente que nos den una imagen sesgada o incompleta de la realidad. ¿Qué beneficios se obtiene con cada venta? ¿Qué dispositivos se están comparando? ¿Qué porcentaje de dispositivos está en uso? Las cifras que se manejan en España es de tres terminales Android por cada terminal iPhone. A nivel mundial, diferentes estudios hablan de mil millones de terminales Android frente a

setecientos millones de terminales iOS. Como veis son unas cifras lo suficientemente importantes para presentarlas al cliente y aportarle una visión más amplia de la realidad. Filosofía: abierto y cerrado Resulta curioso que lo que para nosotros es uno de los puntos fuertes de la plataforma Android, los clientes lo perciben a veces como una debilidad. Me refiero al sistema abierto, que a veces es percibido como el salvaje Oeste, una plataforma sin ley donde, en cuanto te descuides, te has instalado un programa con malware. Y lo que es peor, a veces Android es el mayor enemigo de sí mismo. Os pongo unos ejemplos: • Un sistema operativo abierto permite a las operadoras distribuirlo. Así, los usuarios no tendrán

que esperar por sobrecarga de los servidores cuando aparece una versión nueva del sistema operativo para todos los usuarios. Sin embargo, hay veces que las operadoras tardan en distribuir la versión nueva, o es una versión modificada con funcionalidad diferentes.

• Al ser fácilmente modificable, se da el caso de que los sistemas operativos se hacen la competencia entre ellos mismos: los diferentes “flavours” de Android compiten entre ellos. Esta situación peculiar no se da en un sistema cerrado, donde la experiencia resulta mucho más consistente.

• Se ofrece una mayor variedad de hardware, lo que permite producir modelos muy personalizados. Como contrapartida, aparece una fragmentación que no existe cuando el hardware está controlado.

• El proceso de aprobación de aplicaciones es prácticamente inexistente, lo que permite subir aplicaciones a la tienda en apenas una hora. Sin embargo, esto permite que programadores poco escrupulosos puedan subir aplicaciones que no hacen lo que dicen, con la posibilidad de encontrare con malware o un troyano.

Esta situación, la oposición entre sistemas abiertos y cerrados, no es nueva en absoluto. Un ejemplo equivalente ocurre en el mundo de los videojuegos: ¿qué es mejor, una consola cerrada y propietaria, con un sistema de aprobación de juegos estricto, o un sistema abierto, tipo PC, donde cualquiera puede vender su juego, sea una castaña o algo sublime? Hardware Vamos a ver en detalle algunos de estos puntos. El primero de ellos es el hardware. Se estima que hay más de doce mil dispositivos Android diferentes, entre teléfonos, relojes, tabletas, lectores de ebooks y televisores. Por el contrario, el número de dispositivos iOS no va más allá de una docena. Esto hace que inicialmente sea más sencillo desarrollar para iOS, la variación de funcionalidad es mucho menor. Sistema operativo Hay que tener presente que no somos el usuario tipo. Nosotros, en cuanto sale una versión nueva del sistema operativo, corremos a instalarla. Sin embargo, un usuario “normal” no está al tanto de las novedades, y actualiza el sistema operativo con mucha menos frecuencia. En el caso de iOS, una vez estabilizado el sistema operativo, aproximadamente un noventa y seis por ciento de usuarios lo han instalado en sus dispositivos. Así, pasado cierto tiempo, podemos permitirnos abandonar la versión anterior sin graves repercusiones. Actualmente, tres meses después de la salida de iOS7, ya lo ha instalado un setenta y cinco por ciento de usuarios. Por el contrario, en el caso de Android, la tasa de actualización es mucho menor: aproximadamente un treinta y tres por ciento de los usuarios están usando la versión más reciente del sistema operativo, otro treinta y tres la anterior, y el resto, una versión dos iteraciones por

detrás. Esta fragmentación dificulta la tarea de los programadores, y a su vez, potencia la idea de dificultad y complejidad del entorno Android. Mercados Como comentaba antes, otro reto al que debemos enfrentarnos es desechar la información que no aplica, educando al cliente. Las noticias más espectaculares suelen venir de EE.UU. e - insisto - es un mercado muy diferente del europeo y del español. Pero, lamentablemente, el cliente no suele filtrar esa información y el cliente la malinterpreta. Software Os quiero poner tres ejemplos que muestran la diferencia entre mercados: • Instagram - empresa estadounidense - empleó dieciocho meses en tener disponible una versión

para Android. Lamentablemente, esa es la información que recibe el cliente: han hecho primero una versión iOS y han tardado dieciocho meses en tener la de Android. Sin embargo, pocos se acuerdan de que en las primeras veinticuatro horas, la aplicación tuvo un millón de descargas en Google Play.

• Vine - también estadounidense - empezó también como iOS y seis meses después sacó al mercado la versión Android.

• King - empresa europea - lanzó la primera versión de Candy Crush Saga para Facebook y siete meses después, simultáneamente, lanzó la versión móvil para ambas plataformas.

Primero para Android A pesar todo lo indicado anteriormente, Android tiene una serie de ventajas que le convierten en una primera opción totalmente viable, y que debemos recalcar al cliente, para que pierda el miedo: • El gran número de dispositivos vendidos (diez a siete en el mundo, tres a uno en España) lo

convierten en una plataforma a tener en cuenta. • La curva de aprendizaje es menor, por lo que cuesta menos formar a un programador. • Las herramientas de desarrollo han mejorado enormemente. • La UI ha madurado en los dos últimos años, acortando distancias con iOS en unos aspectos,

superándole en otros. Filosofía (II): principios de diseño Esta madurez de la UI, así como el cuidado por el detalle permite un acercamiento a ambas plataformas. Si echáis un vistazo a las recomendaciones de diseño, veréis que, con distintos nombres, se buscan metas comunes: que yo disfrute usando el dispositivo, que vea sólo la información relevante, pero que se pueda acceder a la totalidad de la misma en caso necesario, que se utilicen atajos consistentes en todas las aplicaciones, que simplifique mi vida, que me ayude a tomar decisiones… Hasta aquí hemos analizado la situación actual: dónde estamos y por qué. Ahora tenemos la pelota en nuestro tejado. ¿Qué podemos hacer para ir cambiando la situación? Voy a hablar de cada uno de los pasos que se suelen dar en un desarrollo. No todos se pueden aplicar a todos los proyectos, pero resulta útil tenerlos en cuenta. UX El primer paso es el diseño del producto digital. Si estamos adaptando una aplicación de iOS, hay que tener presente las diferencias entre ambas plataformas.

• Mantener la simplicidad. Si una operación que en iOS se se hace en dos gestos necesita siete en Android, es que esa operación no es adecuada. En vez de replicarla y complicar innecesariamente la interacción, es mejor sustituirla por otra que sea más sencilla.

• Hay que tener en cuenta las diferencias de navegación y las interacciones. No hay que imitar, sino sustituir. Si una interacción no es habitual en Android, conviene sustituirla por una que lo sea.

Y podemos inclinar la balanza a nuestro favor si aprovechamos las funciones propias del sistema operativo, aunque no estén presentes en la versión original de la aplicación. Por ejemplo, incluir el reconocimiento de voz, que en Android es muy robusto, añadir la posibilidad de compartir información entre otras aplicaciones o crear un widget para la aplicación, funcionalidades que no existen o son muy pobres en iOS. Diseño Si nos limitamos a portar la aplicación sin más, vamos a obtener una especie de monstruo de Frankenstein, que ni es iOS ni es Android. No se trata de trasladar, sino de adaptar la aplicación, y eso implica rehacer los assets, teniendo en cuenta las diferentes densidades de píxeles y los tamaños de pantalla de los dispositivos. Igualmente, hay que modificar el interface gráfico para eliminar algunos botones necesarios en iOS, pero redundantes en Android, como el botón “atrás”. Para lograr esta adaptación, la situación ideal es contar con un diseñador que conozca ambos mundos. Al disponer de una visión global de ambos interfaces, puede aportar las soluciones más adecuadas en cada caso. Y, si se trata de un desarrollo en paralelo, se puede diseñar desde el primer momento buscando una meta común. Acceso a recursos Otro punto a considerar son los botones físicos que hay en cada plataforma. Android nos ofrece un botón “Atrás”, un botón “Menú” y, en algunos dispositivos, un botón “Configuración”. Vamos a utilizarlos, eliminando los elementos redundantes del interface gráfico. Así podremos liberar un valioso hueco en la pantalla, algo imprescindible en dispositivos con pantallas pequeñas. Y, al igual que tenemos en cuenta los diferentes botones, hay que tener en cuenta el resto del hardware. ¿Tiene GPS el dispositivo? ¿Bluetooth? ¿Acelerómetro? ¿Cámara? Un ecosistema tan abierto como el de Android nos obliga a comprobar la existencia de esas funcionalidades y adaptar el comportamiento de nuestra aplicación según existan o no. Por ejemplo, y volviendo al tema de adaptar en vez de trasladar: ¿qué ocurre si el dispositivo donde queremos ejecutar la aplicación no tiene GPS? Si el GPS es imprescindible para el funcionamiento de la aplicación, tendremos que indicarlo así, pero si no lo es, quizás podamos ofrecer al usuario algo en su lugar (un mapa fijo, por ejemplo) que supla esa funcionalidad. Demos al usuario una alternativa viable, no un pegote sin sentido. Desarrollo Reconozco que esta cosa de hablar así en abstracto es muy fácil. Por ejemplo, una situación ideal es desarrollar ambas aplicaciones en paralelo, con un único jefe de proyecto, un diseñador / UX y dos equipos de desarrollo. Así, tanto el jefe de proyecto como el diseñador tienen una visión global del proyecto, lo que permite a los equipos de desarrollo centrarse en su tarea, sin otras distracciones.

Y en cuanto a las herramientas, ya podemos enterrar el Eclipse y lanzarnos de cabeza al Android Studio, eso sí, siempre usando la support library, que hasta que no nos libremos de las versiones más antiguas del sistema operativo tendremos que ir arrastrando. API Este consejo no es tanto orientado al desarrollo Android, sino al desarrollo multiplataforma. Si la aplicación que estáis desarrollando va a correr en diferentes sistemas operativos y, por la lógica de negocio, hay que hacer cálculos complicados, cread un API para realizar las operaciones en el servidor. Es un consejo de sentido común que no se puede aplicar en todos los casos, pero si se alinean los astros y lo podéis usar, adelante. Estamos desarrollando una aplicación de productividad personal llamada Hightrack (http://hightrack.me) En este caso, el cliente tenía claro desde el primer momento que quería aplicación web, aplicación Android y aplicación iOS. Montamos un API para traernos los datos y, al cabo de un tiempo nos dimos cuenta de que en cada versión estábamos haciendo por separado la lógica de negocio. No sólo estábamos repitiendo el mismo trabajo tres veces, sino que aumentaban las posibilidades de cometer un error. Decidimos modificar el API para que los resultados ya estuvieran procesados, y nuestra vida mejoró notablemente: no se repite el trabajo, las pruebas son más fáciles de hacer y, si hay un error, basta con modificarlo en el servidor: las aplicaciones recibirán los datos correctos sin necesidad de subir una nueva versión a la tienda correspondiente. Testing El testing ha sido la bestia negra del proceso de desarrollo de Android. Si tenemos en cuenta el funcionamiento del emulador, el número de dispositivos, la diversidad de hardware, los distintos tamaños de pantalla… es natural delegar las pruebas en el usuario final y esperar a su feedback para hacer las correcciones necesarias. NUNCA se debe hacer algo así. Es un error muy grave sacar una aplicación a medio probar: no vamos a tener una segunda oportunidad y, si algo no funciona, el usuario lo borra y a otra cosa. Además, esta situación contribuye a la imagen que a veces tiene Android como algo desorganizado (el salvaje Oeste al que hice referencia anteriormente). En este caso, el entorno iOS es mucho más robusto: el entorno de desarrollo incluye herramientas para comprobar el consumo de recursos, si se crean procesos zombies, si hay leaks de memoria, y permite hacer test de usuarios automatizados, algo que podemos hacer desde hace poco si utilizamos espresso. Para mejorar esta situación es vital utilizar las nuevas funcionalidades de alfa y beta testing que se han implementado en Google Play, y así hacer un despliegue controlado al cliente, testers o compañeros y probar la aplicación en más dispositivos, pero de manera controlada. Una vez que haya pasado los ciclos de revisión necesarios, podemos abrirla al público. Publicación Ya para terminar, aunque no es parte estricta de la migración de aplicaciones, quería - por completar - comentar la publicación en la tienda. Una vez más, las diferencias de filosofía entre ambas plataformas se hace patente. Por un lado, la aproximación de Apple, controlando lo que se sube, mediante revisión, lo que incluye un retraso considerable a la hora de publicar, pero garantizando que la aplicación funciona

y hace lo que se espera de ella. A nosotros, por ejemplo, tras seis días de espera, nos echaron atrás una aplicación porque nos faltaba un logo en una pantalla. Lo corregimos en cinco minutos y seis días más tarde, la aprobaron: tardamos doce días en total en publicar la aplicación. Por otro lado, la aproximación de Android, sin revisión salvo que haya quejas, permite tener una aplicación disponible para descargar en una hora. Eso sí, puede haber aplicaciones de baja calidad, malas copias o “cosas” que ni siquiera funcionan. Otras alternativas Una posibilidad para abaratar costes es utilizar herramientas que permiten reutilizar código, sin depender de la plataforma. No soy muy partidario de esas herramientas, pero pueden ser una solución adecuada si se cumplen estos tres requisitos: • El proyecto tiene un gran alcance: necesitamos llegar a todos los dispositivos lo antes posible. • El presupuesto es reducido. • Estamos dispuestos a hacer sacrificios de usabilidad y diseño. Conclusiones Si habéis llegado hasta aquí, enhorabuena. Espero que ahora tengáis una visión un poco más clara de por qué estamos en esta situación y como va evolucionando de “iOS first” a “Vamos a desarrollar para ambas plataformas” En nuestras manos está hacer o adaptar aplicaciones de manera que entreguemos un producto brillante, mejor que el original que acabe de inclinar la balanza a nuestro favor y conseguir así que nuestros clientes también se enamoren de un robot. Muchas gracias.