Android MVP架构中Presenter是否应返回值？

Great question—this is a common point of confusion when implementing MVP in Android, so let’s break it down clearly based on MVP’s core principles and practical use cases.

The Short Answer #

Most of the time, no. Presenters are designed to act as a middle layer coordinating the View and Model, and direct return values break MVP’s intended unidirectional flow and increase coupling between layers.

Why Direct Return Values Are Problematic #

Let’s cover the key issues:

• Breaks unidirectional communication: MVP relies on the View triggering actions in the Presenter, and the Presenter notifying the View of results (not the other way around). Returning values forces the View to wait for a response, creating a bidirectional dependency that makes the code harder to test and maintain.
• Fails with asynchronous operations: Most real-world Android tasks (network calls, database queries) are asynchronous. A Presenter method that tries to return a value from an async operation will either return a placeholder (like null or an empty object) or block the UI thread—both are bad practices.
• Increases coupling: If the View depends on a return type from the Presenter, changing that type later requires modifying both the Presenter and every View that calls the method.

The Correct Approach: Callback/Notification Patterns #

Instead of returning values, Presenters should communicate results back to the View via:

• View callbacks (interface methods): Define methods in your View interface that the Presenter can call when results are ready.
• Observer patterns: If you’re using Jetpack components, LiveData can be a clean way to pass results, though traditional MVP often sticks to interfaces for simplicity.

Here’s a quick example using interface callbacks:

// View Interface (defines what the Presenter can tell the View to do)
interface UserProfileView {
    fun showUserDetails(user: User)
    fun showLoadError(errorMessage: String)
    fun showLoadingIndicator()
}

// Presenter
class UserProfilePresenter(
    private val view: UserProfileView,
    private val userRepository: UserRepository
) {
    fun loadUserProfile(userId: String) {
        view.showLoadingIndicator()
        // Async call to repository
        userRepository.fetchUser(userId, object : UserRepository.Callback {
            override fun onUserFetched(user: User) {
                view.showUserDetails(user)
            }

            override fun onFetchFailed(error: String) {
                view.showLoadError(error)
            }
        })
    }
}

Are There Any Exceptions? #

A rare exception might be simple, synchronous, pure functions—like a Presenter method that calculates a total price from a list of items, or formats a date string. For example:

fun formatUserJoinDate(timestamp: Long): String {
    return DateFormat.getDateInstance().format(Date(timestamp))
}

Even here, though, it’s better to keep consistency: you could add a onJoinDateFormatted(dateString: String) method to the View interface instead. But for tiny, stateless operations, a return value won’t cause major harm—just don’t make this a habit for complex logic.

Final Takeaway #

Stick to unidirectional flow: View calls Presenter methods to trigger actions, Presenter handles logic and data fetching, then notifies the View of results via callbacks. This keeps your code modular, testable, and aligned with MVP’s core goals.

内容的提问来源于stack exchange，提问作者nyongrand