Closed remulasce closed 9 years ago
One thing to look at is the "searching" progress spinner on the autocomplete field.
It correctly starts/ends when text is being searched, but there's a delay before the dropdown is actually shown, but the progressbar has already stopped spinning.
So it would be nice to either improve the dropdown performance to match the sql search, or to make the progress spinner actually match when stuff is happening.
Ugh. Progress spinner problems seem to be Android's fault.
Multiple Filter calls will be sent off if you enter multiple letters at once. When the first results come in, the progressbarthing is currently made invisible. That means there could be subsequent letters that have not been filtered. The fxn I was using to check for this is meant for something else entirely (thanks Stack Overflow, you dun goofed me up).
So the issue is, the Filter won't tell me what things it actually filtered! And, the threadpool-deal the Filterable manager uses will kill off filter tasks when new ones arrive, so I can't count how many filter requests I've sent off minus the number that return back. So I can't tell if there's susequent filter requests in progress.
So I need to find out how to track how many requests are out, or what text was actually filtered from the last Filterable.
Which means more research before I decide what to do.
I'm looking at maybe calling a new DoneFiltering(String text) function on ProgressView, from the Filter, in the filter's PublishResults.
That should allow me to send over what text has been actually filtered.
But there's still questions I have about the actual order all these fxns are called in. It may be easier than I think.
Ok, implemented that, and it works.
Most of the performance stuff is in the platform-specific code.
So we might as well boot up the profiler while we can't work on java_core.