android - usar - tipos de entradas de cargadores para celular
¿Por qué los cargadores son malos en Android? (1)
He leído un par de tweets y comentarios aquí y allá sobre que los cargadores son malos y usarlos es una buena manera de "dispararse en la cara". También commonsguy anunció que interrumpirá cualquier trabajo en su biblioteca: Loaderex . Commonsguy también dijo que "los cargadores son una abstracción fallida".
Obviamente me estoy perdiendo algo aquí y me gustaría aprender más y entender por qué los cargadores son malos y por qué debería uno evitarlos.
Nota: he creado una aplicación de Android (quizás de complejidad media) en la que utilizo los cargadores y no he tenido ningún problema con los cargadores. Por eso me desconcierta.
También me gustaría conocer otras alternativas mejores para los cargadores. Gracias por adelantado
¿Por qué los cargadores son malos y por qué hay que evitarlos?
Notarás que esto no es lo que dije. Dije que los cargadores son una abstracción fallida. Hay una diferencia.
Una recomendación general, cuando se trata de crear un marco para una reutilización significativa, es diseñar y crear tres implementaciones discretas del marco. Si su marco puede admitir tres enfoques diferentes, el diseño probablemente sea lo suficientemente flexible como para manejar futuras implementaciones.
El marco del Loader , al final del día, está diseñado en torno a una implementación: CursorLoader . Período. No hay otras implementaciones concretas de Loader en el SDK. En particular, el marco de Loader tiene un contrato que requiere que las implementaciones de Loader puedan entregar resultados actualizados automáticamente. Si bien este es un contrato encantador desde el punto de vista de los usuarios del marco de Loader , dificulta las cosas para aquellos que podrían crear implementaciones del marco de Loader .
SharedPreferences crear dos implementaciones separadas del marco de Loader , para SQLite y SharedPreferences (tres si se cuenta SQLCipher para Android por separado). El SQLite uno apesta, porque la única manera de hacer las cosas de recarga automática es que el Loader sepa qué es lo que necesita ser recargado, lo cual es un poco pesado. El SharedPreferences solía funcionar, pero se señaló que hoy en día no se llamará a onLoadFinished() si el objeto que representa los resultados (el Cursor para un CursorLoader , SharedPreferences for SharedPreferencesLoader ) es el mismo objeto que antes. Eso rompe SharedPreferencesLoader , ya que el objeto SharedPreferences se actualiza in situ cuando se cambian las preferencias.
Después de escribir mis implementaciones de Loader y usarlas un poco, llegué a la conclusión de que no valían la pena. Prefiero cargar cosas yo mismo de forma asíncrona usando AsyncTask o IntentService y usar un bus de mensajes (Otto, EventBus de Greenrobot, etc.) para notificar a las partes interesadas sobre los cambios en los datos. Si bien podría envolver eso dentro de Loader , no estoy convencido de que resolvería suficientes problemas para que valga la pena el esfuerzo.
Ahora, si está usando un ContentProvider y desea usar CursorLoader , está bien. Puede tener sus propios problemas, pero al menos se supone que funciona.
Con respecto a la biblioteca CWAC-LoaderEx, la discontinúo porque:
Solo tengo tantas horas en el día, y como parte de la gran clasificación AAR de las bibliotecas de CWAC, estoy decidiendo qué bibliotecas vale la pena mantener.
No uso CWAC-LoaderEx personalmente, aparte de un par de ejemplos de libros
CWAC-LoaderEx depende de demasiada implementación interna de
Loaderpara que me sienta cómodo y pueda seguir funcionando a largo plazo (consulteSharedPreferencesLoader)
CWAC-LoaderEx no irá a ningún lado, pero simplemente no le dedicaré más tiempo. Si alguien con una bifurcación mantenida / extendida se pone en contacto conmigo, estaré encantado de vincular su bifurcación desde el proyecto README.
También me gustaría conocer otras alternativas mejores para los cargadores.
Todo lo que hace un Loader es cargar contenido de forma asíncrona, volver a cargar ese contenido tras un cambio detectado en el contenido y retener dicho contenido en un cambio de configuración. Un fragmento de modelo retenido (o sin cabeza) puede hacer lo mismo, en concierto con una AsyncTask .