MVP Architecture Setup for Android App

MVP Architecture Setup for Android App

MVP on Android — pattern with history. Before Architecture Components it was de facto standard: separated logic from Activity through Presenter interface. Now chosen for Java projects where switch to Kotlin + ViewModel unjustified, or where team knows pattern well and change costly.

MVP structure in Android context

Three participants: Model (data and business logic), View (interface, implemented by Activity or Fragment), Presenter (manages logic, doesn't know Android SDK).

public interface ProfileContract {
    interface View {
        void showProfile(UserProfile profile);
        void showError(String message);
        void showLoading(boolean show);
    }

    interface Presenter {
        void loadProfile(String userId);
        void onDestroy();
    }
}

public class ProfilePresenter implements ProfileContract.Presenter {
    private final ProfileContract.View view;
    private final UserRepository repository;
    private CompositeDisposable disposables = new CompositeDisposable();

    public ProfilePresenter(ProfileContract.View view, UserRepository repository) {
        this.view = view;
        this.repository = repository;
    }

    @Override
    public void loadProfile(String userId) {
        view.showLoading(true);
        disposables.add(
            repository.getProfile(userId)
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(
                    profile -> { view.showLoading(false); view.showProfile(profile); },
                    error -> { view.showLoading(false); view.showError(error.getMessage()); }
                )
        );
    }

    @Override
    public void onDestroy() { disposables.clear(); }
}

Activity implements ProfileContract.View, creates Presenter in onCreate, calls presenter.onDestroy() in onDestroy.

Screen rotation problem

This main MVP disadvantage versus MVVM: Presenter doesn't outlive Activity recreation. Solutions: store Presenter via retain Fragment (outdated), via ViewModelStore (irony — use ViewModel as Presenter container), or accept state loss and reload data.

In projects where MVP settled, often choose second path: RetainedPresenterFragment without UI, holding Presenter in setRetainInstance(true). Works, but looks like workaround.

When MVP appropriate

Legacy Java project without Kotlin plans. Team familiar with pattern. Project with small screen count where MVVM + StateFlow overhead unjustified.

For new Kotlin project — MVVM + ViewModel preferable: better Jetpack integration, no rotation problems, cleaner testing.

What's included in setup

Create base contract structure (View/Presenter interfaces). Set up base BasePresenter class with lifecycle management. Wire DI via Dagger 2. Example module with Presenter tests via JUnit + Mockito without Android dependencies.

Timelines

MVP structure setup from scratch: 2–3 days. Refactoring existing project: 1–2 weeks depending on volume. Cost — by code analysis results.