¿Está todavía utilizando AsyncTask para cargar elementos de listView en segundo plano?

Fondo

He oído que hay algunas nuevas soluciones para cargar datos en el fondo que son más recomendados que AsyncTask (como cargadores ).

El problema

AsyncTasks son grandes y fáciles de usar. Sin embargo, tiene algunas limitaciones:

La clase en sí tiene que ser modificada, ya que está limitada por el número de tareas pendientes (unos 256 o menos). Por supuesto, en el adaptador de un listView, siempre cancelo una tarea si no es necesario (por ejemplo, cuando necesito actualizar una vista que se utilizó para un elemento diferente).
También tengo que cancelarlos todos (o manejar de una manera diferente) cuando la actividad / fragmento se está recreando.
Debido a 1 & 2, necesito manejarlos y tener una referencia a todos ellos
AsyncTask utiliza una cola de tareas, ya veces necesito usar una pila en su lugar, así que tuve que crear mi propia clase de AsyncTask que utiliza una pila en su lugar.

La pregunta

¿Hay alternativas para AsyncTask?

Sé que esto fue preguntado en algunos posts antes (como aquí ), pero estaba pensando si hay una nueva forma general de cargar datos en el fondo que reemplaza el asyncTask.

Acerca de Loaders, creo que la idea es que se utilizan para bases de datos y contentProviders, pero también se pueden utilizar para cargar (por ejemplo) datos de Internet (como archivos de imágenes)?

También hay una bonita muestra hecha por google ( aquí , llamada "bitmapFun"), que según lo que veo usa AsyncTask (e incluso extenderlo, quizás por las mismas razones que he mencionado). Pero tal vez me falta algo allí también?

Tal vez debería considerar la posibilidad de revisar su enfoque, la necesidad que tiene de realizar varias actualizaciones dependiendo de la vista y cancelar todas las tareas pendientes de las vistas anteriores da la impresión de que está realizando la carga de datos individualmente para cada vista que se debe crear .

En una vista de lista con un adaptador de lista, el enfoque habitual es cargar una parte de los datos (ya sea como lista de ValueObject o como Cursor de varias filas de la base de datos) paginadas a petición o en una meta, no elemento por artículo. Por lo tanto, si desea actualizar la siguiente página, básicamente realizará una sola operación, ya sea utilizando AsyncTask o Loaders para obtener los nuevos elementos en el modelo y luego hacerlos disponibles para que la interfaz de usuario los muestre. De esta manera, aplicará MVC, y no tendrá varias tareas pendientes para cancelar y controlar, y su estructura sería más sólida y más fácil de administrar.

Acerca de las alternativas, si se trata de una base de datos, la forma más sencilla es utilizar el CursorLoader, es decir, los cargadores en lugar de AsyncTask , pero si se trata de datos que provienen de la red o sistema de archivos, estás un poco libre Para elegir entre la variedad de otras opciones disponibles. AsyncTask es mucho más simple de usar, en su mayoría recomendado para cosas simples o consultas de un disparo. Pero también puede utilizar Loaders para tales tareas, consulte AsyncTaskLoader .

Sí.

Los cargadores se gestionan AsyncTasks. Si no está utilizando un cargador, es probable que falte la gestión que requieren.

AsyncTasks (y cargadores) son una manera bastante mala de conseguir la materia que está apagado el dispositivo. Para obtener datos de un servidor remoto, busque el uso de un IntentService. Consulte: https://www.youtube.com/watch?v=xHXn3Kg2IQE

AsyncTask está diseñado para ser una clase auxiliar en torno a Thread y Handler y no constituye un marco de subprocesamiento genérico. AsyncTasks idealmente debe ser utilizado para operaciones cortas (unos pocos segundos a lo sumo). Si necesita mantener los temas en ejecución durante largos períodos de tiempo, es muy recomendable utilizar las diversas API proporcionadas por el pacakge java.util.concurrent como Executor, ThreadPoolExecutor y FutureTask. Consulte http://developer.android.com/reference/android/os/AsyncTask.html para obtener más información.

Una alternativa a asynctask es robospice. https://github.com/octo-online/robospice .

Puedes empezar con robopice aquí. https://github.com/octo-online/robospice/wiki/Starter-Guide .

Una muestra de robospice en https://play.google.com/store/apps/details?id=com.octo.android.robospice.motivations&feature=search_result .

Algunas de las características de robospice.

1.executes asynchronously (in a background AndroidService) network requests (ex: REST requests using Spring Android). 2.is strongly typed ! You make your requests using POJOs and you get POJOs as request results. 3.enforce no constraints neither on POJOs used for requests nor on Activity classes you use in your projects. 4.caches results (in Json with both Jackson and Gson, or Xml, or flat text files, or binary files, even using ORM Lite). 5.notifies your activities (or any other context) of the result of the network request if and only if they are still alive 6.no memory leak at all, like Android Loaders, unlike Android AsyncTasks notifies your activities on their UI Thread. 7.uses a simple but robust exception handling model.