Como desarrolladores, a veces tendemos a establecernos en nuestros caminos. El móvil es probablemente uno de los paisajes más cambiantes de la informática, así que desde una perspectiva técnica, se puede perdonar que uno se aferre a las viejas y fiables formas de resolver los mismos problemas en lugar de subirse al carro de cada nueva biblioteca, arquitectura o experimento glorificado.
Sin embargo, aunque los usuarios no tienen forma de saber lo anticuadas que son algunas de las soluciones bajo el capó, lo que deberían (y hacen) es notar lo moderno que es el aspecto general del software, y si nuestra aplicación funciona bien o no con el sistema en el que se está ejecutando. Permitan que despotriquemos un poco sobre algunas características de Android que, en nuestra opinión, siguen siendo vergonzosamente infrautilizadas o no utilizadas correctamente por nosotros, los desarrolladores de aplicaciones. Adoptar las nuevas tendencias de UX es un paso crucial en la evolución de la plataforma, y deberíamos intentar colectivamente hacerlo mejor para poder ofrecer una experiencia fresca y más consistente a nuestros usuarios en 2020.
UI escalable
Con más de una década de experiencia en el soporte de pantallas con cualquier relación de aspecto imaginable, la multi-ventana de forma libre no debería ser nada nuevo para Android. Aún así, la mayoría de las aplicaciones no lo manejan adecuadamente.
Hoy en día tenemos Chromebooks que ejecutan aplicaciones para Android en ventanas redimensionables. Samsung DEX hace lo mismo (más específicamente, One UI tiene la característica de «vista emergente» que ni siquiera requiere un monitor externo). Incluso el editor de diseño de Android Studio nos permite arrastrar la esquina de la ventana de previsualización y verificar cómo se vería el diseño para cualquier posible relación de aspecto. Con todo, el tiempo de android:screenOrientation=»retrato» y android:resizableActivity=»false» se ha acabado, ya que atar las manos de los usuarios es simplemente perezoso. Lo que necesitamos son UI-s que puedan adaptarse rápidamente y con gracia a cualquier tamaño en cualquier momento dado sin perder el estado.
Muchas de las bibliotecas de Jetpack hacen esta tarea más fácil de lo que parece. Mantener la capa de datos completamente separada de la vista es por lejos la forma más simple de hacerlo, y ViewModel fue creado específicamente para este propósito. Poner un poco más de atención en el manejo cuidadoso de los eventos del ciclo de vida también puede arreglar los problemas potenciales. Otra cosa que puede romper la restauración del estado es un retroceso de fragmentos incorrectos, algo que el componente de navegación puede abstraer.
Al implementar la interfaz de usuario real, ConstraintLayout debería ser nuestro mejor amigo, junto con los calificadores de recursos para los casos más extremos. En las pantallas que muestran listas, un GridLayoutManager con un recuento dinámico de la extensión podría ser otra herramienta útil.
Considerando todo esto, apoyar la multi-ventana de forma libre es más un desafío para el equipo de diseño que para nosotros, ya que una arquitectura bien pensada tiene el efecto secundario de guardar y restaurar adecuadamente el estado de la pantalla después de los cambios de configuración.
Manipulación de las ventanas
Las muescas en la pantalla y las cámaras de perforaciones que ocupan valiosas regiones de la pantalla es un problema más reciente que, de hecho, no pedimos… Pero, de nuevo, optar por no participar se siente como huir del problema y somos mejores que eso! Las recientes API nos permiten dibujar cualquier contenido bajo las barras del sistema mientras que rellenamos las partes importantes de información dependiendo de las inserciones de la pantalla con un trabajo sorprendentemente pequeño.
La librería Insetter de Chris Banes encapsula la complejidad de sobreescribir el método dispatchApplyWindowInsets() de un ViewGroup raíz personalizado o escribir nuestro propio OnApplyWindowInsetsListener. No debemos olvidar que, como no queremos bloquear la aplicación en orientación vertical, no sólo tenemos que ocuparnos de los insets superiores e inferiores de la ventana, sino de los cuatro.
Consideremos también la posibilidad de configurar el atributo android:windowLayoutInDisplayCutoutMode del tema de la aplicación a shortEdges: esto hará que la interfaz de usuario se extienda bajo el recorte de pantalla en modo apaisado también (al contrario del comportamiento por defecto que sólo lo hace en vertical y vuelve al buzón en modo apaisado).
El resultado del mínimo esfuerzo de hacer esto bien será una aplicación de inmersión que aprovecha al máximo todo el espacio disponible en la pantalla en lugar de estar rodeada de feas barras negras.
Soporte para el modo oscuro
Si tu preciosa marca sólo funciona sobre un fondo blanco cegador, es difícil abrir tu aplicación después del atardecer. A medida que más y más diseños abrazan el lado oscuro de Material, los que se niegan a hacerlo sobresalen como un pulgar dolorido. Lo mismo puede decirse a la inversa: algunos usuarios prefieren el tema del día (que a pesar de todo el reciente oscurecimiento podría ser más cómodo de mirar, especialmente con luz solar directa). La solución es clara: los usuarios quieren opciones, por lo que también podríamos apoyar ambas preferencias de temas desde una etapa temprana de desarrollo.
Más vale tarde que nunca: el modo nocturno ya no está oculto en las opciones de desarrollo. Ahora cualquiera puede cambiar su preferencia entre los temas claros y oscuros en cualquier momento, pero los resultados no son, por desgracia, los que cabría esperar (incluso en el caso de las aplicaciones de Google). iOS está muy por delante: un cambio maestro afecta a cada una de las aplicaciones, mientras que en nuestro caso las implementaciones individuales son muy inconsistentes.
Hemos caído en la misma trampa que cuando escribimos código que hackea la configuración del lenguaje a nivel de sistema del usuario: cada aplicación parece haber empezado a usar sus propios selectores de temas personalizados. Si esto es o no un problema es discutible, pero al menos acordemos añadir una opción por defecto para seguir la preferencia del sistema global.
La implementación real del soporte de temas duales no es, una vez más, muy difícil de hacer para un proyecto totalmente nuevo, pero podría ser un esfuerzo bastante grande para uno heredado. Los calificadores de recursos nocturnos y no nocturnos son probablemente los mejores lugares para empezar, mientras que el uso de atributos personalizados en lugar de referencias directas de color es también algo a tener en cuenta.
Splash screen
Una splash screen no es un concepto nuevo en absoluto, pero al ser lo primero que los usuarios ven en nuestras aplicaciones, no implementarlas correctamente es dolorosamente obvio.
Puede que tengas una hermosa animación de introducción de 5 segundos que te gustaría poner en la cara de los usuarios cada vez que inicien tu aplicación. O puede que necesites descargar algunos datos antes de poder mostrar algo significativo. Si alguna vez has añadido una pantalla con el único propósito de bloquear al usuario para que no llegue a la pantalla principal lo más rápido posible, debemos decirte que hay mejores formas de tratar estos problemas.
Las aplicaciones para Android tardan un tiempo en cargarse antes de que se llame al método onCreate() de la primera Activity. Durante este tiempo la ventana del tema de la aplicación, windowBackground, se dibuja en la pantalla. La mejor pantalla de bienvenida es simplemente un fondo personalizado dibujable (probablemente una lista de capas) para el tema, que se anula en el momento en que se crea la primera Activity (llamando a setTheme() antes de super.onCreate()).
Reflexiones finales
Aunque hay muchos otros aspectos de una aplicación moderna y exitosa, creemos que los cuatro anteriores probablemente se aplican a cualquier tipo de proyecto Android (incluso a los juegos – ¡cambia de opinión!). Uno puede pensar en ellos como requisitos básicos para integrar perfectamente la experiencia que su aplicación proporciona en el aspecto general de Android.
Aunque la implementación de algunas de estas cosas requiere un esfuerzo adicional de planificación y diseño, nos gustaría argumentar que no es algo en lo que debamos ser conservadores. El resultado de crear aplicaciones que se sientan como una parte natural del sistema operativo será un ecosistema más maduro, algo por lo que todos deberíamos trabajar.
