Best Practices for Handling Search
Asked Answered
F

3

14

I've got a SearchView setup, and I have a loosely decoupled architecture using Retrofit and Otto.

I am wondering what the Best Practices are for Search in Android, or any mobile application in general (meaning something like this could be applied to iOS as well).

Specifically I am using an AutoCompleteTextView to handle suggestions in my SearchView and the data is coming straight from the API. I don't believe this is a best practice since everytime a user changes text in the SearchView there is an API call initiated.

I'm thinking about storing a Cache in SQLite and then pinging results from there, but what if the user wants the most immediate data? How would you handle that? What pattern would that employ?

Would appreciate any thoughts on the best architecture or approach to Search in Android.

Ferrin answered 7/7, 2015 at 18:38 Comment(0)
F
0

So to answer this question in a sufficient way, as I was not satisfied with the other answers here there are a few more steps to consider in this problem.

First we would need to ask a few questions in regards to how we would tackle this issue:

  • Is there autocomplete?
  • What is the scope of the search?
  • Would there be caching?

And many more questions.

I would probably first build a custom adapter to handle the querying in the search, then implement aggressive caching on the user's queries. This is important in the sense that a user's queries are very important. It would probably make sense to only used cached results for Autocomplete it is very expensive to implement autocomplete and have it ping the server at every text change.

Caching can be accomplished by using the SQLite helpers in Android. This can be expensive, but we are dealing with simple query objects, (as this should be the case from the API the objects should be memory or byte size expensive).

Ferrin answered 26/9, 2015 at 22:19 Comment(0)
H
11

I think there is no sense to make an API call before user stopped typing. So, you can put a delay, say, 500ms. When user stops typing, after 500ms you make an API call and show the results.

You can use a Handler's postDelayed method for scheduling search API calls. You can use Handler to control the message queue. You post a delayed Runnable each time user types a character and cancel previous messages. It will look this way:

public void onTextChanged(CharSequence s, int start, int before, int count) {
    handler.removeCallbacks(searchRunnable);
    handler.postDelayed(searchRunnable, 500);
}
Haws answered 7/7, 2015 at 18:47 Comment(9)
Yes I forgot to add this in my original question, I was going to put a handler as well so it doesn't make an api call unless the user stops typing. The most important question I have though is for AutoComplete and Suggestions, what are best practices for handling that? SQLite?Ferrin
What is your data source? Is it a REST API? When you get data from your server you store it in cache and then you can reuse it by filtering when user removes characters from query. I don't think you should cache search results in database because then your search results won't be always up-to-date. You can use this for offline search, but I wouldn't use search cache in online..Haws
It is a REST API, so your suggestion is not to use an SQLite DB for AutoComplete? Should I store AutoComplete suggestions in an SQLite DB, and then ping the server on timed intervals to get up to date information? What do you think about that strategy?Ferrin
Do you need to support offline search? If yes, then you need SQLite DB for sure. If no, it depends on what functionality you want to see. For instance, if you have cache, you can display it when user types characters and make API call meanwhile. After you have a response, update the list with the latest data and update DB. I don't prefer this solution because I don't like when data gets updated when I see it. I'd rather wait for a network response and display relevant data first, and only then store it to DB for offline purposes.Haws
Also, if you show data from your database, some items may be removed on the server and you will show results that don't exist anymore. Make sure that you handle this situation if you go with database cache.Haws
So your solution would be to do this: Send API Call --> Update DB? What if its the first time the user is doing a search then what?Ferrin
sorry, I'm not sure I understand the question.. if it's the first time than you obviously have nothing in your DB and you need to make an API call to display something..Haws
Coming back to this today, will be testing out your answer.Ferrin
I have a hard time giving this answer the bounty, if you would like it please give me a full blown out answer.Ferrin
S
1
  • first you have to make the column as index which is search attribute.
  • you have to store only that column on sqlite database.Its used to select options from your table when search is made by users.
  • then you call api for search result, after the word selected in search bar.
Shandy answered 20/7, 2015 at 13:28 Comment(0)
F
0

So to answer this question in a sufficient way, as I was not satisfied with the other answers here there are a few more steps to consider in this problem.

First we would need to ask a few questions in regards to how we would tackle this issue:

  • Is there autocomplete?
  • What is the scope of the search?
  • Would there be caching?

And many more questions.

I would probably first build a custom adapter to handle the querying in the search, then implement aggressive caching on the user's queries. This is important in the sense that a user's queries are very important. It would probably make sense to only used cached results for Autocomplete it is very expensive to implement autocomplete and have it ping the server at every text change.

Caching can be accomplished by using the SQLite helpers in Android. This can be expensive, but we are dealing with simple query objects, (as this should be the case from the API the objects should be memory or byte size expensive).

Ferrin answered 26/9, 2015 at 22:19 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.