Problem with the search results of listview

Hello there. After the listview element update i have seen a bug: after the list of all elements is loaded, if i search a word or number that is contained in multiple line i can't see all of them in the result list.
Explaining better, if i know that in my list there are 6 lines where there is the word "red" and i serch "red" i get only 4 results, for example. I noticed that if i add more height to the listview element to have more lines, then all the results appear, but the element listview is scrollable so the height shouldnt be a problem i guess.
Anyone has experienced the same issue?
thanks for the support

1 Like

Could you try exporting and importing your project into the App Inventor Test Server, building the new Companion, and seeing if it works there?

1 Like

yeah, i am already working on the test server, still i have the bug

1 Like

Thanks for the report; maybe someone could file an issue on GitHub?

1 Like

Please provide a sample aia project that replicates this behaviour
(note: I did a bit of testing on the ai2-test server and got a similar issue, with not all results being returned on scroll, and then the previous results changing when scrolling back up. You can test this here: It produced the same result when testing on n187d)


From now, everything was working properly, but since this new release, search filter is sooo long processing with my 7000 words list.
So bad...

1 Like

Since nb188?
Filter too long? How much time did it take prior to nb188 to search your ListView and how long does it take now.

What you can do:

  • realize there are trade offs to create a ListView with more features than previously.
  • provide the developers with an example showing timing before and after the change so they can see if anything can be done to improve filtering speed.
  • filter your List using Blocks instead of the ListView. One way described by Sajal
  • port your ListView List to a ListPicker, then perform your filter / search in the ListPicker. The ListPicker component has not changed.
  • get a new Android with a faster processor perhaps?
  • use javascript to filter your List.
1 Like

Currently filtering is done with Liner Search algorithm so it may be take to long time to process 8000 items.

1 Like

If you can sort your search list, this might speed up an external search ...


Thanks for answering me.

It take nearly 3-5 seconds to filter the 7000 words list. (It was instantly made before this new release)

Li already try to use blocks, but it takes too much time to proceed.

Listpicker is not exactly what i need

My android phone seems to have enough speed power.

Here is my original apk working properly
Please notice that first load is a bit long, wich is totally normal.

As you will see, search bar is efficient

1 Like

By the way, about your tutorial, used language is "shimaore". This is my own csv file used in your example.
Now i would say that i actually use tinydb that is really faster than using a csv file.


What do you mean when you say "currently"?
Because before this new release, everithing was right and made instantly...

Release nb187 (August 22) included improved performance of ListView using the RecyclerView library (@27vinayvyas) The 'new' version of ListView adds significant new functionality,. including the ability to display an image and detail text. It is probable these additional functionalities slow the filtering.

Your screen in your "original apk" looks like

where the Search list box displays 'properly' whereas currently the Search List box displays with a black background. Did you create your GooglePlay version using the test server?

I am trying to establish when your app filtering was last working 'fast' versus 'slow' (what dates). Wwhat might have changed in the nb188 release of App Inventor (Nov 11) when MIT ( @Susan_Lane )

  • Fixed ListView filter functionality to handle backspacing/clearing
  • Cleaned up code issues in ListView and implement some unit tests
  • and broke the ListView Filter background

It appears these changes might have affected filtering speed performance.

I'm looking at this.

One unfortunate possibility is that the fast filtering from the previous release was actually a bug that changed when I fixed the backspace/clearing issue. It took a surprising amount of work to keep the filter results accurate for all our tests. I'm not sure all the CardView/RecyclerView methods work exactly as intended.

ListView may not be the right solution for searching 7000 records.

@Susan_Lane i got some solution to increase the searching speed of the ListView.

  1. as you see in this code when the text of the filter-bar was changed it will change ListView data but onTextChanged() method is continues I mean text changing process is going on but instead of this we can call it through afterTextChanged(), so it will call only after text changed it means text changing process was completed.

  2. when ever the user search in filter-bar it will render new items from data and then add them to recyclerView. for more information you can check this thread on android documentation

A possibility to decreased filtering speed may be how the Filter works.

At present, my test bed on a Samsung Android 8.1 works like this:

  • type a letter; and the LV filters the entire list.
  • type another letter; and the LV again filters the entire list. Perhaps it should not filter until Done is pressed on the keyboard?
  • when you use the keyboard pop up to select Done, the ListFilter does not clear text as it should
  • when DeviceDefault Theme is set, the LV filter area displays as Black and text typed in the LV filter cannot be seen . When switching to Classic Theme, the search box 'appears'.

Evidently it was adequate after nb187 and prior to nb188 :cry:

I worked with notifyDataSetChanged and didn't find that it made any difference. However, I tried a lot of combinations of things, and there are more things to try. I didn't do anything with afterTextChanged because the filter for the previous version of ListView used onTextChanged.

If you want to try out your idea and put up a draft PR, I'll be glad to take a look.

@Susan_Lane also there are properties required for ListView and some issues are there regarding UI, I have created issue see this for that and one small design docs can you please check it, here is the link..

Okay sure i will put PR on this.

The progressive search on each character is part of the ListView design, and this is how it worked before the upgrade. It's not a great way to search 7000 records, but it's not designed for that use case.

Since filter was not working properly after the upgrade, it's quite possible that it was only adequate with the old, single-string version of ListView.