Tengo una actividad en Android que necesita llamar a otra actividad (para obtener una contraseña del usuario) antes de que aparezca su propia pantalla. Mi código actualmente lo hace llamando a startActivity() desde adentro on Resume(); funciona, pero he estado teniendo un comportamiento incoherente. ¿Alguien puede decirme si este enfoque es legal o no (y si no, cómo debería hacerlo)?¿Puedo llamar a startActivity() desde dentro onResume()?
Gracias, Richard.
Calling startActivity() en onResume() es absolutamente bien. Tengo muchas actividades que hacen esto, a menudo en reacción a eventos que han sucedido mientras se detenía la actividad.
Todo indica startActivity() decirle a Android que comience la nueva actividad y la agregue a la parte superior de la pila cuando el hilo principal esté disponible, que en este caso será cuando Android haya terminado de llamar a todas las devoluciones de llamada del ciclo de vida Actividad actual.
Si está experimentando un comportamiento extraño, dudo que esté relacionado con esto.
Puede llamar a startActivity() desde onResume() pero es una llamada asincrónica. Entonces onResume() (y los otros métodos de la actividad actual) seguirán ejecutándose hasta que el sistema operativo Android se desplace a su llamada asincrónica startActivity() y comience la nueva actividad.
El comportamiento inconsistente que está experimentando probablemente esté relacionado con su actividad que continúa durante un período de tiempo indefinido hasta que el SO carga la nueva actividad.
'startActivity()' es asíncrono, pero eso significa que es no-bloqueante, no que está bloqueando, y 'onResume()' continúa inmediatamente después de la llamada, no espera a la otra actividad. – Frxstrem
De hecho es legal, pero dependiendo de lo que quieras hacer exactamente, puede ser poco práctico. Una forma común es comenzar con su "segunda" actividad como se definiría en el manifiesto y luego entregarla a la primera actividad. Otra forma más sería iniciar una actividad para obtener un resultado en, por ejemplo, onCreate(), que se puede hacer incluso antes de llamar a cualquier setContentView(). Hay muchas formas de hacer esto, así que creo que necesitamos un poco más de información para poder brindar una respuesta más precisa.
No parece una buena idea.
Algunas alternativas:
para pedir la contraseña, se puede utilizar un cuadro de diálogo en lugar de una actividad.
por qué no siempre pasan a través de esta actividad intermedia. En caso no hay necesidad de pedir una contraseña que podría mostrar algo más, como una animación mientras se conecta al servicio (suponiendo que la contraseña es una cosa a la red)
La contraseña descifra el contenido que muestra la actividad, por lo que preferiría tener la contraseña disponible antes de mostrar los datos.No tengo ninguna opción sobre el orden de la actividad porque este problema ocurre cuando la orientación de la pantalla cambia (borro deliberadamente la contraseña cuando se destruye la actividad). – user1163984
¿Los usuarios aceptan tener que volver a ingresar su contraseña cada vez que encienden el dispositivo? –
Bueno, en este caso, soy el usuario. Pero sí, necesito encontrar una manera de evitar que eso suceda con el cambio de orientación de la pantalla. – user1163984
¿Define _inconsistent_ behavior? –
Las rarezas se producen cuando la actividad se destruye y se vuelve a crear al cambiar la orientación de la pantalla. Pasar de vertical a horizontal produce una secuencia diferente de llamadas a los métodos de las dos actividades (detener, reanudar y demás) que al revés, y la secuencia es diferente nuevamente bajo el depurador; Sospecho que hay algún tipo de condición de carrera. También me he dado cuenta de que Logcat tiene quejas de 'currículum inesperado mientras se reanuda' de system_process. – user1163984