Я сделал фасад. Всюду появились методы AC.e("offer created", params....)

За ним 4 аналитики

вообще рекомендую делать один класс на каждый ивент приложения

Спасибо за тему с аспектами, гляну. Зачем столько классов?

так получится четкое описание каждого ивента

У меня их 100 шт)) можно классифицировать по операциям с сущностями. Crud. Тогда базовый класс будет иметь конструктор Event(string entityname, OperationType t)

А кто-то делает иначе?

Дайте пожалуйста линк на какой нить пример mvp где есть тесты презентера

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

Тут раньше скидывали

Еще от Артема мне в свое время помогло его приложение
https://artemzin.com/blog/how-to-mock-dependencies-in-unit-integration-and-functional-tests-dagger-robolectric-instrumentation/

спасибо

Ребят, а можете поделится ссылкой например как реализовать роутер? и заодно куда его инжектить? в презентер? или в активити, а потом вызывать по интерфейсу метод в презентере?

а посмотри на либку, не обязательно ее использовать, может идеи просто появятся https://habrahabr.ru/company/mobileup/blog/314838/

[осторожно спойлер!] там роутер в презентер инжектится))

презентеры живут вечно?
У меня используется в роли бд реалм, который желательно закрыть когда он больше не нужен или когда закрыли приложение.
Как вы отлавливаете онДестрой приложения что бы позакрывать все конекшены и в какой сущности?

кстати не первый раз слышу про хорошие идеи с этой библиотечки

Кстати с чатика Мокси прозвучал хороший вопрос, а где должна быть геолокация? Собственно а где должны быть также и ContactProvide, CallendarProvider и прочие андроидовские средства.
Я думаю, что работы с ними должна проводиться в Data слое на уровне работы с той же сетью или БД, то есть под Репозиторием.
Этим мы добиваемся того, что в бизнес-логике не будет андроидовских классов. Ну и плюс получается вполне корректное разделение по слоям.
Кто что думает?