Комментарии 9
Немного странное именование полей вы выбрали:
Если я захочу маппить входящий JSON в объект без переименования полей, то ничего не получится, потому что код превращается в
Что в большинстве языков невалидно.
"name": {
"+++": "Новое название",
"---": "Старое название"
}
Если я захочу маппить входящий JSON в объект без переименования полей, то ничего не получится, потому что код превращается в
newValue = data->diff->name->+++
Что в большинстве языков невалидно.
+5
Насколько я могу судить, речь идет о php, когда json_decode возвращает объект класса stdClass.
В таком случае можно использовать примерно следующий синтаксис:
Либо вызвать json_decode со вторым параметром, равным true, получить array и работать с ним.
В таком случае можно использовать примерно следующий синтаксис:
$str = '{"name": {"+++": "Новое название", "---": "Старое название"}}';
$obj = json_decode($str);
echo $obj->name->{'+++'};
Либо вызвать json_decode со вторым параметром, равным true, получить array и работать с ним.
0
Это вроде как нигде не проблема, ключом ассоциативного массива обычно является строка, поэтому всегда можно получить доступ как:
data->diff->name["+++"]
Вопрос удобно ли использовать два стиля обращения к ячейке?+1
В нашем проекте ключевым сервисом является сервер обмена сообщениями. Рассылкой уведомлений о новом сообщении занимается отдельный демон. Демон хранит состояние клиента и некоторые данные. У нас есть следующие типы клиентов: Мобильный IOs, Android & WEB. Пуш уведомления на мобильные клиенты рассылаются через API Apple Push Notification Service & Google Cloud Messaging. Уведомление WEB клиентов происходит через флеш. Флеш открывает постоянное соединение с демоном на 80 порту, и при появлении нового события получает порцию JSON, который парсится и передаётся в кэллбэк JS, а тот в свою очередь изменяет HTML.
0
Интересно. А на каких технологиях реализован сам демон? Си?
0
да, сам демон написан на сях…
исторически так сложилось, что у нас вся разработка преимущественно на си, есть питон и перл.
общение между бэкендом и демонами преимущественно осуществляется по мемкешовому протоколу. В этом свои плюсы — отладка, не нужно писать собственных клиентов…
написал один типовой демон и потом теражируй его, вписывая новый функционал
исторически так сложилось, что у нас вся разработка преимущественно на си, есть питон и перл.
общение между бэкендом и демонами преимущественно осуществляется по мемкешовому протоколу. В этом свои плюсы — отладка, не нужно писать собственных клиентов…
написал один типовой демон и потом теражируй его, вписывая новый функционал
0
Очереди мы используем, но уже внутри процеса. Ну, во первых у нас нагрузка не такая, как у вас и масштабироваться не нужно. Одни поток принимает данные и распихивает его по очередям. Другие потоки читают свои очереди и делают соответствующие пуши на службы гугла и эпла. Один поток слушает (принимает) эпл нотификации, а еще один отвечает за статистику и данные (пишет в БД). Практически тоже, что и у вас… только масштабы меньше :)
В общем все очень интересно…
нагрузка 3 млн сообщ в день
В общем все очень интересно…
нагрузка 3 млн сообщ в день
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Push-уведомления в REST API на примере системы Таргет Mail.Ru