Size: a a a

Android Architecture

2017 January 27

EM

Eugene Matsyuk in Android Architecture
теперь про ваш случай
источник

EM

Eugene Matsyuk in Android Architecture
Вообще такую ситуацию может разруливать Репозиторий
То есть в случае ошибки отдавать данные из БД
источник

EM

Eugene Matsyuk in Android Architecture
если логика не такая простая, и где-то нужно так, а где-то по-другому, то репозиторий может отдавать наружу два метода: для получения данных с сервера и с БД
А интерактор уже сам решает, что делать
источник

AP

Alexander Popsuenko in Android Architecture
У меня просто реализовано так, что репозиторий - это абстракция. От неё наследуются отдельно репозиторий для сети, который лезет в ретрофит, и репозиторий для бд, который лезет в DAO.
источник

AP

Alexander Popsuenko in Android Architecture
Получается, это неправильно?
источник

OS

Oleg Scherbatykh in Android Architecture
А чем плохо на уровне интерактора менять репозиторий?
источник

OS

Oleg Scherbatykh in Android Architecture
т.е. хранить оба там
источник

VM

Valeriy Miller in Android Architecture
Я так понял, что вам нужна одна реализация репозитория, которая в зависимости от ситуации будет отдавать данные из интернета или из БД. А интерактору все равно от куда он получил данные.. поправьте если не правильно понял)
источник

AT

Andrey T in Android Architecture
Сделай 2 интерактора один для БД и один для Сети и разруливай все в перезентере, либой сделай класс прослойку который будет управлять этими двумя интеракторами и отдавать данные преснтеру или кому-то еще
источник

VM

Valeriy Miller in Android Architecture
Получение данных - это ответственность слоя Model, а значит репозитория. В презентере это точно не стоит разруливать.
источник

EM

Eugene Matsyuk in Android Architecture
Alexander Popsuenko
У меня просто реализовано так, что репозиторий - это абстракция. От неё наследуются отдельно репозиторий для сети, который лезет в ретрофит, и репозиторий для бд, который лезет в DAO.
Немного искажаете смысл Репозитория.
Репозиторий как раз агрегирует данные из разных источников. Что я имею в виду. Один репозиторий чисто для работы с контактами. Туда входит и БД, сеть и т.д для получения контактов. Второй Репозиторий для работы с сообщениями. Туда входит и работы с БД и с сетью для сообщений уже
Посмотрите доклад мой и код на гитхабе)
источник

SB

Sasha Bobrova in Android Architecture
Alexander Popsuenko
Кстати, ребят, меня с момента, как я начал использовать CleanArchitecture, мучает вопрос.
Если у нас при запросе из сети произошла ошибка, то нам нужно вернуть данные из бд.
Кто должен определять это? Интерактор? Тогда он будет знать о двух репозиториях.
источник

EM

Eugene Matsyuk in Android Architecture
Valeriy Miller
Получение данных - это ответственность слоя Model, а значит репозитория. В презентере это точно не стоит разруливать.
поддерживаю
максимум - разруливает интерактор
но уж точно не презентер, это вообще не его обязанность
источник

AP

Alexander Popsuenko in Android Architecture
Eugene Matsyuk
Немного искажаете смысл Репозитория.
Репозиторий как раз агрегирует данные из разных источников. Что я имею в виду. Один репозиторий чисто для работы с контактами. Туда входит и БД, сеть и т.д для получения контактов. Второй Репозиторий для работы с сообщениями. Туда входит и работы с БД и с сетью для сообщений уже
Посмотрите доклад мой и код на гитхабе)
Смотрю твой доклад как раз)
Потому и вспомнил про свой вопрос.
источник

EM

Eugene Matsyuk in Android Architecture
там про Репозитории как раз я тоже рассказываю =)
источник

AP

Alexander Popsuenko in Android Architecture
Так и сделаю, уберу разные реализации репозиториев и отдам туда код по выбору источника.
источник

EM

Eugene Matsyuk in Android Architecture
эти примеры еще нужно изучить)
источник

AP

Alexander Popsuenko in Android Architecture
Сделал закладку в хроме. Посмотрю сегодня, если успею
У меня сегодня день видосов докладов)
источник

A

Artur in Android Architecture
Можно ссылку на доклад, пожалуйста?
Я создал репозиторий, который сливает поток сообщений из БД (приходят мгновенно) и из сети (с задержкой), презентер подписан на эти изменения (rx). Проблема в том, что если репозиторий возвращает обсервабл с сообщениями, я не могу узнать, что произошла проблема с получением данных из сети. Если  я кину exception в момент получения данных с сети, у меня могут не сработать onNext  для сообщений с базы и они не отобразятся. Если же я просто поглощу ошибку в момент получения данных из сети, у пользователя отобразятся только закешированные данные и я не увижу, что что-то пошло не так, чтобы предупредить пользователя.
источник

ВБ

Виталий Бендик in Android Architecture
Ну и да, не по любой ошибке можно отдавать данные из БД, могут быть такие ошибки на которые надо иначе реагировать, например разлогинивать пользователя
источник