Подумал тут насчёт продумывания сабжа и зашёл в тупик.
Есть несколько вариантов:
1. Как в ServerListener. Поступление новых сообщений отслеживается через /x/c. Если они имеются, то выводится уведомление: "Новых сообщений: <число>", но при этом ничего на устройство не скачивается. Когда пользователь жмёт на оповещение, то запускается фетчер.
Плюс подхода - избежание "неожиданных ситуаций". Предположим, в эхе
ii://pipe.2032 решил нагадить бот/спамер и закинул туда 50000 сообщений. Пользователь смотрит на оповещение и думает: "Ага, что-то тут нечисто!". Потом идёт проверять станцию, а база на телефоне остаётся в чистоте от мусора.
Либо по-другому: любители разного чтива закинули куда-нибудь в
ii://lit.14 сразу 50 огроменных рассказов. У пользователя на мобильном интернете остаётся мало трафика, и он осознанно решает не фетчить сообщения до прихода домой, чтобы сэкономить несколько мегабайт.
Минус подхода - использование /x/c. Не все ноды его поддерживают, а фичу хочется для любых станций сразу.
2. Подход "фонового фетча". Фетчер сам запускается и сам фетчит сообщения, а пользователю только говорит о результатах.
Плюсы - универсальность для всех нод и относительная простота реализации.
Минусы - незащищённость базы от спама и от большого трафика.
3. Смесь первого и второго подхода. Делаем проверки не по /x/c, а по индексу, то есть по /u/e.
Плюсы - поддержка всех нод и защита от спама
Минусы - глюкавость при изменении настроек станций (особенно с расширенным /u/e); постоянный жор трафика независимо от наличия новых сообщений; надо где-то хранить и запоминать индекс вне базы; будет сложнее реализовать этот хитрый алгоритм.