Налаштування архітектури MVP для Android-додатку

Настройка архітектури MVP для Android-застосунку

MVP на Android — паттерн з історією. До Architecture Components він був стандартом де-факто: відділяв логіку від Activity через інтерфейс Presenter. Тепер його вибирають для проектів на Java, де перехід на Kotlin + ViewModel недоцільний, або там, де команда хорошо знає паттерн та змінювати його дорого.

Структура MVP в Android-контексті

Три учасники: Model (дані та бізнес-логіка), View (інтерфейс, який реалізує Activity або Fragment), Presenter (керує логікою, не знає про 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 реалізує ProfileContract.View, створює Presenter в onCreate, викликає presenter.onDestroy() в onDestroy.

Проблема повороту екрана

Це головний недостаток MVP порівняно з MVVM: Presenter не переживає пересоздання Activity. Рішення: зберігати Presenter через retain Fragment (застаріло), через ViewModelStore (ірронія — використовуємо ViewModel як контейнер для Presenter), або прийняти утрату стану та перезавантажити дані.

У проектах, де MVP устояв, часто вибирають другий шлях: RetainedPresenterFragment без UI, який зберігає Presenter в setRetainInstance(true). Працює, але виглядає як костиль.

Коли MVP уместен

Legacy Java-проект без планів на Kotlin. Команда, знайома з паттерном. Проект з невеликим числом екранів, де overhead MVVM + StateFlow не виправданий.

Для нового проекту на Kotlin — MVVM + ViewModel переважніший: краща інтеграція з Jetpack, немає проблем з rotation, чищіше тестування.

Що входить у настройку

Створення базової структури контрактів (View/Presenter інтерфейси). Настройка базового класу BasePresenter з керуванням життєвим циклом. Підключення DI через Dagger 2. Образцовий модуль з тестами Presenter через JUnit + Mockito без Android-залежностей.

Терміни

Настройка MVP-структури з нуля: 2–3 дня. Рефакторинг існуючого проекту: 1–2 тижні залежно від обсягу. Вартість — по результатам аналізу коду.