Loader framework vs AsyncTask simple

Question

En mi aplicación necesito una gran cantidad de productos CRUD: leer registros de la base de datos SQLite local, insertar objetos y actualizar productos. La mayoría de las consultas son tan simples que no se bloquearán aunque se ejecuten en la interfaz de usuario, sin embargo, en esta aplicación quiero adoptar el patrón de Windows Phone: una animación comenzó inmediatamente y se inició en la animación cuando resultado es entregado.

Planeé usar un AsyncTask para el trabajo, sin embargo, noté que Honeycomb (y el paquete compat) presenta esta nueva estructura de cargador . La principal ventaja parece que los datos cargados por un Loader sobreviven a la configuración. El proyecto LoaderEx de Commonsware establece puentes entre SQLite y el marco, pero surgen algunos problemas.

1. Recursos de limpieza: Yo uso una sola actividad, crear el SQLiteOpenHelper en onCreate() y cerrarla onDestroy(). Dado que el gestor de carga aún puede estar ejecutándose, lo compruebo y configuro un indicador pendingClose en mi objeto de devolución de llamada, por lo que cerrará el cursor y el ayudante cuando termine la carga. Creo que no cerrando la base de datos no es dañina, pero SQLite se queja si no lo haces, y no me gustan los mensajes de error :) El punto aquí es que los datos no sobreviven a los cambios de configuración, por lo que la ventaja del cargador desaparece

2. ¿Cuántos cargadores debo crear? Digamos que tengo las queridas tablas Customer y Order. Los cargadores se identifican por ID como CUST_L o ORD_L, pero cada vez que el usuario hace clic en algún resumen, quiero mostrar una pantalla con los detalles. ¿Debo I restart un cargador con diferentes parámetros, o debería I init uno nuevo con una identificación aleatoria? Esto puede suceder docenas de veces. ¿El marco del cargador está pensado para muchos trabajos pequeños en ejecución o solo para algunas tareas largas?

3. ¿Cuál es el propósito de usar ID dentro de la interfaz LoaderCallbacks? ¿Por qué no un simple initLoader(params, callback)? No creo que se pueda reutilizar un poco de lógica dentro de una devolución de llamada: eventualmente se bifurcará (con if-else o switch en ID) por lo que no entiendo el objetivo de dar un identificador al objeto de devolución de llamada, en lugar de un enfoque ingenuo one-callbacks-por-operación.

que estoy pidiendo esto porque todo el marco parece overengineered a mí y sin utilidad real. No entiendo el objetivo de centralizar el código con un LoaderManager, y no puedo ver ninguna nueva oportunidad que AsyncTask no haya ofrecido.

El único punto de victoria es la supervivencia de los cambios de configuración, pero no puedo explotarlo debido a la limpieza de recursos, y no puedo encontrar una manera alternativa de cerrar el SQLiteOpenHelper porque (obviamente) el SQLiteCursorLoader lo requiere pero limpio depende del usuario. Así que AsyncTask parece ser la opción ganadora aquí, pero tal vez me esté perdiendo algo.

Answer 1

1. Los proveedores de contenido son mucho más poderosos que el enfoque "raw-DB". Muchos enlaces en stackoverflow conducen a discusiones sobre esto.
2. LoaderManager intenta distinguir los cargadores por sus ID (por eso la firma de initLoader especifica este argumento).Se necesita ID para el cargador para volver a entregar el resultado en caché en caso de que ya existan datos para el cargador con ID específico (por lo tanto, no es necesario volver a cargarlo de forma asíncrona).
3. llamada restartLoader obliga a LoaderManager a iniciar la operación asincrónica especificada por el cargador creado anteriormente. initLoader intenta reutilizar el cargador existente antes de crear uno nuevo.
4. Fragmentos y actividades tienen sus propios gestores de carga que no se superponen.

Mi experiencia demuestra que, a pesar de que el uso de proveedores de contenido suena excesivo para implementar, en realidad vale la pena en el futuro. El golpe de rendimiento es insignificante (intenté medirlo), los enlaces de UI-Data se agregan de inmediato (debido a que el observador de contenido y los CursorLoaders pueden suscribirse a las notificaciones de Uri), la sincronicidad implementada por el framework a través de cargadores. En mi humilde opinión, cada vez que se necesita una base de datos, el proveedor de contenido con cargadores la mayoría de las veces es la mejor solución que se te puede ocurrir.

Otros escenarios que implican el uso de la base de datos directamente, le obligarán a implementar todo manualmente.