PrayersScreen:

This is the feature/screen that I have migrated from xml to compose in the part 1, as there I just developed a temporary solution, now I will show how implement it in a more scalable way.

I have 3 main things in this screen: SearchInput, Selectable Filter and Prayers List.

SanctusSearchBar:

I implemented it inside sanctus-components, to make it a reusable component, although it is probably the only case, for now, that has a search input.

A simple wrapper around the SearchBar from the Material 3 Compose library.

Here are some things worth paying attention to:

BodyLargeText used as the component for the placeholder component, but where does it come from?

I have created all Text components based on the SanctusAppTypography, and a GenericText component used in all text labels.

GenericText:

It is just a wrapper for Text component from compose library to concentrate any other changes I want to make.

TextLabels:

You can observe that for the style I’m using the SanctusAppTypography to define how the labels looks like.

Coming back to SanctusSearchBar, a few things are worth mentioning:

leadingIcon: I have used a default Search icon from the material library, and for the tint color MaterialTheme.colorScheme.primary, so it will always reflect the SanctusAppTheme that was defined and explained in the first article.

trailingIcon: this icon only appears if there is a text in the search input, and if the icon is clicked it clears the input and triggers the onSearch listener to reset the search state.

To finish this component, I used 4 parameters, but only one is mandatory: query. It represents the text typed by the user and is used for the search. The responsibility for handling it stays outside the component — in this case, it’s managed in the ViewModel as a StateFlow.

Since the query is managed in the ViewModel using StateFlow, the data will survive configuration changes and persists until the ViewModel is destroyed.

PrayersScreen using SanctusSearchBar

Why did I use collectAsStateWithLifecycle?

Calling the selectedFilters StateFlow from the ViewModel using this extension function makes it a compose state, meaning it is now a lifecycle aware, so it will only collect the selectedFilters when the composable is an active lifecycle, preventing memory leaks.

PrayersFilterComponent:

The filters, which are selectable items, will reflect which types of prayers will be displayed in the list.

I have created 2 main components in the sanctus-components module that represent the filter:

SelectableItem:

I have set the colors using the theme of the app, but if in the future I want to use others, I can simply pass them in the parameters.

I created the SelectableItemData to be used as a selectable item in the component. Each item holds a SelectableType, which is a generic interface. This allows different parts of the app to implement their own type like: PrayerType, NovenaType and ChapletType, making this component completely independent of the feature that implements it.

TagText: a text component with a tag style:

TagText

As you can see, I used another already created text component, to keep the app consistent.

SelectableItemList:

This is the list that contains all the selectable items and displays them inside a LazyRow. I am using dimensions from the application definition.

PrayersFilterComponent:

I created a SelectableFilterType that implements the SelectableType, which was mentioned in the SelectableItem. Three types were created and used in the component together with others specific attributes, like colors and text.

It is important to observe that PrayersFilterComponent has 2 parameters: selectedFitlers, which comes from the viewModel and is the current filter state, and also the listener of each filter, which is also toggles the selected option in the viewModel.

This is how the PrayersScreen calls this component in the end:

Prayers List:

I’m using LazyColumn for it, but here I will go further and start explaining the PrayerStates, which are all the states that can be displayed in the screen. It can be the list of prayers, but also Error, Empty or Loading

PrayerState:

These are all the states that can come from the PrayerViewModel and read by the PrayersScreen.

PrayerState.Empty:

This shows the empty state, which is a generic component:

EmptyScreen Preview

What It Shows: An optional icon, a title (always visible), an optional subtitle, Optional “Search: query” if search is enabled and an action button if a action is presented. Action button is present when an action is needed which is defined by the presence of actionText e onActionClick.

PrayerState.Error:

ErrorStateScreen preview

What It Shows: an X icon that can be different if passed in the parameter, a title (always visible), subTitle, retryText and errorMessage when present, and if onRetry parameter is passed, shows a button to handle the function invocation.

PrayerState.Loading:

LoadingStateScreen Preview

What It Shows: a default loader and a loading text message.

PrayerState.Success:

What It Shows: the list of prayers is using a LazyColumn to avoid loading all items at once in the UI, as it is behaves similar to the old RecyclerView, so it only loads what is currently displayed on the screen.

I have implemented 3 Items, but they are all using a common compose component inside:

The only difference between them is the attributes that are being passed to the CardWithImage component, and of course the type of Prayer.

ChapletCardItem — NovenaCardItem — PrayerCardItem

CardWithImage:

This CardWithImage composable displays a clickable card with a title, tag, and image. It supports both drawable and vector assets. The layout uses a row with text content on the left and an image on the right, with consistent spacing from a design system. It’s fully accessible and handles different image types through a sealed class.

Finally the combination of all those things in the PrayersScreen

This article was previously published on proandroiddev.com.