¿Hay alguna razón para no llamar a setIntent al anular onNewIntent?

Question

Al experimentar un problema similar al this question, comencé a preguntarme por qué tenemos que llamar explícitamente al setIntent al anular onNewIntent, y por qué este código no se realiza ya por super.onNewIntent.

@Override 
public void onNewIntent(Intent intent) 
{ 
    super.onNewIntent(intent); 

    // Why isn't this performed by the framework in the line above? 
    setIntent(intent); 
} 

Answer 1

Intent objetos se adjuntan constantemente al Activity, Service y otros componentes mientras estos componentes se estén ejecutando. No simplemente desaparecen porque te mudaste a otra aplicación. La razón de esto es porque Android puede matar el proceso en cualquier momento, pero el usuario puede querer regresar y continuar lo que estaba haciendo. Esto hace que Intents sea ideal para almacenar o transmitir bits de información pequeños (ya veces grandes), a través de los Extras.

El método onNewIntent() es específicamente para manejar componentes de aplicación que son más persistentes y por lo tanto se puede llamar más de una vez durante su LifeCycle pero necesita realizar un seguimiento de los motivos por los que se invocó. . Si llama al setIntent() o no depende de lo que necesite hacer.

Si no le importa por qué se llamó posteriormente, puede conservar el Intent original al no llamar al setIntent(). Esto es particularmente útil cuando su Activity (o algún otro componente) hace lo mismo sin importar quién lo llamó y qué datos proporciona.

Si tiene que responder individualmente a cada evento, al menos debe almacenar la información nueva de Intent. Esto significa que puede evitar setIntent(), sin embargo, ninguno de los componentes a los que enlaza tendrá información de Intent a menos que se lo envíe directamente. Este puede ser el comportamiento deseado para una aplicación que no puede asegurar que el original Intent se manejó completamente.

Si tiene que responder a cada uno de forma individual Intención y el original Intent no importa, a continuación, utiliza setIntent(). Esto descarta el original Intent, que todavía está allí ... y coloca el nuevo Intent de modo que si el usuario se aleja (una vez más), volverán al mismo lugar.

La razón por la cual super.onNewIntent() no maneja esto es porque las clases de componentes principales no pueden determinar si la nueva Intent es o no más importante que la anterior. Todo lo que le importa es que tiene un Intent, no es lo que es. Es por esto que anulamos métodos como estos, de modo que nosotros determinamos lo que es importante y lo que no. La sensación general es que las clases base como Activity pueden usar cualquier dato que tengamos, de la forma que quiera (a menos que anulemos y le digamos lo contrario). Sin embargo, no deberían (y a menudo no pueden) deshacerse de nuestros datos a menos que les indiquemos específicamente. Este es un argumento que realmente no desea tener con algunos programadores. jeje

Espero que esto ayude.

Answer 2

la documentación para el estado onNewIntent: "Tenga en cuenta que getIntent() sigue devolviendo la intención original Puede utilizar setIntent (Intención) para actualizar a este nuevo intento.". Supongo que existe OnNewIntent para que su actividad pueda ser notificada y el super probablemente no haga nada.

Answer 3

Acabo de eliminar el código setIntent(intent) de mi onNewIntent(Intent intent) implementación.

Motivo: My MainActivity is single top. Mientras mi aplicación se ejecuta, inicia otras actividades, como la actividad de la cámara. Cuando la aplicación vuelve a la actividad principal, en onResume() el (último) intento devuelto por getIntent() se volvería a procesar incluso si ya se hubiera procesado antes.

Mi nueva implementación (trabajando hasta ahora): Almacena la intención desde onNewIntent(Intent intent) en un campo de instancia privada. En onResume, marque este campo para no nulo y reinícielo inmediatamente a nulo, procesando el intento una vez y solo una vez.

Ver también https://groups.google.com/forum/#!topic/android-developers/vrLdM5mKeoY