Звучит как что-то очень странное. Используй Flow из бд

можно поробовать как то так
val myLiveData = liveData { //Suspend block
emitSource(...)
}

Сама эта лайвдата в себе содержит PagedList. тут работа с пагинацией короче. И получается так, что она асинхронность там берется чтобы настроить работы BoundaryCallback

получается livedata in livedata?

а ты знаешь, работает

Благодарочка))

Создай поле livedata и пости туда

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

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

На странице со списком подписался сразу на livedata, затем вызвал метод загрузки первой порции данных. Как только загрузятся, выполнить post в livedata и получишь результат на экране. Пользователь сделает скрол, вызовешь метод подгрузки данных, опять сделаешь пост в livedata, и данные отобразятся на экране.

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

То, что есть минусы - это да. Иногда приходится просто транзитом тащить данные и делать лишние преобразования. Но я не знаю подходов, у которых вообще нет минусов. «Забить на архитектуру» явно не из таких.

Главное что бы все были довольны👍

Кто-то, кто подписывается на состояния. Можно во фрагменте, можно в отдельный файл вынести связывание.

Спрошу нетипичный вопрос. Представьте, что у вас есть сокет-соединение с каким-то бэком, и какой-то свой протокол общения по нему. Набор команд, логика их обработки, где-то автоматическая, где-то по событию от пользователя.
Видны сразу понятные части для такой штуки: транспорт для сокета и декодирования сообщений, модель команд, парсер-сериализатор, и стейт-машина со всей логикой. Вопрос: есть ли какой-то стандартизированный подход к проектированию такой штуки? Типа стандартного паттерна или фреймворка, готовый каркас (или рисунок каркаса), где нужно просто каждую часть правильно реализовать?

наверное, не совсем ответ на вопрос, но:
WebSocketStateContext - содержит в себе текущее состояние и Flow/Flowable событий, умеет передовать входящие сообщения и всякие подключиться/отключиться
WebSocketState (Connected, Diconnected, Connecting…) - умеет обрабатывать только те команды, которые допустимы в текущем состоянии (подключить или отключить/отправить
WebSocketEvent - все, что вылетает из сокета - сообщение, события подключения/отключения
имхо, парсер должен лежать где-то в WebSocketStateContext и трансформировать сырые данные в какие-то классы/объекты

Не вебсокет, просто сокет) Примерная структура понятна, да. Вопрос скорее в том, реально ли каждый это заново изобретает, или есть общепринятая практика.

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

Спасибо что поделились)

У меня с сокетами стандартно все разделено на уровни дата,  модель, и т.д.

Есть, но она в архиве у меня