сделай foreground сервис, тогда сможешь быть спокоен что твою аппку не убьет система

Про сервис и мне интересно, куда его пихать, и как с ним взаимодействовать следуя "чистой архитектуре".
в случае с rx-java интеракторы выдают всегда обзерваблы, а презентеры уже жонглируют процессом.

А вот в случае сервиса, реальный пример: запустили сервис, и кидаем из него калбеки, о смене той же позиции.
Как в этой ситуации правильно спроектировать приложение?

Я бы засунул этот сервис куда-нибудь в утилитный пакет, затем в интеракторе открыл постоянный обсервэйбл, и обрабатывал данные с нужной периодичностью. Мне тоже интересно что Евгений скажет по этому поводу))

Как по мне, гео позиция это репозиторий, который отдает данные интерактору (в случае rx отдает observable который эмитет координаты) а интерактор в свою очередь это дело обрабатывает и отдает модель в презентер. Возможно что то упустил в обсуждении, и причину почему такая реализация не подойдёт

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

Согласен

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

Их = рх

Если в таком ключе, то мы об одном и том же говорим)

@eugene_matsyuk еще вспомнил, что у отдела майкрософт паттернс и практикс есть неплохой гайд по архитектуре, про слои там тоже есть. На пдф ссылка не работает, но есть веб версия https://msdn.microsoft.com/en-us/library/dd673617.aspx, там в целом про архитектурку https://msdn.microsoft.com/en-us/library/ee658109.aspx и про каждый отдельный слоя глава, вот например бизнес-логика https://msdn.microsoft.com/en-us/library/ee658103.aspx, в общем материал интересный. Точно помню, что у них есть в доках к Unity (не тот что 3D, а местный Dagger) есть материал хороший, и к фреймворку Prism, позже поищу. Для коллекций ресурс думаю вам сгодится)

Ребят а по rxfirebase вы либы юзаете, или свои пишите?

Их несколько на гитхабе, какая наиболее стабильная/удобная/популярная?

@eugene_matsyuk такой вопросик про слой repository. если случается кейс, в котором у нас два экрана с примерно одинаковыми данными. то под эти два экрана делать три репозитория (один родительский с общими методами и два других с уникальными методами) или два репо с дублирующимся кодом не так страшно, как величают?

Смотря как дальше у вас будет)
Если экраны дальше будут ещё больше отличаться друг от друга, то может стоит просто два репозитория сделать
Ну а так, конечно же, выносите в общий)

@sandrb не подскажешь?)

я не использовал никаких сторонних rx оберток над firebase: для моих задач это было бы лишним. Где было нужно я просто оборачивал в Single.create(...)

Возможно rx кастомные обертки - это удобно, если использовать firebase database в совсем real-time online режиме. Но не подскажу, мне и так все было хорошо (я использовал database, auth и remote config) без дополнительных оберток и firebaseUI

Ребят кто что может подсказать ?