Ejecutable se registró con éxito pero no corre

Question

En un proyecto existente Android que he encontrado el siguiente fragmento de código (donde inserté la camada depuración)

ImageView img = null; 

public void onCreate(...) { 

    img = (ImageView)findViewById(R.id.image); 

    new Thread() { 
     public void run() { 
      final Bitmap bmp = BitmapFactory.decodeFile("/sdcard/someImage.jpg"); 
      System.out.println("bitmap: "+bmp.toString()+" img: "+img.toString()); 
      if (!img.post(new Runnable() { 
       public void run() { 
        System.out.println("setting bitmap..."); 
        img.setImageBitmap(bmp); 
        System.out.println("bitmap set."); 
       } 
      })) System.out.println("Runnable won't run!"); 
      System.out.println("runnable posted"); 
     } 
    }.start(); 

Nuevo en el desarrollo de Android, y después de haber buscado en Google alrededor, Entiendo que esta es la forma de hacer las cosas sin bloquear el hilo principal (UI), mientras aún se configura la imagen en el hilo de la interfaz de usuario después de la decodificación. (at least according to android-developers) (que he verificado por la tala Thread.currentThread().getName() en varios lugares)

ahora veces la imagen simplemente no se presenta, única y stdout dice

I/System.out(8066): bitmap: android.graphics.Bitmap@432f3ee8 img: android.widget.ImageView@4339d698 
I/System.out(8066): runnable posted 

con no dejar rastro de los mensajes de la Runnable. Aparentemente, Runnable no hace run(), aunque img.post() devuelve true. Tirando de ImageView en onCreate() y declararlo final no ayuda.

No tengo ni idea. Simplemente establecer el mapa de bits directamente, mientras bloquea el hilo de la interfaz de usuario, arregla las cosas, pero quiero hacer las cosas bien. ¿Alguien entiende lo que está pasando aquí?

(ps. Todo esto fue observado en un Android 1.6 y el androide-3 SDK)

Answer 1

Si nos fijamos en los documentos de View.post hay algo de información relevante:

Este método se puede invocar desde fuera de la interfaz de usuario enhebrar solo cuando esta vista se adjunta a una ventana.

Puesto que usted está haciendo esto en onCreate, es probable que a veces su View no se pueden unir a la ventana todavía. Puede verificar esto anulando onAttachedToWindow y colocando algo en los registros y también registrando cuando publica. Verá que cuando la publicación falla, la llamada posterior ocurre antes del onAttachedToWindow.

Como los otros han mencionado, puede usar Activity.runOnUiThread o proporcionar su propio controlador. Sin embargo, si desea hacerlo directamente desde el View sí, sólo tiene que conseguir el View 's controlador:

view.getHandler().post(...); 

Esto es especialmente útil si usted tiene una vista personalizada que incluye algún tipo de carga en segundo plano. También existe la ventaja adicional de no tener que crear un nuevo controlador separado.

Answer 2

Creo que el problema es que está actualizando la interfaz de usuario (ImageView) con un hilo separado, lo cual no es el hilo de interfaz de usuario . La interfaz de usuario solo se puede actualizar con el subproceso UI.

Puede resolver esto mediante el uso Handler:

Handler uiHandler; 

public void onCreate(){ 
    ... 
    uiHandler = new Handler(); // This makes the handler attached to UI Thread 
    ... 
} 

luego vuelva a colocar el:

if (!img.post(new Runnable() { 

con

uiHandler.post(new Runnable() { 

para asegurarse de que el imageview se actualiza en el hilo de interfaz de usuario.

Handler es un concepto bastante confuso, Yo también me llevó horas de investigación para comprender realmente sobre esto;)

Answer 3

, no veo nada de malo, obviamente, lo que tienes ahí; llamar a View.post() debería hacer que se ejecute en el subproceso de UI. Si tu actividad se fue (quizás a través de una rotación de pantalla), tu ImageView no se actualizaría, pero aún esperaría que una entrada de registro dijera "setting bitmap ...", incluso si no pudieras verla.

Sugiero tratar lo siguiente y ver si se hace una diferencia:

1) Uso Log.d (el registrador estándar de Android), en lugar de que System.out

2) Pase su Ejecutable a la actividad. runOnUiThread() en lugar de View.post()

Answer 4

Tuve el mismo problema y el uso de view.getHandler() también falló porque el controlador no estaba presente. runOnUiThread() resolvió el problema. Es de suponer que esto realmente hace algunas colas hasta que la interfaz de usuario esté lista.

La causa para mí estaba llamando a la tarea de carga icono en una clase base y el resultado que se devuelven tan rápidamente que la clase principal no hubiera estabished la vista (getView() en el fragmento).

Soy un poco sospechoso de que falle falsamente alguna vez. ¡Pero ahora estoy listo para eso! Gracias chicos.

Answer 5

Extendí ImageView clase para resolver este problema. Recopilo los ejecutables pasados ​​a publicar mientras que la vista no está adjuntada a la ventana y en el onAttachedToWindow ejecutable recopilada.

public class ImageView extends android.widget.ImageView 
{ 
    List<Runnable> postQueue = new ArrayList<Runnable>(); 
    boolean attached; 

    public ImageView(Context context) 
    { 
     super(context); 
    } 

    public ImageView(Context context, AttributeSet attrs) 
    { 
     super(context, attrs); 
    } 

    public ImageView(Context context, AttributeSet attrs, int defStyle) 
    { 
     super(context, attrs, defStyle); 
    } 

    @Override 
    protected void onAttachedToWindow() 
    { 
     super.onAttachedToWindow(); 

     attached = true; 

     for (Iterator<Runnable> posts = postQueue.iterator(); posts.hasNext();) 
     { 
      super.post(posts.next()); 
      posts.remove(); 
     } 
    } 

    @Override 
    protected void onDetachedFromWindow() 
    { 
     attached = false; 
     super.onDetachedFromWindow(); 
    } 

    @Override 
    public boolean post(Runnable action) 
    { 
     if (attached) return super.post(action); 
     else postQueue.add(action); 
     return true; 
    } 
} 

Answer 6

utilizar el siguiente código, puede publicar su código de TrenzadoPrincipal cualquier momento y lugar, pero no depende de ninguna Context o Activity. Eso puede evitar que view.getHandler() fracaso o tediosas onAttachedToWindow() telas etc.

new Handler(Looper.getMainLooper()).post(new Runnable() { 
     @Override 
     public void run() { 
      //TODO 
     } 
    });