¿Cuál es el caso de uso para un fragmento sin interfaz de usuario?

Question

La guía para desarrolladores de Android tiene una sección decente sobre el uso de Fragments. Una forma de usar Fragmentos es sin una IU. Hay algunas referencias al uso de esto como medio de procesamiento en segundo plano, pero ¿qué ventajas aportan los Fragmentos a esta área? ¿Dónde elegiría usar un Fragmento sobre Subprocesos, AsyncTasks, Gestores, etc. para el procesamiento en segundo plano?

Answer 1

Una instancia de Fragment puede persistir a través de cambios en la configuración del dispositivo (como la rotación de la pantalla). Debido a que un Activity se destruirá y volverá a crear cuando se produzca un cambio de configuración, es difícil diseñar uno que haga un seguimiento de un hilo o AsyncTask. Por otro lado, el sistema se encarga de volver a conectar un Fragment persistente al Activity correcto en el otro extremo (por así decirlo) del cambio de configuración. Todavía estaría usando un hilo o AsyncTask, solo que ahora el Fragment lo está reteniendo.

Puede haber otros usos para él, pero hay uno que se me ocurre.

Answer 2

Tengo una gran cantidad de código bastante complejo que maneja inicios de sesión para varias redes sociales: Facebook, Google, Twitter. Este es el código que necesito volver a usar en diferentes actividades ya que el usuario puede iniciar sesión desde diferentes lugares en la aplicación. No pertenece a una clase de actividad base porque solo puede heredar de una clase y estoy usando esa herencia para otra funcionalidad no relacionada.

Un fragmento de Ui-less es perfecto para mi situación y un fragmento se adapta bien a la necesidad ya que necesito devoluciones del ciclo de vida, por ejemplo (Facebook es notorio en este sentido, necesita, por ejemplo, en ActivityResult, etc.).

Answer 3

Estoy de acuerdo con Greg Ennis.

Estoy trabajando en una aplicación en este momento que tiene que ejecutar una serie de llamadas api RESTful. En su mayor parte, estos solo se realizan dentro de una sola actividad. Pero acabo de utilizar un fragmento sin cabeza para tratar con un caso en el que dos actividades diferentes, cada una necesaria para hacer la misma secuencia de llamadas múltiples y, por supuesto, manejar los errores en cualquier lugar de la secuencia. Al centralizar la secuencia en un fragmento, podría evitar duplicar una buena cantidad de código.

Tenemos otra llamada api que recupera MUCHOS datos que están siendo analizados en el hilo de UI en este momento y toman demasiado tiempo. En una versión futura de la API de back-end, el lado del servidor buscará los datos y se requerirá que nuestra aplicación realice una serie de llamadas de API para obtener los resultados completos. Estoy pensando que sería una gran aplicación para un fragmento retenido sin cabeza. La actividad de inicio puede iniciar el fragmento sin cabeza y la secuencia de llamada. Si no hay ningún error desde la primera llamada, esa actividad puede iniciar la siguiente actividad, para mostrar los resultados iniciales, mientras que el fragmento sigue resoplando y pidiendo al servidor la siguiente página de datos. Las llamadas de API ya están hechas en un hilo de fondo. Estoy bastante seguro de que el fragmento retenido tendrá que ejecutarse en un hilo de trabajo propio.

Hay más información sobre los fragmentos retenidos en Understanding Fragment's setRetainInstance(boolean)

Answer 4

Éstos también se llaman sin cabeza Fragmentos. Puede leer más here