El SDK de Android nos permite crear AVDs (Android Virtual Devices) para diversas versiones del sistema operativo y con variadas características hardware. Pero, seamos realistas, su rendimiento deja bastante que desear, incluso en máquinas potentes.

A medida que van saliendo nuevas versiones de Android el esfuerzo que tiene que realizar el software para emularlas es cada vez mayor, lo que provoca que se ejecuten con bastante lentitud. Y mejor no hablemos de tabletas. Para arrancar un AVD con configuración de tableta hay que armarse de paciencia.

Afortunadamente, tenemos otra opción para emular Android obteniendo un mayor rendimiento: usar una máquina virtual que ejecuta la versión para procesadores Intel x86 de Android. Hay varios proyectos que buscan la mejor forma de realizar esta tarea. Yo me voy a centrar en AndroidVM, que es una de las soluciones más sencillas.

Descargando todo lo necesario

Lo primero que hay que descargar es la imagen de la máquina que vamos a instalar. Lo podemos hacer desde http://androvm.org/blog/download/. Hay varias versiones:

• Versión para emular teléfonos: vbox86p

• Versión para emular tabletas: vbox86t

• Versión para emular tabletas con capacidades de teléfono: vbox86tp

Además, de cada una de ellas hay una versión básica y otra que incluye las aplicaciones de Google, Houdini (un emulador de ARM) y soporte Flash. Lo del emulador de ARM se debe a que las imágenes son de Android para x86 y algunas aplicaciones se ejecutan en modo nativo y están compiladas para ARM (por ejemplo, el reproductor flash).

La imagen la descargamos en formato OVA (Open Virtualization Appliance), que es un paquete OVF (Open Virtualization Format) comprimido. El paquete contiene varias imágenes de disco y un fichero descriptor en formato XML. Las imágenes de disco de estos paquetes AndroVM están en formato VMDK (Virtual Machine Disk). Es el formato que utilizan los productos de VMware, pero también lo soporta VirtualBox, que es el que utilizaré en este post.

En esa misma página también es recomendable descargar la aplicación AndroVM Player, que nos servirá para que la máquina virtual utilice el hardware gráfico de la máquina anfitriona. Conviene descargar la versión que se corresponda con la versión de Windows que tengamos, 32 o 64 bits. No requiere instalación, basta con descomprimirla en un directorio.

Instalación de la máquina virtual

Instalar la imagen que hemos descargado es fácil y rápido. Basta con hacer doble click sobre ella o seleccionar Archivo | Importar servicio virtualizado en VirtualBox. Aceptamos las opciones predeterminadas y ya tenemos la máquina instalada.

Sencillo, ¿verdad?

Configuración de VirtualBox

La última versión de AndroVM Player es capaz de configurar la máquina virtual de forma automática la primera vez que se ejecuta, por lo que podemos saltarnos este apartado y los dos siguientes y pasar directamente a la configuración de AndroVM Player.

Aún así, como las cosas no siempre funcionan como debieran, explicaré aquí la forma “manual” de hacerlo, por si tuviéramos que recurrir a ella.

Para poder comunicarnos con la máquina virtual desde la anfitriona necesitamos un adaptador sólo-anfitrión (host-only). Para ver qué adaptadores tenemos configurados abrimos VirtualBox y seleccionamos Archivo | Preferencias. En la ventana que se abre seleccionamos Red:

Seguramente habrá uno ya creado y podremos utilizarlo. Si no hay ninguno, o si no queremos mezclar redes, podemos añadir uno (usando el botón superior de la derecha). Lo importante es que tenga activo el servidor DHCP. Para comprobarlo hay que abrir los detalles del adaptador, haciendo doble click sobre él. Luego pulsamos en la pestaña Servidor DHCP:

Hay que seleccionar Habilitar servidor y rellenar los datos. Se escoge una dirección para el servidor, se pone una máscara de tipo C (255.255.255.0) y luego se establece un rango de direcciones para las máquinas virtuales, teniendo cuidado de que no incluya la asignada al servidor.

Configuración de la máquina virtual

El siguiente paso es configurar la máquina virtual. La seleccionamos en VirtualBox y pulsamos el botón Configuración. Hay que seleccionar Red en el menú de la izquierda.

La máquina virtual viene configurada con dos adaptadores de red. Uno lo utiliza para conectarse a Internet y el otro está disponible para poder conectarlo con la máquina anfitriona. Este último viene desactivado, así que tenemos que configurarlo. Para ello, en la pestaña Adaptador 1 hay que cambiar la lista desplegable Conectado a de No conectado a Adaptador sólo-anfitrión. Luego, en Nombre seleccionamos el adaptador que configuramos antes.

Aceptamos los cambios, y ya estamos listos para iniciar la máquina. Al hacerlo arrancará Android, de forma muy similar a como lo hacen los AVD que se crean con el SDK:

Si no se ve la pantalla entera, podemos activar el modo ajustado, usando la tecla anfitrión (Host) + A. También podemos usar la misma configuración para salir de ese modo.

Configuración de la máquina Android

Tal y como viene configurada la máquina, el renderizado gráfico se realiza por software. Para que utilice el hardware gráfico de la máquina virtual hay que ejecutar la aplicación androVM Configuration. Es importante comprobar que en la parte superior de la aplicación se muestre la IP que se le ha asignado a la máquina Android. Si no aparece, habrá que revisar la configuración del adaptador 1, porque algo habremos hecho mal.

Para activar la aceleración hardware hay que seleccionar la opción Hardware OpenGL y pulsar Save. Nos pedirá reiniciar. Hay que pulsar No. Luego apagamos la máquina (desde el botón de cerrar de la ventana Windows en la que se ejecuta). Nota: Enviar la señal de apagado no sirve de nada, hay que apagarla.

Configuración de AndroVM PLayer

Ahora hay que configurar AndroVM Player. Al ejecutarlo se muestra la siguiente ventana:

La aplicación permite escoger las dimensiones y la densidad de píxeles de la máquina Android, bien seleccionando una configuración típica o bien introduciendo los datos manualmente. En la parte inferior hay otra lista desplegable para escoger la máquina virtual que queremos iniciar.

Si la aplicación no ha sido capaz de localizar la carpeta donde está instalado VirtualBox, tendremos que indicárselo nosotros. Para ello pulsamos el botón Settings de la esquina inferior derecha.

En la ventana de opciones tenemos que seleccionar el ejecutable VBoxManage.exe, que se encuentra en la carpeta de VirtualBox (de forma predeterminada, C:/Archivos de programa/Oracle/VirtualBox/). Pulsamos el botón Browse y lo localizamos.

También podemos escoger si queremos que la máquina virtual se ejecute dentro de una ventana de VirtualBox (In a GUI) o no (Headless). Lo mejor es escoger Headless, dado que la pantalla de la máquina Android se verá dentro de la aplicación AndroVM Player, por lo que no necesitamos tener también la ventana de VirtualBox.

Cerramos la ventana de opciones y cerramos también la aplicación AndroVM Player si sigue indicando que no encuentra VBoxManage. Al abrirla de nuevo debería haber desaparecido el mensaje. Ya podemos seleccionar la resolución y la máquina virtual en las listas desplegables:

Ejecución desde AndroVM Player

Para ejecutar la máquina virtual hay que pulsar el botón Run. Si nos hemos saltado algunos pasos y no hemos activado la aceleración gráfica, AndroVM Player se dará cuenta y nos ofrecerá la opción de activarla por nosotros:

Pulsamos Enable hardware acceleration para continuar. Si tampoco tenemos VirtualBox correctamente configurado, nos saldrá otro aviso:

Ahora tenemos que pulsar Setup VirtualBox. Si no tenemos un adaptador sólo-anfitrión creado, AndroVM Player lo creará por nosotros. Dependiendo de la versión de Windows, puede que se nos soliciten credenciales de administración (incluso varias veces). Si es el caso, se las otorgamos y seguimos.

Nota

Las credenciales son necesarias para crear un adaptador de red virtual en Windows. El interfaz es necesario para hacer de puente entre el equipo real y la red virtual que VirtualBox crea para las máquinas.

La siguiente comprobación que realiza AndroVM Player es si el adaptador de red de la máquina virtual está conectado al adaptador sólo-anfitrión. Si no es así, mostrará una nueva advertencia:

Nuevamente se ofrece a hacer el trabajo por nosotros, así que pulsamos Setup Network Adapter para terminar la configuración de la máquina virtual.

Nota

Hay que tener en cuenta que todos estos pasos sólo hay que hacerlos la primera vez que se arranca la máquina y sólo si no la hemos configurado manualmente. Las siguientes veces, la máquina arrancará directamente.

Si todo está bien configurado la máquina virtual se ejecuta con aceleración gráfica hardware. Además, AndroVM Player proporciona una barra que incluye los botones habituales de un teléfono Android:

Además de la interfaz de AndroVM Player, también podemos utilizar algunas teclas para simular algunos de los botones físicos de los terminales Android:

• Inicio: realiza la función del botón HOME, que sirve para regresar al lanzador de aplicaciones.

• ESC: equivale al botón ATRÁS.

• F1 o F10: botón MENÚ.

• F3: botón BUSCAR.

• F4 o Fin: botón de encendido (POWER).

• F11: pasar a pantalla completa (F11 de nuevo para volver a ventana).

Si usamos el botón de apagado de la botonera de AndroVM Player para apagar la máquina Android, se cerrará la máquina virtual, pero la aplicación AndroVM Player seguirá en ejecución. Es mejor usar el botón de cierre de la ventana AndroVM Player. Al pulsarlo se muestran dos opciones: una para cerrar la máquina virtual y la aplicación (Shutdown VM and Exit) y otra para cerrar sólo la aplicación dejando la máquina virtual en funcionamiento (Exit). Si vamos a necesitar la máquina más adelante, es mejor no cerrarla.

La aplicación no da la opción de crear una instantánea de la máquina virtual para no tener que arrancarla cada vez (algo que tarda algunos minutos). Aunque podríamos crear esa instantánea desde la interfaz principal de VirtualBox, luego no podremos abrir la máquina desde AndroVM Player (da un error de estado incorrecto). Esto es debido a la aceleración hardware, cuyo estado no se puede almacenar y recuperar.

Nota

A veces da algún error y dice que no puede comunicarse con la máquina. Desde la interfaz principal de VirtualBox podemos ver si la máquina ha arrancado realmente o no. Si esperamos a que esté lista y pulsamos Run de nuevo debería funcionar. También puede ocurrir que se muestre la interfaz de la aplicación AndroVM Player, pero con la pantalla en blanco, quedándose así indefinidamente. En este caso hay que cerrar la aplicación sin cerrar la máquina virtual y volver a ejecutarla. Si sigue sin funcionar, habrá que cerrar la máquina virtual desde VirtualBox y después volver a ejecutar AndroVM Player.

Ni que decir tiene que la versión tableta se configura exactamente de la misma forma (la resolución mínima para que se active la interfaz de tabletas es 1024×768):

Enlace de la máquina Android con el SDK

Para poder usar la máquina para desarrollar, tenemos que conectarla al PC. Para ello hay que usar la línea de comandos y ejecutar

adb connect <IP>

donde <IP> es la IP de la máquina virtual. La IP se muestra en la ventana junto al nombre de la aplicación AndroVM Player (si no lo vemos en la propia ventana, podemos dejar el cursor del ratón sobre el icono de la barra de tareas para que se muestre completo).

Podemos comprobar que la máquina se ha conectado con el comando adb devices. Si se muestra la IP de la máquina junto a la etiqueta device, todo estará listo para ejecutar nuestras aplicaciones. A partir de aquí funciona como un AVD o como un dispositivo real conectado al PC.

Compartir archivos

AndroVM Player proporciona acceso de forma automática a las carpetas que se comparten con la máquina virtual desde VirtualBox si se marcan para que se monten automáticamente.

Para compartir una carpeta en VirtualBox hay que abrir la configuración de la máquina virtual Android y seleccionar Carpetas compartidas en el menú lateral:

Añadimos una nueva carpeta pulsando en el botón Agregar carpeta compartida (el que tiene un signo de suma de color verde). En Ruta carpeta hay que seleccionar la carpeta de la máquina anfitriona que queremos compartir (pulsando en la flecha y seleccionando Otro) y en Nombre carpeta hay que escribir el nombre que se le asignará en la máquina virtual. Finalmente, hay que seleccionar la casilla de verificación Automontar (imprescindible). Pulsamos Aceptar para compartir la carpeta y luego otra vez Aceptar para cerrar las opciones.

Las carpetas configuradas de esta forma se montan en la máquina Android en la ruta /mnt/shared, por lo que podemos acceder a ellas desde cualquier explorador de archivos (la máquina AndroVM incluye Astro):

Limitaciones

Con todo esto ya tenemos lista una máquina virtual Android con aceleración gráfica y con un rendimiento bastante superior al de los AVDs que se crean con el SDK de Android. Pero hay que tener en cuenta que tenemos algunas limitaciones respecto a estos últimos.

Para empezar no tenemos un botón para rotar la pantalla, ni tampoco parece haber una combinación de teclas que permita hacerlo (como en los AVDs). Si una aplicación rota la pantalla, la máquina se rota correctamente, por lo que podemos usar una aplicación que fuerce una orientación.

Otra opción es utilizar las resoluciones manuales de AndroVM Player para invertir las dimensiones y arrancar la máquina en modo apaisado. Así podremos probar las aplicaciones en ambas orientaciones.

También hay que tener en cuenta que no podemos tener cualquier versión de Android. Ahora mismo la versión de AndroVM disponible es la 4.1.1, por lo que si queremos probar nuestras aplicaciones en versiones anteriores tendremos que crearnos AVDs o utilizar dispositivos reales con esas versiones (si disponemos de ellos).

No obstante, aunque no podamos hacer pruebas de compatibilidad con diversas versiones, sí que podemos probar toda la funcionalidad de nuestra aplicación en una de las versiones de Android más recientes, con posibilidad de depurar y con una mejor respuesta que la que podemos tener con los AVDs. Merece la pena, ¿no?

Es necesario aclarar que no es el único diseño que permite esta distribución. Recientemente se ha añadido un nuevo diseño, GridLayout, que también permite distribuir las vistas en forma de tabla. Está disponible desde la versión 14 de la API de Android, que se corresponde con la versión 4.0 del sistema operativo (Ice Cream Sandwich), y es bastante más potente que TableLayout.

Por el momento, dado que usar GridLayout impide que la aplicación funcione en versiones anteriores, vamos a centrarnos en ver cómo se utiliza TableLayout y ya hablaremos de GridLayout más adelante.

Lo primero que es necesario destacar de TableLayout es que no tiene, estrictamente hablando, una estructura de tabla. En realidad, TableLayout es una especialización de LinearLayout. En concreto, de un LinearLayout vertical. Aunque con un comportamiento particularizado.

Al igual que en un LinearLayout, en un TableLayout se pueden incluir todo tipo de vistas. Sin embargo, hay una vista específica que sólo se puede utilizar en TableLayout y que es la que aporta la funcionalidad necesaria para crear la tabla: TableRow.

TableRow es, a su vez, otra especialización de LinearLayout. Esta vez de un LinearLayout horizontal. Así que resulta evidente que, lo que se nos vende como una estructura de tabla, es en realidad un grupo de LinearLayout horizontales dentro de un LinearLayout vertical.

Esta organización tampoco resulta tan extraña. De hecho, es muy similar a la de las tablas en HTML, con las que este diseño comparte otras características, como veremos a continuación.

Resulta evidente que cada TableRow representa una fila de la tabla y que las vistas que contengan harán las veces de columnas. En concreto, cada vista que se añade a un TableRow va a parar a una columna diferente. Por ese motivo se suele decir que cada celda de un TableLayout sólo puede contener una vista. No obstante, nada impide que cualquiera de esas vistas sea un diseño y que contenga, a su vez otras vistas dentro.

Lo que diferencia a TableLayout de una estructura similar creada con varios LinearLayout es el tratamiento global que le da a las vistas que se incluyen en todos los TableRow. Para empezar, aunque cada TableRow tenga una cantidad diferente de vistas en su interior, el conjunto se representará como una tabla donde todas las filas tienen el mismo número de columnas. La cantidad total de columnas que tendrá la tabla la determina el TableRow que más vistas incluya. De forma similar, el ancho de cada columna también vendrá determinado por la vista con mayor anchura de todas las incluidas en esa columna, aún estando en diferentes TableRow.

Propiedades del diseño

TableLayout hereda directamente de LinearLayout, por lo que dispone de todas sus propiedades. Aunque algunas, como android:orientation, carecen de efecto si se intentan usar aquí.

Por su parte, TableLayout tiene algunas propiedades exclusivas:

Las propiedades de encoger y expandir permiten que nuestro diseño se adapte perfectamente a cualquier tamaño de pantalla, al tiempo que controlamos cuáles de las columnas pueden variar su tamaño y cuáles no. Una misma columna se puede marcar con ambas propiedades, de forma que se adapte a tamaños más pequeños o más grandes. Si las propiedades se aplican a más de una columna, el tamaño que es necesario añadir o reducir se reparte de forma equitativa entre todas ellas.

Parámetros

Al igual que ocurre con las propiedades, TableLayout hereda también todos los parámetros de diseño de LinearLayout. Sin embargo, aunque existe una clase TableLayout.LayoutParams, no se define en ella ningún nuevo parámetro. Así que sólo disponemos de los que proporciona LinearLayout, y con algunas limitaciones.

Por ejemplo, el parámetro android:layout_width de los elementos que incluyamos en un TableLayout siempre tendrá el valor match_parent, ignorando cualquier otro valor que tratemos de poner. Aunque hay que tener en cuenta que, normalmente, dentro del TableLayout sólo pondremos elementos de tipo TableRow, por lo que es normal que la anchura de estos elementos siempre iguale a la del TableLayout.

En el caso del parámetro android:layout_height, también encontramos una diferencia: TableLayout no obliga a definirlos en los elementos que contiene (los TableRow). Si no se incluyen, se asume el valor wrap_content.

Parámetros de TableRow

Como ya hemos comentado, TableRow es también una especialización de LinearLayout. Por lo tanto, es un diseño. Y como tal puede proporcionar parámetros para que se utilicen como atributos de las vistas que se incluyan en él.

En concreto, la clase TableRow.LayoutParams proporciona dos:

Uso de TableLayout en XML

Veamos ahora un ejemplo de actividad cuyo diseño principal es un TableLayout:

El código XML que permite crear esta tabla es el siguiente:

<?xml version="1.0" encoding="utf-8"?>
<TableLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/Tabla"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:stretchColumns="1" >

    <TableRow
        android:id="@+id/Cabecera"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" >

        <TextView
            android:id="@+id/ColumnaAnio"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:padding="5px"
            android:text="Año"
            android:textColor="#005500"
            android:textSize="26sp" />

        <TextView
            android:id="@+id/ColumnaCiudad"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_gravity="center_horizontal"
            android:padding="5px"
            android:text="Ciudad"
            android:textColor="#005500"
            android:textSize="26sp" />

        <TextView
            android:id="@+id/ColumnaOro"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:padding="5px"
            android:text="Oro"
            android:textColor="#005500"
            android:textSize="26sp" />

        <TextView
            android:id="@+id/ColumnaPlata"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:padding="5px"
            android:text="Plata"
            android:textColor="#005500"
            android:textSize="26sp" />

        <TextView
            android:id="@+id/ColumnaBronce"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:padding="5px"
            android:text="Bronce"
            android:textColor="#005500"
            android:textSize="26sp" />
    </TableRow>

    <TableRow
        android:id="@+id/SeparadorCabecera"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" >

        <FrameLayout
            android:id="@+id/LineaCabecera"
            android:layout_width="fill_parent"
            android:layout_height="2px"
            android:layout_span="6"
            android:background="#FFFFFF" >
        </FrameLayout>
    </TableRow>

    <TableRow
        android:id="@+id/Fila1"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" >

        <TextView
            android:id="@+id/Anio1"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="1900"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Cuidad1"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="París"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Oro1"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="1"
            android:textSize="20sp" />
    </TableRow>

    <TableRow
        android:id="@+id/Fila2"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" >

        <TextView
            android:id="@+id/Anio2"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="1976"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Cuidad2"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="Montreal"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Plata2"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_column="3"
            android:gravity="center"
            android:text="2"
            android:textSize="20sp" />
    </TableRow>

    <TableRow
        android:id="@+id/Fila3"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" >

        <TextView
            android:id="@+id/Anio3"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="1992"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Cuidad3"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="Barcelona"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Oro3"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="13"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Plata3"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="7"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Bronce3"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="2"
            android:textSize="20sp" />
    </TableRow>

    <TableRow
        android:id="@+id/Fila4"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" >

        <TextView
            android:id="@+id/Anio4"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="2012"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Cuidad4"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="Londres"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Oro4"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="3"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Plata4"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="10"
            android:textSize="20sp" />

        <TextView
            android:id="@+id/Bronce4"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="4"
            android:textSize="20sp" />
    </TableRow>

    <TableRow
        android:id="@+id/SeparadorTotales"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" >

        <FrameLayout
            android:id="@+id/LineaTotales"
            android:layout_width="fill_parent"
            android:layout_height="2px"
            android:layout_span="5"
            android:background="#FFFFFF" >
        </FrameLayout>
    </TableRow>

    <TableRow
        android:id="@+id/Totales"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" >

        <TextView
            android:id="@+id/TextoTotal"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_span="2"
            android:gravity="right"
            android:text="Total"
            android:textColor="#0000CC"
            android:textSize="22sp" />

        <TextView
            android:id="@+id/OroTotal"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="17"
            android:textSize="22sp" />

        <TextView
            android:id="@+id/PlataTotal"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="19"
            android:textSize="22sp" />

        <TextView
            android:id="@+id/BronceTotal"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:gravity="center"
            android:text="6"
            android:textSize="22sp" />
    </TableRow>

</TableLayout>

Como se puede observar, la actividad contiene un único TableLayout que ocupa todo su espacio visible. Dentro del TableLayout se incluyen únicamente diseños TableRow, uno por cada fila. Y dentro de los TableRow se incluyen diversos TextView, con las cadenas de texto que se muestran en cada celda de la tabla.

La única excepción son los TableRow que se utilizan para las líneas separadoras (la que separa la cabecera de la tabla y la que separa la fila de totales). En estos TableRow se ha incluido un FrameLayout con una altura muy pequeña (2 píxeles) y con el fondo de color blanco.

Es una forma sencilla de crear líneas y se utiliza con frecuencia con todo tipo de diseños, no únicamente con TableLayout. Esto se debe a que, a diferencia de otros entornos, en Android los widgets no tienen propiedades específicas para los bordes. No podemos definir, como, por ejemplo, en HTML, el ancho, color y estilo de cada borde simplemente asignando valores a propiedades.

Esto no quiere decir que no se puedan mostrar bordes en las celdas de un TableLayout, sino que hacerlo resulta un poco más complejo de lo que cabría suponer. En Android los bordes forman parte de la imagen gráfica del widget, la cual se puede modificar mediante un tipo de recursos llamados dibujables (drawables). De estos recursos hablaremos en un futuro post.

Además de usar un FrameLayout para crear líneas, también podemos jugar con los colores de fondo del TableRow y el de los widgets de las celdas, junto con el padding, para simular los bordes. Aunque de esta forma las opciones de personalización son algo menores.

Ejemplo en Java

Como ya es habitual, ahora veremos la forma de crear la misma interfaz de usuario mediante código Java:

    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);

        // Datos para la tabla
        String cabeceras[] = { "Año", "Ciudad", "Oro", "Plata", "Bronce" };
        String datos[][] = { { "1900", "París", "1", "", "" },
                             { "1976", "Montreal", "", "2", "" },
                             { "1992", "Barcelona", "13", "7", "2" },
                             { "2012", "Londres", "3", "10", "4" } };

        // TableLayout (diseño principal de la actividad)
        TableLayout tabla = new TableLayout(this);
        tabla.setLayoutParams(new TableLayout.LayoutParams(
           LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT));
        tabla.setColumnStretchable(1, true);

        // Cabecera de la tabla
        TableRow cabecera = new TableRow(this);
        cabecera.setLayoutParams(new TableLayout.LayoutParams(
           LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTENT));
        tabla.addView(cabecera);

        // Textos de la cabecera
        for (int i = 0; i < 5; i++)
        {
           TextView columna = new TextView(this);
           columna.setLayoutParams(new TableRow.LayoutParams(
              LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT));
           columna.setText(cabeceras[i]);
           columna.setTextColor(Color.parseColor("#005500"));
           columna.setTextSize(TypedValue.COMPLEX_UNIT_SP, 26);
           columna.setGravity(Gravity.CENTER_HORIZONTAL);
           columna.setPadding(5, 5, 5, 5);
           cabecera.addView(columna);
        }

        // Línea que separa la cabecera de los datos
        TableRow separador_cabecera = new TableRow(this);
        separador_cabecera.setLayoutParams(new TableLayout.LayoutParams(
           LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTENT));
        FrameLayout linea_cabecera = new FrameLayout(this);
        TableRow.LayoutParams linea_cabecera_params =
           new TableRow.LayoutParams(LayoutParams.FILL_PARENT, 2);
        linea_cabecera_params.span = 6;
        linea_cabecera.setBackgroundColor(Color.parseColor("#FFFFFF"));
        separador_cabecera.addView(linea_cabecera, linea_cabecera_params);
        tabla.addView(separador_cabecera);

        // Array para los totales
        int valores_totales[] = { 0, 0, 0 };

        // Filas de datos
        for (int f = 0; f < 4; f++)
        {
           TableRow fila = new TableRow(this);

           for (int c = 0; c = 2) valores_totales[c-2] += Integer.parseInt(datos[f][c]);
              }
           }

           tabla.addView(fila);
        }

        // Línea que separa los datos de la fila de totales
        TableRow separador_totales = new TableRow(this);
        separador_totales.setLayoutParams(new TableLayout.LayoutParams(
           LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTENT));
        FrameLayout linea_totales = new FrameLayout(this);
        TableRow.LayoutParams linea_totales_params =
           new TableRow.LayoutParams(LayoutParams.FILL_PARENT, 2);
        linea_totales_params.span = 6;
        linea_totales.setBackgroundColor(Color.parseColor("#FFFFFF"));
        separador_totales.addView(linea_totales, linea_totales_params);
        tabla.addView(separador_totales);

        // Fila de totales
        TableRow totales = new TableRow(this);
        totales.setLayoutParams(new TableLayout.LayoutParams(
           LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTENT));

        TextView texto_total = new TextView(this);
        TableRow.LayoutParams texto_total_params =
           new TableRow.LayoutParams(
              LayoutParams.WRAP_CONTENT,
              LayoutParams.WRAP_CONTENT);
        texto_total_params.span = 2;
        texto_total.setText("Total");
        texto_total.setTextColor(Color.parseColor("#0000CC"));
        texto_total.setTextSize(TypedValue.COMPLEX_UNIT_SP, 22);
        texto_total.setGravity(Gravity.RIGHT);
        totales.addView(texto_total, texto_total_params);

        for (int i = 0; i < 3; i++)
        {
           TextView columna = new TextView(this);
           columna.setLayoutParams(new TableRow.LayoutParams(
              LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT));
           columna.setText(String.valueOf(valores_totales[i]));
           columna.setTextSize(TypedValue.COMPLEX_UNIT_SP, 22);
           columna.setGravity(Gravity.CENTER);
           totales.addView(columna);
        }

        tabla.addView(totales);

        // Añadimos la tabla a la actividad
        setContentView(tabla);
    }

En este caso me he creado varios arrays con la información que tiene que mostrarse en la tabla. Los recorro mediante bucles for, dentro de los cuales voy creando un widget para cada cadena de texto a mostrar. Además, los totales los calculo a medida que voy añadiendo las filas de datos, guardándolos en otro array para mostrarlos después en la última fila de la tabla.

En las filas de datos, las cadenas vacías las ignoro, pero cada widget lo asocio a la columna que le corresponde para que se coloque en su sitio, dejando columnas vacías si es necesario. Esto se hace mediante el atributo público column de la clase TableRow.LayoutParams.

Esta clase no dispone de un constructor que permita definir al ancho y alto del widget y, al mismo tiempo, asociarlo a una columna. Así que primero tenemos que crear el objeto, luego asignar el número de columna al atributo column y después asociarle el objeto con los parámetros al widget al incluirlo en el TableRow (en la llamada a addView).

Con el parámetro android:layout_span que necesitamos para que los FrameLayout que crean las líneas horizontales ocupen todo el ancho del TableLayout hay que hacer lo mismo: crear un objeto TableRow.LayoutParams, asignar el número de columnas a ocupar al atributo público span y asociar los parámetros al widget al llamar a addView para agregarlo al TableRow.

Por último, un detalle importante a tener en cuenta: si se va a crear un objeto LayoutParams para un TableRow, debe ser siempre de la clase TableRow.LayoutParams, aunque sólo se vaya a definir ancho y alto y no sea necesario utilizar ninguno de los parámetros propios del TableRow. Si usamos un objeto de la clase ViewGroup.LayoutParams el TableRow podría incluso no mostrarse en la actividad.

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80.

Esta alineación puede ser vertical u horizontal. O sea, que LinearLayout sirve para colocar vistas en una misma fila o columna, pero no ambas cosas a la vez.

Las vistas se colocan en el mismo orden en se agregan al diseño o en el que aparecen en el archivo XML.

De forma predeterminada, LinearLayout tiende a establecer el mismo tamaño para cada vista que contiene, repartiendo el espacio disponible de forma equitativa entre todas ellas. Sin embargo, algunas propiedades de las vistas y ciertos parámetros que el propio LinearLayout añade permiten variar este comportamiento.

Veamos cómo sacarle partido a este diseño.

Propiedades

Comencemos por algunas de las propiedades que tiene LinearLayout, además de las que le aporta la clase View y que ya vimos en un post anterior:

Parámetros de diseño

Al igual que el resto de diseños, LinearLayout define su propia clase de parámetros de diseño, que añade propiedades a las vistas que contiene. En este caso, LinearLayout.LayourParams hereda de ViewGroup.MarginLayoutParams. Esta última clase, como ya vimos en el post sobre padding y margen, hereda de ViewGroup.LayoutParams añadiendo las propiedades que permiten definir márgenes para las vistas.

Esta jerarquía de clases permite que LinearLayout.LayoutParams herede parámetros genéricos como android:layout_width y android:layout_height y, al mismo tiempo, los de los márgenes (android:layout_marginLeft, android:layout_marginTop, etc). A todos estos añade dos de cosecha propia: gravedad y peso.

Gravedad

La gravedad (android:layout_gravity) es idéntica a la que proporciona FrameLayout, por lo que no volveré a describirla aquí. Lo que sí hay que tener en cuenta es en qué se diferencia respecto a la gravedad del propio diseño (android:gravity), comentada en el apartado anterior.

Aunque funcionan de forma muy similar, la propiedad android:gravity afecta al conjunto de todas las vistas contenidas en el diseño, mientras que el parámetro android:layout_gravity sólo afecta a la vista a la que se le asigna. Las siguientes capturas dejarán más claras las diferencias:

En la captura se muestra un LinearLayout horizontal con fondo rojo. Al igual que en la captura anterior, el atributo android:gravity tiene el valor center_horizontal. La diferencia es que, ahora, el segundo TextView utiliza el parámetro android:layout_gravity con el valor bottom, lo que provoca que se alinee con la parte inferior del LinearLayout. El otro TextView, al no definir ningún alineamiento, se queda en la parte superior (es el comportamiento predeterminado). Pero lo más destacable de la captura es cómo el atributo android:gravity afecta al conjunto de los dos TextView contenidos en el LinearLayout, centrándolos horizontalmente como si fueran un único elemento, en lugar de hacerlo individualmente.

Veamos ahora las dos capturas siguientes:

Las dos capturas muestran un LinearLayout (con fondo rojo) que contiene dos TextView. El primer TextView tiene los valores bottom y center_horizontal en el parámetro android:layout_gravity, mientras que el segundo sólo tiene el valor center_horizontal en su parámetro android:layout_gravity. En ninguna de las dos capturas se ha utilizado el atributo android:gravity del LinearLayout.

¿En qué se diferencian, entonces, los diseños de ambas capturas? Tan sólo en una cosa: la orientación del LinearLayout. En la captura superior el LinearLayout es horizontal, mientras que en la captura inferior es vertical. Esto pone de relieve una particularidad del parámetro android:layout_gravity cuando se utiliza en un LinearLayout (y que no se daba en el FrameLayout): las opciones de alineamiento que afectan a la dirección en la que se orienta el LinearLayout se ignoran.

En la primera captura, donde el LinearLayout es horizontal, se está ignorando el valor center_horizontal de ambos TextView. En la segunda captura, que muestra un LinearLayout vertical, el valor que se está ignorando es el bottom del primer TextView.

Si lo piensas tiene bastante sentido. La primera regla de un LinearLayout es que las vistas se muestran en orden secuencial, según se hayan añadido al diseño. Permitir total libertad a la hora de usar la gravedad podría alterar ese orden.

Por ejemplo, supongamos que en un LinearLayout vertical se incluyen tres vistas y se utiliza center_vertical en el parámetro android:layout_gravity de la primera y la tercera. Si el diseño tratara de centrar estas dos vistas tendría que alterar la secuencia en que fueran agregadas, colocando la segunda vista en la parte superior y a continuación, en el centro, la primera y la tercera. Como esto no está permitido, lo que se hace es ignorar esos valores de la gravedad. Lo que sí se podría hacer, en este mismo ejemplo, es aplicar la gravedad center_vertical a todo el contenido del LinearLayout usando el atributo android:gravity. En ese caso, las tres vistas quedarían centradas verticalmente, sin que se alterara el orden en el que fueron agregadas.

En la captura inferior, la que muestra un LinearLayout vertical, también se ve claramente dónde está el problema de aplicar las opciones de alineamiento en la dirección del LinearLayout: si se hiciera caso al valor bottom, el TextView con fondo verde se tendría que colocar en la parte inferior del LinearLayout, quedando debajo del TextView con fondo azul, e invirtiendo el orden en que fueron agregados ambos widgets al diseño.

Peso

Ya hemos comentado que LinearLayout, de forma predeterminada, tiende a repartir el espacio disponible de forma uniforme entre las vistas que tiene que distribuir, asignando un tamaño similar a cada una de ellas (aunque teniendo en cuenta las restricciones que la propia vista imponga).

El peso permite variar este comportamiento, asignando a cada vista un nivel de «importancia» que se traduce en más o menos espacio ocupado en el resultado final, de forma proporcional al valor asignado. El atributo que se utiliza para ello es android:layout_weight.

Si, por ejemplo, asignamos pesos 1, 2 y 3 a tres vistas, LinearLayout tratará de asignar la mitad del espacio disponible a la que tiene peso 3 (3 es la mitad de la suma total de los pesos, que es 6 en este ejemplo). De forma similar, la otra mitad del espacio libre la repartirá entre las otras dos vistas tratando de usar el doble para la que tiene peso 2. La siguiente captura muestra esa situación:

Hay que tener en cuenta que el reparto no es exacto. Incluso si la vista no incluye ninguna restricción especial, como android:minWidth, su contenido puede afectar al espacio que se le asigne finalmente. Android siempre tratará de conseguir la mejor visualización posible para cada vista, aunque tenga que incumplir ligeramente alguna de las restricciones que impongamos.

Si no asignamos peso a una vista se supone que su peso es cero. En este caso su tamaño se determinará con las restricciones habituales, y las vistas con peso se repartirán el resto del espacio de forma proporcional a dicho peso:

El valor del peso es de tipo float, por lo que podemos utilizar decimales si queremos más precisión (y complicarnos la vida innecesariamente).

No es necesario, como se menciona en algunos textos, que la suma de los pesos sea 1. Los pesos pueden sumar cualquier cantidad salvo que se utilice la propiedad android:weightSum de LinearLayout. En ese caso, la suma no podrá superar la cifra que se especifique. Esto puede servir para determinar la proporción que ocupa una vista sin asignar peso a las demás. Por ejemplo, si la suma se establece a 1 y se asigna un peso de 0,3, la vista ocupará el 30% del espacio. No lo usarás a menudo.

Uso de LinearLayout en XML y en Java

Tomemos como ejemplo la interfaz de usuario que se muestra en la siguiente captura, creada mediante la combinación de varios LinearLayout:

El código XML que permite crear ese diseño es el siguiente:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/principal"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical" >

    <LinearLayout
        android:id="@+id/num_telefono"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:baselineAligned="true"
        android:orientation="horizontal" >

        <TextView
            android:id="@+id/telefono"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:paddingLeft="2sp"
            android:paddingRight="2sp"
            android:text="Teléfono:"
            android:textSize="17sp" />

        <EditText
            android:id="@+id/prefijo"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_weight="3"
            android:textSize="17sp" />

        <EditText
            android:id="@+id/numero"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_weight="9"
            android:textSize="17sp" />

    </LinearLayout>

    <LinearLayout
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        android:orientation="vertical" >

        <LinearLayout
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"
            android:orientation="horizontal" >

            <TextView
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:paddingLeft="2sp"
                android:paddingRight="2sp"
                android:text="Descripción:"
                android:textSize="17sp" />

            <TextView
                android:layout_width="fill_parent"
                android:layout_height="wrap_content"
                android:gravity="right"
                android:paddingRight="2sp"
                android:text="OK"
                android:textColor="#00AA00"
                android:textSize="17sp" />

        </LinearLayout>

        <EditText
            android:id="@+id/descripcion"
            android:layout_width="fill_parent"
            android:layout_height="fill_parent" />

    </LinearLayout>

</LinearLayout>

El equivalente en Java es el que se muestra a continuación:

   /** Called when the activity is first created. */
   @Override
   public void onCreate (Bundle savedInstanceState)
   {
      super.onCreate(savedInstanceState);

      DisplayMetrics met = getResources().getDisplayMetrics();

      // Texto "Teléfono:"
      TextView telefono = new TextView(this);
      telefono.setLayoutParams(new ViewGroup.LayoutParams(
         LayoutParams.WRAP_CONTENT,
         LayoutParams.WRAP_CONTENT));
      telefono.setPadding(
         (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_SP, 2, met),
         0,
         (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_SP, 2, met),
         0);
      telefono.setText("Teléfono:");
      telefono.setTextSize(TypedValue.COMPLEX_UNIT_SP, 17);

      // Cuadro de texto para el prefijo
      EditText prefijo = new EditText(this);
      prefijo.setLayoutParams(new LinearLayout.LayoutParams(
         LayoutParams.WRAP_CONTENT,
         LayoutParams.WRAP_CONTENT,
         3));
      prefijo.setTextSize(TypedValue.COMPLEX_UNIT_SP, 17);

      // Cuadro de texto para el número
      EditText numero = new EditText(this);
      numero.setLayoutParams(new LinearLayout.LayoutParams(
         LayoutParams.WRAP_CONTENT,
         LayoutParams.WRAP_CONTENT,
         9));
      numero.setTextSize(TypedValue.COMPLEX_UNIT_SP, 17);

      // Diseño para el número de teléfono
      LinearLayout num_telefono = new LinearLayout(this);
      num_telefono.setLayoutParams(new ViewGroup.LayoutParams(
         LayoutParams.FILL_PARENT,
         LayoutParams.WRAP_CONTENT));
      num_telefono.setBaselineAligned(true);
      num_telefono.setOrientation(LinearLayout.HORIZONTAL);
      num_telefono.addView(telefono);
      num_telefono.addView(prefijo);
      num_telefono.addView(numero);

      // Texto "Descripción:"
      TextView desc = new TextView(this);
      desc.setLayoutParams(new ViewGroup.LayoutParams(
         LayoutParams.WRAP_CONTENT,
         LayoutParams.WRAP_CONTENT));
      desc.setPadding(
         (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_SP, 2, met),
         0,
         (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_SP, 2, met),
         0);
      desc.setText("Descripción:");
      desc.setTextSize(TypedValue.COMPLEX_UNIT_SP, 17);

      // Texto "OK"
      TextView ok = new TextView(this);
      ok.setLayoutParams(new ViewGroup.LayoutParams(
         LayoutParams.FILL_PARENT,
         LayoutParams.WRAP_CONTENT));
      ok.setGravity(Gravity.RIGHT);
      ok.setPadding(
         0,
         0,
         (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_SP, 2, met),
         0);
      ok.setText("OK");
      ok.setTextColor(Color.parseColor("#00AA00"));
      ok.setTextSize(TypedValue.COMPLEX_UNIT_SP, 17);

      // Diseño para la línea de texto
      LinearLayout textos = new LinearLayout(this);
      textos.setLayoutParams(new ViewGroup.LayoutParams(
         LayoutParams.FILL_PARENT,
         LayoutParams.WRAP_CONTENT));
      textos.setOrientation(LinearLayout.HORIZONTAL);
      textos.addView(desc);
      textos.addView(ok);

      // Cuadro de texto para la descripción
      EditText descripcion = new EditText(this);
      descripcion.setLayoutParams(new ViewGroup.LayoutParams(
         LayoutParams.FILL_PARENT,
         LayoutParams.FILL_PARENT));

      // Diseño para la parte inferior
      LinearLayout inferior = new LinearLayout(this);
      inferior.setLayoutParams(new ViewGroup.LayoutParams(
         LayoutParams.FILL_PARENT,
         LayoutParams.FILL_PARENT));
      inferior.setOrientation(LinearLayout.VERTICAL);
      inferior.addView(textos);
      inferior.addView(descripcion);

      // Diseño principal de la actividad
      LinearLayout principal = new LinearLayout(this);
      principal.setLayoutParams(new ViewGroup.LayoutParams(
         LayoutParams.FILL_PARENT,
         LayoutParams.FILL_PARENT));
      principal.setOrientation(LinearLayout.VERTICAL);
      principal.addView(num_telefono);
      principal.addView(inferior);

      setContentView(principal);
   }

La forma de construir el diseño por código es similar a la que ya hemos visto en posts anteriores: primero se crean los widgets, luego el diseño que los contiene directamente y después se añaden los primeros dentro del segundo. Se sigue en sentido ascendente, creando los contenedores superiores e insertando en ellos las vistas que tienen que contener. Lo último que se crea es el diseño principal de la vista, al que se añade todo el contenido. El último paso consiste en asignar ese diseño principal a la vista, con el método setContentView.

Para asignar el peso a los EditText se ha usado la clase LayoutParams que se define en LinearLayout en lugar de la que incluye ViewGroup y que se ha utilizado en el resto de los casos. LinearLayout.LayoutParams proporciona un constructor que, además de los parámetros para el ancho y el alto de la vista, permite especificar un valor para el peso.

Para asignar el padding de los widgets que lo necesitan, se ha utilizado el método setPadding que incluye la clase TextView. A diferencia de la versión XML, en Java no tenemos métodos separados para cada padding y es necesario especificar los cuatro valores en todas las ocasiones. Por suerte, podemos usar el valor cero para los límites en los que no queramos colocar un padding.

En este ejemplo, la gravedad (como propiedad) no la hemos usado en un diseño, sino en un widget. En concreto, en un TextView. Como veremos más adelante, muchos widgets incorporan propiedades similares a las de los diseños. En algunos casos, ambos las heredan de la clase View. En otros casos, como en este, simplemente definen la misma propiedad y con el mismo nombre.

La propiedad android:gravity de TextView funciona exactamente igual y permite los mismos valores que su homóloga en LinearLayout, de la que hemos hablado más arriba. En Java, los posibles valores los proporciona la clase Gravity.

En este caso se ha utilizado la propiedad android:gravity en lugar del parámetro android:layout_gravity porque el TextView que se quería alinear a la derecha está incluido en un LinearLayout horizontal. Como ya hemos explicado, una gravedad horizontal utilizada en un LinearLayout también horizontal se ignora. Para conseguir el efecto deseado (que el texto OK quedara alineado a la derecha) ha sido necesario hacer que el TextView ocupara todo el espacio disponible (atributo android:width con valor FILL_PARENT) y usar gravedad derecha en el contenido.

Por último, para definir el color del texto OK en el código Java se ha utilizado el método parseColor de la clase Color. Este método acepta la misma cadena de texto que permite definir colores en un archivo XML.

Hay, no obstante, otras formas de crear y utilizar colores tanto en XML como en Java. Las veremos en un futuro post.

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80.

En este post me voy a centrar en dos de las más parecidas: ScrollView y HorizontalScrollView. Ambas actúan como contenedores genéricos añadiendo una funcionalidad muy concreta al FrameLayout: desplazamiento.

Veamos cómo funcionan.

ScrollView

ScrollView es una de esas vistas que está a medio camino entre el diseño y el widget. Por un lado, se puede considerar diseño, dado que puede incluir otras vistas e impone ciertas reglas para ubicarlas y dimensionarlas. Pero, por otro lado, también tiene algo de interfaz gráfica (la barra de desplazamiento) y permite interacción con el usuario, como los widgets.

La clasifiquemos como la clasifiquemos, ScrollView es una vista muy interesante: le añade desplazamiento vertical a FrameLayout. Esto nos permite mostrar un contenido de tamaño (altura) superior al que cabría en la pantalla proporcionando al usuario la posibilidad de desplazarse a lo largo de él. Teniendo en cuenta la cantidad de pantallas con tamaños diferentes que pueden tener los dispositivos Android, está claro que esta vista es una de las que más utilizaremos en nuestras aplicaciones.

Veamos cómo usar ScrollView en un diseño XML:

<?xml version="1.0" encoding="utf-8"?>
<ScrollView
   xmlns:android="http://schemas.android.com/apk/res/android"
   android:layout_width="fill_parent"
   android:layout_height="wrap_content"
   android:scrollbars="vertical">
   <LinearLayout
      android:layout_width="fill_parent"
      android:orientation="vertical"
      android:layout_height="fill_parent"
      android:paddingRight="5px" >
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="1" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="2" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="3" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="4" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="5" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="6" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="7" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="8" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="9" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="10" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="11" />
      <EditText
         android:layout_height="wrap_content"
         android:layout_width="fill_parent"
         android:text="12" />
   </LinearLayout>
</ScrollView>

En el ejemplo se muestra el que seguramente será el uso más frecuente de ScrollView: como contenedor de un LinearLayout vertical. Dentro del LinearLayout se incluirán el resto de vistas de la interfaz de usuario. En el ejemplo, unos cuantos EditText que ocupan más del espacio disponible de la pantalla.

Al LinearLayout se le ha añadido un padding derecho para que la barra de desplazamiento se vea mejor al no superponerse a los cuadros de texto. Hay que tener en cuenta que normalmente la barra de desplazamiento no aparece hasta que no desplazamos el dedo por la pantalla. Puedes obtener más información sobre el padding en este post.

La interfaz que se genera es esta:

Veamos ahora cómo generar esa misma interfaz mediante código:

   @Override
   public void onCreate (Bundle savedInstanceState)
   {
      super.onCreate(savedInstanceState);

      LinearLayout ll = new LinearLayout(this);
      ll.setOrientation(LinearLayout.VERTICAL);
      ll.setLayoutParams(new LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT));

      for (int i = 0; i < 12; i++)
      {
         ll.addView(new EditText(this), new LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTENT));
      }

      ScrollView sv = new ScrollView(this);
      sv.setLayoutParams(new LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT));
      sv.setVerticalScrollBarEnabled(true);
      sv.addView(ll);

      setContentView(sv);
   }

Esta vez he utilizado una variante del método addView que hemos usado otras veces, que permite especificar los parámetros de diseño de la vista que se añade en la misma llamada. Eso me permite crear directamente cada EditText en la misma sentencia en la que lo añado al ScrollView. Como todos los EditText del ejemplo son iguales, los creo y añado en un bucle.

Nota

En este código no se añaden los textos numéricos que se han incluido en el XML (y que se pueden observar en la captura). Para añadirlos habría que crear primero cada objeto EditText (fuera de la llamada a addView) y añadirle luego el texto con setText. El contenido del bucle for quedaría así:

         EditText et = new EditText(this);
         et.setText(Integer.toString(i + 1));
         ll.addView(et, new LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTENT));

Propiedades

ScrollView sólo añade una propiedad a las que ya proporciona FrameLayout: android:fillViewport (setFillViewport). Ya hemos visto que ScrollView permite ver el contenido de una vista que tiene una altura superior a la que la pantalla de nuestro dispositivo es capaz de mostrar, pero, ¿qué pasa si el tamaño de la vista es inferior al del espacio disponible?

En este caso, ScrollView se comporta como cualquier otra vista, en función del valor que le demos al parámetro android:layout_height. Lo habitual, en el caso de ScrollView es que usemos el valor wrap_content, lo que hace que el tamaño del diseño se ajuste a su contenido. En esta situación, si el contenido es mayor que el espacio disponible, se mostrará todo lo que quepa permitiendo el desplazamiento. Y si el contenido es menor, el tamaño del diseño se reducirá.

Puede ocurrir que eso no sea lo que queremos. Quizás queramos que alguna vista que hayamos situado en la parte inferior del ScrollView quede alineada con la parte inferior de la pantalla aunque el resto del contenido sea menor que el espacio disponible. Usando wrap_content esas vistas quedarían más arriba.

Un primer impulso puede ser usar fill_parent. Pero eso no produce totalmente el efecto deseado. De hecho, no produce ningún efecto al usarlo en combinación con ScrollView, porque su contenido no tiene el tamaño de la pantalla como límite.

Para alcanzar nuestro objetivo necesitamos una combinación de la propiedad android:fillViewport de ScrollView junto con el parámetro android:layout_weight de LinearLayout. Este último parámetro, que explicaré con más detalle en el post sobre LinearLayout, sirve para que las vistas se repartan el espacio sobrante, hasta ocupar el tamaño máximo que puede tener el LinearLayout. Veamos cómo funciona esta combinación:

En las capturas se muestra un ScrollView que contiene un LinearLayout vertical. Dentro del LinearLayout se incluyen un TextView y un Button. El objetivo es que el botón quede siempre en parte inferior de la pantalla, pero que no se muestre hasta que el usuario desplace el texto hasta el final si resulta ser más largo de lo que se puede mostrar de una sola vez.

Cuando el texto es corto lo normal es que el botón quede justo debajo del texto, como se muestra en la primera captura. Da igual que se use el valor fill_parent para el parámetro android:layout_height del TextView o del propio LinearLayout. Ni siquiera usar el parámetro android:layout_weight en el TextView logra, por sí solo, que se expanda la vista que contiene el texto y desplace el botón hasta la parte inferior de la pantalla.

Por otro lado, si usamos únicamente android:fillViewport en el ScrollView tampoco obtendremos resultado alguno (se seguirá comportando como en la primera captura), salvo que usemos también fill_parent en el parámetro android:layout_height del TextView. En ese caso ocurrirá lo que se muestra en la segunda captura, que tampoco es lo que queremos, porque el botón queda inaccesible.

La única forma de conseguir nuestro objetivo es poner a true la propiedad android:fillViewport del ScrollView y usar el parámetro android:layout_weight en el TextView. En ese caso se verá como en la tercera captura, con el botón en la parte inferior, lo que resulta mucho más estético.

Todo esto sólo tiene utilidad cuando el texto es más corto que lo que la pantalla permite mostrar. Si el texto es largo el botón sólo resultará visible cuando el usuario desplace el ScrollView, y siempre quedará en la parte inferior (como se puede observar en las dos últimas capturas).

La barra de desplazamiento

Las barras de desplazamiento también se controlan mediante propiedades que se traducen en atributos de la vista en el XML. Curiosamente, las propiedades relacionadas con barras de desplazamiento están definidas directamente en la clase View, por lo que, en principio, todas las vistas disponen de ellas.

Esto no significa, obviamente, que todas las vistas tengan funcionalidad de desplazamiento, ni mucho menos. Podemos forzar el uso de la barra de desplazamiento en, por ejemplo, un Button. Incluso podemos conseguir que se muestre dicha barra, haciendo que el contenido sea muy grande. Pero en ningún caso podremos desplazar ese contenido. Y tampoco es que tenga mucho sentido tratar de hacerlo, dicho sea de paso.

Además, aunque la vista pueda tener barras de desplazamiento, puede que no soporte todos los posibles valores de algunas de las propiedades. Por ejemplo, como ScrollView sólo implementa desplazamiento vertical, tratar de mostrar la barra de desplazamiento horizontal no tiene ningún efecto.

Veamos las propiedades que permiten gestionar las barras de desplazamiento:

• android:scrollbarFadeDuration: de forma predeterminada, la barra de desplazamiento sólo se muestra cuando se está arrastrando el contenido de la vista, desapareciendo poco tiempo después. Este atributo permite definir cuánto tiempo (en milisegundos) permanece visible la barra tras el desplazamiento.

• android:fadeScrollbars (setScrollbarFadingEnabled): permite activar o desactivar el desvanecimiento de la barra de desplazamiento. Si se usa con el valor false, las barras se muestran todo el tiempo. Teóricamente se debería poder conseguir el mismo efecto usando el valor cero en android:scrollbarFadeDuration, pero no siempre funciona.

• android:scrollbarSize: permite establecer el ancho de la barra de desplazamiento. Es de tipo dimensión, pero no funciona correctamente en algunas versiones de Android: http://code.google.com/p/android/issues/detail?id=14317.

HorizontalScrollView

Este widget es idéntico a ScrollView, salvo porque el desplazamiento lo realiza horizontalmente en lugar de verticalmente. El resto del comportamiento es idéntico y las propiedades que permiten personalizar ScrollView funcionan de forma idéntica en HorizontalScrollView, por lo que no hay mucho más que añadir aquí.

Doble desplazamiento

Android no dispone de una vista que realice ambos desplazamientos simultáneamente.

Una solución rápida puede ser incluir un HorizontalScrollView dentro de un ScrollView (o viceversa). Sin embargo, eso no provoca totalmente el efecto deseado. El problema es que la barra de desplazamiento forma parte de la vista. Si el HorizontalScrollView está dentro de un ScrollView y su tamaño vertical es superior a lo que se puede visualizar, la barra de desplazamiento del HorizontalScrollView sólo será visible cuando se esté mostrando la parte inferior de la vista:

En cualquier caso, a pesar de que la parte mostrada no incluya la barra de desplazamiento, podremos seguir moviendo el contenido a izquierda y derecha, aunque sin ver dicha barra.

Podemos hacer que el problema pase desapercibido si ocultamos ambas barras de desplazamiento, utilizando la propiedad android:scrollbars en ambas vistas.

La única forma de conseguir una vista contenedora que soporte desplazamiento en ambas direcciones mostrando correctamente las barras es crearnos una nosotros mismos. Eso queda fuera del alcance de este post, pero podéis encontrar una implementación detallada aquí: http://blog.gorges.us/2010/06/android-two-dimensional-scrollview/

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80.

Es el momento ahora de profundizar más en esas vistas, viendo más detalles sobre ellas y ejemplos de uso. Empezaremos por los diseños básicos, dado que será lo primero que tengamos que crear en nuestra actividad, para subdividir el espacio y controlar la ubicación de los widgets. En concreto, comenzaremos por el FrameLayout, el diseño más sencillo de todos los disponibles, pero también el más eficiente.

FrameLayout no realiza ninguna distribución de las vistas, simplemente las coloca unas encima de otras. Esto le evita tener que relacionar los tamaños de unas vistas con los de las demás, por lo que se ahorra recorridos del árbol de vistas, tardando menos en mostrar su contenido.

La gravedad

Que FrameLayout coloque las vistas una sobre otra no significa que todas se alineen automáticamente a la esquina superior izquierda del diseño. Por un lado tenemos el padding. El diseño, al ser una vista, también tiene esa propiedad. Y por otro lado tenemos el margen, si el FrameLayout está contenido en otro diseño que lo soporta. Puedes ver más detalles sobre padding y margen en este post.

Pero, además de todo esto, tenemos un parámetro que nos permite controlar el alineamiento de las vistas contenidas en el diseño: la gravedad. Este parámetro, definido en FrameLayout.LayoutParams, y que se corresponde con el atributo android:layout_gravity no es exclusivo de FrameLayout. LinearLayout también lo proporciona y, por herencia, también TableLayout, TableRow e incluso RadioGroup. Los valores disponibles para el parámetro y el resultado obtenido con cada uno de ellos son comunes para todos estos diseños, por lo que les será de aplicación lo que voy a explicar a continuación.

La gravedad permite indicar cómo se debe alinear la vista sobre la que se aplica, tanto horizontal como verticalmente, en relación a los límites del área disponible para el contenido del FrameLayout. Este área incluye todo el espacio que el FrameLayout ocupa en la actividad menos el padding que se haya establecido.

En la siguiente lista se enumeran algunos de los valores que se pueden utilizar para establecer la gravedad. En el archivo XML, al atributo android:layout_gravity se le asigna una cadena de texto que contiene uno o más de estos valores. Si hay más de uno se separan mediante |. Para cada uno de estos valores existe una constante de igual nombre que se puede utilizar para asignar la gravedad mediante código Java. De forma similar, si en Java usa más de una constante, se agregan mediante el operador lógico |:

En el siguiente ejemplo podemos ver el funcionamiento de las primeras constantes enumeradas:

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout
   xmlns:android="http://schemas.android.com/apk/res/android"
   android:layout_width="fill_parent"
   android:layout_height="fill_parent">
   <TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="Sin gravedad"
      android:textSize="23sp"
      android:background="#080" />
   <TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="right"
      android:background="#080"
      android:textSize="23sp"
      android:layout_gravity="right" />
   <TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="bottom"
      android:background="#080"
      android:textSize="23sp"
      android:layout_gravity="bottom" />
   <TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="bottom|right"
      android:background="#080"
      android:textSize="23sp"
      android:layout_gravity="bottom|right" />
   <TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="center_vertical"
      android:background="#080"
      android:textSize="23sp"
      android:layout_gravity="center_vertical" />
   <TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="center_horizontal"
      android:background="#080"
      android:textSize="23sp"
      android:layout_gravity="center_horizontal" />
</FrameLayout>

Este ejemplo genera la siguiente interfaz de usuario:

La gravedad puede tomar más valores que los descritos aquí, pero su funcionamiento es algo más complejo, por lo que los trataré con detalle en un futuro post.

Crear FrameLayout por código

Ya hemos visto en el ejemplo de uso del parámetro gravedad cómo se utiliza el diseño FrameLayout en XML. Veamos ahora cómo crear esa misma interfaz de usuario por código:

   @Override
   public void onCreate (Bundle savedInstanceState)
   {
      super.onCreate(savedInstanceState);

      TextView tv1 = new TextView(this);
      tv1.setLayoutParams(new ViewGroup.LayoutParams(
         ViewGroup.LayoutParams.WRAP_CONTENT,
         ViewGroup.LayoutParams.WRAP_CONTENT));
      tv1.setText("Sin gravedad");
      tv1.setTextSize(TypedValue.COMPLEX_UNIT_SP, 23);
      tv1.setBackgroundColor(Color.rgb(0, 136, 0));

      TextView tv2 = new TextView(this);
      tv2.setLayoutParams(new FrameLayout.LayoutParams(
         ViewGroup.LayoutParams.WRAP_CONTENT,
         ViewGroup.LayoutParams.WRAP_CONTENT,
         Gravity.RIGHT));
      tv2.setText("right");
      tv2.setTextSize(TypedValue.COMPLEX_UNIT_SP, 23);
      tv2.setBackgroundColor(Color.rgb(0, 136, 0));

      TextView tv3 = new TextView(this);
      tv3.setLayoutParams(new FrameLayout.LayoutParams(
         ViewGroup.LayoutParams.WRAP_CONTENT,
         ViewGroup.LayoutParams.WRAP_CONTENT,
         Gravity.BOTTOM));
      tv3.setText("bottom");
      tv3.setTextSize(TypedValue.COMPLEX_UNIT_SP, 23);
      tv3.setBackgroundColor(Color.rgb(0, 136, 0));

      TextView tv4 = new TextView(this);
      tv4.setLayoutParams(new FrameLayout.LayoutParams(
         ViewGroup.LayoutParams.WRAP_CONTENT,
         ViewGroup.LayoutParams.WRAP_CONTENT,
         Gravity.BOTTOM | Gravity.RIGHT));
      tv4.setText("bottom|right");
      tv4.setTextSize(TypedValue.COMPLEX_UNIT_SP, 23);
      tv4.setBackgroundColor(Color.rgb(0, 136, 0));

      TextView tv5 = new TextView(this);
      tv5.setLayoutParams(new FrameLayout.LayoutParams(
         ViewGroup.LayoutParams.WRAP_CONTENT,
         ViewGroup.LayoutParams.WRAP_CONTENT,
         Gravity.CENTER_VERTICAL));
      tv5.setText("center_vertical");
      tv5.setTextSize(TypedValue.COMPLEX_UNIT_SP, 23);
      tv5.setBackgroundColor(Color.rgb(0, 136, 0));

      TextView tv6 = new TextView(this);
      tv6.setLayoutParams(new FrameLayout.LayoutParams(
         ViewGroup.LayoutParams.WRAP_CONTENT,
         ViewGroup.LayoutParams.WRAP_CONTENT,
         Gravity.CENTER_HORIZONTAL));
      tv6.setText("center_horizontal");
      tv6.setTextSize(TypedValue.COMPLEX_UNIT_SP, 23);
      tv6.setBackgroundColor(Color.rgb(0, 136, 0));

      FrameLayout fl = new FrameLayout(this);
      fl.addView(tv1);
      fl.addView(tv2);
      fl.addView(tv3);
      fl.addView(tv4);
      fl.addView(tv5);
      fl.addView(tv6);

      setContentView(fl);
   }

En el código se observa cómo se crean primero los TextView y luego el FrameLayout. Los TextView se añaden al FrameLayout y después se asigna el diseño a la actividad para que se muestre. Se puede observar también cómo la gravedad se asigna a cada widget como parámetro, creando un FrameLayout.LayoutParams y pasándosela al constructor. Además, no es necesario asignar las constantes fill_parent a los atributos correspondientes del FrameLayout porque ese es el valor que tienen de forma predeterminada.

Conviene aclarar que los valores 0, 136 y 0 que se le pasan al método rgb de la clase Color, son los equivalentes decimales a la cadena hexadecimal que hemos utilizado en el archivo XML: #080. La conversión no es directa porque en XML hemos usado el formato #RGB, que sólo emplea un dígito hexadecimal para cada color. En este caso, los valores posibles para cada color oscilan entre 0 y 15. Sin embargo, los valores que admite el método rgb oscilan entre 0 y 255, por lo que la conversión se ha tenido que hacer de forma proporcional.

Finalmente, comentar que la clase TextView dispone de un método setTextSize que permite especificar una dimensión junto con sus unidades para establecer el tamaño del texto. De esta forma nos ahorramos tener que calcular primero los píxeles equivalentes utilizando los métodos que vimos en el post dedicado a las dimensiones.

En el próximo post veremos algunas especializaciones del FrameLayout: clases que heredan de este diseño, incorporando su funcionalidad básica y añadiendo funcionalidad particular.

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80.

Aunque en todo momento hemos ido relacionando los elementos que se utilizan en XML con clases y métodos Java, lo cierto es que a la hora de proponer ejemplos me he limitado a mostrar código XML. No hemos visto cómo utilizar esos archivos XML en un proyecto ni cómo crear esas mismas interfaces directamente en Java. En este post voy a poner remedio a ambas cosas.

Utilizar el diseño en una actividad

En el post sobre diseño en XML utilizamos como ejemplo el código que se muestra en la siguiente captura:

Si queremos utilizar este diseño necesitamos un proyecto y una actividad. Ya vimos en un post anterior cómo crear un proyecto. Veamos ahora cómo agregar una nueva actividad:

Crear una nueva actividad en el proyecto no nos añade un diseño XML (porque no es algo obligatorio), por lo que tendremos que agregarlo nosotros siguiendo los siguientes pasos:

Como lo que queremos es escribir directamente el código (o copiarlo del otro post), tenemos que pulsar sobre la pestaña inferior con el nombre del archivo, a la derecha de Graphical Layout, para mostrar el editor de código XML. Ahora sólo nos queda reemplazar el código que se genera de forma predeterminada por el nuestro y guardar el archivo.

El lugar adecuado para cargar el diseño es, como ya vimos, el método onCreate. El código necesario para que el diseño que hemos creado en XML se muestre en la actividad es el siguiente, asumiendo que hemos guardado el XML anterior en la carpeta res/layout con el nombre prueba.xml:

/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState)
{
   super.onCreate(savedInstanceState);
   setContentView(R.layout.prueba);
}

Para ver el resultado tenemos que asegurarnos de que la nueva actividad se muestre cuando se inicie la aplicación. Eso se controla en el manifiesto de la aplicación. Tenemos dos formas de hacerlo: usando el editor visual o modificando directamente el código. Veamos como se hace con el editor:

Si pulsamos en la última pestaña inferior, AndroidManifest.xml, podemos ver el código XML que se ha creado:

<activity android:name="IUIntroXML">
   <intent-filter>
      <action android:name="android.intent.action.MAIN"></action>
      <category android:name="android.intent.category.LAUNCHER"></category>
   </intent-filter>
</activity>

Se puede observar claramente que el código reproduce la estructura que hemos ido creando. Podemos, por tanto, conseguir lo mismo añadiendo esas mismas líneas (el <intent-filter> y su contenido) a cualquier actividad que tengamos en la aplicación. Además, aunque lo habitual es que sólo una de ellas esté configurada para ser actividad de inicio, podemos tener este Intent Filter en varias actividades a la vez. En esta situación, cualquiera de las actividades marcada con la acción MAIN puede ser la primera que se muestre al iniciar la aplicación. Y cualquier actividad con la categoría LAUNCHER tendrá un icono en el lanzador de aplicaciones del dispositivo cuando la instalemos.

Creando la interfaz de usuario por código

Para terminar este post, veamos el código que permite crear el mismo diseño que el archivo XML mostrado arriba, pero sin utilizarlo:

/** Called when the activity is first created. */
@Override
public void onCreate (Bundle savedInstanceState)
{
   super.onCreate(savedInstanceState);

   TextView etiqueta1 = new TextView(this);
   etiqueta1.setText("Esto es una etiqueta de texto");
   etiqueta1.setLayoutParams(new LayoutParams(
      LayoutParams.WRAP_CONTENT,
      LayoutParams.WRAP_CONTENT));

   Button boton1 = new Button(this);
   boton1.setText("Esto es un botón");
   boton1.setLayoutParams(new LayoutParams(
      LayoutParams.WRAP_CONTENT,
      LayoutParams.WRAP_CONTENT));

   LinearLayout principal = new LinearLayout(this);
   principal.setOrientation(LinearLayout.VERTICAL);
   principal.setLayoutParams(new LayoutParams(
      LayoutParams.FILL_PARENT,
      LayoutParams.FILL_PARENT));
   principal.addView(etiqueta1);
   principal.addView(boton1);

   setContentView(principal);
}

Se crea un objeto para cada una de las vistas. En el constructor se pasa la propia actividad (this) como contexto. La vista la necesita para acceder a sus recursos.

Las propiedades de cada vista se modifican con los métodos set correspondientes. Los parámetros, como ya hemos mencionado en posts anteriores, son diferentes. Se asignan mediante el método setLayoutParams utilizando una clase LayoutParams. En este caso se ha usado la versión más general, definida como clase anidada en ViewGroup, en lugar de la específica del LinearLayout (que tiene el mismo nombre: LayoutParams).

Una vez creadas las tres vistas, se añaden los widgets al diseño, en el mismo orden en que se pusieron en el archivo XML, dado que es el orden en que queremos que se muestren. Para ello se utiliza el método addView que proporciona la clase ViewGroup.

Finalmente se asigna el diseño a la actividad, utilizando una sobrecarga del mismo método setContentView que usamos para cargar el diseño XML.

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80

Están formadas por un valor numérico con decimales (float) y una cadena de texto de dos caracteres que representa la unidad en la que se expresa el valor numérico. En el archivo XML ambos datos se escriben juntos, en una sola cadena de texto, sin espacio o separadores entre ellos.

La ventaja que representan es que la mayoría de las unidades son relativas, tanto a características físicas del dispositivo en el que se están utilizando, como a diversos elementos de estilo que estén activos en un momento dado. Esto permite que unos mismos valores utilizados en un diseño sean traducidos a tamaños diferentes en cada dispositivo en que se ejecute la aplicación, de forma que la experiencia del usuario sea similar.

Si usáramos siempre medidas expresadas en píxeles podría ocurrir que un elemento que tiene un tamaño adecuado para su uso en un dispositivo en particular se viera demasiado pequeño en otro dispositivo con mayor densidad de píxeles (cantidad de píxeles por cada pulgada de pantalla).

Queda claro que las dimensiones las vamos a utilizar bastante, así que veamos cómo hacerlo.

Unidades

Las que se enumeran a continuación son las diferentes unidades que podemos utilizar para definir dimensiones:

Uso de dimensiones en XML

Las dimensiones se pueden utilizar directamente en los atributos en forma de cadena de texto. Por ejemplo:

<EditText
   android:layout_width="wrap_content"
   android:layout_height="wrap_content"
   android:minWidth="160sp" />

Sin embargo es muy frecuente utilizar la misma dimensión para más de una vista, por lo que resulta más práctico usar un archivo de recursos. Como las dimensiones son recursos simples, el archivo habrá que crearlo en res/values. La sintaxis básica es la siguiente:

<?xml version="1.0" encoding="utf-8"?>
<resources>
   <dimen name="nombre_de_la_dimensión">valor</dimen>
</resources>

El nombre es el identificador que usaremos en los atributos a los que queramos asignarles la dimensión y el valor es la cadena que habríamos usado directamente (pero sin comillas). Por ejemplo:

<?xml version="1.0" encoding="utf-8"?>
<resources>
   <dimen name="cuadros_texto">160sp</dimen>
</resources>

Podemos definir más de una dimensión en un mismo archivo XML, simplemente añadiendo más elementos <dimen> dentro de <resources>. Para usarlas luego en atributos se utiliza el nombre asignado a la dimensión (que actúa de identificador):

<EditText
   android:layout_width="wrap_content"
   android:layout_height="wrap_content"
   android:minWidth="@dimen/cuadros_texto" />

Usar dimensiones en Java

Si definimos dimensiones en un archivo XML de recursos, el compilador añadirá las constantes correspondientes a la clase R, tal y como hace con los identificadores de las vistas. Podemos utilizar estas constantes para acceder a las dimensiones desde el código utilizando el método getDimensionPixelSize de la clase Resources. Se haría así:

EditText et = new EditText(this);
et.setLayoutParams(new LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT, ViewGroup.LayoutParams.WRAP_CONTENT));
Resources res = getResources();
et.setMinimumWidth(res.getDimensionPixelSize(R.dimen.cuadros_texto));

Primero hay que obtener un objeto de la clase Resources. El método getResources que la clase Activity hereda de Context lo proporciona. Este objeto contiene la información necesaria sobre la pantalla en la que se muestra la actividad como para poder convertir cualquier dimensión relativa en un valor en píxeles, que es lo que esperan la mayoría de los métodos.

La clase Resources tiene también un método getDimension que devuelve la misma información. La diferencia es que el método getDimensionPixelSize procesa el valor que devuelve getDimension para que se pueda usar con seguridad como tamaño. Hace dos cosas: redondear el valor devuelto por getDimension y, si el valor resultante es cero, sustituirlo por 1.

Por otro lado, también es posible utilizar dimensiones en Java sin definirlas previamente en XML. El siguiente ejemplo sería equivalente al que hemos visto antes:

EditText et = new EditText(this);
et.setLayoutParams(new LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT, ViewGroup.LayoutParams.WRAP_CONTENT));
int valor = (int) TypedValue.applyDimension(
   TypedValue.COMPLEX_UNIT_SP,
   (float) 160,
   getResources().getDisplayMetrics());
et.setMinimumWidth(valor);

El método applyDimension de la clase TypedValue permite convertir una dimensión en su equivalente en píxeles según el contexto actual (el contexto contiene, básicamente, las características de la pantalla donde se va a mostrar la actividad).

TypedValue es una clase que permite crear objetos con tipos dinámicos, por lo que comúnmente se utiliza para almacenar recursos XML en Java. La clase incluye una serie de constantes que permiten asociar un tipo a un valor numérico, como las unidades en el caso de las dimensiones. En el ejemplo hemos utilizado la constante COMPLEX_UNIT_SP para indicar que el valor 160 que le pasamos al método applyDimension está expresado en píxeles independientes de la escala.

Como se puede ver, podemos utilizar dimensiones sea cual sea la forma en que escojamos crear nuestras interfaces de usuario, por lo que no hay excusas para no aprovechar este recurso que nos ayuda a que nuestra aplicación se vea como realmente queremos en cualquier tipo de dispositivo.

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80.

Echamos en falta rápidamente una forma de dejar algo de espacio entre las vistas o de alejar su contenido de los bordes. Y para ello Android nos proporciona dos tipos de propiedades, padding y margen (margin). Las dos tienen una función similar, pero la realizan de diferente forma. La principal diferencia es que el padding forma parte de la vista y el margen del diseño. Este detalle, aparte de influir sobre en qué clase se incluyen las propiedades, determina dónde se sitúa ese espacio adicional que añaden. Mientras que el padding es un espacio situado entre el borde de la vista y su contenido, el margen se sitúa entre el borde de la vista y los bordes de los elementos que la rodean o del diseño que la contiene.

Seguramente quede más claro con la siguiente captura:

El fondo (background) de todos los TextView de esta interfaz se ha establecido en verde, por lo que cada recuadro verde muestra el área total que está ocupando la vista, sus límites. Se puede observar como, si no utilizamos ni padding ni margen (segunda fila), el tamaño de cada vista se ajusta completamente al contenido y las vistas quedan totalmente pegadas unas a otras. Cuando usamos padding (filas 1 y 3) añadimos un espacio entre el texto y los límites de la vista (espacio que se rellena con el fondo). Por su parte, el margen (filas 1 y 4) agrega ese espacio alrededor de los límites de la vista pero por fuera de ella, provocando que las vistas se separen unas de otras y de los bordes de los LinearLayout que las contienen (y permitiendo que se vea el fondo del diseño, azul o rojo en la interfaz de ejemplo). Finalmente, la captura también demuestra que se pueden utilizar las dos propiedades a la vez (fila 1) y el resultado que proporcionan.

El padding es una propiedad de las vistas, como vimos en un post anterior. El margen, al ser externo a las vistas, se deja en mano de los contenedores de vistas, por lo que se implementa como parámetro de los diseños. Sin embargo ambas se utilizan de forma muy similar. Veamos cómo:

Padding

El padding, como propiedad de la clase View, es compartida por todas las vistas, ya sean widgets o diseños. Está formada, en realidad, por cuatro propiedades, una para cada lateral de la vista. En XML se accede a estas propiedades mediante los atributos android:paddingLeft, android:paddingRight, android:paddingTop y android:paddingBottom de las vistas. Estos atributos permiten establecer un valor distinto para cada uno de los laterales o dejar alguno sin asignar. De forma predeterminada, cada una de estas propiedades tiene el valor cero.

En el diseño XML tenemos disponible también el atributo android:padding, que permite establecer el padding de todos los laterales a la vez. Este atributo nos permite ahorrar código cuando queremos que el padding de los cuatro laterales tenga el mismo tamaño.

Para modificar el padding por código disponemos del método setPadding (definido en la clase View). Este método recibe obligatoriamente cuatro valores, que se corresponden con los laterales izquierdo, superior, derecho e inferior, respectivamente. No disponemos de sobrecargas del método setPadding, por lo que siempre tendremos que especificar los cuatro valores cuando asignemos el padding desde Java.

No es la única diferencia entre el uso del padding desde XML y desde Java. Los atributos XML tienen un valor de tipo dimensión. Las dimensiones son un tipo de recurso que incluyen un valor numérico y una unidad. Esto permite definir el padding en términos de píxeles, de medidas físicas como milímetros o pulgadas o incluso de medidas abstractas relativas a la densidad de píxeles de la pantalla o al tamaño de la fuente que se utiliza en la vista. Para más detalles, consulta este post.

Sin embargo, los parámetros del método setPadding son de tipo int y no admiten unidades. Así, en Java sólo se puede establecer el padding en píxeles. No obstante, también hay una forma de calcular en Java los píxeles a los que equivale cualquier dimensión. Lo veremos en un próximo post.

La clase View dispone también de los métodos getPaddingLeft, getPaddingRight, getPaddingTop y getPaddingBottom, que permiten obtener el padding actual de cada lateral de la vista, en píxeles. Hay que tener en cuenta que algunas vistas pueden dejar un espacio adicional para una barra de desplazamiento (suponiendo que la vista admita el uso de barras de desplazamiento y se esté utilizando un estilo para las mismas que requiera espacio adicional). Si es el caso, el valor devuelto por estos métodos get puede no corresponderse con el establecido mediante los atributos XML o el método setPadding.

Margen

Como ya hemos visto, los márgenes son externos a la vista a la que se le aplican. Por lo tanto, no es de extrañar que no sean propiedades de la clase View como ocurre con el padding. En lugar de eso, son parámetros de los diseños.

En un post anterior vimos que los diseños comparten unos parámetros básicos que se definen en la clase ViewGroup.LayoutParams. También que cada diseño define su propia clase LayoutParams que hereda de la de ViewGroup. Lo que no mencioné es que esa herencia no es directa.

Dentro de la clase ViewGroup se define otra clase con parámetros. Se trata de MarginLayoutParams. Esta clase hereda a su vez de ViewGroup.LayoutParams. Las clases de parámetros que se definen en los diseños heredan (directa o indirectamente) de esta clase MarginLayoutParams. De esta forma se agregan los márgenes a los parámetros básicos que comparten todos los diseños.

Al igual que con el resto de parámetros de diseño, los atributos XML correspondientes se aplican sobre las vistas contenidas en el diseño como si fueran propiedades propias. Y, de igual forma, los atributos de MarginLayoutParams también se distinguen mediante el prefijo layout_.

Para establecer los márgenes de cada vista, la clase MarginLayoutParams proporciona los atributos android:layout_marginLeft, android:layout_marginRight, android:layout_marginTop y android:layout_marginBottom. Al igual que con el padding, estos atributos permiten establecer valores de margen diferentes para cada lateral de la vista. También en este caso tenemos un atributo android:layout_margin que permite establecer el mismo valor para el margen de los cuatro laterales a la vez.

Siguiendo con las similitudes, la clase MarginLayoutParams proporciona un método setMargins que permite asignar valores a los márgenes de los laterales izquierdo, superior, derecho e inferior de la vista. Por supuesto, todo lo explicado sobre dimensiones y valores en píxeles para el padding se aplica exactamente igual para el margen.

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80.

En este post vamos a profundizar algo más en los diseños viendo, sobre todo, qué cosas tienen en común, antes de entrar en detalles particulares de cada uno de los tipos que tenemos disponibles.

Diseños

A diferencia de la mayoría de los widgets, los diseños no heredan directamente de la clase View, sino que heredan de la clase ViewGroup que, a su vez, hereda de View. De esta forma, los diseños tienen todas las propiedades de las vistas (puesto que son también vistas) y, al mismo tiempo, heredan todo lo que ofrece ViewGroup.

ViewGroup no es sólo la clase madre de los diseños, sino que aparece entre los ancestros de cualquier vista que pueda contener a otras, aunque no sean propiamente diseños. Esto conviene aclararlo. Llamamos diseños a las vistas que no sólo pueden contener otras vistas, sino que, además, se encargan de distribuirlas en la actividad, controlando su posición y dimensiones, de acuerdo a unas reglas establecidas.

Sin embargo hay otras vistas, como ListView, Gallery o DatePicker, que también contienen otras vistas. Lo que ocurre es que en estos casos, los tipos de vistas que pueden contener o la forma en que se distribuyen está muy limitada o es fija. Los diseños son bastante más flexibles.

Al igual que la clase View, la propia clase ViewGroup también proporciona algunas propiedades a los diseños. Sin embargo, no son propiedades que se utilicen con frecuencia por lo que no hablaré de ellas por el momento.

Los parámetros de los diseños

De lo que sí voy a hablar ahora es de una clase que se define dentro de la clase ViewGroup y que tiene suma importancia: ViewGroup.LayoutParams. Esta clase también define propiedades que luego se pueden usar como atributos en los archivos XML donde se definen los diseños. La diferencia radica en que estos atributos no se aplican sobre los diseños, sino sobre las vistas que contienen.

Nota

El compilador nos permite asignar valores a estos parámetros por medio de atributos en las etiquetas de las vistas como si fueran propiedades propias. Pero no debemos olvidar que siguen siendo parámetros del diseño y que es éste el que condiciona cuáles tenemos disponibles en cada caso.

Podemos tener, por ejemplo, dos Button idénticos, uno en un RelativeLayout y otro en un LinearLayout. Si el parámetro alignTop sólo está definido en el diseño RelativeLayout, el atributo correspondiente, android:layout_alignTop, sólo lo podremos usar en el <Button> que esté dentro del <RelativeLayout> y no en el otro.

El compilador recopila los valores de todos estos atributos y los encapsula en un objeto de esta clase ViewGroup.LayoutParams. Luego asigna ese objeto a la vista mediante el método setLayoutParams. Este método se define en la clase View, por lo que todas las vistas lo heredan. Posteriormente, el diseño recupera los valores de estos parámetros de las vistas y los utiliza para calcular dónde debe situar cada una de ellas y con qué dimensiones.

Todo esto nos proporciona una forma sencilla de asociar a cada vista la información necesaria para que el diseño que la contiene trabaje con ella. Y, aún más, el mecanismo de herencia de Java permite que cada diseño proporcione sus parámetros particulares haciendo que estén disponibles para todas las vistas que se incluyan en él.

Cada diseño, además de heredar de ViewGroup, también proporcionará su propia clase LayoutParams, cada una de las cuales heredará de ViewGroup.LayoutParams. Para seguir el mismo esquema, estas clases estarán definidas dentro de la clase que implementa el diseño. Por ejemplo, el diseño RelativeLayout tendrá asociada una clase RelativeLayout.LayoutParams.

Como estas clases heredan de ViewGroup.LayoutParams, dispondrán de entrada de todos los parámetros que se definen aquí. Además, las propiedades de la herencia en Java nos permiten asignar objetos de una clase hija a variables de la clase madre. Esto significa que se puede utilizar el método setLayoutParams de la clase View (disponible en todas las vistas) para asignar un objeto de una clase derivada de ViewGroup.LayoutParams como, por ejemplo, RelativeLayout.LayoutParams.

De esta forma podemos tener los parámetros particulares de cualquier diseño disponibles en todas las vistas. El compilador se encargará del resto, permitiéndonos usar los atributos XML relacionados en cada vista que incluyamos en el diseño.

Las dimensiones de una vista

Ya hemos visto que los parámetros que se definen en ViewGroup.LayoutParams van a formar parte de los parámetros de todos los diseños, pero ¿cuáles son esos parámetros?

Pues básicamente dos: ancho y alto, representados por los atributos XML android:layout_width y android:layout_height.

Nota

El prefijo layout_ es una forma de distinguir los atributos propios de las vistas de los parámetros de los diseños. Las ayudas a la codificación del editor en Eclipse nos permiten saber qué parámetros tenemos disponibles en cada vista concreta escribiendo android:layout_ y pulsando Ctrl + Espacio:

El objetivo de estos dos parámetros es proporcionar a las vistas una forma de indicar cuáles deben ser sus dimensiones en relación al diseño que las contiene. Todas las vistas están obligadas a definirlos, dado que el diseño no podría visualizarlas sin esta información. Se les puede asignar un valor de tipo dimensión o una de las constantes predefinidas.

Una dimensión es un valor numérico que va acompañado de una cadena de texto que indica la unidad en la que se expresa dicho valor numérico. Por ejemplo, «20px» significa 20 píxeles y «10mm» indica 10 milímetros. Puedes ver más detalles sobre las dimensiones y las unidades que tenemos disponibles en este post. Por el momento nos basta con saber que asignar una dimensión a uno de estos atributos sirve para especificar un tamaño fijo para el ancho o el alto de la vista.

Fijar el tamaño de las vistas no suele ser muy recomendable si pretendemos que nuestra aplicación se vea bien en todo tipo de pantallas. Para estas situaciones disponemos de dos constantes que le dicen al diseño cómo debe dimensionar la vista sin dar valores exactos:

Un apunte sobre fill_parent

Desde la versión 8 de la API de Android, que se corresponde con la versión 2.2 del sistema operativo, la constante fill_parent se considera obsoleta (deprecated). En su lugar hay que utilizar match_parent. Es simplemente un cambio de nombre, la funcionalidad es la misma.

Esto significa que si programamos con versiones anteriores de la API tenemos que utilizar obligatoriamente fill_parent y que si lo hacemos con la 8 o posterior deberíamos usar match_parent, aunque podemos seguir usando fill_parent hasta que una futura versión de la API la elimine.

En cualquier caso, como el valor de ambas constantes es el mismo, usar match_parent no impedirá en ningún caso el correcto funcionamiento de la aplicación en una versión de Android anterior a la 2.2.

Hay que tener en cuenta que estos parámetros no son los únicos atributos que usa el diseño para decidir las dimensiones de las vistas. Hay otros atributos, como android:minWidth y android:minHeight que también se tienen en cuenta. Esto sirve, por ejemplo, si usamos la constante wrap_content con el ancho de un EditText, que no suele tener una cadena asignada. Si no definimos un ancho mínimo con android:minWidth, el diseño mostrará una vista realmente pequeña:

Anidación de diseños

En realidad decidir el tamaño de cada vista es algo bastante más complejo, y no sólo porque algunos diseños añaden numerosos parámetros a tener en cuenta a la hora de determinar dónde y con qué tamaño colocar cada vista. También está el hecho de que los diseños se pueden incluir unos dentro de otros, a distintos niveles de profundidad y mezclándose con widgets en cada uno de ellos. Esto da lugar a una estructura de árbol donde la raíz es el primer diseño que se añade a la actividad y que se puede extender por numerosas ramas.

Todo esto obliga al sistema a realizar varios recorridos por este árbol, recogiendo información de cada diseño y widget y relacionándola entre sí, para acabar asignando unas coordenadas y unas dimensiones a cada una de las vistas. Algo imprescindible para poder mostrar la actividad.

Por ejemplo, un diseño también puede usar la constante wrap_content en sus propios atributos. En este caso, para poder determinar el tamaño del diseño es necesario conocer primero el de las vistas que contiene. Para ello hay que ir descendiendo en el árbol hasta llegar a vistas con tamaño fijo o determinable directamente a partir de sus propiedades. Una vez asignado el tamaño de las hojas se puede recorrer el árbol hacia arriba para asignar el de las ramas.

Pero no siempre es tan sencillo. Los atributos que sólo determinan tamaños mínimos requieren conocer qué otras vistas compiten por el espacio y qué dimensiones pretenden tener para determinar qué tamaño se asigna finalmente a cada una. Esto obliga a hacer otra pasada más por todo el árbol.

El objetivo de explicar todo esto es que comprendas que los diseños que escojas y la cantidad de niveles en que los anides pueden tener un impacto tremendo en el tiempo que se tarda en mostrar la actividad. Hay muchas situaciones en las que se puede conseguir la misma interfaz de usuario utilizando menos diseños o usando otros más óptimos. Para saber qué utilizar en cada caso hay que conocer a fondo cada diseño. Por eso dedicaré en breve unos cuantos posts a hablar sobre cada uno de los diseños disponibles en la API de Android. También publicaré más adelante otro post sobre optimización de interfaces de usuario.

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80.

En este post vamos a ver cómo se crean todos estos elementos y qué propiedades tienen en común. Más adelante veremos cómo, una vez creados, los incluimos y mostramos en nuestras actividades.

Podemos crear widgets y diseños tanto por código como utilizando archivos de recursos en XML situados en la carpeta layouts. Ni qué decir tiene que es preferible optar por la segunda opción, que no sólo permite tener una vista previa aproximada de la interfaz en tiempo de codificación, sino también disponer de diferentes interfaces de usuario para una misma actividad. Esto permite escoger la más adecuada en tiempo de ejecución en función del tamaño de la pantalla o del idioma que tenga configurado el dispositivo, por ejemplo.

Aunque me centraré en los recursos XML, también iré mencionando los elementos Java que se corresponden con ellos. En este otro post explico cómo se crean interfaces de usuario completas por código.

Diseño en XML

Para empezar, veamos un pequeño ejemplo de interfaz de usuario creada en XML:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/principal"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical">
    <TextView
        android:id="@+id/etiqueta1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Esto es una etiqueta de texto">
    </TextView>
    <Button
        android:id="@+id/boton1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Esto es un botón">
    </Button>
</LinearLayout>

Se trata de un diseño LinearLayout vertical que ocupa todo el área disponible de la actividad y que contiene dos widgets: una etiqueta de texto y un botón. Este diseño genera la interfaz de usuario que se muestra en las siguientes capturas. Hay que tener en cuenta que el aspecto de los widgets depende la versión de Android que utilicemos, por lo que variará de un dispositivo a otro o de un emulador a otro. La captura de la izquierda está hecha con Android 1.5 y la de la derecha con la versión 2.3:

La estructura del archivo XML es de tipo árbol, con un elemento principal que hace de raíz y una serie de elementos que se incluyen unos dentro de otros a diferentes niveles de profundidad. Lo más importante aquí es que sólo tenemos un elemento raíz del que dependerán, directa o indirectamente, el resto de vistas. Lo habitual es que ese elemento sea un diseño que define la organización principal de la actividad y que contiene el resto de diseños y widgets. No obstante, también podría ser un widget, si es lo único que necesita la actividad.

En el ejemplo, la raíz es un LinearLayout vertical, definido con la etiqueta XML <LinearLayout>. Por comodidad, la mayoría de etiquetas y atributos de los archivos XML se llaman de forma idéntica a las clases y propiedades con que se corresponden (aunque hay excepciones). Dentro de la etiqueta <LinearLayout> se incluyen otras dos, <TextView> y <Button>, que se corresponden con los widgets del mismo nombre (la etiqueta de texto y el botón que se muestran en las capturas).

Una pequeña aclaración

En Android se utiliza el término diseño (layout) para referirse tanto a la vista que contiene otras vistas y se encarga de organizarlas y dimensionarlas, como al conjunto de vistas (incluyendo widgets y diseños) que se muestran en una actividad. Por este motivo la carpeta en la que se incluyen los archivos XML como el de arriba se llama también layout.
En este blog utilizaré el término diseño para referirme a ambas cosas indistintamente. Espero que el contexto deje claro de qué estoy hablando en cada momento.

Propiedades de las vistas

El aspecto y el comportamiento de las vistas, tanto diseños como widgets, se pueden personalizar mediante propiedades. En el archivo XML las propiedades se representan mediante atributos de las etiquetas que se corresponden con las vistas. En la API, las propiedades son atributos privados o protegidos de las clases que implementan las vistas.

Para modificar una propiedad sólo tenemos que darle un valor al atributo correspondiente, incluyéndolo dentro de la etiqueta XML que representa la vista. Sin embargo, por código no podemos hacer lo mismo, dado que los atributos privados o protegidos no son accesibles y el lenguaje java no permite definir propiedades en las clases como hacen otros lenguajes (C#, por ejemplo). Por este motivo, cada atributo XML se suele corresponder con un método de la clase cuyo nombre coincide (casi siempre) con el del atributo, pero con la cadena set como prefijo. Este prefijo es una convención habitual para indicar que el método sirve para establecer el valor de un atributo de la clase. Si la clase permite también recuperar el valor del atributo, existirá un método similar con prefijo get.

Hay que tener en cuenta, que cuando hablo del nombre del atributo me refiero a lo que va a continuación de android:. Este prefijo que llevan todos los atributos del archivo XML es el espacio de nombres en el que se definen. Sin entrar en muchos detalles (no es el objetivo de este post) los espacios de nombres en XML tienen una función similar a la de los paquetes en Java (salvando las distancias): permiten definir símbolos dentro de un ámbito de forma que no tengan conflictos, por tener el mismo nombre, con los de otro ámbito. Los espacios de nombres se definen en esquemas XML que incluyen las etiquetas disponibles, los atributos que puede tener cada etiqueta y qué etiquetas pueden estar contenidas dentro de otras. En nuestro archivo XML, anteponer el prefijo android: sirve para especificar el espacio de nombres donde se declara el atributo. El espacio de nombres está declarado en el atributo xmlns de la etiqueta <LinearLayout> y aunque pueda parecer una URL (dirección web) en realidad sólo es un identificador con forma de URL.

La API de Android aprovecha la herencia de java para homogeneizar las propiedades disponibles para las vistas. Dado que las propiedades son atributos de clases, pueden ser heredadas por las clases hijas (si se definen como protegidas y no como privadas). De esta forma, como todas las vistas heredan directa o indirectamente de la clase View, las propiedades que se definen en esta clase estarán disponibles en todas las hijas.

Identificadores

Una de las propiedades que proporciona la clase View es la que se utiliza en el ejemplo como android:id. Se trata de un identificador para las vistas, aunque no es obligatorio. En el archivo XML, asignar un identificador a una vista sirve para poder hacer referencia a ella tanto en el propio archivo XML como en la actividad que lo utilice. Si no vamos a referenciar una vista no es necesario asignarle un identificador.

Para poder usar el identificador XML desde el código Java, el compilador genera una clase llamada R en la que se incluye una constante por cada atributo Id del archivo XML. El método findViewById de la clase Activity nos permite obtener la vista que necesitamos a partir de estas constantes de la clase R.

Por otro lado, cuando la interfaz de usuario se crea por entero desde el código tenemos objetos definidos para cada vista y podemos usarlos para acceder a sus propiedades o como referencia en otras vistas, sin necesidad de asignar identificadores.

Aunque a primera vista no lo parece, el identificador es en realidad un número. De hecho, el método setId que permite establecer el identificador por código recibe un entero (int) como parámetro. Sin embargo, trabajar directamente con identificadores numéricos en los archivos XML no resulta demasiado práctico, por lo que el compilador nos permite utilizar unas cadenas de texto especiales que luego son traducidas a los números que correspondan. El formato de esas cadenas de texto es el siguiente:

   @[<nombre_de_paquete>:|+]<tipo_de_recurso>/<nombre_de_recurso>

Nota

Aunque el compilador no va a protestar si usamos el mismo nombre en más de una vista, sólo se va a crear un identificador y, por tanto, una única constante en la clase R. Si tratamos de localizar la vista que le corresponde, se devolverá siempre la primera que se encuentre con el identificador buscado, lo que puede dar lugar a comportamientos no deseados. Incluso, si el tipo de la vista que se devuelve no se corresponde con el del objeto al que se intenta asignar, se producirá un error en la aplicación durante su ejecución.

En resumen, si asignamos a un atributo Id una cadena como @+id/principal, el compilador le asignará un número a la vista, por ejemplo el 0x7f050000 (2.131.034.112 en hexadecimal), y creará una constante de nombre R.layout.principal en el archivo R.java. La constante será de tipo int y tendrá el valor 0x7f050000. Además, cuando se cree el objeto correspondiente a la vista, se le asignará el número 0x7f050000 como identificador (usando setId).

Si más adelante usamos una cadena como @id/principal en otro atributo, el compilador reconocerá el nombre del recurso y lo remplazará por el mismo valor numérico, 0x7f050000, para pasárselo al método que se corresponda con el atributo.

Otras propiedades

La clase View proporciona otras muchas propiedades a las vistas. Veamos algunas de las más habituales:

Luego, cada vista concreta añade sus propias propiedades. Por ejemplo, <TextView> y <Button> disponen de un atributo android:text, que permite establecer el texto que mostrarán. En futuros posts iremos viendo las propiedades particulares de diferentes diseños y widgets.

Recuerda que en esta página dispones de enlaces a todos los artículos sobre Android que he publicado en La columna 80.