2010-01-16 20 views
5

Estoy escribiendo una aplicación que básicamente es un contenedor alrededor de 250K JNI. El JNI (un motor de juego) tiene API como handle_penUp (int x, int y). Algunas veces necesita consultar al usuario desde dentro handle_penUp() (a través de devoluciones de llamada en código Java), por lo que el diálogo que utilizo para implementar la consulta debe bloquear.Cuadro de diálogo de bloqueo desde el código JNI

Entiendo que el hilo principal de ejecución no puede bloquear. Así que he generado un segundo hilo que realiza todas las llamadas JNI que pueden dar lugar a devoluciones de llamadas que deberían bloquearse. Dentro de ese segundo hilo, cuando necesito poner un diálogo de bloqueo, llamo a startActivityForResult() y luego a acquire() en un semáforo. Cuando se llama a onActivityResult() en el hilo principal, se llama a release() en el mismo semáforo.

Esto funciona si mi consulta se implementa como una nueva actividad, pero no si quiero mostrar el diálogo() dentro de la actividad existente. Los mensajes de registro me dicen que mi hilo necesita un Looper. Agregaré uno y anexaré información sobre si funciona, pero parece que voy por el camino equivocado. Lo que necesito es una receta para hacer diálogos de bloqueo (útil solo porque cada otra plataforma los tiene y por lo tanto el código portado funcionará de esa manera.)

Respuesta

0

Definitivamente no desea dos subprocesos de interfaz de usuario. Solo debe haber un hilo que se comunique con el SDK de Android en lo que respecta al flujo de control y la pantalla (es decir, todo lo relacionado con el dibujo, las actividades de inicio, la visualización de cuadros de diálogo, etc.).

Además, tenga en cuenta que no desea mantener realmente el hilo ejecutándose: todo se basa en eventos, por lo que desea que su código responda a algo, haga algo y luego salga lo antes posible.

Cuando dices "bloquear", ¿qué quieres decir exactamente? ¿Qué necesita ser bloqueado? Si simplemente necesita dejar de responder a los eventos, ¿por qué no tiene un valor booleano establecido en verdadero mientras el cuadro de diálogo está visible y simplemente ignora todos los eventos mientras es verdadero?

+0

probablemente bloque como en el bloqueo frente a no bloquear io (la llamada no se devuelve hasta ha obtenido la entrada solicitada o ha fallado, versus haber regresado inmediatamente e informar cualquier entrada si alguna ya estaba en un buffer) –

2

Suena muy cerca de un problema que tuve al configurar alguna vista visible/invisible desde el hilo táctil.

el problema es que no se puede hacer algunas operaciones en la GUI formar otro hilo (que es su caso)

lo que hay que hacer es usar una manija en su hilo principal lo declaré en la Actividad

public static final Handler handlerVisibility = new Handler() { 
    public void handleMessage(Message msg) { 
     int visibility = msg.getData().getInt("visibility"); 
     view.setVisibility(visibility); 
    } 
}; 

he elegido la opción de estática pública para que pueda acceder en cualquier lugar (porque no tengo más que una llamada a la vez y que me sentía perezoso para pasar a lo largo de las subclases).

entonces lo que quiere hacer es enviar un mensaje a este controlador y desde el controlador está en la misma rosca que la interfaz gráfica de usuario funciona ^^

Message msg = MainActivity.handlerVisibility.obtainMessage(); 
    Bundle b = new Bundle(); 
      b.putInt("visibility", View.VISIBLE); 
    msg.setData(b); 
      MainActivity.handlerVisibility.sendMessage(msg); 

Esto debería resolver su error looper y le permiten a enviar solicitud interfaz gráfica de usuario de un hilo a otro

creo que sirve

Jason

Cuestiones relacionadas