Надоели конечно все эти поделки от Google

Реально работает хорошо только схема с активно-пассивным сервером данных. Раньше использовали только схему с пассивным сервером данных. Т.е. используется доработанная модель почтового сервера:
- если получатель данных не готов - то сообщение от сервера данных хранит почтовый сервер(сервер сообщений). При переходе в активное состояние получатель считывает готовые данные с почтового сервера - получает почту(сообщения)
- если получатель активен - то сообщение от сервера данных почтовый сервер передает получателю сразу
- если одинаковые данные(и соответственно сообщения) идут как из пулемета, то одинаковые сообщения проверяются почтовым сервером на дубликаты и старые отбрасываются
Т.е. получаем - когда получатель активен - то он читает все сообщения(данные). Когда пассивен - только последние изменения.
Это касается всех Observable объектов - таблицы БД, наличие отсутствие сети и ее качество, различные Content provider или Intent зависимые объекты - например от включения/выключения экрана.
Пример https://github.com/shishkin1966/CleanArchitecture5

Т.е. используется модель Сервер данных -> Почтовый сервер -> Получатели данных (читатели почты)

При этом сообщение может быть направлено сразу нескольким получателям (Пр.: таблица в БД изменилась или пришел ответ от сервера с курсами валют) - т.е. может быть указано сразу несколько адресатов

Даже фактически это модель Сервер данных -> Мессенджер -> Получатели данных (читатели сообщений)
А запрос к данным через Retrofit или к Room будет включать уже список адресов получателей данных

pand,
После того как я и все разрабы компании отказались от модели Google(к тому времени ее и не было) была разработана собственная модель, лишенная глупости Google
Может и Вы попрактикуетесь - и уйдете с нее
Кто например сейчас помнит Loaders - а это был просто последний крик моды
Или например постраничная загрузка данных.
Вам не приходилось тянуть 25000 строк с БД в RecyclerView? C БД размером в 500Мб на мобиле? Или организовать поиск по такой БД
с не оптимизированному запросу типа LIKE "%что_то_там%"
Наиболее функциональна модель длинного чтения - чтение данных в запросе по нарастающей 5-10-20-20-20.. строк с сетевых запросов, и по 10-50-100-100... строк с БД. Все в фоне. Промежуточные результаты отдаются View(ListView или RecyclerView) для отрисовки.
Поэтому и советую сразу уйти - чтобы не было мучительно больно за бесцельно потраченное время. Хотя у кого какие проекты бывают. Вы наверно не знаете, что функция getCount() в курсоре вызывает перебор всех записей, что может занять несколько минут
если это курсор по сложному фильтру. Поэтому ее НИКОГДА не используют.

Описание модели выборки данных:
- Получатель данных направляет запрос. Запрос включает список получателей
- Репозиторий перенаправляет запрос конкретному провайдеру данных (БД или сетевому или иному - например длинный по времени расчет)
- Данные выбираются и формируется результат запроса с учетом наличия ошибки при выполнении
- Результат в виде сообщения отдается Мессенджеру
- Мессенджер проверяет список получателей и если какие-либо получатели активны - то пересылает сообщение получателям, если нет - то оставляет у себя. Попутно проверяется - если одинаковые письма не нужны - то все старые копии удаляются.
- Получатель асинхронно получает сообщения и выводит или данные результата или сообщение об ошибке, хранящееся в результате. При активации получателя производится чтение всех пришедших на его адрес сообщений
- Одновременно получатель сообщает мессенджеру свое состояние - активен или пассивен.

Пример - добавление данных в таблицу счетов БД
- Запрос после выполнения самой операции в БД (insret), говорит Observable объекту - данные изменились , который уже в свою очередь разошлет сообщение (Данные изменились) по своим подписчикам. Вам до лампочки кто получатель - презентер, view или widget и в каком он состоянии.

Можете заодно поплюхаться с LiveData - одновременно например сделая 100 вставок или изменений с задержкой в 50-100 мс.

pand,

Конкретно доставлять сообщения можно через EventBus. Но народ ругается на сложность различных Event при усложнении проектов. Поэтому используется простой Месенджер(Mail сервер). В котором получатели сообщений должны регистрироваться(входить) и отменять регистрацию (выходить), а также читать почту при открытии (onResume).

pand,

Если у вас проект состоит из 10 экранов, 2 табличек в БД и 8 запросов в сеть - то лучшее решение это WeakReference<Listener>

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

Про LiveData и Lifecycle - после нескольких месяцев экспериментов - все послали на ....

Смотрите у других, у меня, думайте сами - решайте сами. Но использовать Google - только если сами ничего не можете.

Про 100 запросов после 50 мс. Это реальности на длинных транзакциях через Content Providers или в Room с LiveData.
Лечится тупо Debouncer с подавлением дребезга и Мессенджером, который пропускает только последнее сообщение удаляя все предыдущие. Т.о. получатель получит только последние измененные данные. Если хотите потрахаться с LiveData - можете - не запрещено.

Про EventBus - крутая штука в крутых руках. Но с разрастанием проекта сообщения придется делить на потоки. Об этом надо думать заранее. Поэтому используйте EventBus, Rx или как я - Bolts ( https://github.com/BoltsFramework/Bolts-Android - он намного проще Rx). На EventBus , как и Rx должно быть согласие команды. Учтите, что Rx работает только с ПОСЛЕДОВАТЕЛЬНОСТЯМИ. Поэтому если поменяется логика - все полетит к черту. Rx как в тюрьме - все по расписанию. Ни девочек, ни пьянок, ни шмали.

Про отправку сообщений - если получатель в onResume и onPause (висит в фоне) - то сообщение ему отправляется сразу.

pand,

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

pand,

Говоря о EventBus - на больших проектах просто очуметь будет девочек, алкоголя и шмали. Не трудно и потеряться. С EventBus очень трудно ищутся ошибки зацикливания сообщений.

Схема приложения указанная в исходниках