[#] Уведомления для IDEC Mobile
vit01(mira, 1) — All
2016-10-09 09:36:31


Подумал тут насчёт продумывания сабжа и зашёл в тупик.

Есть несколько вариантов:

1. Как в ServerListener. Поступление новых сообщений отслеживается через /x/c. Если они имеются, то выводится уведомление: "Новых сообщений: <число>", но при этом ничего на устройство не скачивается. Когда пользователь жмёт на оповещение, то запускается фетчер.

Плюс подхода - избежание "неожиданных ситуаций". Предположим, в эхе ii://pipe.2032 решил нагадить бот/спамер и закинул туда 50000 сообщений. Пользователь смотрит на оповещение и думает: "Ага, что-то тут нечисто!". Потом идёт проверять станцию, а база на телефоне остаётся в чистоте от мусора.

Либо по-другому: любители разного чтива закинули куда-нибудь в ii://lit.14 сразу 50 огроменных рассказов. У пользователя на мобильном интернете остаётся мало трафика, и он осознанно решает не фетчить сообщения до прихода домой, чтобы сэкономить несколько мегабайт.

Минус подхода - использование /x/c. Не все ноды его поддерживают, а фичу хочется для любых станций сразу.

2. Подход "фонового фетча". Фетчер сам запускается и сам фетчит сообщения, а пользователю только говорит о результатах.

Плюсы - универсальность для всех нод и относительная простота реализации.
Минусы - незащищённость базы от спама и от большого трафика.

3. Смесь первого и второго подхода. Делаем проверки не по /x/c, а по индексу, то есть по /u/e.
// Можно даже сделать так, чтобы ноды c /x/c проверялись именно по нему, а ноды без /x/c - по индексу.

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

[#] Re: Уведомления для IDEC Mobile
vit01(mira, 1) — vit01
2016-10-09 09:39:51


Итак, за что проголосует народ? Может быть, есть, что предложить получше?