Mejores prácticas para el diseño adaptativo

Las mejores prácticas recomendadas para el diseño adaptativo incluyen:

Al diseñar tu app, intenta dividir widgets grandes y complejos en otros más pequeños y simples.

Refactorizar widgets puede reducir la complejidad de adoptar una UI adaptativa al compartir piezas clave de código. También hay otros beneficios:

• Por el lado del rendimiento, tener muchos Widgets const pequeños mejora los tiempos de reconstrucción (rebuild) en comparación con tener Widgets grandes y complejos.
• Flutter puede reutilizar instancias de Widgets const, mientras que un Widget complejo más grande debe ser configurado en cada reconstrucción.
• Desde la perspectiva de la salud del código, organizar tu UI en piezas más pequeñas ayuda a mantener baja la complejidad de cada Widget. Un Widget menos complejo es más legible, más fácil de refactorizar y menos propenso a comportamientos inesperados.

Para obtener más información, consulta los 3 pasos del diseño adaptativo en Enfoque general.

Más allá del tamaño de la pantalla, también deberías dedicar tiempo a considerar las fortalezas y debilidades únicas de los diferentes formatos (form factors). No siempre es ideal que tu app multiplataforma ofrezca una funcionalidad idéntica en todas partes. Considera si tiene sentido enfocarse en capacidades específicas, o incluso eliminar ciertas funciones, en algunas categorías de dispositivos.

Por ejemplo, los dispositivos móviles son portátiles y tienen cámaras, pero no son ideales para trabajos creativos detallados. Teniendo esto en cuenta, podrías centrarte más en capturar contenido y etiquetarlo con datos de ubicación para una UI móvil, pero enfocarte en organizar o manipular ese contenido para una UI de tablet o escritorio.

Otro ejemplo es aprovechar la barrera de entrada extremadamente baja de la web para compartir. Si estás desplegando una app web, decide qué enlaces profundos (deep links) admitir, y diseña tus rutas de navegación teniéndolos en cuenta.

La conclusión clave aquí es pensar en lo que hace mejor cada plataforma y ver si hay capacidades únicas que puedas aprovechar.

Crear una gran UI táctil a menudo puede ser más difícil que una UI tradicional de escritorio debido, en parte, a la falta de aceleradores de entrada como clic derecho, rueda de desplazamiento o atajos de teclado.

Una forma de abordar este desafío es enfocarte inicialmente en una gran UI orientada al tacto. Aún puedes hacer la mayoría de tus pruebas usando el objetivo de escritorio por su velocidad de iteración. Sin embargo, recuerda cambiar con frecuencia a un dispositivo móvil para verificar que todo se sienta bien.

Después de haber pulido la interfaz táctil, puedes ajustar la densidad visual para usuarios de mouse y luego añadir todas las entradas adicionales. Aborda estas otras entradas como aceleradores: alternativas que hacen que una tarea sea más rápida. Lo importante a considerar es lo que un usuario espera al usar un dispositivo de entrada en particular, y trabajar para reflejarlo en tu app.

Una app adaptativa debería verse bien en ventanas de diferentes tamaños y formas. Aunque bloquear una app en modo retrato en teléfonos puede ayudar a acotar el alcance de un producto mínimo viable, puede incrementar el esfuerzo requerido para hacer que la app sea adaptativa en el futuro.

Por ejemplo, la suposición de que los teléfonos solo renderizarán tu app en modo retrato a pantalla completa no está garantizada. El soporte para apps multiventana es cada vez más común, y los dispositivos plegables tienen muchos casos de uso que funcionan mejor con varias apps ejecutándose lado a lado.

Si de verdad debes bloquear tu app en modo retrato (pero es mejor que no lo hagas), utiliza la API Display en lugar de algo como MediaQuery para obtener las dimensiones físicas de la pantalla.

Para resumir:

• Las pantallas bloqueadas pueden ser un problema de accesibilidad para algunos usuarios
• Los niveles de gran formato de Android requieren soporte para retrato y paisajístico (landscape) al nivel más bajo.
• Los dispositivos Android pueden anular una pantalla bloqueada
• Las guías de Apple indican apuntar a soportar ambas orientaciones

Evita usar el campo de orientación de MediaQuery o OrientationBuilder cerca de la parte superior de tu árbol de widgets para cambiar entre diferentes diseños de app. Esto es similar a la recomendación de no verificar tipos de dispositivo para determinar el tamaño de la pantalla. La orientación del dispositivo tampoco te informa necesariamente sobre cuánto espacio tiene la ventana de tu app.

En su lugar, utiliza sizeOf de MediaQuery o LayoutBuilder, como se discute en la página de Enfoque general. Luego utiliza puntos de interrupción (breakpoints) adaptativos como los que recomienda Material.

Las apps que usan todo el ancho de la ventana para mostrar cajas o campos de texto no funcionan bien cuando se ejecutan en pantallas grandes.

Para aprender cómo evitar esto, consulta Diseño con GridView.

Evita escribir código que verifique si el dispositivo en el que te estás ejecutando es un "teléfono" o una "tablet", o cualquier otro tipo de dispositivo al tomar decisiones de diseño (layout).

El espacio que realmente se le da a tu app para renderizar no siempre está ligado al tamaño de pantalla completa del dispositivo. Flutter puede ejecutarse en muchas plataformas diferentes, y tu app podría estar ejecutándose en una ventana redimensionable en ChromeOS, lado a lado con otra app en tablets en modo multiventana, o incluso en imagen en imagen (picture-in-picture) en teléfonos. Por lo tanto, el tipo de dispositivo y el tamaño de la ventana de la app no están realmente conectados fuertemente.

En su lugar, utiliza MediaQuery para obtener el tamaño de la ventana en la que tu app se está ejecutando actualmente.

Esto no solo es útil para el código de UI. Para aprender cómo abstraer las capacidades del dispositivo puede ayudar al código de tu lógica de negocio, consulta la charla del Google I/O 2022, Flutter lessons for federated plugin development.

Las apps deben admitir ratones básicos, trackpads y atajos de teclado. Los flujos de usuario más comunes deben admitir la navegación por teclado para garantizar la accesibilidad. En particular, tu app debe seguir las mejores prácticas de accesibilidad para teclados en dispositivos grandes.

La librería Material proporciona Widgets con un excelente comportamiento predeterminado para la interacción táctil, de mouse y de teclado.

Para aprender cómo agregar este soporte a Widgets personalizados, consulta Entrada de usuario y accesibilidad.

Para mantener la posición de desplazamiento en una lista que no cambia su diseño cuando la orientación del dispositivo cambia, utiliza la clase PageStorageKey. PageStorageKey persiste el estado del Widget en almacenamiento después de que el Widget es destruido y restaura el estado cuando se recrea.

Puedes ver un ejemplo de esto en la app Wonderous, donde almacena el estado de la lista en el Widget SingleChildScrollView.

Si el Widget List cambia su diseño (layout) cuando cambia la orientación del dispositivo, es posible que tengas que hacer un poco de cálculo (ejemplo) para cambiar la posición de desplazamiento al rotar la pantalla.

Las apps deben conservar o restaurar el State de la app a medida que el dispositivo rota, cambia el tamaño de la ventana o se pliega y despliega. De forma predeterminada, una app debería mantener el State.

Si tu app pierde el State durante la configuración del dispositivo, verifica que los plugins y extensiones nativas que utiliza tu app admitan el tipo de dispositivo, como una pantalla grande. Algunas extensiones nativas pueden perder el State cuando el dispositivo cambia de posición.

Para obtener más información sobre un caso del mundo real donde ocurrió esto, consulta Problem: Folding/unfolding causes state loss en Developing Flutter apps for Large screens, un artículo gratuito en Medium.