Исправление mono, (текущая версия) :
Рассылка, в любом случае, будет только для тех кто явно скачал себе клиентское приложение, тут даже галочка не нужна.
Я вижу следующие варианты решения задачи:
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 человек точно не выдержит), а самостоятельно реализовывать весь бекенд достаточно трудоёмко.
Исходная версия mono, :
Рассылка, в любом случае, будет только для тех кто явно скачал себе клиентское приложение, тут даже галочка не нужна.
Я вижу следующие варианты решения задачи:
1. Реализовать на лоре всю функциональность, связанную с регистрацией, разрегистрацией мобильных клиентов для пушей, работу с Apple Push Notifications (APN) и Google Cloud Message (GCM). Это сложно, трудоёмко и потребует реализации некого API, но самый правильный вариант. Трудоёмкость его мне оценить очень сложно.
2. Parse.com в качестве посредника. Это «backend as service», который может хостить некий код на js и рассылать уведомления и на iOS и на Android с помощью своего SDK.
Т.е, ЛОР, в момент появления нового уведомления будет сообщать об этом сервису на parse.com, с помощью HTTP-реквеста, а там уже будет непосредственное управление подпиской на уведомления конечных устройств, работа с Apple Push Notifications и Google Cloud Message.
Тут нужно хорошо подумать на счёт секьюрности. Лишнее звено – это очень большой минус на который нужно уломать Макса.
Наверное, это самый простой вариант. Я могу в одно рыло его реализовать. И серверную часть и клиентскую. :)
3. Некий изолированный сервер-посредник, который будет раз в N-минут забирать rss с лора, чтобы узнать о появлениях новых уведомлений, работать с APN, GMC, управлять регистрациями устройств, и т.д, и т.п.
Для этого тоже можно использовать parse.com (у меня прототип так работал), но при увеличении популярности можно легко выйти за бесплатные пороги parse.com (2000 человек точно не выдержит), а самостоятельно реализовывать весь бекенд достаточно трудоёмко.