Programación Android y Java
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.
En numerosos listados en los que se puedan mostrar una gran cantidad de elementos resulta necesario algún mecanismo de paginación que permita ir obteniendo, generalmente desde un servicio web REST, los elementos a mostrar a medida que el usuario solicita más datos al hacer scroll del listado:
En los últimos años hemos vivido una revolución en el desarrollo de aplicaciones web, incluyendo las aplicaciones híbridas para dispositivos móviles, en lo que respecta al frontend (interfaces/interacción con el usuario) gracias al imparable auge de herramientas y frameworks como AngularJS, jQuery, Backbone.js, Bootstrap o Ionic. Esta revolución incluso ha llegado al backend de la mano de Node.js y sus frameworks como Express.
Bower es un gestor de paquetes que nos ayudará en la utilización de todas estas APIs y frameworks de JavaScript y CSS. Gracias a Bower no tendremos que descargar y copiar manualmente en los proyectos estas dependencias, haciendo asimismo su actualización muy sencilla.
El patrón de diseño Swipe To Refresh, más conocido como Pull To Refresh, puede ser considerado como el mecanismo estándar en aplicaciones móviles para actualizar el contenido de un listado o grid de datos con los elementos más recientes los cuales son añadidos en la parte superior del listado. Al deslizarse el listado hacia abajo y mostrarse el primer elemento, si el usuario intenta seguir deslizando un poco más (a veces se muestra un mensaje informando al usuario de esta posibilidad) se procede a la obtención de nuevos datos mostrando un Progress Dialog indeterminado.
