Постоянство Android MVP

Question

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

Мой первый вопрос:

• Должен ли я хранить свои данные в репозитории (так как я использую кинжал 2, а репозиторий находится в области приложения) или я должен хранить их в презентаторе и каким-то образом сохранять их там. Лично я хотел бы оставить это в докладчике, однако я пытаюсь научиться традиционным способом.

Мне также известны компоненты архитектуры Android, в частности ViewModel, однако я хотел бы сохранить шаблон MVP вместо MVVM.

Мой второй вопрос:

• После достижения настойчивости, как мне использовать LiveData с MVP?

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

Приветствия

Answer 1

Должен ли я хранить свои данные в репозитории или хранить их в презентаторе и каким-то образом сохранять их там?

У вас есть интересный вопрос, который у меня возник когда-то, когда я начал работать с MVP. Вот мои 2 цента:

Продолжалось обсуждение двух упомянутых вами вариантов. Я лично предпочитаю шаблон хранилища. Это намного чище IMO, и с ним легче справляться с такими случаями, как поворот экрана, когда запрос уже поступил, и т.д. Также каждый раз, когда устройство вращается, вам не нужно извлекать данные из БД. Если вы думаете, что это дорого, может быть, вы можете создать уровень кеша до БД. Есть очень интересная и подробная статья: Докладчики не для настойчивых Майк Нахимович , который во время своей работы в качестве разработчика Android в New York Times работал над библиотекой под названием Store , который помогает достичь того же. Из статьи:

Я бы предложил использовать хранилища данных, которые абстрагируют загрузку данных. Вместо того, чтобы докладчику нужно было кэшировать данные, мы можем использовать шаблон репозитория и создавать провайдеры / хранилища данных, которые могут получать данные из сети и кэшировать их, когда они нам нужны. С одной стороны, этот подход облегчает сохранение ваших данных. Еще одним преимуществом является то, что у нас есть единый источник правды для наших данных. Наконец, мы можем исключить такие вещи, как Interactors, и просто сделать так, чтобы ваш Presenter подписывался на ваши магазины, когда им что-то нужно для представления.

Надеюсь, это немного поможет.

Answer 2

Репозиторий должен действовать только как ваш шлюз для доступа к данным из разных источников данных.

Например

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

При этом

Презентатор должен хранить ссылку на данные, которые он запрашивает (т. Е. UserModel), репо получает данные только из любого источника данных и все. То же самое относится к любым операциям с данными (сохранение, удаление, обновление, получение и т. Д.). Поэтому, если вам нужно хранить ссылку на область приложения для вашего объекта данных, создайте отдельный класс, скажем, с именем InMemoryStore, отметьте его как область приложения и сохраните в нем ссылки. Используйте шаблон Repository для запроса данных из него.

Также важно отметить

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

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

Наконец

Поскольку я использую RxJava, я не чувствовал необходимости использовать LiveData, поэтому я недостаточно осведомлен об этой теме.

Вы можете проверить этот полный пример , чтобы узнать, как применить MVP с RxJava и Dagger

Надеюсь, это было полезно и понятно :) 1036 *