Fragmentación de Android (pero la buena)

Vamos a ver cómo empezar a trabajar con los Fragments de Android.

¿Pero no se suponía que la fragmentación de Android era algo malo?

Sí, pero no hablo de esa fragmentación.

Cuando hablamos de Fragments hablamos de un nuevo elemento añadido a la API a partir de HoneyComb. Los fragments son “pedazos” de la interfaz que colocamos en nuestros layouts.

Y direis “pues eso es un View”. Y yo os diré “pues no”. Y si no le dais al botón de leer más, os quedareis con el misterio.

Vamos a ver cómo empezar a trabajar con los Fragments de Android.

¿Pero no se suponía que la fragmentación de Android era algo malo?

Sí, pero no hablo de esa fragmentación.

Cuando hablamos de Fragments hablamos de un nuevo elemento añadido a la API a partir de HoneyComb. Los fragments son “pedazos” de la interfaz que colocamos en nuestros layouts.

Y direis “pues eso es un View”. Y yo os diré “pues no”. Y si no le dais al botón de leer más, os quedareis con el misterio.

Por que los fragments tienen un ciclo de vida propio, lo cual nos permite utilitzarlos para implementar la lógica de la aplicación, y dejar las Activities como encargados de mostrar los Fragments que deseemos según el tamaño de pantalla.

Pongamos un ejemplo.

Imaginad que tenemos la típica aplicación que lista elementos y al pulsar uno de ellos, nos muestra el detalle de ese elemento. El problema se encuentra al ejecutar la aplicación en un tablet, donde se produce el “efecto oceano” (grandes espacios sin ocupar con elementos flotando). Pues nuestra Activity debería hacer dos cosas:

a) Si la pantalla es extra grande (vamos, un tablet), debería mostrar los dos fragments y gestionar los mensajes entre ellos.

b) Si la pantalla es grande, normal, o pequeña, debe mostrar un sólo fragment y llamar a una segunda Activity que muestre el fragment de detalle.

Como ya he dicho, de esta forma no es necesario implementar la lógica del programa en dos sitios, ya que los Fragments tienen su propio ciclo de vida.

¿Honeycomb? un pelín exclusivistas los de la gran G

Para que no exista todavía una mayor fragmentación (de la mala) debido a los Fragments (los buenos), y evitar un “apocalipsis honeycomb”, los señores de Google han decidido incluir los Fragments dentro de una API llamada AndroidSupport (versión 4, por ahora) que permite utilizar ciertos elementos de Android 3 incluso en 1.6.

Para instalarla, podeis añadirla como API desde el AVD manager, pero los más sencillo es añadir un Fragment a un Layout, y automágicamente os dirá que necesitais la librería y que si quereis que la instale.

Si ya la tenéis instalada, deberéis incluir en vuestro proyecto el archivo android-support-v4.jar que está en la carpeta extrasandroidcompatibilityv4 del SDK de Android.

¿Empezamos ya?

Vale, vamos a ver un pequeño proyecto de ejemplo.

Necesitamos:

  1. Un proyecto de Android
  2. Tres layouts que vamos a llamar main.xml, f1.xml y f2.xml. En los dos últimos colocad los controles que os de la gana.
  3. Una actividad principal (que llamaremos MainActivity) que establezca como layout de la actividad a main.xml en el onCreate

¿Ya? pues sigamos.
Lo primero es cambiar la clase MainActivity para que herede de ActivityFragment y no de Activity, ya que la clase Activity nativa de versiones de Android inferiores a 3  no soporta Fragments. Si nuestra aplicación fuese nativa de 3 o superior no sería necesario este cambio.
Ahora vamos a incluir los dos Fragments en nuestro Layout main.xml. Para ello usaremos el siguiente marcado:

Vamos a explicar cada atributo:

  1. layout_height y layout_width ya están más que explicados y no creo que haga falta entrar en ello.
  2. android:id. Cada elemento Fragment de un layout debe tener un tag android:id con un identificador único o bien un tag android:tag con una cadena única (o bien nada).
  3. android:name. Este es el más importante. Es la ruta canónica a la clase encargada de suministrarno la View a mostrar en el Fragment y a gestionar su ciclo de vida. Aun no las hemos creado.
  4. <!– Preview: layout=@layout/f1 –> Este tag es simplemente para decirle al editor de layouts de Eclipse que muestre este layout en el editor. También se puede configurar via menú contextual del editor.

Y una vez hecho esto, pues pondriamos otro elemento similar, pero para el segundo fragmento:

Listos.

Ahora vamos a crear la clase Fragment1 que va a encargarse de inflar el fragmento:

Cómo veis, el formato es parecido al de una Activity, pero en vez del método onCreate, tenemos el método onCreateView, que debe devolver la View a mostrar en el fragmento. Este método recibe tres parámetros:

  1. inflater: un LayoutInflater que podemos utilitzar (y de hecho lo hacemos) para inflar la vista.
  2. container: un ViewGroup que usaremos para hacer de root durante el inflado.
  3. savedInstance: el Bundle con el estado del fragment si ha sido destruido

Y simplemente devolvemos el resultado de inflar el layout con el método inflate. Para los que no lo conozcais, el tercer parámetro del método inflate (el booleano) indica si hay que crear una nueva View dentro del root o se debe inflar la View directamente en el root. En este caso, no nos hace falta y así evitamos elementos innecesarios.

Por último, sólo queda hacer la clase Fragment2 que será identica a Fragment1 cambiando el fragmento a hinchar.

¡Y ya está! Con esto hemos finalizado nuestro primer experimento con Fragments. Queda mucho por rascar, esto es el primer ejemplo, pero poco a poco y sin prisa. El próximo día hablaremos de cómo crear estos Fragments desde código.

Id en paz.

 

 Por que los fragments tienen un ciclo de vida propio, lo cual nos permite utilitzarlos para implementar la lógica de la aplicación, y dejar las Activities como encargados de mostrar los Fragments que deseemos según el tamaño de pantalla.

Pongamos un ejemplo.

Imaginad que tenemos la típica aplicación que lista elementos y al pulsar uno de ellos, nos muestra el detalle de ese elemento. El problema se encuentra al ejecutar la aplicación en un tablet, donde se produce el “efecto oceano” (grandes espacios sin ocupar con elementos flotando). Pues nuestra Activity debería hacer dos cosas:

a) Si la pantalla es extra grande (vamos, un tablet), debería mostrar los dos fragments y gestionar los mensajes entre ellos.

b) Si la pantalla es grande, normal, o pequeña, debe mostrar un sólo fragment y llamar a una segunda Activity que muestre el fragment de detalle.

Como ya he dicho, de esta forma no es necesario implementar la lógica del programa en dos sitios, ya que los Fragments tienen su propio ciclo de vida.

¿Honeycomb? un pelín exclusivistas los de la gran G

Para que no exista todavía una mayor fragmentación (de la mala) debido a los Fragments (los buenos), y evitar un “apocalipsis honeycomb”, los señores de Google han decidido incluir los Fragments dentro de una API llamada AndroidSupport (versión 4, por ahora) que permite utilizar ciertos elementos de Android 3 incluso en 1.6.

Para instalarla, podeis añadirla como API desde el AVD manager, pero los más sencillo es añadir un Fragment a un Layout, y automágicamente os dirá que necesitais la librería y que si quereis que la instale.

Si ya la tenéis instalada, deberéis incluir en vuestro proyecto el archivo android-support-v4.jar que está en la carpeta extrasandroidcompatibilityv4 del SDK de Android.

¿Empezamos ya?

Vale, vamos a ver un pequeño proyecto de ejemplo.

Necesitamos:

  1. Un proyecto de Android
  2. Tres layouts que vamos a llamar main.xml, f1.xml y f2.xml. En los dos últimos colocad los controles que os de la gana.
  3. Una actividad principal (que llamaremos MainActivity) que establezca como layout de la actividad a main.xml en el onCreate

¿Ya? pues sigamos.
Lo primero es cambiar la clase MainActivity para que herede de ActivityFragment y no de Activity, ya que la clase Activity nativa de versiones de Android inferiores a 3  no soporta Fragments. Si nuestra aplicación fuese nativa de 3 o superior no sería necesario este cambio.
Ahora vamos a incluir los dos Fragments en nuestro Layout main.xml. Para ello usaremos el siguiente marcado:

Vamos a explicar cada atributo:

  1. layout_height y layout_width ya están más que explicados y no creo que haga falta entrar en ello.
  2. android:id. Cada elemento Fragment de un layout debe tener un tag android:id con un identificador único o bien un tag android:tag con una cadena única (o bien nada).
  3. android:name. Este es el más importante. Es la ruta canónica a la clase encargada de suministrarno la View a mostrar en el Fragment y a gestionar su ciclo de vida. Aun no las hemos creado.
  4. <!– Preview: layout=@layout/f1 –> Este tag es simplemente para decirle al editor de layouts de Eclipse que muestre este layout en el editor. También se puede configurar via menú contextual del editor.

Y una vez hecho esto, pues pondriamos otro elemento similar, pero para el segundo fragmento:

Listos.

Ahora vamos a crear la clase Fragment1 que va a encargarse de inflar el fragmento:

Cómo veis, el formato es parecido al de una Activity, pero en vez del método onCreate, tenemos el método onCreateView, que debe devolver la View a mostrar en el fragmento. Este método recibe tres parámetros:

  1. inflater: un LayoutInflater que podemos utilitzar (y de hecho lo hacemos) para inflar la vista.
  2. container: un ViewGroup que usaremos para hacer de root durante el inflado.
  3. savedInstance: el Bundle con el estado del fragment si ha sido destruido

Y simplemente devolvemos el resultado de inflar el layout con el método inflate. Para los que no lo conozcais, el tercer parámetro del método inflate (el booleano) indica si hay que crear una nueva View dentro del root o se debe inflar la View directamente en el root. En este caso, no nos hace falta y así evitamos elementos innecesarios.

Por último, sólo queda hacer la clase Fragment2 que será identica a Fragment1 cambiando el fragmento a hinchar.

¡Y ya está! Con esto hemos finalizado nuestro primer experimento con Fragments. Queda mucho por rascar, esto es el primer ejemplo, pero poco a poco y sin prisa. El próximo día hablaremos de cómo crear estos Fragments desde código.

Id en paz.

 

 

1 Comment

  1. Jose Gil · September 12, 2011 Reply

    Bueno, pues ya sabemos un poquito más. Ahora toca ponerlo en práctica.
    Gracias Sergi

Leave a Reply