У каждого представления должен быть предъявитель в образце MVP?

Question

Я работаю над небольшим приложением, используя шаблон MVP. В моей домашней деятельности есть viewpager с несколькими фрагментами, и у каждого фрагмента есть свой ведущий. Фрагменты не связываются друг с другом, поэтому у активности нет логики c, она просто инициализирует фрагменты при запуске. Так что, если я хотел бы реализовать шаблон по книге и остаться верным его принципам, должен ли я реализовать презентатор также для этой деятельности? И если да, то какова должна быть его роль?

Answer 1

Если вы хотите реализовать MVP по книге и оставаться верным ее принципам, у каждого пользовательского интерфейса, в котором есть взаимодействие с пользователем, должен быть докладчик. В этом случае, если ваша деятельность не взаимодействует с пользователем, вам не нужно иметь докладчика, а ваши фрагменты могут иметь свои собственные. Если вам нужно, скажем, показать загрузку пользователю из-за некоторой загрузки данных перед показом фрагментов (это взаимодействие с пользователем, потому что вы взаимодействуете с пользователем, чтобы сообщить ему, что что-то происходит, поэтому им следует подождать), тогда, возможно, было бы неплохо подумать о том, чтобы иметь ведущего для деятельности.

MVP совершенно не заботится о том, является ли Activity / Fragment / View, он просто знает View, который рассматривается как абстракция всего, что может быть показано пользователю:)

Это, по крайней мере, с точки зрения «правил». Мои 2 цента, будь гибким, если ты видишь, что на самом деле это добавляет ценности для тебя и твоего проекта, делай это, в противном случае иногда приходится «нарушать» правила или создавать свои собственные.

Answer 2

Для использования фрагментов с их собственными презентаторами я пытаюсь использовать дуо-контрактные классы duo для управления событиями пользовательского интерфейса во фрагментах.

Например, рассмотрим событие щелчка, чтобы отобразить всплывающее сообщение в случае двух возможных результатов: 1. Сохранить и 2. Удалить

Затем я объявлю два метода контракта вида следующим образом:

interface View{
     fun showSaveMessage()
     fun showDeleteMessage()
}

И затем, во фрагменте, я буду использовать экземпляр моего докладчика. Класс для отображения сообщений в подходящее время, например: presenter.doSaveAction(), докладчик, в свою очередь, заставит представление отобразить сообщение о тосте.

Кроме того, когда я приду к фактическим логикам c фрагмента, как и для извлечения некоторых данных с удаленного сервера, я использую класс Interactor вместе с классами Presenter-View для его выполнения.

Я считаю, что all остается верным Принципы практически зависят от того, какое приложение вы создаете. Иногда для архитектуры приложения более целесообразно использовать MVVM с MVP , чем только шаблон MVP.

Надеюсь, это ответит на ваш вопрос, вроде?