Programación Android y Java
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.
El testing automatizado suele ser uno de los grandes olvidados en el proceso de desarrollo de software y la primera “víctima” de las desviaciones de presupuestos y plazos de entrega. Sin embargo es parte fundamental del proceso de creación de software, incluso existe una metodología (TDD) en la que a grandes rasgos el desarrollo se hace en base a los tests que debe verificar el software y no al revés, esto es, primero se diseñan los tests y luego la aplicación que los verifica.
A finales del verano de 2015, Google publicó dentro de las librerías de compatibilidad un nuevo módulo para permitir realizar cierta integración entre nuestras apps y el navegador Chrome 45+. El objetivo consiste básicamente en poder solicitar a Chrome mostrar un contenido web y que el navegador “parezca” que forma parte de nuestra app y no de la sensación al usuario que hemos salido de la misma.
Durante el desarrollo de aplicaciones que van a ser utilizadas en distintos entornos (desarrollo, testing, producción, etc) solemos encontrarnos con el problema de adaptar la aplicación a cada uno de dichos entornos. Esto sucede habitualmente con los ficheros de configuración, por ejemplo los parámetros utilizados para la conexión a la base de datos, pero también es posible que necesitemos incluir librerías distintas en función de la versión de Java o incluso el sistema operativo que estamos utilizando.
Última actualización : 18/08/2016
La especificación de Material Design para los campos de texto recoge la utilización de las denominadas “etiquetas flotantes” (floating labels). Este elemento de usabilidad consiste en ubicar las etiquetas de los campos de texto dentro del mismo (inline) para posteriormente mostrarlas en la parte superior del campo mientras este tenga el foco o bien contenga algún valor. El objetivo es optimizar el espacio vertical de la pantalla al mostrarse la etiqueta dentro del campo del texto pero evitar a la vez que el usuario pierda la noción del contenido que corresponde al campo del texto. La siguiente animación, extraída de la aplicación de ejemplo que construiremos en el presente tutorial, muestra este comportamiento:
Uno de los componentes gráficos definidos por Material Design que más rápidamente han sido adoptados en Android es el nuevo estilo de pestañas integradas en la barra de acciones. Podemos encontrar una infinidad de ejemplos de su implementación, por ejemplo Google Play:
Una limitación que a veces encontramos al utilizar un layout en Android es la imposibilidad de definir dimensiones relativas mediante porcentajes. Siempre podemos implementar nuestro propio layout pero la estrategia más habitual suele ser utilizar LinearLayout y el atributo layout_weight tal y como se muestra en el tutorial Diseño Android: Dashboard UI con LinearLayout. El problema de esta técnica es que estamos limitados a utilizar sólo LinearLayout y que el “anidamiento” de los mismos si se utiliza layout_weight penaliza el rendimiento de la generación de la interfaz gráfica debido a los cálculos realizados para obtener el tamaño a utilizar.
Es posible que en alguna ocasión nos veamos en la necesidad de realizar algún tipo de operación directamente con el mensaje SOAP que recibe y/o envía nuestro servicio web. Esta tarea puede realizarse con el mecanismo de Handlers (“manejadores”) definidos en la especificación JAX-WS y que permite “interceptar” las peticiones y respuestas SOAP en un método que implementamos. Este mecanismo puede ser aplicado tanto al servidor como a los clientes.
Existen dos tipos de handlers:
Un Broadcast Receiver puede verse como un listener que atiende a eventos del sistema, esto es, lanzados por el sistema operativo, o bien a eventos lanzados por aplicaciones. Además, el evento puede incluir información adicional en un Intent. Nos encontramos por tanto ante un mecanismo que nos permitirá integrar aplicaciones entre sí y/o con Android, pero también establecer un canal de comunicación interno entre componentes (activities, fragments…) de una misma app. En el presente tutorial veremos una introducción a las posibiliaddes que nos ofrece la utilización de este componente.
