Las 3 principales lecciones aprendidas en el desarrollo de Android

Este mes hemos entrevistado a Diego Ojeda – Android Lead en @Apiumhub y aquí comparte sus recomendaciones, tendencias en desarrollo de Android y las 3 principales lecciones aprendidas. 

1.¿Cómo empezar a utilizar el SDK de Android?

El SDK (Software Development Kit – Kit de Desarrollo de Software) es un conjunto de herramientas desarrollado y distribuido por Google para que los programadores puedan desarrollar aplicaciones que se ejecuten en Android, el sistema operativo móvil más popular a día de hoy.

Dentro de este SDK encontramos herramientas que nos permiten interactuar con nuestro dispositivo (instalando aplicaciones desde el ordenador), descompilar un fichero .apk para ver su interior, debuggar nuestras aplicaciones…
Aparte de estas herramientas, este SDK contiene las librerías necesarias para poder interactuar con el sistema operativo Android a través de código; esto es, desarrollar nuestras propias aplicaciones.
La forma más sencilla de utilizar este SDK es descargarse la herramienta oficial para desarrollar aplicaciones para Android: Android Studio. Este es un IDE que, desde el momento que lo arrancamos, nos permite empezar a programar nuestras propias aplicaciones y ejecutarlas tanto en nuestro dispositivo como en un emulador. Además, Google proporciona cursos gratuitos para iniciarse en el mundo del desarrollo de apps desde su plataforma de Code Labs.

2. ¿Qué es Google Play Instant e Instant Apps?

¿Alguien se acuerda de las Demos de los juegos allá por los años 2000? Esos pequeños fragmentos de un juego que te permitían jugar uno o dos niveles antes de pedirte que compraras el juego completo. Pues las Instant Apps son su equivalente moderno. En lugar de instalar en tu dispositivo una aplicación con su funcionalidad completa, puedes acceder a una pequeña parte de ella para probarla, o hacer una operación concreta sin tener que instalar nada en tu dispositivo.

El mejor ejemplo de estas instant apps son los juegos. ¿Quieres probar un juego sin tener que instalarlo en tu dispositivo y descargar los cientos de MegaBytes que este ocupa? Con instant apps puedes hacerlo.
Sin embargo, como todo en el mundo de la informática, las instant apps también tienen sus pegas. Por ejemplo, no se pueden recibir push notifications, se sobrecarga la RAM y sólo funcionan en dispositivos de Android 6.0 en adelante.
Aun así, las instant apps son un gran avance en el mundo del desarrollo de aplicaciones móviles, ya que permiten a los desarrolladores ampliar su base de usuarios enormemente al poder estos probar sus aplicaciones antes de descargarlas.

ARTÍCULO RELACIONADO: ¿Cómo elegir una empresa de desarrollo de software a medida?

3. ¿Por qué elegir Flutter para aplicaciones multiplataforma?

Se podría decir que, desde que nacieron las plataformas mobile más populares (Android y iOS) se ha intentado buscar una forma de unificarlas; es decir, se ha intentado que, a partir de una única base de código, obtengamos una aplicación que funcione en Android y otra que funcione en iOS.

Hace ya más de 10 años de esto, y, a lo largo de este tiempo, estas tecnologías han ido evolucionando y mejorando. Una de las más populares en los últimos tiempos es Flutter, la apuesta de Google por las aplicaciones cross-platform. Flutter es un framework para desarrollar aplicaciones móviles usando Dart como lenguaje de programación. Es una apuesta muy innovadora por parte de Google ya que es el primer framework de estas características que permite declarar interfaces de usuario de forma declarativa.

Aun así, la principal diferencia con sus competidores, y lo que ha hecho que se vuelva tan popular, es que el código de nuestra aplicación Flutter se compila a código nativo para cada plataforma, lo que permite usar todas y cada una de las funcionalidades disponibles en ellas (por ejemplo el acceso a la cámara no se hace a través de plugins como en otros frameworks similares).

Flutter también ha conseguido que, a partir de una sola base de código, se consiga un aspecto nativo en Android y iOS, haciendo que sus componentes se transformen a los propios de cada plataforma, lo que desemboca en una mejor experiencia de usuario y un menor esfuerzo por parte de los desarrolladores para adaptar sus aplicaciones a cada una de estas plataformas.

4. Las 3 principales lecciones aprendidas en el desarrollo de Android

A lo largo de nuestros años de experiencia desarrollando aplicaciones Android, hemos aprendido mucho y nos hemos encontrado con errores que son recurrentes en el desarrollo de aplicaciones móviles. Estos son algunos ejemplos de nuestros aprendizajes:

• El cambio de paradigma con la introducción de ConstraintLayout:
  Hasta la llegada de este tipo de layout, las vistas se construían anidando LinearLayout dentro de LinearLayout, con algún RelativeLayout o FrameLayout entre ellos. Esto hacía que la construcción de vistas por parte del sistema operativo fuera realmente costosa, así como el mantenimiento del código por parte de los desarrolladores, ya que los ficheros .xml con estas vistas eran gigantescos. ConstraintLayout cambió esto, ya que permite tener una jerarquía de vistas plana, donde el posicionamiento de las mismas se especifica en función de otras vistas y su padre, lo que solventa gran parte de los problemas antes mencionados.
  
• El mal uso de las corrutinas de Kotlin:
  Unos meses después de que se anunciara Kotlin como el lenguaje oficialmente recomendado por Google para el desarrollo de aplicaciones Android, se lanzaron las corrutinas. Las corrutinas son una herramienta que nos ayuda a solventar el problema de trabajar con código asíncrono de forma secuencial y no bloqueante en nuestra aplicación. En nuestra experiencia nos hemos encontrado que la implementación de estas corrutinas en las aplicaciones Android no se hace correctamente, ya que no se entiende correctamente el concepto de scope o las implicaciones que tiene lanzar una corrutina sin asociarla al ciclo de vida de un Activity.
  
• El mal uso de los ViewModels:
  Hace ya algún tiempo, Google lanzó sus librerías de Architecture Components, dentro de las cuales se encontraba el ViewModel; una aproximación de Google para solventar el problema de la recreación de Activities/Fragments al cambiar, por ejemplo, entre los modos landscape y portrait en nuestra aplicación. Estos Viewmodels son componentes que son agnósticos al ciclo de vida de la aplicación, y es por esto que sobreviven a estos cambios de orientación. A lo largo de nuestra experiencia nos hemos encontrado con muchos casos en los que hay referencias a vistas dentro del viewModel, o acciones dependientes del ciclo de vida del Activity al que están ligados, lo que va en contra de la razón de la existencia de estos ViewModels.