Closed flofriday closed 1 year ago
The code is little bit more verbose than it seems it would be necessary because the adapter has to call code from the fragment. I modeled the solution to be similar to the RefreshListener
which needs to do something similar.
I tested it out and it seems to work to just set swipeRefreshLayout.setEnabled(!adapter.searching);
in updateSearchStatus()
in StoriesFragment
. This function should be called whenever the search status is updated and I tried it out and it seems to be working.
The RefreshListener
approach is used because we want to pass information from the adapter to the fragment. For search, this is already done using exitSearch()
in StoriesFragment
(this should probably be a callback actually). As this is already implemented, I think this is the easiest approach.
However I agree with the UX sentiment that the refresh indicator should be disabled while searching. Before I close the PR, is there something that you see missing from the swipeRefreshLayout.setEnabled(!adapter.searching);
approach?
Wouldn't that also disable the refresh animation once the results are loaded?
It did, but you were right that the RefreshEnabler
abstraction was unnecessary and initially disabling the gesture is possible in updateSearchStatus()
.
I now removed that but overall I think that we should keep the refresh in the search once the results are loaded. Which this PR should now do.
Okay I see, tried it out and works, thanks :)
There is no logical reason to refresh while you are typing. However, the refresh would have revealed an invalid cache and would start loading the results from the previous search.
You could reproduce this with:
Now the refresh gesture is disabled while you are in the search and no results have been loaded.