Про архитектуру у начинающих не спрашивают сильно подробно, но вопросы в стиле "Какие вы знаете?" и "Расскажите быстренько" обязательно будут.
MVP — одна из самых простых. Расшифровывается как Model-View-Presenter. Если вы только-только начинаете познавать андроид и ищете работу, то приложения для резюме проще всего писать как раз с такой архитектурой. Почему? Потому что она простая. Я именно так и делала. А ещё там легко писать тесты и это покорит будущего работодателя. И архитектура в приложении для резюме заметно улучшит ваши шансы получить приглашение на собеседование.
Модель — это логика. Тут хранятся данные, сохраненные штуки и бизнес-логика. Модель максимально независима. И ничего не знает про презентер и вью. Этот слой (все классы) можно просто взять и перенести в другой проект или вообще в другую платформу. Ничего не сломается. Например моя простая моделька: https://github.com/Ladgertha/MVPExample/blob/master/app/src/main/java/ru/ladgertha/mvpexample/Model.kt. Видите, тут нет ни презентера, ни вью.
Обычно здесь репозитории, база данных и пр. Некоторые тут же делают логику приложения. Главное помнить, модель — это чистое POJO (Plain Old Java Object). POJO — не то что надо писать на java, а то что тут не должно быть контекста, библиотек и различных андроид-штук. Только чистый код.
View — это активити/фрагменты/xml. Тут отображаются данные. Вью знает про презентер, но ничего не знает про модель. Можно проверить на проекте https://github.com/Ladgertha/MVPExample. Если удалить модель, то в активити не станет красным. Кстати, аналогично можно проверить и для модели: если удалить активити и презентер, то модель не будет красной.
Пример использования: если надо поменять цвет по нажатию кнопки, то сразу всё делаем в активити. Если нужна логика (например, сложить 2 и 3 или отобразить сохраненные настройки), то при обнаружении клика вызываем метод презентера и тот уже сам разбирается, что надо сделать.
Presenter — в идеале это тоже POJO, но иногда не избежать случаев, когда все-таки нужен контекст. Тут хранится логика приложения. Презентер знает о модели и активно взаимодействует с ней. Также он говорит вью что должно показываться на экране. Но важно, что презентер не напрямую взаимодействует с вью, а через специальный интерфейс: https://github.com/Ladgertha/MVPExample/blob/master/app/src/main/java/ru/ladgertha/mvpexample/MainView.kt. Активити наследуется от этого интерфейса и переопределяет методы, которые там указаны.
При MVP количество кода заметно увеличивается, но зато много плюсов:
- Всё разделено;
- Разработчики могут по отдельности параллельно работать на моделью, презентером и вью. Не будет никаких конфликтов и пересечений. Если пишешь модель, то абсолютно все равно, что там происходит во вью. И наоборот;
- Приложение легче тестировать и добавлять новые фичи;
- Вроде как легче читать и в самих классах меньше кода. Тут не знаю, потому что активно MVP не использовала.
Важное напоминание: более низкий слой ничего не знает о более высоких. Даже презентер не знает про вью. Он взаимодействует с ней через специальный интерфейс, а не напрямую.
И мой пример использования:
Задача: при нажатии на кнопку мы хотим, что число каждый раз увеличивалось на 2.
Есть активити с кнопкой. Это View. На кнопку вешаем setOnClickListener. При клике вызываем презентер: presenter.onButtonCountClick(). Переходим в презентер: в методе onButtonCountClick мы получаем из модельки число, которое там сохранено, увеличиваем его и сохраняем обратно в модель. Когда всё сделано, вызываем view.setButtonText(newNumber). Это метод интерфейса, который реализует вью. Всё просто.