Prev

Next

Leap, Processing, ReasonLeap, Processing, Reason Recientemente nos ha llegado nuestro Leap motion, un controlador financiado por crowdfunding que es capaz de reconocer la posición y velocidad de las manos y los dedos, así como una serie de gestos. Para integrarlo en nuestros desarrollos se han desarrollado librerías, plugins y wrappers para gran cantidad de lenguajes...

Read more

ABCKit for 5ABCKit for 5 Hace pocos meses, el equipo de Arquinauta nos encargó el desarrollo de la aplicación "ABCKit for 5". No vamos a hablar de lo útil que resulta para que los niños de entre tres y seis años aprendan a identificar las letras, deletrear palabras y practicar el trazo mediante cuatro actividades de diferente complejidad,...

Read more

Creando webs para China: Talents UnitedCreando webs para China: Talents United Durante el verano de 2012 lanzamos Talents United, una web que permite a los artistas de todas las áreas dar a conocer sus obras y proyectos. Unos meses después nos surgió un desafio: internacionalizar Talents para China. Nuestro contacto en Shanghai nos explicó que el proyecto tenía muchas posibilidades de prosperar,...

Read more

El CosmonautaEl Cosmonauta Hace unos años Javier Cañada nos presentó a los dueños de una productora de cine, Riot Cinema. Eran tres socios, de una juventud insultante. Bruno, Carola y Nico fueron los responsables de llevar a cabo el spot de PosterDigital. Pusieron un pueblo entero patas arriba durante todo un fin de semana, pero el resultado...

Read more

Los premios de nuestros clientes son nuestros premiosLos premios de nuestros clientes son nuestros premios Nuestro cliente Fintonic ha recibido uno de los galardones más importantes en el mundo online europeo, el Lovie Award de oro a las mejores prácticas. Por contextualizar, Fintonic supone la consecución de un trabajo que muchos otros han intentado hacer antes, pero que nadie había logrado lanzar de forma exitosa: Un...

Read more

Web Components. La siguiente revolución tecnológica

Category : Web

Cuando ya parecía que nos habíamos acostumbrado al nuevo paradigma de aplicaciones web basado en JS pesado y frameworks MVC en cliente, resulta que aparece una nueva (realmente no tan nueva) forma de hacer las cosas: Web Components.

¿Qué son los Web Components?

Web Components are a collection of standards which are working their way through the W3C. Discover how this new concept formed by Templates, Decorators, Shadow DOM, Custom Elements, and HTML Imports will revolutionize the way we develop and interact on the web.

Zeno Rocha - vía WebComponents.org

El principio es muy sencillo: todo es un componente, y como tal puede invocarse declarativamente. La idea principal es que la complejidad ya no la tiene la programación de la aplicación sino cada uno de los componentes que la forman, no tenemos ni M, ni V, ni C sino unos componentes que, como por ejemplo la etiqueta <input>, saben lo que hacer en cada momento. En este aspecto estamos más cerca del paradigma de Custom Tags de Java que de los includes de PHP.

A la sombra del borrador de Web Componentes del W3C han ido apareciendo nuevos frameworks y librerías que utilizan este paradigma como base. Aparecen nuevos conceptos como Shadow DOM o Virtual DOM y debemos aprender a vivir con ellos dado que suponen cambios muy significativos en la forma en que se harán las cosas.

Y es que Javascript sigue buscando su estilo. Recordemos que aunque es una lenguaje con cierta solera no es hasta hace unos años cuando se ha empezado a usar intensivamente. La mejora y estandarización de los navegadores y la aparición de nodejs  ha dado un salto cualitativo en la forma de hacer las cosas y es ahora cuando estamos viviendo esta revolución.

Estos son los principales frameworks/librerías que han surgido (¡y estamos empezando!) a raíz de esta nueva vuelta de tuerca al desarrollo de aplicaciones web pesadas:

1. Polymer: Es un polyfill de Google que implementa la especificación de Web Components. Ya dispone de una amplia comunidad y gran cantidad de elementos disponibles.

2. X-tag: Es el proyecto de Mozilla para Web Components. Al estar basado en la especificación del polyfill de Polymer, si bien no está directamente asociado al proyecto,  es posible usar elementos de X-tag dentro de elementos Polymer.

3. React: Bajo el soporte de Facebook, React propone una forma un tanto diferente de construir componentes completamente encapsulados (y en algún caso con cierto engorro en su desarrollo). Pero los resultados son realmente asombrosos. La forma en la que se invocan los componentes no es exactamente declarativa pero recuerda mucho. Aunque esto se aleja de la especificación de W3C de Web Components me parece interesante ponerlo aquí. Incluso podemos hacer que convivan como ha hecho Vjeux en un experimento.

Sin duda estas nuevas tecnologías de desarrollo están aquí para quedarse, no creo que sustituyan a la vieja y buena manera de hacer las cosas (MVC) pero ciertamente van a  suponer una nueva nueva revolución y darán que hablar.

Por otra parte y haciendo un poco de abuelo Cebolleta, recuerdo que hace más de 7 años en la empresa donde trabajaba ya teníamos un catálogo de componentes Javascript completamente encapsulados que sabían qué hacer en cada momento y que se invocaban de forma declarativa. Posteriormente se utilizó Rhino para poder ejecutar este Javascript en servidor…. y bueno, yo estoy volviendo a vivir todo esto, pero eso sí, con una comunidad mucho más amplia y una nueva manera de hacer (bien) las cosas.

La empatía

Category : Nosotros, Web

En este preciso instante, en alguna parte del mundo, estoy segura de que alguien está escribiendo su currículo y poniendo en la sección “Habilidades”: “facilidad para trabajar en equipo”. Todos lo hemos hecho. En el papel, supuestamente, todos estamos preparadísimos para trabajar en coordinación con otros, pero… ¿hasta qué punto es verdad?

Hace unas semanas en el 04×10, que se celebra todos los meses en Madrid, di una charla sobre los problemas de comunicación que a veces existen entre diseñadores y desarrolladores. Problemas que también darían para otra charla a la inversa: ¿hasta qué punto los desarrolladores van a favor de obra? ¿Hasta qué punto ven que las ideas de los diseñadores no son peregrinas y que, generalmente, cada cambio tiene una razón…?

A final de cuentas, un factor que hará que nuestros proyectos salgan adelante con mayor o menor éxito es la capacidad de empatía que tengamos. Suena hippie, lo sé, pero está claro que en desarrollo web cuánto más conscientes seamos de las necesidades de la persona que va a recibir lo que hemos diseñado, más fácil será su trabajo. Si somos capaces de ponernos en el lugar del otro (y viceversa), desarrollar productos sólidos y eficientes será bastante más fácil. Trabajo en equipo de verdad.

Lo mejor de esta idea es que parece que se está poniendo de moda. Hace poco menos de una semana ha surgido Lifetramp una red social que permite a sus usuarios ser la sombra de un diseñador, un desarrollador, un artesano o lo que busques durante un día. De esta manera, cualquier persona será capaz de realmente vivir cómo es el trabajo de otras personas y decidir si quiere trabajar de eso, aprender ese oficio o simplemente saciar su curiosidad.

Cada vez se impone más la idea de que, por más que juegues de 9, para meter goles no está mal saber cómo piensa un portero. Y viceversa.

El penoso estado digital de la Administración

8

Category : Web

j'accuse

Estos días, tras tener que hacer una serie de trámites online, he estado pensando en cómo está la presencia online de la Administración y, sinceramente, es para echarse a llorar.

Tenemos, por ejemplo, al registrador de .es enviando contraseñas en texto plano. Esto demuestra por una parte que están guardando las contraseñas de los usuarios en base de datos, no un hash. A estas alturas, en 2014. Lo cual, a su vez, evidencia una total falta de respeto por las normas más básicas de seguridad y buenas prácticas por parte de, ni más ni menos, el responsable de que cuando pones algo terminado en .es en tu navegador te lleve a donde quieres ir y no a cualquier otro sitio:

textoplano

Claro que hay cosas más divertidas. A lo mejor no eres usuario de Windows, puede que seas un loco usuario de otros sistemas operativos “experimentales” como, no sé, MacOS X, iOS, Ubuntu… Pues bien, las webs de los organismos oficiales en España (dominios.es, o también madrid.org o la del Ministerio de Hacienda utilizan el certificado raíz de la FNMT y este organismo no se ha molestado en asegurarse de pasar el proceso de auditoría de navegadores como Chrome en estos sistemas operativos. No pasa nada, porque los usuarios de  sistemas operativos distintos a Windows ya sabemos que somos ciudadanos de segunda, gracias a la proverbial tozudez de nuestra Administración de no seguir un estándar ni aunque los estén ahogando, así que podemos ir a bajarnos el certificado raíz de la FNMT a su web e instalarlo en nuestro sistema operativo. El problema es que la web desde la que podemos bajar estos certificados está firmada, a su vez con el propio certificado raíz que queremos bajar (o sea, está autofirmada), cosa que puede hacer cualquiera, montando un ataque man-in-the-middle. Dicho de otra forma, no podemos bajarnos el certificado de la FNMT sin comprometer la seguridad de nuestro ordenador. Estupendo todo.

Certificado FNMT

Por cierto, para acceder a la página de descarga del certificado, he preferido buscar en google que navegar por la web de la FNTM, porque la navegación en las webs de la Administración es tan mala que llegar al contenido que buscas parece más cuestión de suerte.

Por terminar por hoy, supongamos que eres un ciudadano de primera, con tu Windows actualizado y fiel usuario de Internet Explorer, en el que tienes instalados tus certificados, y decides montar tu negocio online. Vas a dominios.es y registras un nombre estupendo, no sé, prosa.es. Luego te pasas un par de años montando tu tienda de ebooks. Contratas a una buena empresa de desarrollo, gestionas una comunidad, te gastas un buen dinero en SEO y SEM… Cuando el negocio empieza a ir bien, tras muchos días de trabajar hasta las tantas, el Gobierno, en su infinita sabiduría, decide fundar el Patronato Regional de Ondas Sacras de Andalucía, declara que prosa.es es de interés general y te lo quitan. De un día para otro. Esto fue lo que le pasó a la empresa textil que era la registradora de sareb.es cuando se puso en marcha el banco malo. Y sí, es legal y nueva muestra de la falta de previsión y ceguera de la Administración hacia los más elementales estándares de funcionamiento, conducta y buenas prácticas en Internet.

Dan ganas de irse a vivir a Estonia.

Me enamoré de un robot

Category : Movilidad

Este artículo es una adaptación de la charla “Me enamoré de un robot – Migración de aplicaciones iOS a Android” dada en DroidCon Spain el 10 de diciembre de 2013.

Me enamoré de un robot
Este artículo no pretende ser técnico. No tratará de frameworks, metodologías, librerías, stacks, fragmentos sino de la evolución del mercado de aplicaciones móviles.

A lo largo del último año, en Tecnilógica hemos visto cambiar el mercado de las apps. Los clientes demandan cada vez más aplicaciones Android que quieren desarrollar a la vez o en vez de la correspondiente aplicación iOS. Queremos mostrar diferentes argumentos que nos ayudarán a animar a nuestros clientes a potenciar esta tendencia, desarrollando primero la aplicación Android o, al menos, poder desarrollar las diferentes versiones simultáneamente.

No pretendemos avivar el fuego entre ambas plataformas. Tanto iOS como Android tienen unos aspectos que las hacen muy atractivas, así como en otros campos se quedan un poco cojas y hay espacio 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, que trataremos más adelante, 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
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 frecuentemente nos dan una imagen de la realidad sesgada o incompleta. ¿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. Son unas cifras lo suficientemente importantes para presentarlas al cliente y aportarle una visión más amplia de la situación.

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. Nos referimos 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:

  • Android, al ser un sistema operativo abierto, permite su distribución a las operadoras de telefonía. Así, los usuarios no tendrán que esperar por sobrecarga de los servidores cuando aparece una versión nueva del sistema operativo. 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, independientemente de su calidad?

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
Entre los círculos técnicos, en cuanto sale una versión nueva del sistema operativo, corremos a instalarla. Sin embargo, un usuario estándar 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, cuatro meses después de la salida de iOS7, ya lo ha instalado un ochenta 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 comentábamos antes, otro reto al que debemos enfrentarnos es desechar la información no pertinente, educando al cliente. Las noticias más espectaculares suelen venir de EE.UU., un mercado muy diferente del europeo y del español. Pero, lamentablemente, el cliente no suele filtrar esa información, por lo que tiende a malinterpretarla.

Software
Estos tres ejemplos 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 saben 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 con una base de usuario muy amplia.
  • 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 leemos las recomendaciones de diseño, nos daremos cuenta de que, con distintos nombres, se buscan metas comunes: que el usuario 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 nuestra vida, que ayude a tomar decisiones…

Migración o adaptación
Hasta aquí hemos analizado la situación actual: dónde estamos y por qué. ¿Qué podemos hacer para ir cambiando la situación? Vamos a ver los pasos más habituales que se suelen dar en un desarrollo y cómo se pueden adaptar para conseguir una aplicación de tanta o más calidad que la aplicación iOS.

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.

  • 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, en vez de un pastiche sin sentido.

Desarrollo
Esta cosa de hablar así en abstracto es muy fácil, como si contáramos con recursos ilimitados. 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, afortunadamente ya se puede prescindir del Eclipse, usando en su lugar el Android Studio, eso sí, siempre usando la Support Library, para mantener la compatibilidad con versiones más antiguas del sistema operativo.

API
Este consejo no es tanto orientado al desarrollo Android, sino al desarrollo multiplataforma. Si la aplicación que desarrollamos va a correr en diferentes sistemas operativos y la lógica de negocio implica cálculos complicados, una buena solución es crear 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 en caso de que se pueda usar nos ahorrará bastantes quebraderos de cabeza.

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 que comentamos 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, queremos – 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 rechazaron una aplicación porque faltaba un logo en una pantalla. Lo corregimos en cinco minutos y seis días más tarde, la aprobaron: en total tardamos doce días 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. 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.

Ejemplo: Hightrack
ht_ios_android El caso de Hightrack forma parte de la tendencia que hemos comentado. El cliente tenía claro desde el primer momento que quería una versión para ambas plataformas. Con un dispositivo de cada clase, pasó un tiempo manejando todo tipo de aplicaciones, hasta familiarizarse con el diseño, interacciones y propiedades de cada sistema. A partir de ahi, diseñó el interfaz adaptándolo a cada plataforma, respetando los diferentes tipos de navegación, animaciones, tipografía, para dotar a la aplicación de personalidad propia y evitar que parezca una adaptación apresurada.

Conclusiones
En resumen: tenemos en nuestras manos la posibilidad de hacer o adaptar aplicaciones de manera que entreguemos un producto brillante, mejor que el original. También contamos con la información necesaria para conseguir que el cliente evolucione de “iOS first” a “Android first” Consigamos que nuestros clientes también se enamoren de un robot.