feat(card-browser): Redesign using Material 3 SearchView [Dev only]#20454
feat(card-browser): Redesign using Material 3 SearchView [Dev only]#20454david-allison wants to merge 18 commits intoankidroid:mainfrom
Conversation
|
Important Maintainers: This PR contains Strings changes
|
1184ec6 to
a547847
Compare
There was a problem hiding this comment.
I haven't seen the code yet
Status bar should be transparent
Should the Add button be a primary option in the search view? Other options are 1. putting it on the menu 2. replacing it with Preview
The menu entries (or some of them) could have icons
Sorting can be better, but handled in #20240
Agreed, but I wanted to save it for the research study
How would you feel about: Add is primary if there are no results, Preview is primary otherwise EDIT: I tried, I moved 'preview' to 'always' and add is 'ifRoom', Android wants 2 icons. We may be able to do better when we remove the legacy menu
💜 GREAT idea, thank you!
I did have sorting in this PR, but I extracted it to the below (blocked currently). These also affect sorting on the 'non-dev' app |
21a4334 to
287cef9
Compare
287cef9 to
f966011
Compare
1b96af3 to
266914c
Compare
b202025 to
c9d9bf8
Compare
c9d9bf8 to
cf7267d
Compare
This is a new Material 3 based SearchView Supports: * Chips (filters: decks; tags etc...) * Saved Searches * History & saving searches from history * Toggle to an 'Advanced Search' This PR is just an initial design and a sample test, no functionality Issue 18709
Starts off the implementation of the Material 3 SearchView by allowing a user to press 'search/enter' to submit a search to the card browser Part of 18709
A history entry can be saved, or tapped to search for it History is limited on the root fragment to 5 entries 'See more' will be implemented at a later date For issue 18709
Many users do not know about saved searches, and this makes them more prominent. Saved Searches are persisted in the collection, currently unordered AnkiDroid now has an easy mechanism to save any search in the history Searches have a basic 'manage' panel, only available if searches exist, allowing a user to see, select and remove their searches, this uses the previous screen A search may be tapped to search, or like Google Chrome, an 'insert' button may be used to replace the current input of the search bar with the search, without submitting it. Part of 18709: Material 3 SearchView
Updates SearchResult with `toUserSpannable`: producing a user-facing string, where the filter selections are dimmed, and the search text is prominent. This makes it obvious why the filters are removed from the EditText when a user taps into it This updates the empty search from '' to 'deck:*', which matches Anki Desktop. Part of 18709
Part of 18709
If someone backs out of the search fragment, the changes should be discarded Part of 18709
Part of 18709
Example: query = 'foo' deck = Default Would produce 'foo deck:Default', where 'deck:Default' is faded, as it came from a chip Coloring requires the database (buildSearchString), so we want to offload this for later to reduce latency So we now have a 'Loading' and 'Loaded' state for when the history changes Part of 18709
hide 'action_list_my_searches' & 'action_save_search' - in SearchView hide 'action_search_by_tag' - in a chip Part of 18709
* Anki Desktop no longer shows this prominently * A poll of Discord shows people no longer use it * Technically a tag Part of 18709
and sync Filter state to StandardSearchFragment.kt Part of 18709
This fixes resetting state on back, and submission Part of 18709
Part of 18709
Part of 18709
Define a color which is better than the standard purple Calculation: colorSurfaceContainerHigh (HCT model) * +15 Chroma (light) * +10 Chroma (dark) * Choose a darker gray (plain) * Eyeball a light black (black) and set colorSurfaceContainerHigh Issue 18709
'add' only appears if there are 0 cards selected so preview is hidden From a review comment on 20454
cf7267d to
bf2e931
Compare



Purpose / Description
The overall aim of this change is to move the Card Browser to a Material 3 SearchView.
When tapped, a new interface for search selection is shown.
Due to this interface, we can remove the following options menu items:
Filters/chips
A single-line chip bar, horizontally scrollable, is placed below the SearchView. This is visible when the SearchView is expanded and collapsed. Tapping on a chip either opens our existing dialog (decks; tags), or opens a bottom sheet, where one or more items may be selected. When an item is selected, the search is instantly re-applied, and the chip changes to a 'selected' state.
The label is updated to reflect the selection.
Flagschanges toFlag/No Flagif the red flag is selected orFlag +1if an additional flag is selected. In the latter case,Redwould be the flag which the user selected first. In the case of Flags and State, the icon is updated to match the icon of the first selected flag/stateMultiple selections with the same filter act as a logical
OR(for example: a red OR an orange flag). Different filters act as anAND(Default deckAND(a red flagORan orange flag))An additional 'sort order' chip is displayed when the SearchView is collapsed. The icon is reversed if the direction of sort is reversed
StandardSearchFragmentThe initial fragment when a SearchView is opened. This displays the search history to the user, chips, and the user's saved searches.
Search history
Each SearchHistory item renders the
SearchRequest: the query is shown in a dark color, and the filter selections are shown in a lighter color, so a user can differentiate where their textual input ends.Search History entries are persisted using IDs, not names, so (for example) a search history entry is still valid if the deck is renamed.
Any search history item can be marked as a saved search
Saved Searches
A concept in Anki Desktop. We implement:
Saved searches are sorted in the backend, so we cannot easily control the order
A user can tap a saved search to immediately search, or tap the 'insert' to replace the text in the search bar with the value of the search
We reuse our existing Saved Searches dialog for management of the searches:
SearchView Functionality
A
CardBrowserSearchViewModelis introduced, now responsible for both the filters and the search query. This ViewModel supports submitting the completed query to theCardBrowserViewModel. This is introduced to reduce the complexity of theThis ViewModel is also responsible for the saved search and history logic exposed by the
StandardSearchFragment, as well as an existingAdvancedSearchFragmentScrolling
The SearchView is hidden on scroll
RecyclerViewFixes
How Has This Been Tested?
Unit tested, dev-only functionality, so low-risk. Also tested on my Pixel 9 Pro (Android 16)
git rebase -x "./gradlew jacocoUnitTestReport --daemon" $(git merge-base HEAD main)Checklist