¿Puedo hacer una solicitud sincrónica con volley?

Imagine que estoy en un servicio que ya tiene un hilo de fondo. ¿Puedo hacer una solicitud usando volley en ese mismo hilo, para que las devoluciones de llamada se realicen sincrónicamente?

Hay 2 razones para esto: - Primero, no necesito otro hilo y sería un desperdicio crearlo. - Segundo, si estoy en un ServiceIntent, la ejecución del subproceso finalizará antes de la devolución de llamada y, por lo tanto, no tendré respuesta de Volley. Sé que puedo crear mi propio servicio que tiene algún hilo con un runloop que puedo controlar, pero sería deseable tener esta funcionalidad en volea.

¡Gracias!

Parece que es posible con la RequestFutureclase de Volley . Por ejemplo, para crear una solicitud JSON HTTP GET síncrona, puede hacer lo siguiente:

RequestFuture<JSONObject> future = RequestFuture.newFuture();
JsonObjectRequest request = new JsonObjectRequest(URL, new JSONObject(), future, future);
requestQueue.add(request);

try {
  JSONObject response = future.get(); // this will block
} catch (InterruptedException e) {
  // exception handling
} catch (ExecutionException e) {
  // exception handling
}

Tenga en cuenta que la respuesta de @Matthews es correcta PERO si está en otro subproceso y realiza una llamada de volea cuando no tiene Internet, su devolución de llamada de error se llamará en el subproceso principal, pero el subproceso en el que se encuentre se bloqueará PARA SIEMPRE. (Por lo tanto, si ese hilo es un IntentService, nunca podrá enviarle otro mensaje y su servicio estará básicamente muerto).

Utilice la versión de get()que tiene un tiempo de esperafuture.get(30, TimeUnit.SECONDS) y detecte el error para salir de su hilo.

Para coincidir con la respuesta de @Mathews:

        try {
            return future.get(30, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
            // exception handling
        } catch (ExecutionException e) {
            // exception handling
        } catch (TimeoutException e) {
            // exception handling
        }

A continuación lo envolví en un método y uso una solicitud diferente:

   /**
     * Runs a blocking Volley request
     *
     * @param method        get/put/post etc
     * @param url           endpoint
     * @param errorListener handles errors
     * @return the input stream result or exception: NOTE returns null once the onErrorResponse listener has been called
     */
    public InputStream runInputStreamRequest(int method, String url, Response.ErrorListener errorListener) {
        RequestFuture<InputStream> future = RequestFuture.newFuture();
        InputStreamRequest request = new InputStreamRequest(method, url, future, errorListener);
        getQueue().add(request);
        try {
            return future.get(REQUEST_TIMEOUT, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
            Log.e("Retrieve cards api call interrupted.", e);
            errorListener.onErrorResponse(new VolleyError(e));
        } catch (ExecutionException e) {
            Log.e("Retrieve cards api call failed.", e);
            errorListener.onErrorResponse(new VolleyError(e));
        } catch (TimeoutException e) {
            Log.e("Retrieve cards api call timed out.", e);
            errorListener.onErrorResponse(new VolleyError(e));
        }
        return null;
    }

Probablemente se recomienda usar los Futuros, pero si por alguna razón no desea hacerlo, en lugar de cocinar su propio bloqueo sincronizado, debe usar a java.util.concurrent.CountDownLatch. Entonces eso funcionaría así ...

//I'm running this in an instrumentation test, in real life you'd ofc obtain the context differently...
final Context context = InstrumentationRegistry.getTargetContext();
final RequestQueue queue = Volley.newRequestQueue(context);
final CountDownLatch countDownLatch = new CountDownLatch(1);
final Object[] responseHolder = new Object[1];

final StringRequest stringRequest = new StringRequest(Request.Method.GET, "http://google.com", new Response.Listener<String>() {
    @Override
    public void onResponse(String response) {
        responseHolder[0] = response;
        countDownLatch.countDown();
    }
}, new Response.ErrorListener() {
    @Override
    public void onErrorResponse(VolleyError error) {
        responseHolder[0] = error;
        countDownLatch.countDown();
    }
});
queue.add(stringRequest);
try {
    countDownLatch.await();
} catch (InterruptedException e) {
    throw new RuntimeException(e);
}
if (responseHolder[0] instanceof VolleyError) {
    final VolleyError volleyError = (VolleyError) responseHolder[0];
    //TODO: Handle error...
} else {
    final String response = (String) responseHolder[0];
    //TODO: Handle response...
}

Como la gente parecía tratar de hacer esto y se encontró con algunos problemas, decidí que en realidad proporcionaría una muestra de trabajo de la "vida real" de esto en uso. Aquí está https://github.com/timolehto/SynchronousVolleySample

Ahora, aunque la solución funciona, tiene algunas limitaciones. Lo más importante, no puede llamarlo en el hilo principal de la interfaz de usuario. Volley ejecuta las solicitudes en segundo plano, pero de forma predeterminada, Volley utiliza Looperla aplicación principal para enviar las respuestas. Esto provoca un punto muerto ya que el subproceso principal de la interfaz de usuario está esperando la respuesta, pero Looperestá esperando onCreateque termine antes de procesar la entrega. Si realmente desea hacer esto, podría, en lugar de los métodos auxiliares estáticos, crear una instancia de su propia RequestQueuetransmisión y pasarla ExecutorDeliverya un Handleruso Looperque esté vinculado a un hilo diferente del hilo principal de la interfaz de usuario.

Como observación complementaria a ambos @Blundells y @Mathews respuestas, no estoy seguro de cualquier llamada se entrega a cualquier cosa , pero el hilo principal mediante voleo.

La fuente

Al echar un vistazo a la RequestQueueimplementación , parece que RequestQueueestá utilizando a NetworkDispatcherpara ejecutar la solicitud y a ResponseDeliverypara entregar el resultado ( ResponseDeliveryse inyecta en el NetworkDispatcher). A ResponseDeliverysu vez, se crea con un Handlerengendro del hilo principal (en algún lugar alrededor de la línea 112 en la RequestQueueimplementación).

En algún lugar sobre la línea 135 en la NetworkDispatcherimplementación , parece que también se entregan resultados exitosos a través de lo mismo ResponseDeliveryque cualquier error. De nuevo; una ResponseDeliverybasada en una Handlerfreza desde el hilo principal.

Razón fundamental

Para el caso de uso en el que se debe realizar una solicitud, es IntentServicejusto asumir que el hilo del servicio debe bloquearse hasta que tengamos una respuesta de Volley (para garantizar un alcance de tiempo de ejecución vivo para manejar el resultado).

Las soluciones sugeridas

Un enfoque sería anular la forma predeterminada en que RequestQueuese crea a , donde se utiliza un constructor alternativo, inyectando uno ResponseDeliveryque se genera a partir del hilo actual en lugar del hilo principal. Sin embargo, no he investigado las implicaciones de esto.

Utilizo un candado para lograr ese efecto. Ahora me pregunto si es correcto para mí ¿alguien quiere comentar?

// as a field of the class where i wan't to do the synchronous `volley` call   
Object mLock = new Object();


// need to have the error and success listeners notifyin
final boolean[] finished = {false};
            Response.Listener<ArrayList<Integer>> responseListener = new Response.Listener<ArrayList<Integer>>() {
                @Override
                public void onResponse(ArrayList<Integer> response) {
                    synchronized (mLock) {
                        System.out.println();
                        finished[0] = true;
                        mLock.notify();

                    }


                }
            };

            Response.ErrorListener errorListener = new Response.ErrorListener() {
                @Override
                public void onErrorResponse(VolleyError error) {
                    synchronized (mLock) {
                        System.out.println();
                        finished[0] = true;
                        System.out.println();
                        mLock.notify();
                    }
                }
            };

// after adding the Request to the volley queue
synchronized (mLock) {
            try {
                while(!finished[0]) {
                    mLock.wait();
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

Quiero agregar algo a la respuesta aceptada de Matthew. Si bien RequestFuturepuede parecer que realiza una llamada sincrónica desde el subproceso que lo creó, no lo hace. En cambio, la llamada se ejecuta en un hilo de fondo.

Por lo que entiendo después de pasar por la biblioteca, las solicitudes en el RequestQueuese envían en su start()método:

    public void start() {
        ....
        mCacheDispatcher = new CacheDispatcher(...);
        mCacheDispatcher.start();
        ....
           NetworkDispatcher networkDispatcher = new NetworkDispatcher(...);
           networkDispatcher.start();
        ....
    }

Ahora ambos CacheDispatchery NetworkDispatcherclases extienden hilo. De manera efectiva, se genera un nuevo subproceso de trabajo para eliminar la cola de solicitudes y la respuesta se devuelve a los escuchas de éxito y error implementados internamente por RequestFuture.

Aunque se alcanza su segundo propósito, pero su primer propósito no lo es, ya que siempre se genera un nuevo hilo, sin importar desde qué hilo ejecute RequestFuture .

En resumen, la solicitud síncrona verdadera no es posible con la biblioteca Volley predeterminada. Corrígeme si estoy equivocado.

Puede hacer una solicitud de sincronización con volley pero debe llamar al método en un hilo diferente o su aplicación en ejecución se bloqueará, debería ser así:

public String syncCall(){

    String URL = "http://192.168.1.35:8092/rest";
    String response = new String();



    RequestQueue requestQueue = Volley.newRequestQueue(this.getContext());

    RequestFuture<JSONObject> future = RequestFuture.newFuture();
    JsonObjectRequest request = new JsonObjectRequest(Request.Method.GET, URL, new JSONObject(), future, future);
    requestQueue.add(request);

    try {
        response = future.get().toString();
    } catch (InterruptedException e) {
        e.printStackTrace();
    } catch (ExecutionException e) {
        e.printStackTrace();
    } catch (JSONException e) {
        e.printStackTrace();
    }

    return response;


}

después de eso puedes llamar al método en hilo:

 Thread thread = new Thread(new Runnable() {
                                    @Override
                                    public void run() {

                                        String response = syncCall();

                                    }
                                });
                                thread.start();