0

I have the following task to do, I need to build a live search from an endpoint.

Now, the thing is I know how to do it but, what I don't know, is how to do it efficient. The small app should do the following:

  1. Live search from a specific endpoint - a list of over 2000 objects in a json request.
  2. While loading, the app should display a spinner.
  3. Refresh the autocomplete list view.

The only solution I know is the following:

I add a menu to the action bar where I add the search view. Inside the activity I will have a fragment with a list view (better when I want to add some clicking on the items), and when the user searches for something (e.g, "around, "a" first, then "ar", etc) then a new request to the server will be made and all the objects that start with "a" will be loaded to the listview and from then on autocomplete will do its work.

In this way I need to load all the data that contain "a" and filter from there.

Now the problem for me is that I need to parse every time the json file, and it is possible I only need 3 records.

As an improvement, I thought of somehow filtering the json big file and retrieving only the json file that I need, but I am not sure if this is possible and if so at what cost.

Does anyone know a better solution?

Lukas Knuth
  • 25,449
  • 15
  • 83
  • 111
Andrei T
  • 2,985
  • 3
  • 21
  • 28
  • persist your json data in an sqlite db, and then perform your search on that – pskink Jun 05 '15 at 19:19
  • Do you have any control over the server-side component? – Lukas Knuth Jun 05 '15 at 19:27
  • @LukasKnuth, no, not really. – Andrei T Jun 05 '15 at 19:31
  • @andrei okay. How often does the data from the backend change? – Lukas Knuth Jun 05 '15 at 19:32
  • @pskink, if I could, definitely I would have done it, as this is not my first app in Android, but it is my first using the search. – Andrei T Jun 05 '15 at 19:33
  • @LukasKnuth, they told me that while doing this, I should think that it might change randomly. They told me to Imagine the scenario where you want to search for movies, music files, etc, and from time to time the data changes. – Andrei T Jun 05 '15 at 19:35
  • so you don't know how to use sqlite db on android? – pskink Jun 05 '15 at 19:36
  • @pskink, of course I do, that's not the problem but, they don't want it like that, plus if I were to do that, this would require a lot more time(data on the web changes, thus I need to make a request anyway, etc) and I only have a few days - 2. Let's keep just an online search. – Andrei T Jun 05 '15 at 19:39
  • 1
    if you indeed want an online search then see my answer here: http://stackoverflow.com/a/19860624/2252830, it might help in integration autocomplete text view with a web app call – pskink Jun 06 '15 at 05:41

1 Answers1

1

Since you can't change the server-side component, you'll have to make your client smarter.

The way to go here is (as @pskink suggested) to store the data locally. If you make a single request for every entered/deleted character in the search-view, you're practically DOSing their server. Also, this will be slow.

The challenge is to cache the data locally but keep it "fresh" enough so that it doesn't divert to much from the data on the server. Implementing this is harder than it sounds.

I would suggest loading the entire JSON from the Backend as soon as the activity opens. Depending on how big each individual entry in this list is, you might get away with keeping them all in-memory and filtering on that (i'm thinking a Tree might be a good starting point).

If you get any performance or memory problems with this solution, I'd suggest moving the data into some kind of database (it doesn't need to be SQLite, Realm might also be interesting). The same challenge applies for keeping that data up-to-date, of course.

Since you said they told you, I guess you're working with the people behind the server-component. In that case, I have found the best approach is to implement a solution that works (any of the ones above) and show it to them. If it's not fast enough for them, make suggestions:

  • They could give you an API to get only the new/changed entries since a given date (so you can just update the database).
  • It might also be possible to make a hybrid model: Filter on your offline-data first, but also make a request to the server (with a filter-parameter or something) and mix the resulting data. Indicate to the user that you're in the process of fetching more "up-to-date" data, but show them the results you already know. This might not work well if entries are removed frequently.
Lukas Knuth
  • 25,449
  • 15
  • 83
  • 111
  • Thanks for the suggestion, I will analyze that. I also thought about this approach as I used the same approach in a project(without the search part, just synchronizing data with the server) - developed in 1-2 months not in 2 days... – Andrei T Jun 05 '15 at 19:55
  • If you have two days go for option 1 something like [this](http://stackoverflow.com/q/13373854/717341). If it's really *just* 2000 entries, you'll be fine. It won't get any faster than that and your data will always be fresh. You will however have a noticeable "time-to-setup" and if 2000 entries will soon become 10000, you might run into trouble. Make sure you communicate your concerns with the solution and make suggestions on how to do improve it. Reasonable people tend to listen to those. – Lukas Knuth Jun 05 '15 at 20:00
  • Thanks for the help, I might have time to do the db part with a synchronization with the server, it might take me some extra hours but I already have my abstract db that can handle any type of data, transactions, precompiled, etc, it just needs some 4-5 hours of modifications. I accepted your answer. – Andrei T Jun 05 '15 at 20:09