AutoCompleteTextView not displaying result even when the ArrayAdapter is updated

Question

I'm trying to get an AutoCompleteTextView(ACTV) to display results I'm a getting from a network resource. I have set the completion-treshold to 2 and I can see that the request is fired when I enter to characters.

The result I am getting is the correct one. Lets say I write "ca", and I get the result "car" as an autocompletion. I have a callback function which receives the result from an AsyncTask and puts the result into the ArrayAdapter. Then I call .showDropDown() on the ACTV and an empty dropdown is shown (half the size of a normal element). Then if I enter the last letter "r" and the ACTV shows "car", the dropdown is shown and the result is suddenly in the list.

The same happens if I have entered two characters (which returns a valid result), and the remove the last letter. When the letter is removed, "car" is shown as an autocompletion value.

Has anyone had this problem? It looks like the adapter is filled with the result, but the result does not show until the next action I do. I have also tried to run .notifyDataSetChanged() after I have added the result to the adapter, but that should not be needed, or?

Answer 1

Without seeing your code, it's hard to tell what could be going on. But the first thing that comes to mind is that your network request is happening on a different thread, and therefore your performFiltering() may be returning an empty result set prematurely. At that point, publishResults() is returning the empty result, and your dropdown is empty. Later, your AsyncTask will get its result back, and you add the results into the adapter's list, but for one reason or another, it doesn't get displayed yet.

I think you may be mistaken about the need for AsyncTask though. The Filter object is already doing something similar to AsyncTask: performFiltering() is done in a background thread, and publishResults() is called from the UI thread, after performFiltering() is finished. So you can do your network request directly in performFiltering(), and set the results into the FilterResults object, and you won't have to worry about the network request being too slow and causing problems in your UI.

An alternative solution, which is slightly more complicated, but it's what I'm doing in my Filter object (due to existing architecture that does API calls in the background, using an asynchronous callback instead of the blocking/synchronous step as required for performFiltering()), is to use a synchronized object with wait()/notify() for doing cross-thread monitoring, so the effect is the same as doing the network request directly in performFiltering(), but it's actually happening in multiple threads:

// in Filter class..
protected FilterResults performFiltering(CharSequence constraint) {

    APIResult response = synchronizer.waitForAPI(constraint);
    // ...
}

// callback invoked after the API call finishes:
public void onAPIComplete(APIResult results) {
    synchronizer.notifyAPIDone(results);
}

private class Synchronizer {
    APIResult result;

    synchronized APIResult waitForAPI(CharSequence constraint) {
        someAPIObject.startAsyncNetworkRequest(constraint);
        // At this point, control returns here, and the network request is in-progress in a different thread.
        try {
            // wait() is a Java IPC technique that will block execution until another
            // thread calls the same object's notify() method.
            wait();
            // When we get here, we know that someone else has just called notify()
            // on this object, and therefore this.result should be set.
        } catch(InterruptedException e) { }
        return this.result;
    }

    synchronized void notifyAPIDone(APIResult result) {
        this.result = result;
        // API result is received on a different thread, via the API callback.
        // notify() will wake up the other calling thread, allowing it to continue
        // execution in the performFiltering() method, as usual.
        notify();
    }
}

However, I think you may find that the easiest solution is to just do your network request synchronously, directly in the performFiltering() method. The above code example is just one possibility, if you already have the architecture in place for asynchronous/callback-driven API calls, and you don't want to change that behavior in order to get synchronous results in performFiltering().

Answer 2

I think Joe's answer is the way to go. However, I think you should use CountDownLatch instead of wait/notify.

The reason is, with wait/notify, you risk a race condition if your API actually return super fast before you start "wait()"... in this case, notify won't have an effect and wait() will wait indefinitely. With Latch, the code will look like this (copied from Joe and modified):

// in Filter class..
protected FilterResults performFiltering(CharSequence constraint) {
  APIResult response = synchronizer.waitForAPI(constraint);
  // ...
}

// callback invoked after the API call finishes:
public void onAPIComplete(APIResult results) {
  synchronizer.notifyAPIDone(results);
}

private class Synchronizer {
  APIResult result;
  CountDownLatch latch;

  synchronized APIResult waitForAPI(CharSequence constraint) {
      latch = new CountDownLatch(1);
      someAPIObject.startAsyncNetworkRequest(constraint);
      // At this point, control returns here, and the network request is in-progress in a different thread.
      try {
        // Will wait till the count is 0...
        // If the count is already 0, it'll return immediately. 
        latch.await();
        // When we get here, we know that someone else has just called notify()
        // on this object, and therefore this.result should be set.
    } catch(InterruptedException e) { }
    return this.result;
  }

  synchronized void notifyAPIDone(APIResult result) {
    this.result = result;
    // API result is received on a different thread, via the API callback.
    // countDown() will wake up the other calling thread, allowing it to continue
    // execution in the performFiltering() method, as usual.
    latch.countDown();
  }
}

Lastly, I don't have enough credit to post a comment, otherwise I would have...