Cómo Personalizar el título de tu Aplicación Android

Hay varias maneras de personalizar el título de tu aplicación android, yo trataré de explicar aquí la forma mas sencilla que he encontrado.

La pesonalización del título de tu aplicación consiste básicamente en dos pasos:

  1. Crear un layout donde tendremos nuestro título.
  2. Decirle a nuestra aplicación que lo muestre cuando se cree.

Layout (con una imagen y un título):

<?xml version=”1.0″ encoding=”utf-8″?>
<LinearLayout xmlns:android=”http://schemas.android.com/apk/res/android&#8221;
android:id=”@+id/main_title_layout”
android:layout_width=”match_parent” android:layout_height=”wrap_content” android:orientation=”horizontal”
android:background=”@android:color/black”>
<ImageView
android:layout_width=”22dp”
android:layout_height=”22dp”
android:contentDescription=”@string/app_name”
android:src=”@drawable/icon”
android:gravity=”center_vertical” />

<TextView
android:layout_width=”wrap_content”
android:layout_height=”wrap_content”
android:layout_gravity=”center_vertical”
android:paddingLeft=”4dp”
android:text=”@string/app_name”
android:textSize=”12sp”
android:textColor=”@android:color/white”
/>
</LinearLayout>

Supongamos que guardamos el layout con el nombre de “main_title.xml”.

Código para usar el layout anterior en cada Activity

public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//Habilitamos la personalización del título
this.requestWindowFeature(Window.FEATURE_CUSTOM_TITLE);
setContentView(R.layout.main);
getWindow().setFeatureInt(Window.FEATURE_CUSTOM_TITLE, R.layout.main_title);
//Otras acciones de nuestra app
}

Bien, esta sería la teoría, pero en la práctica, si añades un fondo a al layout, se puede apreciar que no encaja del todo:

title_black_padding

Esto parece ser que ocurre, porque realmente lo que hacemos con las instrucciones anteriores es insertar ese layout como título, pero dentro del “título” original.
Para poder solucionarlo añadimos las siguientes instrucciones:

View view = getWindow().findViewById(R.id.main_title_layout);
((FrameLayout) view.getParent()).setPadding(0,0, 0,0);

Donde main_title_layout sería el identificador del Layout contenedor de nuestro título personalizado.

Eso es todo!

A disfrutar!

Google Analytic y EasyTraker

En el artículo de hoy vamos a ver como integrar en nuestra aplicación android las herramientas que nos proporciona google para monitorizar y analizar el uso de nuestras aplicaciones.
Seguro que todos conoceis como funcionan la herramienta de google analytic para monitorizar nuestras páginas web. De forma similar, google proporciona herramientas que nos permiten tanto monitorizar desde donde acceden al google play para instalar nuestras aplicaciones android y ver por qué páginas (pantallas en android) se mueven los usuarios.

Lo primero que tenemos que hacer, si no la tenemos ya, crear una cuenta en Google Analytic (esto queda fuera del tutorial). Desde la pestaña “Admisitracion” creremos un nuevo proyecto (o cuenta) seleccionando el tipo Aplicación introducimos los datos de la aplicación. Al finalizar se nos dará un número de identificación que debemos añadir a nuestro proyecto. Para ello crearemos un fichero analytics.xml que añadiremos en nuestra carpeta values.

<?xml version="1.0" encoding="utf-8" ?>
<resources>
  <!--Replace placeholder ID with your tracking ID-->
  <string name="ga_trackingId">UA-XXXXXXXX-X</string>
  <!--Enable automatic activity tracking-->
  <bool name="ga_autoActivityTracking">true</bool>
  <!--Enable automatic exception tracking-->
  <bool name="ga_reportUncaughtExceptions">true</bool>
</resources>

En la etiqueta de nombre ga_trackingId introduciremos el código devuelto por la página google analytics.

Ahora lo que haremos será añadir la librería libGoogleAnalyticsV2.jar a nuestro proyecto. Desde el administrador del SDK de android podemos bajar la librería seleccinándola desde la sección de extras:

AndroidSdkManager

Una vez que la tengamos descargada la añadimos a nuestras librerias añadiendolas al buil path de nuestro proyecto y además de esto debemos añadirla a la carpeta libs de nuestro proyecto, si no, aunque compile, no funcionará en el dispositivo android.

Ahora queda la última parte, añadir el código a nuestra aplicación. Lo que haremos será sobreescribir los métodos onStart y onStop de la siguiente forma en aquellos Activity que queramos monitorizar:

    @Override
    protected void onStart() {
        super.onStart();
        EasyTracker.getInstance().activityStart(this);
    }
    @Override
    protected void onStop() {
        super.onStop();
        EasyTracker.getInstance().activityStop(this);
    }

Así cada vez que el usuario acceda a los Activity se trazará, dándonos información de las pantallas mas utilizadas.

Espero que os haya sido de utilidad!

Mas info en: https://developers.google.com/analytics/devguides/collection/android/v2/?hl=es#tracking-methods

Saludos!!

Test de Integración vs Test Unitarios

Introducción

Desde hace cierto tiempo la comunidad de desarrolladores y empresas del sector se están concienciando de la importancia de tener definido e implementado un sistema de pruebas sobre el software desarrollado. Para dar soporte a estas pruebas nacieron una serie de frameworks y herramientas como la familia xUnit y entornos de integración continua como Hudson.
¿Cómo se implementan estas pruebas? Básicamente podemos definir dos tipos, Pruebas de Integración y Pruebas Unitarias, cada una de las cuales tiene sus particularidades, comencemos por su definición.

Definición

Tomando las definiciones recopiladas en el blog de  PSDM Consulting podrían definirse como:

  • Prueba unitaria: prueba un único método de una clase. El alcance es muy reducido y está perfectamente acotado. Cualquier dependencia del módulo bajo prueba debe ser sustituida por un mock, o un stub.
  • Prueba de integración: prueba la interacción entre dos o más elementos, que pueden ser clases, módulos, paquetes, subsistemas, etc… incluso la interacción del sistema con el entorno de producción.

Ventajas y desventajas

Conociendo las ventajas y desventajas quizás podamos tener los datos suficientes para tomar la decisión de cuándo usarlas ya que hay distintas posiciones frente al tipo de test a utilizar.

Velocidad de ejecución

Definiendo velocidad por el tiempo que se tarda en ejecutar una prueba de este tipo, podemos afirmar sin realizar ninguna prueba empírica que lo Test de Integración deben ser más lentos de ejecutar que los Test Unitarios, ya que los Test de Integración ejecutan más líneas de código que un Test Unitario que se dedica solo a un método. ¿Cuál es la diferencia de tiempos? Esto depende tanto del código como del framework utilizado para las pruebas y mocks ya que un framework con objetos mocks muy lentos podrían penalizar los tiempos de ejecución de los Test Unitarios e igualar estos tiempos.

Velocidad de implementación

Los Test Unitarios consisten en las pruebas de métodos específicos y atañe sólo al código encerrado dentro de dicho método. Cada acceso al “exterior” es simulado mediante un mock.
Resumiendo mucho tendríamos que implementar un test por cada conjunto de valores de entrada a probar, así como crear los mocks necesarios para cada test.
En los Test de Integración evitamos, en la mayoría de las ocasiones, tener que crear mocks. La complejidad radica en crear las condiciones iniciales (datos iniciales en la BBDD u otros sistemas)  para ejecutar el test, que como apunta Adam Kolawa son fundamentales para que los Test de Integración sean realmente válidos.
Suponiendo que solo tenemos una interfaz para acceder a la aplicación, se debería implementar un conjunto de Test de Integración (en función de los valores de entrada y condiciones iniciales) por cada método esta interfaz, mientras que para los Test Unitarios, tendríamos que implementar un conjunto de test por cada método de cada clase que compone el software que estamos desarrollando.
Imaginemos que implementamos un solo test por método y que nuestra arquitectura corresponde al siguiente esquema, teniendo cada nivel una sola clase.
Service -> Manager -> Dao

Suponiendo que cada clase tiene 5 métodos necesitaríamos: 5 Test de Integración, frente a 15 Test Unitarios. En un caso real, tendríamos variasias clases por nivel sin contar con las clases de utilidades, esta diferencia se hace notoriamente mayor.

Cobertura de código

Si definimos cobertura como las líneas de código recorridas durante la ejecución de un Test, podemos decir que los Tests de Integración recorren mucho más código que los Unitario ya que pasan por más regiones de código. Sin embargo y dependiendo del diseño del código, habrá regiones de código que requieran de complejas condiciones iniciales para que el código sea alcanzado por un Test de Integración lo cual es un punto “en contra” de los Test de Integración, y lo pongo entre comillas por una razón que veremos más adelante.

Mantenibilidad de los Tests

Este es un punto muy controvertido. Mientras que algunos mantienen que los test unitarios son más fáciles de mantener otros, que los test de integración son más fáciles de mantener pero la verdad que siempre dependerá de los tipos de cambios a los que se vean sometidos el código.
Veamos varios escenarios y cómo afectan a los Tests.
– Cambios en clases intermedias que no afectan a los resultados, por ejemplo una refactorización que no afecta a los interfaces: En este caso los test de integración no tienen por qué verse afectados ya que tratan al código como casi una caja negra, sin embargo todas las clases y métodos modificados requerirán de modificación de test unitarios y mocks usados.
– Cambios en el comportamiento general de la aplicación: En este caso tanto los test de integración que esperaban cierto resultado se verán afectados como  los test unitarios que probaban las clases y métodos modificados.

Utilidad para la Mantenibilidad del código

Durante el desarrollo  del software los Test Unitarios nos dan información de qué método es el que está fallando o no da el resultado esperado por el Test. Esta cualidad es muy ventajosa para el desarrollador ya que el Test lo conduce directamente hacia el método a corregir.
Los Test de Integración dan una visión más global convirtiéndose en una poderosa herramienta para realizar las pruebas de regresión. Son capaces de detectar errores producidos durante el tratamiento de la información que no se producen de forma local a un método. Como desventaja , el Test de Integración no conduce al desarrollador al método que produce el error y requiere de depuración por parte de este, sin embargo detectar el error que un Test Unitario no podría es un a ventaja a tener en cuenta.

Proximidad a las pruebas de aceptación

Una de las ventajas que ofrecen los test de integración que no pueden aportar los test unitarios es la implementación de las pruebas de aceptación sobre el software.

Cobertura falseada por los test unitarios

Como comentaba en el apartado de cobertura, se podrían dar regiones de código que pueden ser difícilmente alcanzable por las pruebas de integración. Si estas regiones estuvieran recorridas mediante pruebas unitarias se estaría ocultando este dato, es decir, no conoceríamos regiones de código que nunca se recorren y que pueden ser reimplementadas para que sea un código realmente útil.

Veracidad de las pruebas

De todos es sabido que imposible implementar, en un tiempo razonable, un conjunto de pruebas que garanticen que un software de cierto tamaño no falle. Y esta imposibilidad aumenta con el tamaño del proyecto. ¿Qué pruebas pueden cubrir más errores? Para tratar de contestar a esta pregunta planteemos la siguiente situación:
Tenemos 5 clases que se llaman en cadena para realizar una operación determinada.
A->B->C->D->E
Si cada clase tiene una probabilidad de realizar su cometido con éxito de un 95%, tenemos que la probabilidad total, al ser llamadas encadenadas, es el producto de sus probabilidades, lo que da un resultado de: 0.95^5 = 0.77. Tenemos un 77% de probabilidad de éxito.
¿Qué significa esto? Podríamos decir, que los test de integración tienen más probabilidades de fallar, y por lo tanto de detectar bugs.
A esto habría que añadir que los test de integración prueban la conexión entre métodos, validando que las clases se invoquen de forma correcta entre ellas.

Conclusiones

Los Test de Integración dan una información global que no puede ser ignorada:
– Pruebas de aceptación.
– Pruebas de regresión.
– Pruebas funcionales.
– Menor número de test para probar la aplicación.
– Mantenibilidad más sencilla.
Los Test Unitarios proporcionan ventajas que tampoco pueden ser ignoradas:
– Es una forma sencilla de probar el código de forma exhaustiva e independiente de otros artefactos.
– Dirigen al desarrollador a la porción de código que falla de forma directa.

En conclusión y en mi opinión los Test de Integración deberían estar siempre en todos los desarrollos mientras que los Test Unitarios deberían ser usados para probar métodos complejos o críticos.

Referencias:

[1]http://psdm.co/2012/01/diferencias-entre-pruebas-unitarias-y-de-integracion/
[2]http://www.codeproject.com/Articles/235724/Integration-vs-unit-tests
[3]http://ix.cs.uoregon.edu/~michal/book/index.html
[4]http://geosoft.no/development/unittesting.html
[5]http://www.parasoft.com/jsp/products/article.jsp;jsessionid=baa4J9YnmGUi0g?articleId=2869&redname=unit-testing-best-practices&referred=unit-testing-best-practices