Programación Android y Java
Navigation Drawer es un elemento de interfaz definido por Material Design consistente en el típico menú lateral deslizante, generalmente desde la izquierda. Suele encontrase en la pantalla principal de la app y contar con un botón para desplegarlo aunque también puede ser abierto con un gesto de desplazamiento. Aunque ha sido un tanto denostado en los últimos tiempos y en algunas aplicaciones está siendo reemplazado por la barra Bottom Navigation se sigue utilizando ampliamente.
En el tutorial Introducción a Spring Boot: Aplicación Web con servicios REST y Spring Data JPA se construye una pequeña aplicación web que muestra en pantalla los registros de una tabla de una base de datos MySQL a la que se accede a través de Spring Data JPA, y que también dispone de una pequeña api REST. Sin embargo, falta un elemento vital como son los tests. Para suplir esta carencia, en el presente tutorial voy a mostrar cómo configurar tests de integración en Spring Boot utilizando esa misma aplicación así como algunas opciones y librerías que pueden ser de gran ayuda. Los tests se desarrollarán con JUnit 4 pero al final del tutorial veremos cómo utilizar también JUnit 5.
Una vez que hemos empezado a utilizar la especificación Bean Validation para definir restricciones sobre los atributos de clases Java, en algún momento nos encontraremos con la necesidad de validar restricciones que no sean proporcionadas ni por el estándar Bean Validation ni por Hibernate Validator y que no pueden definirse utilizando expresiones regulares con @Pattern. Por ejemplo, realizar alguna comprobación en una base de datos.
El objetivo de la especificación Bean Validation es establecer un estándar para la definición e implementación de restricciones en clases Java del tipo “el atributo nombre no puede ser nulo”, “el atributo cantidad debe ser un número positivo mayor que 10”, etc. La aplicación más evidente de estas restricciones es la realización de validaciones sobre los datos de entrada de un sistema, ya sean proporcionados por un usuario a través de un formulario o de forma automática por otro proceso. Al tratarse de un estándar compatible con Java SE puede ser utilizado en cualquier aplicación e integrado fácilmente con Spring, Struts 2 o JSF.
Tal y como vimos en el tutorial Spring JDBC Template: simplificando el uso de SQL, a pesar de la existencia de herramientas de mapeo ORM tales como Hibernate y estandarizadas con la especificación JPA, existen escenarios en los que necesitamos trabajar directamente con SQL nativo. El caso más habitual suele ser la ejecución de consultas complejas que deben ser optimizadas o bien son difíciles de implementar de forma eficiente con el ORM.
En el tutorial Diseño Android: Cuadros de diálogo de selección vimos cómo crear un cuadro de diálogo de selección encapsulado en un fragment y también echamos un vistazo rápido a las características de los cuadros de diálogo en Android. En el presente tutorial haremos lo mismo pero en lugar de mostrar un listado de elementos a seleccionar haremos lo propio con un pequeño formulario. En concreto, implementaremos el siguiente formulario con dos campos de texto.
En el tutorial Persistencia en BD con Spring: Integrando JPA, c3p0, Hibernate y EHCache, vimos de forma práctica los pasos a seguir para configurar una aplicación Maven que integre Spring con JPA, utilizando Hibernate como implementación. No es difícil, pero resulta tedioso tener que replicar esta configuración cada vez que empecemos un proyecto nuevo y la configuración puede complicarse si por ejemplo vamos a desarrollar un proyecto web completo y necesitamos también utilizar otros módulos de Spring tales como MVC, Data, Security, etc.
En JPA los atributos y relaciones que forman parte de una entidad pueden ser obtenidas desde la base de datos de dos formas distintas: en el momento en que obtengamos la entidad (EAGER) o bien bajo demanda (LAZY), esto es, la primera vez que se acceda a dichas propiedades o relaciones. Este modo LAZY es posible en Hibernate gracias al uso de objetos proxy que lanzan las consultas necesarias para la obtención de ese objeto, y su objetivo final es mejorar el rendimiento evitando obtener en nuestras aplicaciones datos que realmente no necesitamos (en ocasiones incluso podríamos terminar cargando toda la base de datos en memoria).
Los cuadros de diálogo son un elemento básico de la mayoría de interfaces de usuario y no necesitan presentación alguna. Según las guías de estilos de Material Design, “informan a los usuarios sobre una tarea específica y pueden contener información crítica, requerir decisiones o implicar varias tareas.” En Android, son ventanas que se muestran sobre una pantalla, representada por una Activity o un Fragment, y que bloquean el uso de la pantalla subyacente. Esta ventana es gestionada directamente por una implementación del contrato android.content.DialogInterface, aunque en la práctica será suficiente con utilizar alguna de las implementaciones que ya incluye Android.
Generalmente el uso y explotación de bases de datos SQL en Java lo realizamos a través de herramientas de mapeo ORM tales como Hibernate o Apache OpenJPA que permiten desarrollar la capa de persistencia de nuestras aplicaciones de forma muy rápida con una alta abstracción sobre el modelo relacional. Spring no sólo es muy fácil de integrar con estos productos tal y como vimos en el tutorial “Persistencia en BD con Spring: Integrando JPA, c3p0, Hibernate y EHCache”, sino que además proporciona con Spring Data JPA su propia capa de abstracción que nos facilita y simplifica aún más el trabajo tal y como vimos en la correspondiente serie de tutoriales al respecto.
Seguimos en el blog echando un vistazo a componentes de Material Design de los que disponemos de implementaciones proporcionadas por Google. En este tutorial veremos el componente Bottom Sheet, un panel que se desliza hacia arriba desde la parte inferior de la pantalla. Su uso más habitual es mostrar información contextual o funcionar a modo de menú de selección. Este segundo caso es el que vamos a implementar con dos diseños distintos (modo lista y modo grid) y encapsulado en un fragment. El primero de ellos es una copia del utilizado en la versión 2.0 de Muspy for Android. La siguiente imagen muestra lo que vamos a implementar en este tutorial.
Material Design hace especial hincapié en el concepto de motion (movimiento) para “describir las relaciones espaciales, la funcionalidad y la intención con belleza y fluidez”. Dentro de los patrones de diseño propuestos podemos encontrar ejemplos y consejos para mantener la continuidad al navegar entre las distintas pantallas de forma coherente, natural y elegante, siendo uno de los comportamientos más llamativos el desplazamiento rápido y suave entre pantallas de elementos comunes entre ellas (shared elements). Podemos encontrar un buen ejemplo de ello en Google Play.
