2011-12-19 2 views
1

Моя компания предлагает приложение для iPhone дневных трейдеров, которое в основном говорит им, когда самое время купить или продать. Кластер серверов генерирует эти сигналы BUY и SELL и должен быть доставлен на устройство iOS клиента через минуту или меньше. Для всех других мобильных клиентов, которые мы разработали, нам разрешено опросить сервер в фоновом режиме (один раз в минуту), чтобы проверить наличие обновлений.Надежная передача сообщений от сервера к iPhone

В iOS, однако, кажется, что выполнение чего-либо в applicationDidEnterBackground, связанное со временем или опросом, не является вариантом.

Это привело меня к просмотру push-уведомлений, но из того, что я читаю, они ненадежны. Они используют методику отправки и забывания, которая не гарантирует, что они будут получены.

У вас возникла проблема с этим. Если мы выдаем сигнал BUY, и пользователь действует на него, тогда сигнал SELL генерируется через 10 минут и отправляется через push, но никогда не приходит, они могут потерять много денег.

Итак, есть ли хороший способ сделать это, или мне не повезло? Благодаря!

+0

Приложениям, таким как Colloquy (IRC-клиент), разрешено открывать TCP-соединение для довольно в то время как, возможно, это вариант для вас? –

+0

Кажется, что Colloquy также использует APNS, можете ли вы показать мне, где они заявляют о наличии постоянного TCP-соединения? – Submerged

+0

Тому, кто задал вопрос, являются ли MMS-сообщения опцией (затем удалены комментарий?), я собираюсь сказать «нет». Я не думаю, что MMS или SMS более надежны, чем Push-уведомления. – Submerged

ответ

1

Между вашим сервером и устройством пользователя существует два посредника: a) Apple и b) сеть.

Apple не гарантирует доставку всех уведомлений; только самые последние гарантированно прибудут и только в течение ограниченного периода времени. Для получения дополнительной информации ознакомьтесь с разделом «Качество обслуживания» в разделе Apple Push Notification Service.

Если устройство имеет доступ к сети через мобильный оператор, все может стать уродливым. Я столкнулся с ситуациями, когда некоторые уведомления поступали не намного позже, а некоторые полностью потерялись. По моему опыту, перевозчики защищают - с рвением - качество своих услуг, а не от третьих сторон, таких как Apple. SMS/MMS обычно не будет потерян, в то время как push-уведомление может.

Опрос сервера был бы жизнеспособной альтернативой для вашего приложения. Увы, Apple не разрешает сетевые операции для приложений, которые были помещены в фоновое состояние (за исключением загрузки в Newsstand и VoIP).

+1

Это то, что я подозревал - это действительно слишком плохо, нет лучшей альтернативы. Я надеюсь, что все это позволит использовать фоновые процессы в будущем, но с правилами, чтобы их нельзя было злоупотреблять. – Submerged

+0

Если вы обнаружите, что «последним» является ограничение, вы можете сохранить список уведомлений на сервере, чтобы приложение могло проверить его на старте. – Greg

0

Попробуйте использовать собственный сервис толчок уведомление от Apple: http://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html

Это довольно легко реализовать, с помощью всего нескольких строк кода в приложении и немного PHP и JSON на сервере, чтобы сделать отправку. Хорошо, что ваш сервер отправляет запрос Apple, а собственные серверы Apple обрабатывают доставку на устройство надежно и надежно. Уведомления обычно доставляются в течение 10 секунд после отправки (если устройство не подключено к сети, оно будет доставлено при подключении устройства).

Из моего опыта с push-уведомлениями я не потерял ни одного, и есть опция доставки, которая постоянно пытается доставить ее до тех пор, пока она не будет успешной, и есть даже API-интерфейс обратного вызова на стороне сервера который позволяет вам проверять статус ваших уведомлений. Вы также можете попробовать выполнить такую ​​услугу, как Urban Airship, чтобы выполнить эту работу за вас.


Вы также можете попробовать использовать один из Apple, background modes как часть этого (например, получить «купить» в качестве уведомления, а также приложение ждать «SELL» в фоновом режиме. Самое большое ограничение в том, что приложение может работать только в фоновом режиме в течение примерно 10 минут за раз, поэтому вам придется использовать обходной путь, например, воспроизведение музыки в фоновом режиме (или создание анонсов акций, таких как музыкальный трек; P), или приглашение пользователя повторно открыть приложение для продолжения фоновой сессии

+0

Я реализовал APNS и si nce мы отправляем немало, есть моменты, когда новое push-уведомление отправляется до того, как старое выйдет, и оно отменено. Я проверю городской дирижабль. – Submerged

+0

Если вы используете поддерживаемый API, вы можете убедиться, что первый доставлен ** до **, вы даже отправляете следующий, и держите следующий, ожидающий вашего сервера, до тех пор, пока не появится первый. У Apple есть неясный API, который позволяет проверять статус, а городской дирижабль имеет немного менее неясный API, чтобы делать то же самое. Архитектура APNS очень способна и гибка, но также довольно неясна, поэтому есть не так много вещей, которые вы ** не можете делать с этим, вам просто нужно найти свой путь. – Greg

+0

Полезно знать! Я проверю это. Тот факт, что они ничего не гарантируют, все еще меня беспокоит, но я думаю, это лучшее решение, которое я имею в наличии. – Submerged

0

Некоторые приложения, похоже, действительно хорошо отображают уведомления (GroupMe), а другие - нет. Если вы действительно волнуетесь, вы можете использовать сервис Twilio для отправки пользователю SMS-сообщения со ссылкой, которая откроет ваше приложение и предоставит ему некоторую информацию. Таким образом, SMS может сказать: «ПРОДАМ ПРОДАВАТЬ ПРОДАВАТЬ yourapp: // stock = APL» или что-то в этом роде. Это явно не будет работать для пользователей iPod touch или iPad (хотя я не знаю, будет ли это проблемой для вас.

Смежные вопросы