@Background y la rotación de la pantalla cuando se utiliza AndroidAnnotations, ¿cómo asegurarse de que las devoluciones de llamada se reciben?
Cuando usamos la anotación @Background, comenzamos un nuevo subproceso. Y si durante este hilo se ejecuta en el lugar de rotar la pantalla, vamos a perder la devolución de llamada de ese hilo o cómo se maneja? Con los cargadores esto se soluciona detrás de la pantalla así que no tenemos que preocuparnos de los problemas que ocurrieron con frecuencia cuando utilizamos tareas asíncronas.
¿Pero cómo la anotación de @Background trata con esto?
- ¿Es posible generar una clase interna de una clase para compilar con un procesador de anotación?
- Java - ¿Utilizar anotaciones e interceptar métodos?
- Dile a Proguard que mantenga la anotación en los métodos
- No obtener fuentes procesadas (generadas) de anotación compiladas en apk, usando maven
- @NonNull y anotaciones @Nullable - ¿Afecta el rendimiento en Android?
- Android Studio Annotation AbstractProcessor no encontrado
- Problema con ProGuard y RoboGuice con anotaciones de @Inject
- Android studio + Gradle + Android Anotaciones
- Lint falla en la compilación con el error de seguridad "WrongConstant: Incorrect constant". Anotación de IntDef
- Cómo guardar anotaciones en pdf protegido por contraseña usando MuPDF
- ¿Cuáles son los usos correctos de @NonNull y @Nullable?
- Eliminación post-compilación de anotaciones del código de bytes
- Anotaciones de método Android para evitar que la llamada se realice en el subproceso de GUI
En primer lugar, cuando se utiliza la anotación @Background, el código se ejecuta en un subproceso separado, pero esto no significa necesariamente que se inicie un subproceso nuevo, ya que utilizamos un grupo de subprocesos común (que se puede reemplazar) para Todos los métodos @Background.
Como un AsyncTask, @Background no controla ningún cambio en el ciclo de vida de sus actividades. Por lo tanto, si llama a un método @Background y luego la pantalla se gira, entonces el código @Background se ejecutará, no importa qué, en la instancia en la que fue llamado. Si @Background se coloca en un método que pertenece a la actividad y, a su vez, llama a un método @UiThread, existe el riesgo de que el método @UiThread se active en la instancia de actividad incorrecta si se produce un cambio de configuración.
En Android, antes de Cargadores, la forma usual de manejar eso era usar AsyncTask, mantener referencias a esas tareas en onRetainNonConfigurationInstance () y volver a enlazarlas con la nueva actividad después de un cambio de configuración.
En la última versión, AndroidAnnotations proporciona la anotación de instancia @NonConfiguration, que se puede combinar con @EBean / @Bean y @Background para lograr el mismo efecto.
Aquí hay un código de ejemplo (no probado, escrito desde gmail):
@EActivity public class MyActivity extends Activity { // Using @NonConfigurationInstance on a @Bean will automatically update the context ref on configuration changes (if the bean is not a singleton) @NonConfigurationInstance @Bean MyBackgroundTask task; @Click void myButtonClicked() { task.doSomethingInBackground(); } void showResult(MyResult result) { // do something with result } } @EBean public void MyBackgroundTask { @RootContext MyActivity activity; @Background void doSomethingInBackground() { // do something MyResult result = XXX; updateUI(result); } // Notice that we manipulate the activity ref only from the UI thread @UiThread void updateUI(MyResult result) { activity.showResult(result); } } Creo que podríamos proporcionar soluciones aún mejores, pero hay muchos casos de uso diferentes, y tenemos que pensar en todos ellos. Así que ahora, @Background tiene un comportamiento muy simple y no quiero cambiar eso. Sin embargo, podríamos introducir nuevas anotaciones con un comportamiento avanzado de "hilo + ciclo de vida".
Gracias a "Pierre-Yves Ricau" por proporcionar esta respuesta a través de googlegroup para androidannotations. Espero que esto ayude a otros que podrían quedar atascados con un problema similar.