Common Android UseCase Pattern Mistakes

Photo from Android Documentation

Introduction

A common bad practice I frequently encounter is the misuse of the UseCase pattern in Android development. While UseCases are commonly used in many applications, developers often implement them in ways that move away from their intended purpose.

What are UseCases?

UseCases are tools that help organize complex app logic into simple, reusable pieces. Think of them as containers that hold specific tasks or operations your app needs to perform. They follow a basic programming rule: each UseCase should do one thing and do it well.

Here are the main benefits of using UseCases:

• Promotes code reusability across different parts of the application
• Separates business logic from implementation details for better organization
• Improves testability by isolating complex business operations
• Enables modular architecture that’s easier to maintain and modify

Common Implementation Mistakes

In Android development, I’ve observed two common mistakes:

• Enforcing strict ViewModel-to-UseCase-only access
• Creating one-to-one mappings between Repository methods and UseCases

1. Strict ViewModel-to-UseCase Access

A common implementation pattern strictly enforces that ViewModels can only access UseCases, completely restricting direct repository access. While this approach is part of the Domain Layer pattern, Google’s Android team recommends keeping it optional. This decision should depend on your application’s specific requirements.

This restriction often leads to an explosion of UseCase classes. For instance, if a Repository has 10 methods, you end up creating 10 corresponding UseCases. In scenarios where a ViewModel needs most of the repository’s functionality, injecting a single repository would be more efficient than injecting multiple UseCases.

2. One-to-One Method Mapping

The second mistake involves creating UseCases that simply proxy repository methods. For example, creating a GetUserUseCase that only calls and returns the repository’s getUser method. Sometimes, developers add a simple mapper but essentially maintain the same one-to-one relationship. In such cases, direct repository access from the ViewModel would be more appropriate.

Proper UseCase Implementation

Use cases are specifically designed to handle complex business logic. Here’s an example of a well-implemented use case from Google’s Domain Layer documentation:

/**
 * This use case fetches the latest news and the associated author.
 */
class GetLatestNewsWithAuthorsUseCase(
  private val newsRepository: NewsRepository,
  private val authorsRepository: AuthorsRepository,
  private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
    suspend operator fun invoke(): List<ArticleWithAuthor> =
        withContext(defaultDispatcher) {
            val news = newsRepository.fetchLatestNews()
            val result: MutableList<ArticleWithAuthor> = mutableListOf()
            // This is not parallelized, the use case is linearly slow.
            for (article in news) {
                // The repository exposes suspend functions
                val author = authorsRepository.getAuthor(article.authorId)
                result.add(ArticleWithAuthor(article, author))
            }
            result
        }
}

This UseCase demonstrates proper implementation by combining data from multiple repositories and performing business logic to create a new model.

Google’s Recommendation

A good approach is to add use cases only when required. They should be used when there’s complex business logic that needs to be encapsulated, not as a mandatory layer between ViewModels and Repositories.

Conclusion

When implementing UseCases, focus on their primary purpose: encapsulating complex business logic. Avoid creating unnecessary abstractions and evaluate whether a UseCase is truly needed based on your specific use case. Remember that direct repository access is perfectly acceptable when there’s no complex business logic to encapsulate.

For more detailed information about Google’s Domain Layer guidelines, check out their official guide on Domain Layer.