Ребят, тут все зависит от размера приложения и от того, сколько логики в модели. Если на каждом экране просто запрос в сеть, то модель и не нужна.

у меня реалм выступает моделью

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

ребят, можно я тут не совсем по Moxy, но по архитектуркам, MVP и все дела....

чуваки, внезапные вопрос по MVP, аръитектура и т д. А где лучше хранить переменные, которые нужно сохранять в Bundle на OnSavedInstanceState ? в презентере дублировать метод активити, и в вызове активити делегировать вызове презентеру или всё же как поля класса в активити хранить?

вроде как бы правильно чтобы презентер от андроида отделить, чтобы он не зависил от чего-либо андроидовского

напишу свое мнение. презентер это штука полностью платформозависимая (в отличие от интерактора например). презентер знает про Main thread например и про многие другие вещи. поэтому оперировать бандлами для сохранения стейта для него нормально. я бы делегировал в презентер события сохранения и востановления состояния. только называться они будут иначе, и, по сути не будут просто делегацией. это будут реально методы сохранения состояния презентера (не активити). активити при этом может докладывать в бандл что-то свое специфичное для UI. поскольку вью не должен знать ничего о бизнес-логике, то переменные состояний бизнес-логики в нем хранить не верно.

вот с этим тезисом я полностью не согласен. презентер не должен знать о ДЕТАЛЯХ работы UI, но не о том как работает андроид-приложение в целом

ну т.е. ты за OnSavedInstanceState(Bundle bundle) в презентере, в таком же методе активити вызывать метод презентера, чтобы презентер уже сложил всё свое в бандл ?

а как тогда его тестировать без андроид сдк?

тесты же на обычной jvm запускаются

мокать?

типа да. но это не onSaveInstanceState, это savePresenterState. потому что все остальное активити/фрагмент должен сохранить сам. он сохраняет свой стейт и дает потом такую возможность презентеру. сохранит ли он там что-то или нет, вью не касается и наоборот

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

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

интерактор хорошо, но вот что-то не хочется плодить абстракции. Надо подумать над этим, хмм...

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

поэтому плодить/не плодить вопрос филосовский

не на пустом месте эти абстракции появляются

если ты заморочен на тестах, то интеракторы для тебя благо