Size: a a a

Android Architecture

2017 January 27

AP

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

YS

Yuri Shmakov in Android Architecture
можно сделать враппер и в него запихивать данные + информация о провайдере данных + ошибка, если такая была
источник

EM

Eugene Matsyuk in Android Architecture
Yuri Shmakov
можно сделать враппер и в него запихивать данные + информация о провайдере данных + ошибка, если такая была
вот прям с уст сорвал
только писал это))
источник

EM

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

AP

Alexander Popsuenko in Android Architecture
Alexander Popsuenko
У меня та же проблема, точнее не проблема уже.
Много раз спрашивал, как люди делают.
Я делаю хак с помощью Rx, чтобы послать и данные и ошибку.
Недавно решил, что, как вариант можно пробрасывать модель, которая будет содержать и данные и ошибку.
Второй вариант лучше, если Observable, а не Single, т.к. после OnError конец все равно подписке.
источник

A

Artur in Android Architecture
Yuri Shmakov
можно сделать враппер и в него запихивать данные + информация о провайдере данных + ошибка, если такая была
я так и сделал, но решение не очень нравится
источник

A

Artur in Android Architecture
спасибо. смотрел на днях)
источник

AT

Andrey T in Android Architecture
Eugene Matsyuk
Немного искажаете смысл Репозитория.
Репозиторий как раз агрегирует данные из разных источников. Что я имею в виду. Один репозиторий чисто для работы с контактами. Туда входит и БД, сеть и т.д для получения контактов. Второй Репозиторий для работы с сообщениями. Туда входит и работы с БД и с сетью для сообщений уже
Посмотрите доклад мой и код на гитхабе)
Если следовать твоему посылу, то Realm и SqlLite DB, описанные в этой статье должны быть в одном репозитории https://medium.com/@krzychukosobudzki/repository-design-pattern-bc490b256006
источник

EM

Eugene Matsyuk in Android Architecture
Andrey T
Если следовать твоему посылу, то Realm и SqlLite DB, описанные в этой статье должны быть в одном репозитории https://medium.com/@krzychukosobudzki/repository-design-pattern-bc490b256006
тут можно сделать несколько по-иному
если мы знаем, что работа с бд у нас может поменяться, то можем ввести специальный DBFacade, скажем.
У него будет единый интерфейс, но две разные реализации
Получается, что этот DBFacade будет посредине между репозиторием и непосредственно работой с БД
таким образом, Репозиторий просто дергает этот DBFacade, а как именно идут в БД запросы, его не волнует
источник

AP

Alexander Popsuenko in Android Architecture
Солидарен, так и делаю.
источник

AD

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

EM

Eugene Matsyuk in Android Architecture
Andrew Dementiev
можно сделать прокси-реп, если те репозитарии используются где-то отдельно
не-не, не мешайте в кучу Репозиторий
источник

EM

Eugene Matsyuk in Android Architecture
не надо прокси-реп
ну это немного разные сущности
источник

AT

Andrey T in Android Architecture
Eugene Matsyuk
тут можно сделать несколько по-иному
если мы знаем, что работа с бд у нас может поменяться, то можем ввести специальный DBFacade, скажем.
У него будет единый интерфейс, но две разные реализации
Получается, что этот DBFacade будет посредине между репозиторием и непосредственно работой с БД
таким образом, Репозиторий просто дергает этот DBFacade, а как именно идут в БД запросы, его не волнует
согласен
источник

AP

Alexander Popsuenko in Android Architecture
@eugene_matsyuk
Еще вопрос по видео, ты говоришь, что нужно помечать аннотациями данные из репозитория - согласен на 200%
Но как это сделать, если юзаешь Rx?
источник

EM

Eugene Matsyuk in Android Architecture
Alexander Popsuenko
@eugene_matsyuk
Еще вопрос по видео, ты говоришь, что нужно помечать аннотациями данные из репозитория - согласен на 200%
Но как это сделать, если юзаешь Rx?
Хороший вопрос
Я пишу подробный комментарий в интерфейсе, где описываю, что этот Observable может нам вообще вернуть
источник

EM

Eugene Matsyuk in Android Architecture
это очень оправдывается, если вернуться к этому месту через месяц
источник

EM

Eugene Matsyuk in Android Architecture
а ты уже ничего не помнишь =)
источник

AD

Andrew Dementiev in Android Architecture
Eugene Matsyuk
не надо прокси-реп
ну это немного разные сущности
не, можно конечно через фасады/фабрики подключать источники данных и сделать один, который сам решает как тянуть данные, но если каждый репозитарий где-то используется, а где-то нужно скомбинировать источники, то почему плохо сделать прокси с интерфейсом репозитария, которое тянет данные не напрямую из источников, а из других репов? ну кроме того, что добавится зависимость внутри слоя?
источник

AP

Alexander Popsuenko in Android Architecture
Eugene Matsyuk
Хороший вопрос
Я пишу подробный комментарий в интерфейсе, где описываю, что этот Observable может нам вообще вернуть
Как-то не очень)
Хочется, чтоб подсвечивалось, но никак.
На ум приходят слова дядюшки Боба, не возвращать Null никогда, а если что возвращать заглушку
источник