Android приложение, push-уведомления, вот это всё

А стоит ли? Мобильная версия хороша, а уведомления с лора не настолько важная вещь, чтобы хотеть видеть их немедленно. Тем более, что api нет.

Я предпочитаю black и интересны мне в основном уведомления (ну, когда я с телефона)
Тч с моей точки зрения - стоит. Отсутствие api не такая проблема при живом rss уведомлений.

А что бы вы хотели от клиента, кроме уведомлений? В принципе, я бы покоммитил в проект, была бы дорожная карта.

все упирается в lor-api отсутствие

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

А у ЛОРа есть API для всего этого?

костылей бояться - код не писать

писать костыли вместо - кода, лысому быть

www.linux.org.ru/forum/lor-source/11649215/comments

Неа. В планах лет 5 уже, наверное, но думаю, обойтись можно и без него, минимальным костылевелосипедингом

Я думал, даже прототип некий сделал парсер RSS на сервере, но это костыльно. Нужно в движок это внедрять.

рассылку уведомлений в движок? я думаю, макском на это не согласится, все-таки даже если это сделать отключенным по умолчанию, слать уведомления на пару тыщ человек - напряжно будет для лора

Рассылка, в любом случае, будет только для тех кто явно скачал себе клиентское приложение, тут даже галочка не нужна.

Я вижу следующие варианты решения задачи:

1. Реализовать на лоре всю функциональность, связанную с регистрацией, разрегистрацией мобильных клиентов для пушей, работу с Apple Push Notifications (APN) и Google Cloud Message (GCM). Это сложно, трудоёмко и потребует реализации некого API, но самый правильный вариант. Трудоёмкость его мне оценить очень сложно.

2. Parse.com в качестве посредника. Это «backend as service», который может хостить некий код на js и рассылать уведомления и на iOS и на Android с помощью своего SDK.

Т.е, ЛОР, в момент появления нового уведомления, с помощью HTTP-реквеста, будет сообщать об этом сервису на parse.com, а там уже будет непосредственное управление подпиской на уведомления конечных устройств, работа с APN и GCM.

Тут нужно хорошо подумать на счёт секьюрности. Лишнее звено – это очень большой минус на который нужно уломать Макса.

Наверное, это самый простой вариант. Я могу в одно рыло его реализовать. И серверную часть и клиентскую. :)

3. Некий изолированный сервер-посредник, который будет раз в N-минут забирать rss с лора, чтобы узнать о появлениях новых уведомлений, работать с APN, GMC, управлять регистрациями устройств, и т.д, и т.п.

Для этого тоже можно использовать parse.com (у меня прототип так работал), но при увеличении популярности можно легко выйти за бесплатные пороги parse.com (2000 человек точно не выдержит), а самостоятельно реализовывать весь бекенд достаточно трудоёмко.

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

Без APN и GMC делать доставку пушей нецелесообразно от слова «совсем». Ну и сложно, к тому же.

И даже если это всё сделать, то это повторит существующую функциональность APN, GMC и частично parse.com. Все остальные проблемы оно не решит.

ну хз, именно отправка этих APN и GMC для меня темный лес. а можешь вылить на гитхаб какой то, что ты пробовал сделать? ну чтобы примерно оценить масштаб проблемы

Проблема в том, что даже парсинг страниц упирается в перерасход трафика, нежелательный для мобильного приложения. К примеру, чтобы получить адреса и URL новостей, приходится парсить /news/, а вместе с этим получаем либо полные новости, либо до #cut, даже если пользователь не будет их открывать - большая часть запрашиваемых данных бесполезна. Здесь нужна хотя бы минимальная поддержка JSON, как с комментариями в топиках.

ну я изначально думал про прокладку в виде сервака, который занимается парсингом всего этого барахла, всё в приложение тащить - это ад и израиль

Не просветите насчет API, maxcom его совсем категорично не хочет внедрять, даже через небольшие пуллреквесты?

Набросал список функций API (если оно будет делаться), которые, на мой взгляд, требуются для нормального функционирования мобильного приложения (да и можно будет свой ЛОР запилить заодно):

Для топиков: заголовок, категория, автор, дата и время создания, количество подписанных и количество добавивших в избранное (а также списки пользователей), дата и время последнего редактирования, ник проверившего (только для новостей), список тегов.

Для сообщений: заголовок, автор, дата и время создания, дата и время последнего редактирования, список дочерних комментариев, родительский комментарий.

Для пользователей: все, что в профиле плюс URL аватара, поле комментария, находится ли в игнорируемых, кого игнорирует, URL отслеживаемых и избранных тем, список игнорируемых тегов.

Уведомления: количество непрочитанных, URL, дата события, сброс, сброс отдельного уведомления (например, при открытии топика).

Все это в JSON (что-то требует аутентификацию, что-то - нет). Естественно, все вышесказанное ИМХО и не претендует на абсолютную правильность.

Дело в том, что реально движок ЛОРа надо взять и выбросить. Причем, вместе желательно со структурой базы :-)

Была идея. Почитал борцы ЛОРа, желание отпало.

Вопрос насчет (2). Может есть готовые опенсорсные решения? Мне почему-то кажется, что такое нужно очень многим сайтам, и функционал везде одинаковый:

1. Получить уведомление на мобилку и открыть ссылку в браузере, когда на него кликнули.
2. Аутентификация, например камерой с QR-кода.

Т.к. данные только читаются, то если в ссылке не давать секретных токенов, все будет довольно секурно.