Реализация Interactors с Android MVP Clean Architecture

В настоящее время я создаю приложение для Android и хотел бы основать его на «чистой архитектуре» аналогично предложению следующих авторов:

  • Фернандо Сеяс – Архитектор Android … Чистый путь?
  • Дарио Миличич – подробное руководство по разработке приложений для Android с использованием шаблона «Чистая архитектура»
  • Ромен Пил – Ingedients для здоровой архитектуры Android
  • Дядя Боб – Чистая архитектура
  • Ханнес Дорфманн – Библиотека Мосби
  • Pedro Vicente Gómez Sánchez – эффективный интерфейс для Android
  • Дэвид Герреро – введение в чистую архитектуру Android: шаблон mvp
  • Patryk Poborca ​​- Чистая архитектура и тестирование

Текущая архитектура:

Просмотр (фрагмент) <-> Presenter <-> Интерактор <-> Репозиторий

  • Фрагмент реализует представление и создает презентатор.
  • Презентатор ссылается на фрагмент по интерфейсу View.
  • Ведущий реализует интерфейс Interactor.Callback для представления данных
  • Ведущий создает и запускает Interactor.
  • Interactor извлекает и обновляет данные для выполнения бизнес-логики в фоновом потоке из репозитория.
  • Interactor реализует Repository.Callback для данных DB / Server из репозитория.
  • Interactor регистрируется в репозитории обновлений для требуемых данных.

В текущем проекте на дисплее отображается 1 взаимодействующий (дисплей может включать в себя несколько фрагментов, например ViewPager с 30 фрагментами того же типа) и 1 презентатор на фрагмент. Презентатор и Interactor не имеют зависимостей от структуры, чтобы обеспечить легкое тестирование.

Моя главная проблема заключается в реализации Interactors / UseCases и их отношении к Ведущим (MVP) или ViewModel (MVVM).

Проблема:

Планируется, что Interactor сначала отобразит все необходимые бизнес-объекты (BO) для отображения. Извлечение осуществляется синхронно с уровня данных, и каждый принятый BO направляется на презентатор. Это вызывает задержку, пока все данные не будут показаны в представлении.

Кроме того, он регистрирует обновления для BOs, которых он интересует (так же, как и раньше), чтобы постоянно обновлять представление через презентаторов.


Поэтому я ищу руководство о том, как настроить Interactor в моем случае. У реализации, упомянутых выше, есть одна задача, затем выполнить ее, и фоновый поток Interactor может быть закрыт.

В моем случае Interactor регистрируется для обновлений из datalayer и ждет их обработки, а затем отправляет данные в поток пользовательского интерфейса Presenter, таким образом, живет до тех пор, пока прослушивается презентатор.

Эта функциональность отличается, и я ищу хорошую практику, чтобы заставить ее работать с «чистой архитектурой».

Поэтому, если я понимаю ваш вопрос, ваша озабоченность или сомнения возникают из-за того, что ваш Interactor не собирается выполнять задачу, а затем заканчивается, но ее подписывают или слушают до тех пор, пока операция не будет выполнена.

На мой взгляд, это прекрасно, Interactor реализует прецедент, и в вашей программе, что асинхронный запрос является прецедентом, не имеет значения, требуется ли время и является асинхронной задачей или является синхронной операцией.

Он по-прежнему является прецедентом, когда Презентатор будет создавать экземпляр Interactor, и когда это закончится, он вернет результат операции. Пока вы сохраняете модульность, а Presenter и Interactor не связаны с прямыми зависимостями, но они обмениваются данными по косвенным отношениям, это прекрасно.