Programación Android, Spring y JEE
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.
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 y Android con 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 inyección de dependencias y, en muchos de ellos, utilizar versiones mocks, stubs, dummys, etc de los mismos.
En este tutorial vamos a ver una solución para un escenario en el que necesitamos que una aplicación realice una tarea en segundo plano de forma periódica y sin intervención por parte del usuario, por ejemplo para realizar una sincronización de datos con un servidor. Esta tarea puede ser implementada con un servicio, “un componente de una aplicación que puede realizar operaciones de larga ejecución en segundo plano y que no proporciona una interfaz de usuario”. Además de implementar este servicio, tenemos que encontrar un modo de programar su ejecución periódica y asegurar que se ejecute aunque la aplicación no se esté en ejecutando en ese momento.
La inyección de dependencias (Dependency Injection, DI) es un patrón de diseño que ayuda a hacer nuestras aplicaciones más modulares y fáciles de testear, mantener y evolucionar. Su uso está más que asumido en el mundo Java gracias a Spring y al estándar JEE, y en Android se está utilizando cada vez más de la mano de Dagger 2, herramienta desarrollada por Google utilizando como base Dagger de Square y que también puede utilizarse en Java.
