Repositorio

https://github.com/csolorzanof/DispMovilesClase3

Fragmentos
Un fragmento es una sección, porción o como lo implica el nombre un fragmento de una actividad
en Android. Un fragmento puede existir en más de una actividad y una actividad puede estar
compuesta de múltiples fragmentos. Los podemos categorizar en fragmentos estáticos y
dinámicos. Los fragmentos los podemos utilizar para simplificar la creación de layouts para
Tablets de gran tamaño utilizando layouts de doble panel. Esto permite tener una aplicación
móvil que en un dispositivo de pantalla regular muestre un layout reducido y en una pantalla de
Tablet utilice un layout que se ajuste a esta área. El utilizar un fragmento nos permite diseñar los
componentes una sola vez y reutilizarlos en diferentes configuraciones en los diferentes layouts.

Ciclo de Vida de Fragmentos

Un fragmento es un componente con su propio ciclo de vida, es muy importante entender el ciclo
de vida de los fragmentos ya que este nos provee callbacks en ciertos puntos de su creación,
ejecución y destrucción donde podemos configurar la inicialización, despliegue y limpieza de
este. Los fragmentos se ejecutan en actividades por lo que están ligados al ciclo de vida de la
actividad.

En muchos sentidos el ciclo de vida de los fragmentos es muy similar al ciclo de vida de una
actividad y a primera impresión parece replicar el ciclo de vida de la actividad. Existen muchos
callbacks que se comparten entre los dos. Cuando utilizamos un fragmento en una actividad los
callbacks de sus ciclos de vida se entrelazan en sus tiempos de ejecución. La secuencia completa
de la interacción entre los fragmentos y las actividades se encuentra ilustrado en la
documentación oficial que puede ver en el enlace siguiente:

https://developer.android.com/guide/fragments/lifecycle

Los mismos pasos se ejecutan para inicializar el fragmento y prepararlo para ser mostrado para
ser utilizado por el usuario que cuando hablamos de una actividad. Los mismos pasos se ejecutan
en el fragmento cuando la aplicación pasa a segundo plano, se oculta, se cierra. Al igual que las
actividades los fragmentos deben heredar de una clase padre con todos estos callbacks llamada
Fragment. Podemos hacer un override de estos callbacks definidos en la clase padre
dependiendo el caso de uso que queramos resolver.

Los callbacks del ciclo de vida de los fragmentos son los siguientes:

• override fun onAttach(context: Context): Se ejecuta al momento que un fragmento es

vinculado con una actividad. Le permite hacer referencia a la actividad sin embargo en
este punto ni la actividad ni el fragmento han finalizado su proceso de creación
• override fun onCreate(savedInstanceState: Bundle?): Este es momento donde podemos
realizar cualquier inicialización de nuestro fragmento. Este no es el momento donde
podemos determinar el layout a utilizar ya que en este punto no existe una interfaz de
usuario disponible por lo que no podemos utilizar el setContentView como lo hacemos
en una actividad. Igual que en una actividad en este punto podemos utilizar el parámetro
savedInstanceState para restaurar el estado del fragmento cuando este es re-creado.
• override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?,
savedInstanceState: Bundle?): View?: Este es el momento donde podemos crear el
layout de nuestro fragmento. Lo más importante que debemos recordar es que en lugar
de establecer el layout como en una actividad, un fragmento retorna el View? desde esta
función. Recordemos que todos los componentes son en el fondo un View. Podemos
hacer referencia a otros componentes que tengamos en nuestra actividad pero es
necesario crear el layout antes de poder hacer referencia a estos componentes. Es por
esto que se recomienda hacer cualquier manipulación de los componentes de la actividad
en el callback onViewCreated
• override fun onViewCreated(view View, savedInstanceState: Bundle?): Este callback se
ejecuta en el momento entre que se crea completamente y que pueda ser visible para el
usuario. Es donde típicamente configuramos los componentes del fragmento y
establecemos cualquier funcionalidad o interacción a estos, como por ejemplo agregar
un clickListener.
• override fun onActivityCreated(context: Context): Este callback se ejecuta inmediatamente
después que el onCreate de la actividad ha sido ejecutado. La mayor parte de la inicialización
del fragmento ha sido finalizada y este es el lugar para hacer cualquier configuración final de
ser requerida.
• override fun onStart(): Esto se ejecuta cuando el fragmento esta apunto de ser visible
para el usuario pero que todavía no está disponible para que pueda interactuar con el.
• override fun onResume(): Al finalizar este callback el fragmento está disponible para
interactuar con el usuario. Normalmente hay configuración mínima que se realiza en esta
función ya que cuando la aplicación pasa a segundo plano y luego retorna a ser la
aplicación en primer plano este callback se ejecutara cada vez. Es por esto que no
queremos incluir en este callback código innecesario o redundante que se sea necesario
para la configuración del fragmento.
• override fun onPause(): Igual que a su contraparte en la actividad este callback indica que
la aplicación pasara a segundo plano o ha sido parcialmente cubierta por algún otro
elemento en pantalla. Es recomendado utilizar este callback para guardar cualquier
cambio al estado del fragmento.
• override fun onStop(): El fragmento ya no está visible al final de este callback y pasa a
segundo plano.
• override fun onDestroyView(): Usualmente este callback se utiliza para realizar cualquier
acción de limpieza antes que el fragmento sea destruido. Podemos liberar cualquier
recurso utilizado por el fragmento. Si el fragmento se empuja a la parte inferior de la pila
de y es retenido entonces se puede llamar a este callback sin que el fragmento sea
destruido. Al finalizar este callback el layout del fragmento es eliminado.
 • override fun onDetach(): Este callback se utiliza cuando el fragmento ha sido retirado de
la actividad.

Existen más callbacks para los fragmentos pero estos son los más comúnmente utilizados para la
mayoría de los casos de uso. Puede investigar más alrededor de todo lo relacionado con
fragmentos en la documentación oficial: https://developer.android.com/guide/fragments

Podemos agregar un fragmento a una actividad de dos formas editando el layout de la actividad
y en la vista de código agregar un <fragment …. > o utilizando un FragmentContainerView. La
segunda forma es la preferida.

Al momento de utilizar el FramentContainerView en tiempo de diseño podemos previsualizar el

fragmento a utilizar en tiempo de ejecución estableciendo la propiedad tools:layout en código

El calificador frecuentemente utilizado para definir una resolución de una Tablet es sw donde
esto significa Shortest Width (Anchura más corta) y sirve como un punto de corte donde
definimos que si la anchura de la pantalla es mayor a el tamaño especificado entonces se debe
utilizar este layout. Por ejemplo sw600dp indica que si la pantalla es más grande que 600dp
entonces se debe utilizar el layout con este calificador (600dp es normalmente para tablets de 7
pulgadas). Con las tablets podemos utilizar layouts de doble panel.

Estilos de Material estándar:

https://gist.github.com/webserveis/c8c7e001c617829caa61dae385113e00

Los Listener son un patrón de diseño común para reaccionar a cambios. Especificando una
interface listener estamos definiendo un contrato que debe ser cumplido. Las clases que
implementen el listener son notificadas de los resultados de la operación.

Puede ver que otras opciones de comodines y formatos de string existen en la documentación
oficial:
https://developer.android.com/guide/topics/resources/string-resource

Cuando utilizamos layouts lineares para que el tamaño del layout sea determinado en base al
peso (layout weigth) es necesario que se utilice 0dp en el width o height del layout para el
elemento según sea el caso. 0dp para width cuando es un layout linear horizontal y 0dp para el
height cuando es un layout linear vertical.

Según el caso de uso que se quiera resolver, utilizar fragmentos estáticos es más que suficiente
sin embargo en ocasiones donde la experiencia del usuario en una actividad requiere de 3, 4 o
más fragmentos se recomienda se utilicen fragmentos dinámicos. Esto se logra utilizando un
ViewGroup como el contenedor de los fragmentos al cual podemos agregar, reemplazar y
remover fragmentos los cuales pueden permanecer activos hasta que ya no se necesiten y no es
necesario inflarlos cada vez a través de layouts XML.
El uso de fragmentos dinámicos y estáticos aunque flexible introduce un montón de código extra
para manejar la navegación y puede volverse rápidamente en un problema al dar mantenimiento
a la aplicación. Google introdujo los componentes de Jetpack para atender esta necesidad.