Creating a Search Bar with Filter in RecyclerView

A search field paired with a filterable RecyclerView gives Android users a fast way to find products, messages, locations or records without scrolling through a long list. In a Kotlin application, the feature usually combines an input widget, a list adapter, a searchable data set and a small amount of state management.

The most reliable approach keeps the original collection unchanged and displays a filtered copy. This makes it simple to clear a query, apply category chips or sort results, and restore the complete list whenever the user removes a search term.

Approach	Best for	Strengths	Watch out for
Filter inside the adapter	Small, local lists	Quick to implement	Can mix data and presentation logic
Filter in a ViewModel	Most modern Android apps	Survives rotation and separates concerns	Requires observable UI state
Room or server-side search	Large or frequently changing data	Efficient for substantial data sets	Needs query, loading and error handling
ListAdapter with DiffUtil	Dynamic lists	Smooth updates and minimal redraws	Requires immutable or carefully managed items

Choosing A Searchable RecyclerView Design

Start by deciding whether filtering happens locally or remotely. A café menu, suburb directory or short shopping catalogue can normally be filtered in memory. A property marketplace covering Sydney, Melbourne and Brisbane may need database or server-side queries once the data set becomes large.

For a local search, use a RecyclerView backed by ListAdapter. DiffUtil compares the old and new lists, so the interface updates only the rows that changed. This is smoother than calling notifyDataSetChanged() after every keystroke, particularly on mid-range Android devices commonly used across Australia.

Preparing The Android Data Model

Create a model that contains the values users are likely to search. A product could include name, category, suburb, price and tags. Keeping searchable properties together makes the predicate easy to read and allows you to add more fields later without changing the row layout.

data class Product(
    val id: Long,
    val name: String,
    val category: String,
    val suburb: String,
    val price: Double
)

Use stable identifiers for DiffUtil, such as id, rather than the item position. If the row uses XML data binding, Kotlin data binding can reduce repetitive findViewById code and keep display logic close to the layout. Format Australian dollar values at the presentation layer rather than storing formatted strings in the model.

Building The Search Input

Place a SearchView, TextInputLayout with an EditText, or a Material exposed search field above the list. Give it a descriptive hint such as “Search products or suburbs”, add a clear action, and ensure the field has an appropriate imeOptions value. This helps users searching with a phone keyboard in Perth, Adelaide or regional areas.

Observe text changes rather than waiting for a submit button. For a SearchView, setOnQueryTextListener is sufficient; with Kotlin Flow, convert text changes into a stream and debounce them. Debouncing prevents a database or network request for every character while someone types “Bondi” or “Woolloongabba”.

searchView.setOnQueryTextListener(object :
    SearchView.OnQueryTextListener {
    override fun onQueryTextChange(newText: String): Boolean {
        viewModel.setQuery(newText)
        return true
    }

    override fun onQueryTextSubmit(query: String): Boolean = false
})

Filtering With Kotlin

A simple local filter can normalise the query and compare it with several fields. trim() removes accidental spaces, while lowercase(Locale.ROOT) provides predictable case handling. Search across names, categories and locations so a user can enter either “coffee”, “cafe” or “Newtown” and receive useful results.

fun filterProducts(items: List<Product>, query: String): List<Product> {
    val term = query.trim().lowercase(Locale.ROOT)

    if (term.isBlank()) return items

    return items.filter { product ->
        listOf(
            product.name,
            product.category,
            product.suburb
        ).any { value ->
            value.lowercase(Locale.ROOT).contains(term)
        }
    }
}

For a second filter, such as category or price range, combine conditions rather than replacing the text query. A user might select “Vegetarian” and search “Richmond” at the same time. Expose the filtered list as StateFlow from a ViewModel, then collect it from the lifecycle-aware UI.

Keeping RecyclerView Fast

Avoid repeatedly copying a large list inside the adapter. Keep allProducts in the ViewModel, calculate the visible list when query or filter state changes, and submit the result to ListAdapter. This makes the adapter responsible for binding rows instead of owning the application’s search rules.

If results come from Room or an API, move expensive work away from the main thread. Room can observe a query through Flow, while a remote endpoint can accept parameters such as q, category and page. For a production app, cache the latest result and show loading, empty and error states clearly.

A search with no matches should explain what happened without looking like a broken screen. “No cafés found in Hobart” is more helpful than an empty white list. Provide a clear-search icon and preserve the selected category when the user edits the text, unless the product requirements specify otherwise.

Handling Australian App Details

Australian content often needs practical formatting choices. Display prices with NumberFormat.getCurrencyInstance(Locale("en", "AU")), use kilometres rather than miles, and represent local phone numbers and postcodes accurately. A delivery or store finder may also need suburb, state abbreviation and postcode, such as “Fitzroy VIC 3065”.

Be mindful of Australian spelling and local search behaviour: users may type “favourite”, search for “footy”, or use suburb names with apostrophes and spaces. If the application serves markets from Darwin to Melbourne, consider whether results should be ranked by distance, state or opening hours. Public holiday schedules and daylight-saving differences can affect time-sensitive results between Queensland and New South Wales.

Accessibility matters as much as filtering accuracy. Give the search control a content description, maintain readable contrast and make touch targets large enough for one-handed use on public transport. Test with TalkBack and with longer place names, including “Mount Gravatt” and “Port Macquarie”, so labels do not become awkwardly truncated.

Testing And Extending The Feature

Unit-test the filtering function independently from Android views. Cover blank input, upper and lower case, leading spaces, partial matches, accented characters, multiple fields and zero results. Test combined filters as well: a category selection should continue working when the query is cleared or replaced.

UI tests should confirm that typing updates the list, tapping clear restores all records and rotating the device does not lose the query unexpectedly. Test slower devices and larger data sets, since a search that feels instant with 20 rows may stutter with 20,000.

When the app grows, add sorting, paging, recent searches or server-side suggestions carefully. If deployment includes a backend, documented automation can make environment changes repeatable; these reusable Ansible roles are useful when configuring API services, databases and staging systems consistently.

A well-designed search experience is a combination of clear state, efficient list updates and sensible Australian localisation. Keep the source list intact, debounce expensive work, use DiffUtil, and give users useful feedback for every search state. Add the pattern to your Kotlin project, test it with real local data, and refine the filters around the way your audience actually searches.