Pregunta

Tengo el siguiente problema.Tengo esta implementación de mi Thread con Looper.

public class GeoLocationThread extends Thread{

public Handler handler;
private General general;


public void run(){
    Looper.prepare();       
    handler = new IncomingHandler(general);
    Looper.loop();          

}

public GeoLocationThread(General general){
    this.general=general;
}



private static class IncomingHandler extends Handler{
    private final WeakReference<General> mService; 

    IncomingHandler(General service) {
        mService = new WeakReference<General>(service);
    }

    @Override
    public void handleMessage(Message msg)
    {
         General service = mService.get();
         if (service != null) {
             Location location=service.getLl().getLocation();
                if(location.getAccuracy()<40){                                                                                      
                    service.setOrigin(new GeoPoint((int) (location.getLatitude() * 1E6),(int) (location.getLongitude() * 1E6)));
                }
         }
    }

}

}

y me gustaría hacer lo siguiente:

GeoLocationThread locationThread=new GeoLocationThread(this);
locationThread.start();
lm.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, ll, locationThread.handler.getLooper());

Donde lm es LocationManager.De mi registro y pruebas puedo decir que locationThread.handler.getLooper() devuelve nulo en lugar del Looper.

No sé por qué es nulo.he tratado de llamar locationThread.isAlive() que ha vuelto verdadero.También he intentado conseguir locationThread.handler; que sé que no es nulo.También busqué mucho en Google, pero no encontré más que la documentación.

Muchas gracias de antemano por sus respuestas.

¿Fue útil?

Solución

Tu código está leyendo null muy probablemente porque las dos operaciones no están sincrónicas entre sí.No puedes llamar exitosamente getLooper() en un Handler hasta Looper.prepare() está terminado y el Handler está construido.Porque Thread.start() no se bloquea mientras se ejecuta el otro hilo (por supuesto, ¿por qué lo haría?eso anularía el propósito del nuevo hilo) ha creado una condición de carrera entre el run() bloque del hilo y el código que intenta configurar el detector de ubicación.Esto producirá diferentes resultados en diferentes dispositivos según quién pueda ejecutar primero.

Además, el registro de actualizaciones de ubicación ya es un proceso asincrónico, por lo que uno se pregunta por qué se necesita el subproceso secundario.Simplemente puede solicitar actualizaciones a su oyente sin pasar un secundario Looper y el oyente obtendrá datos publicados cuando haya nuevas actualizaciones disponibles, el hilo principal no permanece bloqueado durante este proceso.

Otros consejos

¿Tienes que llamar a super() en tu constructor?¿Quizás el Looper no se está configurando porque no se llama al constructor principal?

Bien, prueba esto.Hacer esto:

public class GeoLocationThread extends Thread{

ser esto:

public class GeoLocationThread extends HandlerThread{

entonces puedes hacer this.getLooper() cuando construyas el Handler o cuando necesites el looper.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top