те нужно что-то среднее между Suссessful Story, Guide и CookBook

да, будет круто на самом деле

Если это публичное достояние, то те же Guide/CookBook неплохо на github pages получаются. Тогда и комьюнити сможет свои решения через пул-реквесты предлагать.

кстати хорошая идея

Вопрос по поводу моделек.
Пишу модуль чатов. Сообщение может прилететь по http по запросу от преззентера (rxjava + retrofit), а может прилететь по сокетам, realm-time.
Сейчас у меня есть следующие модели:
HttpMessageModel
SocketMessageModel
DbMessageModel - является одновременно бизнес моделью - храню ровно то, что нужно для наполнения вьюх.
ViewMessageModel - совсем «тупая» модель, в которой есть ссылка на картинку и 4 строки (сообщение сверху слева, сверху справа, etc...)

Первые две модели мапятся в третью на уровне модели. Модель данных (бизнес / дб) мапится на уровне интерактора/презентера (тут ещё не решил) в "тупую" модельку вью.

Вопросы:
1) В каком случае есть смысл отделять бизнес-модель от той, что хранится в бд?
2) Как вы считаете, стоит ли создавать такую «тупую» модель, которую наполняет презенте и отправляет в адаптер? Получается, в адаптере совсем нет логики и его наполнением, как и формированием сообщений, занимается презентер (через специальный класс-маппер).

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

поддерживаю

Допустим, этот вопрос я как раз рассатриваю.

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

Презентер получает "тупую" (готовую к отображению, из одних строк) модель с айдишником? Получается, что интерактор может передать презентеру несколько раз одну и ту же модель.

добавь поле айдишника у "тупой" модели))

А вот у меня как раз по репозиторию вопрос, у интерактора есть метод getMessages() который вернет List сообщений, а какой модели? Ведь откуда грузить, из бд или из сети решает репозиторий ведь так? Тогда он должен вернуть одинаковую модель, либо наследника

Да это не проблема) Я в целом про подход. Звучит логично?)

У меня всегда возвращается лист соощений, который был трансформирован из бизнес-объекта. Бизнес объекты берутся из кеша, потом идёт запрос на сервер, полученные данные трансформируются в бизнес объекты, и так же идут в Observable.onNext()

общий объект тогда сделайте, который будет отдаваться репозиторием

Я вообще про абстрактный случай

Репозиторий же решает кто будет источником данных

ну он модель общую и выдает)

Но вернуть может конкретный тип данных, следовательно интерактор знает об 1 модели данных из репозитория