Pull to refresh

Comments 9

Немного странное именование полей вы выбрали:
"name": {
    "+++": "Новое название",
    "---": "Старое название"
}

Если я захочу маппить входящий JSON в объект без переименования полей, то ничего не получится, потому что код превращается в
newValue = data->diff->name->+++

Что в большинстве языков невалидно.
Насколько я могу судить, речь идет о php, когда json_decode возвращает объект класса stdClass.
В таком случае можно использовать примерно следующий синтаксис:

$str = '{"name": {"+++": "Новое название", "---": "Старое название"}}';

$obj = json_decode($str);

echo $obj->name->{'+++'};


Либо вызвать json_decode со вторым параметром, равным true, получить array и работать с ним.
Это вроде как нигде не проблема, ключом ассоциативного массива обычно является строка, поэтому всегда можно получить доступ как:
data->diff->name["+++"]
Вопрос удобно ли использовать два стиля обращения к ячейке?
Можно работать с массивами:

$data = json_decode($json_string, true);
echo $data['diff']['name']['+++'];


Можно с объектами:

$data = json_decode($json_string);
echo $data->diff->name->{'+++'};

В нашем проекте ключевым сервисом является сервер обмена сообщениями. Рассылкой уведомлений о новом сообщении занимается отдельный демон. Демон хранит состояние клиента и некоторые данные. У нас есть следующие типы клиентов: Мобильный IOs, Android & WEB. Пуш уведомления на мобильные клиенты рассылаются через API Apple Push Notification Service & Google Cloud Messaging. Уведомление WEB клиентов происходит через флеш. Флеш открывает постоянное соединение с демоном на 80 порту, и при появлении нового события получает порцию JSON, который парсится и передаётся в кэллбэк JS, а тот в свою очередь изменяет HTML.
Интересно. А на каких технологиях реализован сам демон? Си?
да, сам демон написан на сях…
исторически так сложилось, что у нас вся разработка преимущественно на си, есть питон и перл.

общение между бэкендом и демонами преимущественно осуществляется по мемкешовому протоколу. В этом свои плюсы — отладка, не нужно писать собственных клиентов…

написал один типовой демон и потом теражируй его, вписывая новый функционал
Очереди мы используем, но уже внутри процеса. Ну, во первых у нас нагрузка не такая, как у вас и масштабироваться не нужно. Одни поток принимает данные и распихивает его по очередям. Другие потоки читают свои очереди и делают соответствующие пуши на службы гугла и эпла. Один поток слушает (принимает) эпл нотификации, а еще один отвечает за статистику и данные (пишет в БД). Практически тоже, что и у вас… только масштабы меньше :)
В общем все очень интересно…

нагрузка 3 млн сообщ в день
из них более трети на эпл, чуть меньше на андроид и где-то более трети на WEB
Sign up to leave a comment.