PDF de programación - Construir Interfaces Complejas

Introducción
En un contexto profesional, la interfaz de una aplicación Android es un elemento que no hay que
descuidar: no debemos olvidar que, en un primer momento, es el diseño de la aplicación lo que va a
dar a los usuarios de Play Store una primera impresión y permitirles prejuzgar la calidad de nuestra
aplicación.

De hecho, el diseño de la interfaz gráfica supone una carga de trabajo en consecuencia: además de
las restricciones vinculadas con los múltiples tamaños de pantalla y a las diferentes versiones del
sistema Android, las normas de ergonomía así como las restricciones impuestas por los equipos de
diseño gráfico (por lo general responsables de la integridad del diseño de la aplicación) incluyen su
lote de dificultades para el desarrollador.

Veremos, en este capítulo, cómo reducir la carga de trabajo maximizando el uso de componentes
complejos de la interfaz y, además, veremos cómo implementar los elementos de navegación
sugeridos por Google. A continuación, veremos cómo, utilizando elementos gráficos creados mediante
XML, limitar las variaciones gráficas para los pictogramas, botones y fondos de pantalla. Por último,
terminaremos el capítulo con algunos trucos que simplifican el diseño de las representaciones
utilizadas con mayor frecuencia.

Crear sus propios componentes
Una de las reglas más importantes en términos de diseño de aplicación es la unicidad: si una misma
funcionalidad está presente en varias pantallas de una aplicación, debe presentar el mismo diseño
para todas las pantallas.

Para evitar al desarrollador tener que producir el mismo código en distintas ubicaciones, el sistema
Android le ofrece la posibilidad de diseñar sus propios componentes de interfaz, que podrán utilizarse
con
como, por
ejemplo, editText,ListView, etc.

componentes nativos de

la plataforma

facilidad que

la misma

los

1. Sobrecargar un componente existente

Si el componente que queremos crear es parecido a algún otro componente ya existente, y si lo que
queremos, principalmente, es extender sus funcionalidades, es recomendable sobrecargar dicho
componente en lugar de crear un componente nuevo partiendo de una hoja en blanco.

Todos los componentes, como hemos visto en el capítulo Los fundamentos, forman parte del
paquete android.widget y es posible sobrecargarlos.

a. Extender una clase del paquete android.widget

Por regla general, el layout del componente sobrecargado no se modifica en sí mismo, sino que las
modificaciones realizadas en este contexto son por lo general reducidas. Basta, por tanto, con crear
una nueva clase, que extenderá de la clase del componente que se ha seleccionado, y agregar los
métodos que deseemos.

package es.midominio.miAplicacion;

import android.widget.AutoCompleteTextView;
[...]
public class MiCustomAutoComplete extends AutoCompleteTextView{
...
}

Esta clase deberá proveer dos constructores: uno que se utiliza cuando se declara una instancia de
la clase en el código y otra que se utiliza específicamente cuando el componente se declara en un
archivo de recursos (un archivo de layout de una actividad, por ejemplo).

En ambos casos, resulta obligatorio invocar al constructor correspondiente del padre, llamada que
debe ser la primera instrucción del constructor.

El primer constructor, para una declaración directa en el código, recibe como único parámetro un
objeto Context.

public MiCustomAutoComplete(Context context) {
super(context);
}

El segundo constructor, que se utiliza cuando el componente se declara en un archivo XML de
layout,
de
tipoandroid.util.AttributeSet, que permite recuperar y utilizar de manera simplificada los
atributos declarados en XML.

objeto Context,

además

recibe,

objeto

un

de

un

public MiCustomAutoComplete (Context context, AttributeSet attr){
super(context, attr);
...
}

En el caso de un componente creado por varias piezas, este último constructor es el más
complicado de definir, puesto que debe tener en cuenta todas las propiedades que pueden
haberse declarado en el archivo XML. En el caso de una sobrecarga de un componente nativo, la
llamada al constructor permite evitar este trabajo.

Según la personalización deseada, una vez definidos los constructores, basta con sobrecargar los
métodos correspondientes, consultando la documentación del componente nativo extendido.

b. Integrar el nuevo componente en un layout

La integración de un componente personalizado en un layout se realiza de la misma manera que
para un componente nativo. Es preciso, no obstante, tener en cuenta el empaquetado al que
pertenece el componente personalizado e indicar el nombre completo del paquete de la clase
creada en la etiqueta XML del componente.

<es.midominio.miAplicacion.MiCustomAutoComplete
android:layout_width="fill_parent"
android:layout_height="wrap_content"/>

El uso del componente en el código de la actividad no difiere del uso de un componente nativo: la
referencia al componente se realiza utilizando el método findViewById.

c. Agregar atributos personalizados

Uno de los principales intereses para sobrecargar componentes nativos del sistema reside en la
posibilidad que esto ofrece para definir atributos personalizados. Estos atributos pueden, a
continuación, recibir un valor igual que los atributos nativos mediante la etiqueta XML
correspondiente del componente.

En primer lugar, veremos cómo declarar estos atributos personalizados. A continuación,
estudiaremos cómo vincular sus valores (y explotarlos).

La declaración de atributos personalizados se realiza en un archivo de recursos XML específico,
ubicado en la carpeta values de los recursos del proyecto. Este archivo se denomina,
clásicamente, attrs.xml (por attributes ), aunque es posible asignarle el nombre que se desee.
El archivo attrs es un archivo de recursos: la etiqueta XML de primer nivel es, por tanto, una
etiqueta <resources>. Cada conjunto de atributos personalizados se define en una
etiqueta<declare-styleable>, cuya propiedad name debe estar obligatoriamente informada.
Cada atributo se define en una etiqueta <attr>, con las propiedades name y format.

<?xml version="1.0" encoding="utf-8"?>
<resources>
<declare-styleable name="misAtributosCustoms">
<attr name="miAtributoCustom_1" format="string"/>
<attr name="miAtributoCustom_2" format="boolean"/>
</declare-styleable>
</resources>
Para utilizar estos atributos personalizados en un archivo de layout, es preciso declarar el espacio
de nombres correspondiente (el nombre del paquete de la solución) en el archivo XML dellayout,
de forma análoga al tradicional espacio de nombres "android".

<RelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:capitulo8="http://schemas.android.com/apk/res/
es.midominio.MiAplicacion"

android:layout_width="match_parent"
android:layout_height="match_parent">

<es.midominio.miAplicacion.MiCustomAutoComplete
android:layout_width="fill_parent"
android:layout_height="wrap_content"
capitulo8:miAtributoCustom_1="valor_1"
capitulo8:miAtributoCustom_2="true"/>
</RelativeLayout>

Es posible recuperar los atributos definidos por el componente en la etiqueta XML a nivel de la clase
del componente, típicamente en el constructor. Esta recuperación se realiza en dos tiempos:

de

un

Recuperación
métodoobtainStyledAttributes() del objeto Context.
A continuación, recuperación del valor de cada uno de los atributos a partir del
objetoTypedArray.

gracias

tipo

objeto

de

TypedArray

al

La versión del método obtainStyledAttributes que utilicemos aquí presenta la siguiente
firma:

public final TypedArray obtainStyledAttributes(AttributeSet set,
int[] attrs)

El primer parámetro es de tipo AttributeSet, y se corresponde con el que se recibe
como parámetro del constructor del componente.

El segundo parámetro, una tabla de valores enteros, representa la lista de atributos que se
desean recuperar.

Este segundo parámetro debe explicitarse: se trata de hecho de una tabla con los identificadores
generados en tiempo de compilación de la solución, y que podemos encontrar en el archivoR.java,
dentro de la carpeta gen de la solución.
Para cada conjunto de atributos personalizados (cada etiqueta declare-styleable), el
compilador genera los identificadores y una tabla de valores enteros correspondiente. Las
siguientes reglas se aplican en la nomenclatura de los identificadores y de la tabla:

La tabla lleva el nombre indicado en su etiqueta declare-styleable.
Cada atributo se denomina [nombre_de_la_etiqueta_xml]_[nombre_del_atributo].
Estos elementos son accesibles mediante la clase R.styleable.

En nuestro ejemplo, tendremos:

public static final int
misAtributosCustoms_miAtributoCustom_1 = ...;

public static final int
misAtributosCustoms_miAtributoCustom_2 = ...;

public static final int[]misAtributosCustoms=...;
Y típicamente, es la tabla misAtributosCustoms la que se utilizará como segundo argumento
del método obtainStyledAttributes.

public MiCustomAutoComplete(Context context, AttributeSet attr){
super(context, attr);

TypedArray customAttributes =
context.obtainStyledAttributes(attr,

R.styleable.misAtributosCustoms);
...
}

Por último, resulta muy sencillo obtener los valores de los distintos atributos utilizando el
objetoTypedArray que devuelve el método: en función del tipo definido, basta con utilizar el
método correspondiente.

String atribu