studio - programacion android pdf 2018

¿Cuándo se adjuntan y se separan las vistas?

Question

Esta pregunta no es sobre cómo detectar si una vista está adjunta o separada.

En general, ¿cuándo se adjunta o se separa una vista? ¿Hay un diagrama de ciclo de vida para esto?

Para aclarar, estoy buscando respuestas a lo que sucede cuando: la actividad se envía a un segundo plano, la vista opaca se coloca en la parte superior, la visibilidad se establece en GONE , la vista se infla, los padres se desvinculan, etc. Esta no es una lista exhaustiva; solo quiero entender Cómo funciona unir y separar vistas en un nivel fundamental.

Actualizar con más ejemplos de lo que estoy tratando de obtener:

¿Qué pasa con los fragmentos frente a las actividades?
¿Qué pasa con las vistas anidadas? ¿En qué orden se adjuntan / separan las vistas (padre-> hijo o hijo-> padre)?
¿Se miden las vistas antes de adjuntarlas o después?
¿Qué pasa con el uso de addView () a un ViewGroup manualmente?

Editar: Resumen:

• Para las actividades, las vistas se adjuntan en setContentView() . Las vistas se separan en onDestroy() o cuando se llama a setContentView() con una vista diferente.
• Para los fragmentos, las vistas se adjuntan después de que finaliza onViewCreated() y se separan después de que finaliza onDestroyView() .
• Para los grupos de vistas, las vistas se adjuntan en addView() y se separan en removeView()
• setVisibility() no afecta el estado adjunto de una vista

Answer 1

De la documentación oficial:

Una actividad es una cosa única y enfocada que el usuario puede hacer. Casi todas las actividades interactúan con el usuario ...

Lo primero que se debe tener en cuenta es que no es obligatorio que las actividades se asocien con un diseño. Puede tener una actividad sin interfaz de usuario (y, por tanto, sin vista). Android incluso especifica un tema sin interfaz de usuario para esto.

Pasando a su pregunta: una vista se anexa a una actividad en el momento en que llama a setContentView (vista). Esto generalmente se llama dentro del método onCreate (). La razón por la que normalmente tiene esto en el método onCreate () es porque la mayor parte de la inicialización se realiza allí. ¿Y cómo podría inicializar sus widgets si la vista no se ha inflado y adjuntado a la Actividad? Por lo tanto, si tiene una vista, casi invariablemente terminará llamando a setContentView () dentro de su método onCreate () que precede a cualquier otra inicialización.

Pero, ¿eso significa que la vista (si existe) debe estar vinculada a la actividad solo dentro del método onCreate ()?

Para responder a esta pregunta, veamos cómo es el ciclo de vida de una actividad. Comienzas tu aplicación:

onCreate () -> onStart () -> onResume () // Se llaman de forma consecutiva

La etapa en la que se encuentra ahora es donde se han inicializado todos los widgets.

Entonces, ¿por qué no inflar y adjuntar la actividad en onResume () y hacer todas las inicializaciones allí?

Por supuesto, usted podría. Pero imagina lo que sucede cuando aparece un diálogo (una vista parcialmente opaca) . La actividad ahora está parcialmente cubierta y está en el fondo. Se llama al método onPause (). El diseño todavía está adjunto a la Actividad en este punto. Tomas alguna acción y descartas el diálogo. onResume () se llama. El diseño se inflaría de nuevo. Todas las inicializaciones volverían a suceder y perderías tu estado. Incluso si no tuviera mucho en el proceso de inicialización, aún estaría haciendo una llamada bastante costosa llamando a onCreate () nuevamente. Y desea evitar esto en dispositivos móviles con recursos limitados.

¿Qué sucede cuando aparece una vista opaca y la Actividad está ahora en segundo plano pero aún se está ejecutando (como una llamada entrante o abriendo otra actividad)?

Ahora suceden las siguientes devoluciones de llamada:

onPause () -> onStop ()

Cuando vuelves a la actividad original.

onRestart () -> onStart () -> onResume ()

Por la misma razón que mencioné en onPause (), no desea inflar y adjuntar un diseño aquí.

Pero qué sucede con el diseño en sí mismo cuando una Actividad está en segundo plano. ¿Sigue el diseño adjunto?

Sí, mucho es. Si surge otra actividad que utiliza el mismo diseño que la actividad original, la nueva actividad tiene su propio diseño y no se comparten los diseños.

¿Qué sucede si el usuario termina la actividad presionando el botón Atrás?

Suponiendo que el método onBackPressed () no se anule para lograr un comportamiento personalizado (en cuyo caso, está disponible), se llama a OnDestroy () y se destruye la actividad y ya no hay una Vista asociada.

¿Qué sucede cuando la actividad está en segundo plano y el Android GC decide destruir la actividad y reclamar recursos?

De acuerdo con el ciclo de vida de la actividad dentro de la documentación, se llamará onDestroy (). Pero no hay garantía de esto. En este punto, la actividad y su vista asociada son simplemente basura recolectada y no hay conexión. La próxima vez que inicie la aplicación, se llamará a onCreate () como de costumbre y simplemente comenzará de nuevo desde el principio.

¿Qué pasa cuando giro mi dispositivo?

La forma en que funciona Android es destruir la actividad actual e inflar nuevamente el nuevo diseño y comenzar nuevamente desde el método onCreate (). Entonces, lo que técnicamente sucede es:

onPause () -> onStop () -> onDestroy () -> onCreate () -> onStart () -> onResume ()

Debido a esto, incluso puede tener un diseño y una vista diferentes mientras está en modo horizontal.

EDITAR: se agregó la relación entre actividades, fragmentos y vistas. Un fragmento representa una parte (o comportamiento) en la pantalla. Se puede hacer un fragmento para ocupar la pantalla completa o puede tener varios fragmentos dentro de una Actividad. Los fragmentos tienen su propio ciclo de vida, pero están estrechamente relacionados con el ciclo de vida de la actividad del anfitrión (y más allá del alcance de esta respuesta). Ya que estamos hablando específicamente sobre puntos de vista, limitaré esta respuesta a dos métodos de interés:

• onCreateView ()
• onViewCreated ()

Los métodos se llaman en el siguiente orden:

onAttach () -> onCreate () -> onCreateView () -> onViewCreated ()

Realiza la inflación del diseño real dentro de onCreateView () y luego haces las inicializaciones dentro del método onViewCreated (). Android utiliza el resultado del método onCreateView () para inflar la vista.

Entonces, ¿cuándo se crea el fragmento en primer lugar por la Actividad?

Hay dos formas de mostrar los fragmentos: una es colocarlos dentro del diseño xml de la actividad (como cualquier otro widget normal donde, en lugar del nombre del widget, usará el nombre del paquete completo de la clase del fragmento) o puede haga la adición usando FragmentManager programáticamente (que es el método preferido).

Si estaba definiendo el fragmento dentro del diseño xml, debe saber que el fragmento no se puede eliminar mediante programación. Sería difícil modificar esto y reutilizar ese espacio de pantalla para otros fragmentos. También en este caso, la vista se adjunta y se vincula a la actividad. En este caso, inflará el diseño xml de la Actividad dentro del método onCreate () de la actividad. Así que ahora, el flujo se verá algo como:

onCreate () [Actividad] -> onAttach () [Fragmento] -> onCreate () [Fragmento] -> onCreateView () [Fragmento] -> onViewCreated () [Fragmento] -> onStart () [Actividad] -> onResume ( ) [Actividad] -> onActivityCreated () [Fragmento]

Entonces, primero se crea una instancia de la vista de fragmentos y se adjunta al fragmento antes de que se cree el método onStart () de la actividad.

Si el fragmento se agrega mediante programación, si se agrega dentro del método onCreate (), entonces sigue el mismo flujo. Se puede iniciar en cualquier lugar. Simplemente debe sustituir el ciclo de vida del fragmento dentro de la actividad en el lugar apropiado. Cuando agrega fragmentos mediante programación, mientras el fragmento está alojado en la actividad, la vista se adjunta a la actividad. Cuando el fragmento se elimina de la actividad, se llama a OnDetach () y la vista ya no forma parte de la Actividad. Los recursos tomados por el fragmento pueden ser liberados.

¿Qué pasa con las vistas anidadas, los fragmentos anidados, etc.?

En las vistas anidadas, como un contenedor de diseño dentro de otro, las reglas del contenedor primario se aplican al contenedor secundario inmediato. Siempre el padre se inicializa primero. Entonces, para un widget dentro de un LinearLayout, el LinearLayout principal se construye primero, seguido inmediatamente por el secundario. Cuando se destruyen tales puntos de vista, todo sucede cuando el padre deja de existir. No he leído sobre ninguna documentación en cuanto a un orden en que esto puede suceder. El Android GC puede tener reglas, pero no estoy seguro de que estén documentadas en alguna parte.

También puede haber fragmentos anidados: en este caso, el fragmento primario se inicializa antes que el fragmento secundario (y tiene sentido, ¿no es así?). Cuando un fragmento padre deja de existir, el niño también dejará de existir. El hijo no puede existir sin el padre, pero puede tener el padre sin el hijo.

La línea inferior para las vistas anidadas es que una vez que se destruye la vista principal, toma la vista secundaria inmediatamente con ella.

¿Se miden las vistas antes de adjuntarlas o después?

Las vistas son medidas después de que se adjuntan. Llamar a getMeausredWidth () o getMeasuredHeight () devolverá cero antes de esto. Pero lo que puede hacer es llamar a neasure () directamente en la vista antes de adjuntarla y aprobar MeasureSpecs (sugeriría que lea más sobre esto en los documentos oficiales) para establecer algunas restricciones. Pero esta opción no es infalible, ya que depende de que ViewGroup principal aplique sus propias restricciones que tienen mayor prioridad. Para responder simplemente a su pregunta, las vistas se miden después de adjuntarlas.

¿Qué pasa con el uso de addView () para agregar una vista a un ViewGroup manualmente?

Esto es simplemente lo mismo que las vistas anidadas. El hijo solo existe cuando se agregan y esto lo controla el usuario. En las vistas anidadas definidas en xml de diseño, los hijos se inflan inmediatamente después de sus padres. Aquí el control está más en manos del usuario. Cuando se destruye la vista principal en este caso, toma la vista secundaria con ella.

Como último punto, también me gustaría mencionar que no debería usar las manijas estáticas para las vistas, ya que esto causaría muchos dolores de cabeza con el derribo de las vistas.