Ejercicios y práctica · Desarrollo de Interfaces · DAM

Qué deberías ser capaz de hacer

Errores frecuentes que la práctica debería detectar

• Uso exclusivo de posicionamiento absoluto: Causa una interfaz rígida que no se adapta a diferentes resoluciones o tamaños de ventana. Corrección: Priorizar el uso de gestores de diseño para crear interfaces responsivas y flexibles.
• Ignorar las guías de alineación: Lleva a interfaces visualmente desordenadas y asimétricas. Corrección: Prestar atención a las guías visuales del editor para asegurar una alineación consistente entre los componentes.
• No asignar nombres significativos a los componentes: Causa dificultad para identificar y referenciar componentes en el código. Corrección: Utilizar convenciones de nomenclatura claras (ej. `btnGuardar`, `txtNombreUsuario`).
• Modificar propiedades visuales en lugar de usar estilos/temas: Lleva a inconsistencias visuales y dificultad para mantener la interfaz. Corrección: Para cambios de estilo globales, considerar el uso de hojas de estilo (CSS en JavaFX/Web, XAML styles en WPF) o temas, y usar las propiedades individuales para ajustes específicos.
• Modificar directamente el código dentro de las secciones protegidas del editor: Causa que los cambios sean sobrescritos por el editor al guardar o regenerar el formulario. Corrección: Añadir código personalizado en métodos separados o fuera de las secciones marcadas como generadas automáticamente.
• No entender la relación entre el diseño visual y el código: Dificulta la depuración y la extensión de la interfaz. Corrección: Dedicar tiempo a mapear visualmente los componentes con sus declaraciones y configuraciones en el código generado.
• Poner toda la lógica de negocio directamente en los manejadores de eventos: Causa código acoplado, difícil de probar y mantener. Corrección: Delegar la lógica de negocio a clases o servicios separados, manteniendo los manejadores de eventos lo más ligeros posible.
• No manejar excepciones en los manejadores de eventos: Puede provocar que la aplicación se bloquee o muestre errores inesperados al usuario. Corrección: Implementar bloques `try-catch` para manejar errores y proporcionar retroalimentación adecuada al usuario.
• Confundir XML de UI con XML de datos: El XML de UI describe la estructura y apariencia de los componentes visuales, no el contenido de los datos que se mostrarán. Causa: Falta de comprensión del propósito específico del XML en este contexto. Corrección: Entender que los atributos XML definen propiedades visuales y de comportamiento inicial, mientras que los datos se inyectan en tiempo de ejecución.
• No ver las ventajas de XML y preferir código imperativo para UI: Algunos desarrolladores, acostumbrados a construir UI programáticamente, no aprecian la legibilidad y mantenibilidad del XML. Causa: Falta de experiencia con proyectos grandes o equipos multidisciplinares. Corrección: Trabajar en un proyecto donde la UI cambia frecuentemente o donde diseñadores y desarrolladores colaboran estrechamente para experimentar los beneficios.
• Creer que XML es una solución mágica para todo: Aunque potente, XML tiene sus limitaciones, especialmente para interfaces muy dinámicas o con animaciones complejas que a menudo requieren código. Causa: Expectativas poco realistas. Corrección: Reconocer que XML es excelente para la estructura estática y propiedades iniciales, pero la interactividad y dinamismo se gestionan con código.
• No entender la jerarquía de layouts: Colocar componentes sin un layout contenedor adecuado o anidar layouts de forma ineficiente. Causa: Falta de comprensión de cómo los layouts gestionan la posición y el tamaño de sus hijos. Corrección: Practicar con diferentes tipos de layouts (lineal, relativo, de restricción) y observar cómo afectan la disposición de los componentes.
• Ignorar los namespaces XML: No entender por qué existen `xmlns:android` o `xmlns:app`. Causa: Considerar los namespaces como 'ruido' en el XML. Corrección: Reconocer que los namespaces evitan colisiones de nombres y permiten usar atributos específicos de una plataforma o librería.
• Modificar el XML sin entender el impacto visual: Realizar cambios en el XML 'a ciegas' sin verificar el resultado en el editor gráfico o en la aplicación. Causa: Falta de conexión entre el código y la representación visual. Corrección: Siempre usar la vista previa del editor gráfico o ejecutar la aplicación para validar los cambios en el XML.
• Errores de sintaxis XML al editar manualmente: Un XML mal formado (etiquetas no cerradas, atributos mal escritos) impedirá que el layout se cargue. Causa: Falta de atención al detalle o desconocimiento de la sintaxis XML. Corrección: Utilizar las herramientas de validación XML del IDE y revisar cuidadosamente la estructura.
• IDs duplicados: Asignar el mismo ID a múltiples componentes en el mismo layout. Causa: El sistema no sabrá a qué componente se refiere el código. Corrección: Asegurarse de que cada `android:id` sea único dentro de su contexto de layout.
• No entender la diferencia entre `android:onClick` y `setOnClickListener`: `android:onClick` es un atajo conveniente para eventos simples, pero `setOnClickListener` ofrece más flexibilidad y es el método estándar para manejar eventos complejos o múltiples listeners. Causa: Desconocimiento de las implicaciones de cada enfoque. Corrección: Usar `setOnClickListener` para la mayoría de los casos y `android:onClick` solo cuando la lógica es trivial y no requiere acceso a otros elementos del listener.
• NullPointerException al intentar acceder a un componente: Ocurre cuando `findViewById` devuelve `null` porque el ID no existe en el layout cargado o el layout no se ha cargado correctamente. Causa: ID incorrecto, layout no inflado, o intentar acceder a un componente de un layout diferente. Corrección: Verificar el ID en el XML y asegurarse de que `setContentView` o `inflate` se hayan llamado antes de `findViewById`.