InstantSearch Android missing refresh feature?

Hello,

I am currently developing an application in android using Algolia’s InstantSearch. I study all the examples but none of them deals with maybe a serious issue in android.

Refresh the results when a change has occurred.

In all the example, we are getting results from the index.Let’s go forward to the next step. We load a single result, make a change to a field and save this change back to the index. Then, go back to the list of results. A normal user will expect the list to be refreshed displaying the updated information.

I am afraid that this is not implemented yet. I hope to be wrong. But if not, what do you propose to make the trick ?

Hi @peripc.gr, thanks for reaching out.

You are right, today InstantSearch Android does not provide a refresh widget, as there are many way one might want to implement such a refresh (as a Refresh button, in a scroll-to-refresh fashion, at regular intervals e.g. every minute…). The refresh logic itself is quite trivial:

// Given your Searcher instance
Searcher searcher = Searcher searcher = Searcher.create(appID, apiKey, indexName);
// This is how you refresh current search results
searcher.search();

Let me know if this helps you solve your problem. I’m interested to know how you’ll use this refresh feature in your app, this might help us make it easier to use and more integrated!

Hi @pln,
thank you for your interest.

Let me explain you my application’s logic. It’s very very simple. The MainActivity that it’s launched when the app starts, is a Hits View widget where all items are displayed. This is more or less based on Algolia’s Get Started guide :arrow_down::arrow_down::arrow_down:
https://community.algolia.com/instantsearch-android/getting-started.html

After that, a user can click on any item and a second Activity is fired where the user can make changes in every field she wants. For example, having a product name, a product code, a description and an image, user can change none, 1 or even all fields. When the user presses the back button a dialog ask her if she wants to save the changes and if yes, then index.partialUpdateObjectAsync() is called and the information upload to algolia’s index. So far so good. :smile:

After that, once the user has pressed the back button, the MainActivity with the Hits View is displayed again. And this is the moment I want the list to be refreshed with the latest data. And this is not happening. I have already tried searcher.search() in onResume() method with no success.:disappointed:

I noticed that if I go into an item and return back to the MainActivity even if I don’t make any change, I see updated list. I don’t know what is happening exactly. I have to say that if I try to search even a letter then the list is updated automatically. But until a search is been fired, the list retains the old data.

In MainActivity, the onCreateMethod() has the following code:

...
mSearcher = Searcher.create(applicationID, apiKey, indexName);
mHelper = new InstantSearch(this, mSearcher);
mSearcher.search(getIntent());
...

And onResume()

protected void onResume() {
    super.onResume();
    mSearcher.search();
}

Hey @Periklis, thanks for these details I understand better what you’re building!

Just to make sure I get it right, you don’t see updated data when doing the update and pressing back, but you see updated data when you display an item then go back to the search interface?

Your MainActivity code seems right.
I think the issue comes from searching immediately after the update. See our FAQ entry on indexing speed: reindexing your data after an update takes a few seconds.
As soon as the indexing is complete, calling the search API will return latest results: searcher.search() always displays the latest results available*.

To make sure the indexing is finished, you can use waitTask. This will let you know when the update you trigger with partialUpdateObjectAsync() is complete and available for search (so you can display e.g. a Update Complete! message to the user, to let them know they can search the updated data.

Let me know how it goes!

*: (the only exception is if you enable the search cache with searcher.getIndex().enableSearchCache() to display cached results instead of redoing a search when it was already done recently)

@pln, thank you :slight_smile:

I see now that the “problem” is timing. I tried using waitTaskAsync in my code and it became obvious that it needs more time to complete the indexing than switching activities. Even if you have only 3 items as I do for my tests.

I make the super.onBackPressed() to be called only when requestCompleted has no errors in waitTaskAsync and works. But this causes a delay and some awkward moments to the user before go back to the result page as she wants. It seems like the back button has a malfunction. I may think of a way to inform the user like a ProgressBar view or change the application logic and create a scroll-to-refresh functionality so to give user the free will.

Anyway, I really appreciate your help and your guidance. It’s enlightening. :smiley:

@Periklis, my pleasure glad it was useful :slight_smile:

Indeed those timing situations can be tricky to handle well with a good UX!

You are right that even with 3 items it can take a bit of time:

  • first because there might be a lot of metadata to handle (synonyms, query rules, …)
  • but also because our ESSENTIAL/PLUS/BUSINESS plans give you access to a shared infrastructure (so doing an update at a time where many other customers update their data too will be slower than doing it at a less busy time).

Indeed waiting for requestCompleted without errors before calling onBackPressed will cause some awkwardness as the user might wonder why the interface does not respond to the button press.
The usual recommendation is to act on the back press, but then display an indicator to let them know that they should wait for an update. A basic version of this would be a Toast when updating to say “Please wait” and another one when the update is done and you call searcher.search(), but a ProgressBar could indeed be nicer).