Programación Android, Spring y JEE
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.
Siendo un estándar compatible con Java SE puede ser utilizado en cualquier aplicación e integrado fácilmente con framewoks tan populares como Spring o Struts 2, además de en cualquier servidor de aplicaciones JEE como por ejemplo WildFly. Se puede encontrar un ejemplo básico de integración en Spring Boot en el tutorial Introducción a Spring Boot: Aplicación Web con servicios REST y Spring Data JPA.
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 nuestro 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 de opciones (simple y múltiple) encapsulado en un fragment. También echamos un vistazo rápido a las características que presentan en general 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 tendremos un pequeño formulario.
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 casi 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 poco código y una alta abstracción sobre el modelo relacional. Eso sí, es necesario saber utilizar estas herramientas muy bien para evitar graves problemas de rendimiento.
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.
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.
Al testear cierto comportamiento de un objeto nos encontraremos habitualmente con que ese objeto posee una o varias dependencias de otros objetos en los que se apoya y que, por tanto, condicionan el comportamiento del código que queremos testear. A veces incluso esas dependencias nos impiden la realización de los tests ya que pueden conectarse a servicios, bases de datos, etc, sobre los que no tenemos el control y no podemos configurar para hace nuestros tests.
En el tutorial Testing con JUnit 4 vimos la importancia del testing automatizado y los primeros pasos para realizarlo en Java de la mano de JUnit 4. En los proyectos en los que utilicemos Spring necesitaremos acceder en algunas clases de tests a los beans proporcionados por el contenedor de dependencias y, en muchos de ellos, utilizar versiones mocks, stubs, dummys, etc de los mismos. De este modo podemos realizar test funcionales y de integración de forma efectiva y realista.
