Пагинация ж есть

В любом случае, речь идет просто о кастомном жизненном цикле вьюшки

Будь то ресайклер, вьюпейджер или диалог

Или вообще что-то свое

Я против того, чтобы тянуть детали имплементации фрагмента/активити в пмку и завязываться на их уникальных onPause/onResume

Я за универсальный attach/detach

Если нужно что-то особенное - без проблем, пишем свой bindTo в контексте фрагмента/активити/чегоугодно, имплементим PmView с его untilUnbind и мы в шоколаде

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

Эммм, это как?

Атач/детач - это состояние конкретной вьюшки, а у нас пмки объединяют состояние целого комплекса вьюшек, разве нет?

Если у меня боттом шит отдетачится, а остальной ui останется на месте - анбинд у целой пмки дернется?

Зачем вообще пмке о нем знать, не понимаю =) Только усложняет все

Предполагаю что для ботомшит своя пм-ка (возможно чайлд) и у нее свой жц

Ну это искусственное ограничение, из-за которого у меня со временем началось бы бомбление 😁

Ахаха, вот когда бомбит, то это самый ценный фидбек, кстати :)

Всем привет, был опыт использования библиотеки на одном проекте. И из сложностей столкнулся с ситуацией, что при создании множества экранов часто приходится переписывать похожую логику (В рамках апи библиотеки). Из этого возникает вопрос о том, как выделить эти сценарии для повторного использования? Наследоваться от базовых PmView и PresentationModel не кажется хорошей идеей. Хотелось бы услышать, что думаете по этому вопросу.

Привет. А childPm не подходит?

Вот  childPM только недавно увидел, еще не удалось заиспользовать. Но в случае с child это потребует, что бы View знала про child и брала стейты из неё?

Из вьюхи ты работаешь с основной ПМкой, ничего не зная о childPm. ChildPm просто берет на себя реализацию части интерфейса родительской PMки

И с точки зрения вынесения логики из onBindPresentationModel, хоть она и простая, но постоянно копипастить биндинги тоже напрягает