AsyncTaskLoader vs AsyncTask

Desde Honeycomb y la v4 Compatibility Library , es posible utilizar AsyncTaskLoader . Por lo que entiendo, AsyncTaskLoader puede sobrevivir a través de cambios de configuración, como volteos de pantalla.

¿Se recomienda utilizar AsyncTaskLoader lugar de AsyncTask ? ¿ LoaderManager entra en escena también?

Pero no he encontrado ningún buen ejemplo (s) sobre cómo usar correctamente el AsyncTaskLoader . Los documentos tampoco proporcionan ejemplos. ¿Alguien puede dar algunos buenos ejemplos?

Puede echar un vistazo al código fuente de la biblioteca de compatibilidad para obtener más información. Lo que hace una FragmentActivity es:

  • mantener una lista de LoaderManager
  • asegúrese de que no se destruyan cuando enciende el teléfono (u ocurre otro cambio en la configuración) guardando instancias usando onRetainNonConfigurationInstance()
  • patea el cargador derecho cuando llamas a initLoader() en tu Actividad

LoaderManager usar el LoaderManager para interactuar con los cargadores, y proporcionar las devoluciones de llamada necesarias para crear su (s) cargador (es) y completar sus vistas con los datos que devuelven.

En general, debería ser más fácil que administrar AsyncTask ‘s usted mismo. Sin embargo, AsyncTaskLoader no está exactamente bien documentado, por lo que debe estudiar el ejemplo en los documentos y / o modelar su código después de CursorLoader .

Cuando compare AsyncTaskLoader vs. AsyncTask , como sabrá cuando gire la pantalla de su dispositivo, puede destruir y recrear su actividad, para dejarlo en claro permita que la imagen gire su dispositivo mientras se realiza la transacción de red:

AsyncTask se volverá a ejecutar como hilo de fondo de nuevo, y el procesamiento de fondo de hilo anterior era simplemente redundante y zombie.

AsyncTaskLoader se reutilizará basándose en la Id. De cargador que se registró en Loader Manager antes, así que evite volver a ejecutar la transacción de red.

En resumen, AsyncTaskLoader evita la duplicación de subprocesos de fondo y elimina la duplicación de actividades de zombies.

AsyncTaskLoader realiza la misma función que AsyncTask , pero es un poco mejor. Puede manejar cambios de configuración de actividad más fácilmente, y se comporta dentro de los ciclos de vida de fragmentos y actividades. Lo bueno es que el AsyncTaskLoader se puede usar en cualquier situación en que se utilice AsyncTask. Cada vez que los datos se deben cargar en la memoria para que la Actividad / Fragmento los maneje, The AsyncTaskLoader puede hacer el trabajo mejor.

Sin embargo, hay algunos problemas con el uso de AsyncTasks:

  • Los cambios de configuración pueden estropear las cosas
  • Pausar una actividad no pausa el AsyncTask
  • Una buena cantidad de código repetitivo (lo que significa más posibles errores)

AsyncTaskLoader doc

Algunas diferencias aparte de las descritas en otras respuestas:

Cuando se usa AsyncTaskLoader sobre AsyncTask :

  • AsyncTaskLoader nos da libertad para cargar datos en caché viejos hasta que forceLoad() nuevos datos

  • Podemos establecer retrasos en AsyncTaskLoader mediante setUpdateThrottle() que puede evitar actualizaciones consecutivas al cliente (Actividad / Fragmento)

  • AsyncTaskLoader se puede compartir en varios fragmentos si tienen actividad principal común y si se inició desde getActivity().getSupportLoaderManager()

  • AsyncTaskLoader es destruido por LoaderManger cuando su actividad vinculada ya no está disponible. mientras que necesitamos destruir manualmente AsyncTasks si la actividad de quien llama lo destruye. Esto ahorra nuestro tiempo de escribir todo el material de limpieza. AsyncTaskLoader funciona bien con sus respectivos ciclos de vida.

Entonces, AsyncTaskLoader es mucho mejor que AsyncTask.