java - studio - ¿Cómo se detiene el código durante unos segundos en Android?

splash screen animado android studio

Question

Básicamente, necesito una pausa (basada en unos pocos segundos) para ponerla en una acción, de modo que el usuario pueda ver lo que sucede antes de que se tome la siguiente acción. Entonces para el blackjack, cuando es el turno del crupier y él decide pegar, él golpea, se agrega una carta y luego decide qué hacer. Entonces, antes de que decida qué hacer a continuación, quiero que el código se detenga para que se pueda "ver" lo que el concesionario está haciendo de esta manera. El distribuidor no completa sus acciones en menos de un segundo y el jugador solo ve Los resultados.

¡Gracias por adelantado!

Debo señalar que he intentado usar wait (insertar número aquí); pero me dice por eclipse que causa un error de interceptación de la pila o algo por el estilo y arroja una excepción, sin hacer nada: (

Bueno, esto es interesante, (la forma en que programé las cosas es "interesante" por decir lo menos) Hice el Thread.sleep (5000) y lo arrojé bajo un try catch, duerme durante 5 segundos y luego continúa haciendo el código. Sin embargo, mis actualizaciones de las vistas no se muestran hasta después de presionar un botón (Realmente está odiando la programación impulsada por eventos).

Answer 1

Aprender a pensar en términos de eventos es de hecho la clave aquí. Puedes hacerlo. :)

La primera regla es: nunca detener el hilo de UI. El hilo de la interfaz de usuario es responsable de mantener tu aplicación sensible. Cualquier trabajo que hagas allí no debería bloquear; haz lo que tienes que hacer y regresa lo más rápido posible. Definitivamente evite hacer E / S en el hilo de la interfaz de usuario. (Hay algunos lugares donde no puede ayudarlo debido a los requisitos del ciclo de vida, por ejemplo, guardar el estado de la aplicación en onPause .) Si alguna vez llama a Thread.sleep en el hilo de la interfaz de usuario, lo está haciendo mal.

Android hace cumplir esto con el error "Aplicación que no responde" (o "ANR") que el usuario ve. Cada vez que vea esto en una aplicación de Android, significa que el desarrollador hizo algo que provocó que el hilo de la interfaz de usuario se detuviera por mucho tiempo. Si el dispositivo está realmente empantanado por alguna razón, este error podría no ser culpa del desarrollador de la aplicación, pero generalmente significa que la aplicación está haciendo algo mal.

Puede usar este modelo para su ventaja publicando sus propios eventos. Esto le brinda una manera fácil de decirle a su aplicación, "haga esto más tarde". En Android, la clave para publicar sus propios eventos está en la clase Handler . El método postDelayed permite programar un Runnable que se ejecutará después de una cierta cantidad de milisegundos.

Si tienes una actividad que se parece a esto:

public class MyActivity extends Activity {
private Handler mHandler = new Handler();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mHandler.postDelayed(new Runnable() {
public void run() {
doStuff();
}
}, 5000);
}
private void doStuff() {
Toast.makeText(this, "Delayed Toast!", Toast.LENGTH_SHORT).show();
}
}

Luego, 5 segundos después de crear la actividad, verá la tostada creada en doStuff .

Si está escribiendo una View personalizada, es aún más fácil. Las vistas tienen su propio método postDelayed que hará que todo se publique en el postDelayed correcto y no es necesario que crees el tuyo.

La segunda regla es: las vistas solo se deben modificar en el subproceso de la interfaz de usuario. Esas excepciones que estás recibiendo e ignorando significan que algo salió mal y si las ignoras, es probable que tu aplicación comience a portarse mal de maneras interesantes. Si su aplicación hace la mayor parte de su trabajo en otros hilos, puede post eventos directamente en la vista que desea modificar para que las modificaciones se ejecuten correctamente.

Si tiene una referencia a su Activity desde esa parte de su código, también puede usar Activity#runOnUIThread , que hace exactamente lo que su nombre implica. Es posible que prefiera este enfoque si publicar en una sola vista no tiene sentido en contexto.

En cuanto a las actualizaciones de las vistas que no aparecen hasta que tocas un botón, ¿qué tipo de vistas son estas? ¿Son vistas personalizadas que dibujan estas actualizaciones? Si es así, ¿recuerda llamar a invalidate después de los cambios de datos para activar el redibujado? Las vistas solo se vuelven a dibujar después de haber sido invalidadas.