Add historical searches list to the Reader initial search screen

[renanferrari]

Fixes #11168

This PR introduces a list of historical searches to the initial search screen of the Reader, as shown below.

The implementation here turned out to be quite rudimentary, but it took several rounds of trial and error to reach the minimum code needed to make it work well.

The main challenge here is to keep track of the search screen state, given it is tightly coupled with ReaderPostListFragment. For example, here are some of the conditions we need to keep track of to know when to show the historical searches list:

• Is the search view visible?
• Has the user typed a query?
• Has the user performed a search?
• Is the user seeing any results from a previous search?
• etc.

I considered the possibility of extracting part of this logic to another fragment or to the existing ViewModel, and while I certainly think it can be done, I also think these solutions seemed to require a disproportionate amount of effort when compared to the potential payoffs for this particular feature. In other words, it didn't seem like the right time to invest more in this, especially considering that this is such a small feature.

To test

For each of the tests below, you first need to make sure you're using the build variant thas has enabled IA flags.

1. Basic scenario

0. Make sure you haven't searched for anything before.
1. Open the Reader.
2. Tap the search icon.
3. Notice the initial search screen with the "What would you like to find" message.
4. Make a new search.
5. Notice the loading progress.
6. Wait for the search results.
7. Clear the search field.
8. Notice the initial screen with the historical searches list.
9. Type a new search query.
10. Notice the historical searches list is not being filtered while typing.

2. Repeat search

0. Make sure you've made at least one search before.
1. Open the Reader.
2. Tap the search icon.
3. Notice the initial screen with the historical searches list.
4. Tap on an item in the historical searches list.
5. Notice the search field is now filled with that item query.
6. Notice the loading progress.
7. Wait for the search results.

3. Delete and clear

0. Make sure you've made several searches before.
1. Open the Reader.
2. Tap the search icon.
3. Notice the initial screen with the historical searches list.
4. Tap the delete icon (X) on an item in the historical searches list.
5. Notice the item is gone.
6. Tap the Clear search history button.
7. Notice the initial search screen with the "What would you like to find" message.

Notes

• The search screen can behave erratically after configuration changes, but I think I've managed to prevent the most critical bugs related to that.
• Sometimes the historical searches list can be covered by the suggestions popup – this is an expected behavior.
• @osullivanchris already reviewed this on Slack, so we can go straight to code review.

---

PR submission checklist:

• I have considered adding unit tests where possible.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[peril-wordpress-mobile]

You can test the changes on this Pull Request by downloading the APK here.

[develric]

Hi @renanferrari , thanks for this PR 🙇‍♂️! I agree it was not easy to follow all the conditions in Reader fragment and we will need (more sooner than later) to start a progressive refactor project for that, in any case your solution seems to work well, good job 👍! I tested it both with zalpha and vanilla flavor and didn't find issues. I feel the presence of both the suggestion popup and the history recycler view seems a bit sort of a duplication but I see from your PR description that you already discussed it with @osullivanchris, and also using it is actually smooth so I'm fine with it.

I left only a small inline comment for your consideration. Let me know wdyt 😊.

[develric]

Maybe we can consider to move this interfaces into a dedicated kotlin file. In this way we could avoid to duplicate some of them in the ReaderSearchSuggestionAdapter; wdyt?

NOTE: usually we try to create new classes (like this one) in kotlin where possible; but this is just to share a general comment (so no action required actually 😊).

[renanferrari]

Thanks for the review! 😊 I have now extracted those interfaces to a single Kotlin file.

[renanferrari]

Just a side note: I have also updated the Reader settings screen title from Tags & Sites to Manage Tags & Sites, since we missed it in #11219 👍

[develric]

Hi @renanferrari 😊! Thanks for the changes (and taking care of the settings screen title renaming), all works well 👍! I left just a minor comment about an interface that it seems we are not actually using ad maybe worth cleaning it up (sorry for missing it in my previous pass review 🙇‍♂️). But a part this it's looking good, good job 👍!

[develric]

AFAIU it seems we are not currently using this interface, maybe worth considering removing it? wdyt?

[renanferrari]

That's actually used by ReaderSearchSuggestionRecyclerAdapter. It's just not used by the existing ReaderSearchSuggestionAdapter, which uses SearchView's own OnSuggestionListener for that.

[develric]

Yep I see! Sorry I was missing it 😊!

[develric]

Hi @renanferrari ! LGTM

[osullivanchris]

Great work @renanferrari ! I've had a look at the build and everything seems to be working. Sorry that something we thought would be low hanging fruit turned out to be so complex :)

I do see the duplication which @develric raised. Perhaps something to improve in future. Its not 'broken' and I think we have invested enough time here on something which is already a bit of a side-track from our iA work :)