Comments 24
Чудесно. Если принимаете заявки, то, пожалуйста, опишите пример соккетов на карточный игре один-на-один. Диберц, кинг, очко, три палки, фараончик, волосинка, акулина, что угодно, на Ваш вкус.
Не знаю, за что вам минус поставили, но мне и самому эта тема очень интересна.
К сожалению, я не работал с подобного рода использованием сокетов — поэтому, увы, не могу описать пример.
К сожалению, я не работал с подобного рода использованием сокетов — поэтому, увы, не могу описать пример.
А чего там описывать то? один-на-один, это всего 2 клиента в рамках одного пула, один толкает сообщение серверу, что он делает, сервер шлёт сообщение второму клиенту.
Я конечно может что-то не понимаю, но пример реалзиации вебсокета есть прямо в на гитхабе в самой socketroket. И просто показать то, что может одна либа недостойно статьи на хабре. Есть еще куча реализаций этого протокола. Есть Socket-IO. Можно попытаться сделать energy-diagnostic, чтобы показать как классно юзать вебсокеты. А это по сути капитанская статья. То есть надо показать преимущества и недостатки данного подхода к организации работы с сетью. А это тупо пересказ того, что я и так могу найти в интеренете в два клика. Извините, накипело.
Судя по найденному вами url, в чате используется Pusher.com, а значит можно использовать их библиотеку libpusher (кстати она также требует socketrocket).
«В следующей статье могу описать, как создать свой WhatsApp при помощи открытых инструментов за 4-5 часов работы. Конечно, если вам, дорогие читатели, будет интересно.»
Не думаю что за 4-5 часов работы можно сделать что-то уникальное. Вы случаем на PubNub имеете ввиду под «открытыми инструментами»? Так там все достаточно просто, советую не портить карму.
Не думаю что за 4-5 часов работы можно сделать что-то уникальное. Вы случаем на PubNub имеете ввиду под «открытыми инструментами»? Так там все достаточно просто, советую не портить карму.
Можно сделать, не уникальное, конечно — ведь WhatsApp уже существует :)
Под «открытыми инструментами» имею ввиду сервис от C2Call. Мне пришлось сильно углубиться в него, чтобы реализовать кастомный чат для одного клиента — вот и хочу поделиться опытом.
Если не проходить мой путь проб и ошибок из-за недостатка официальной документации, то вместо моей недели можно потратить всего 4-5 часов и получить готовый WhatsApp с чатом, пересылкой файлов, видеочатом, голосовыми звонками, звонками на оффлайн телефоны, историей чатов и т.д. и т.п. :)
Да, там все совсем не так просто, как кажется на первый взгляд.
Под «открытыми инструментами» имею ввиду сервис от C2Call. Мне пришлось сильно углубиться в него, чтобы реализовать кастомный чат для одного клиента — вот и хочу поделиться опытом.
Если не проходить мой путь проб и ошибок из-за недостатка официальной документации, то вместо моей недели можно потратить всего 4-5 часов и получить готовый WhatsApp с чатом, пересылкой файлов, видеочатом, голосовыми звонками, звонками на оффлайн телефоны, историей чатов и т.д. и т.п. :)
Да, там все совсем не так просто, как кажется на первый взгляд.
Как создать соединение и закрыть его — можно прочитать и в доке либы. А вот как организовать работу вебсокета в фоновом режиме в IOS, я так и не разобрался. Если есть знающие люди, очень прошу подсказать, куда копать хотя бы. Т.к. через 10 минут работы сокет рвет соединение. А если поставить флаг voip, с которым все работает, то в сторе отказ получается, т.к. нет реализованного функционала voip.
Никак, «честный» бэкграунд простым чатам недоступен.
Разве что в iOS 7 можно по пушам и/или периодически получать данные.
Разве что в iOS 7 можно по пушам и/или периодически получать данные.
Спасибо за ответ. Этого я и боялся. В любом случае вебсокет слишком «дорогой» протокол для батареи. Будем думать, как это оптимизировать :)
А нет ли какой-нибудь ссылки с тестами потребления батареи при использовании веб-сокетов? Было бы здорово почитать.
>> слишком «дорогой» протокол для батареи
вероятно этим и объясняются все ограничения яблока по поводу фонового режима.
вероятно этим и объясняются все ограничения яблока по поводу фонового режима.
Простите, а на чем основано ваше предположение, что вебсокет дорог для батареи? Насколько я знаю, то батарею ест не поддержка постоянного соединения, а количество данных передаваемых через сеть.
Все верно. Вебсокет подразумевает как раз постоянную передачу данных, т.к. этот протокол все же предусмотрен больше для реалтайм обмена данными. Именно поэтому я так и написал. Можно сократить объем передаваемых данных, а также частоту, но тогда зачем нужен вебсокет? Когда можно ограничиться пушами и т.д. :)
Я думаю что реалтайм и постоянная передача данных — разные вещи. В нашем приложении мы используем вебсокет, как раз для реалтайма. А передача данных происходит всего несколько раз в минуту. То есть по расходу батареи мы в этом случае выигрываем, так как не дергаем сервер каждые 5-10 секунд для синхронизации.
Если у вас данные передаются раз в N минут, то зачем дергать сервер каждые 5-10 секунд? И если данные идут только с сервера, почему бы не использовать пуш с нагрузкой, который в устройстве оптимизирован по потреблению (насколько я помню, телефон может получать пуши даже в случае спячки)?
В любом случае, в нашем приложении проблема в том, что данных бегает очень много и слишком часто. Это нужно оптимизировать, что мы и делаем :) Другое дело, что для поддержания вебсокета нужно использовать вейк локи, которые и сажают батарею, т.к. ни проц, ни wifi не могут уснуть.
В любом случае, в нашем приложении проблема в том, что данных бегает очень много и слишком часто. Это нужно оптимизировать, что мы и делаем :) Другое дело, что для поддержания вебсокета нужно использовать вейк локи, которые и сажают батарею, т.к. ни проц, ни wifi не могут уснуть.
это решается если приложение описано в манифесте как voip — но там придется много взаимодействовать с платформой, чтобы прошло…
Добавляем SocketRocket в проект
Используем CocoaPods и не парим себе и другим мозг.
Sign up to leave a comment.
Используем вебсокеты в своем iOS приложении