android - org - Es el uso de bibliotecas de eventos como Otto o EventBus una forma recomendada de manejar las relaciones entre Actividades, Fragmentos y subprocesos de fondo

org greenrobot eventbus gradle

Question

En la mayoría de los casos, cuando se trata de un caso

• Hilo del usuario ( AsyncTask ) para realizar el procesamiento en segundo plano
• Devuelve el resultado calculado a Activity o Fragment
• Fragment recreación de la Activity o del Fragment puede ocurrir antes de que el hilo del usuario finalice su procesamiento en segundo plano

Hasta ahora, de muchas fuentes confiables, puedo ver que la forma recomendada es usar Fragmento Retenido

Fuentes

• Mejores prácticas: AsyncTask durante el cambio de orientación
• http://www.vogella.com/tutorials/AndroidBackgroundProcessing/article.html
• http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html

De vez en cuando, escuché que las bibliotecas de bus de eventos son buenas para manejar las relaciones entre Actividades, Fragmentos y subprocesos de fondo. (Consulte https://github.com/greenrobot/EventBus . Indica que funciona bien con Actividades, Fragmentos y subprocesos de fondo )

Me encontré con algunas bibliotecas de autobuses de eventos muy populares

• https://github.com/greenrobot/EventBus
• Otto

Me preguntaba, cuando se trata de manejar las relaciones entre Actividades, Fragmentos y subprocesos de fondo, ¿en qué se diferencia el enfoque del bus de eventos del del Fragmento Retenido ?

¿De qué manera es una forma recomendada?

Answer 1

Me preguntaba, cuando se trata de manejar las relaciones entre Actividades, Fragmentos y subprocesos de fondo, ¿en qué se diferencia el enfoque del bus de eventos del del Fragmento Retenido?

¿De qué manera es una forma recomendada?

Creo que entiendes mal dos conceptos:

1) evitar que una tarea se cree una y otra vez cuando gire su dispositivo

2) enviando mensajes desde un hilo a una actividad o desde un servicio a un fragmento o ...

Cuando colocamos una tarea dentro de un fragmento, simplemente no queremos comenzar de nuevo si estamos rotando. También queremos recuperar el resultado, por ejemplo, queremos actualizar una imageView, pero si pasa una imageView a una asynctask y luego gira su dispositivo si guarda la imageView como una referencia débil, entonces su imageView es nula después de que la actividad haya destruido y si lo almacena como una referencia fuerte entonces filtra la actividad. así que una mejor idea es colocarla dentro de un fragmento y almacenar la vista como una referencia débil y si la actividad onCreate se llama actualizar esa referencia.

EventBus y Otto son muy buenas bibliotecas para enviar mensajes entre cualquier componente o subproceso. Puedes usar esas o soluciones nativas de Android como crear una interfaz o localBroadcastManager o manejador.

¿En qué se diferencia el enfoque del bus de eventos del enfoque de fragmentos retenidos?

No he buscado en el código fuente de esos, pero creo que crearon un objeto de cola singleton y almacenan sus mensajes dentro de él y lo sacan de la cola para pasar sus mensajes a sus oyentes.

Answer 2

El bus de eventos y Otto no son "formas recomendadas" por la guía del desarrollador de Android principalmente porque son bibliotecas de terceros para simplificar la tarea. Y creo que Otto es bastante nuevo, por lo que, obviamente, las guías antiguas no lo están utilizando.

Personalmente me gusta Otto, es lo que uso y no he tenido ningún problema con él hasta ahora. Pero claro, eso es porque se adaptaba a mis casos de uso.

Tengo un ejemplo de cómo usé Otto here .

Edite del futuro: si necesita un bus de eventos, https://github.com/greenrobot/EventBus es mejor que Otto. Además, en algunos casos, LiveData<T> es perfectamente suficiente en lugar de usar el bus de eventos (que en lugar de emitir eventos a cualquiera, solo emite a los suscriptores).