We have an Android app. The Android App uses Volley (https://developer.android.com/training/volley/index.html) to transmit network data.

The point though is not about Volley, is about the pattern Volley uses to execute a remote call. Example:

final TextView mTextView = (TextView) findViewById(R.id.text);

// Instantiate the RequestQueue.
RequestQueue queue = Volley.newRequestQueue(this);
String url ="http://www.google.com";

// Request a string response from the provided URL.
StringRequest stringRequest = new StringRequest(Request.Method.GET, url,
            new Response.Listener<String>() {
    public void onResponse(String response) {
        // Display the first 500 characters of the response string.
        mTextView.setText("Response is: "+ response.substring(0,500));
}, new Response.ErrorListener() {
    public void onErrorResponse(VolleyError error) {
        mTextView.setText("That didn't work!");
// Add the request to the RequestQueue.

As I said the point is not about Volley but about the pattern. I create a new Request, I put the callback in place, and when the call has finished the callback updates the UI.

Really simple.

Now, let's say that the user keeps clicking the damn button, I could generate a lot of calls. I would like to avoid that.

One solution, assuming no concurrency issues since click on the buttons are serial, would be to pass around a boolean variable that will reset to true when the callback has completed.

I don't like that solution because it coupled things a lot.

Of course this code is really simple, in production you could have a more complex class structure.

What do you think could be a better solution?

1 Answer 1


A single user dosn't generate that many calls even when feverishly clicking on an unresponsive button. However, the operating system can get backed up and then dump a bunch of clicks on you all at once.

Rather than passing around a boolean I'd timestamp the request. If this request is identical to the last one from, oh say, less than 300ms then just dump the request before adding it to the queue.

Users would be hard pressed to notice this and it ensures no more than 4 identical requests a second.

Even with this, don't ignore the unresponsiveness that is causing the users to frantically click. This is an indication that it's time to start testing for performance issues and see if they can be resolved.

  • In our case is a scroll event but I get the point. Thank you!
    – dierre
    Jul 29, 2016 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.