신뢰할 수있는 서버 대 iPhone 메시징

우리 회사는 기본적으로 구매 또는 판매 할 때가 언제인지 알려주는 데이 트레이더 용 iPhone 앱을 제공합니다. 서버 클러스터는 이러한 BUY 및 SELL 신호를 생성하며 1 분 이내에 고객의 iOS 장치에 전달해야합니다. 우리가 개발 한 다른 모든 모바일 클라이언트의 경우 백그라운드에서 서버를 폴링하여 (분당 한 번) 업데이트를 확인할 수 있습니다.신뢰할 수있는 서버 대 iPhone 메시징

그러나 iOS에서는 time이나 폴링과 관련이있는 applicationDidEnterBackground에서 작업을 수행하는 것이 옵션이 아닌 것으로 보입니다.

이렇게하면 푸시 알림을 볼 수있게되었지만 내가 읽은 것에서는 신뢰할 수 없습니다. 그들은 send-and-forget 방법론을 사용합니다.

이 문제가 발생할 수 있습니다. 우리가 BUY 신호를 내고 사용자가 그것에 대해 행동하면 10 분 후에 SELL 신호가 생성되고 푸시를 통해 보내지 만 도착하지 않으면 많은 돈을 잃을 수 있습니다.

이렇게하려면 좋은 방법이 있습니까? 아니면 운이 좋을까요? 감사! 애플의 푸시 알림 서비스를 사용하여

출처

2011-12-19 Submerged

Colloquy (IRC 클라이언트)와 같은 응용 프로그램은 TCP 연결을 열린 상태로 유지할 수 있습니다. 잠시만 기다려주십시오. –

Colloquy도 APNS를 사용하고있는 것으로 보입니다. 영구 TCP 연결이있는 곳을 나에게 보여줄 수 있습니까? – Submerged

MMS 메시지가 옵션인지 묻는 사람에게 코멘트?), 아니오라고해야 할 것입니다 .MMS 또는 SMS가 푸시 알림보다 더 안정적이라고 생각하지 않습니다. – Submerged

서버와 사용자 장치 사이에는 두 가지 중개자가 있습니다. a) Apple 및 b) 네트워크.

Apple은 모든 통지의 배달을 보장하지 않습니다. 가장 최근의 것만이 도착하도록 보장되며 제한된 기간 동안 만 보장됩니다. 자세한 내용은 Apple Push Notification Service의 "서비스 품질"섹션을 참조하십시오.

기기가 이동 통신사를 통해 네트워크에 액세스하는 경우 문제가 발생할 수 있습니다. 나는 어떤 통지가 훨씬 늦게 도착할 때까지 도착하지 않았고 일부는 완전히 잃어버린 상황을 경험했다. 내 경험에 비추어 볼 때, 통신 사업자는 애플과 같은 제 3 자의 것보다는 열성적으로 자신의 서비스의 품질을 보호합니다. 푸시 알림이있는 동안 SMS/MMS는 일반적으로 손실되지 않습니다.

서버를 폴링하면 앱의 대안이 될 수 있습니다. 아아, Apple은 백그라운드 상태에 놓인 앱 (뉴스 스탠드 다운로드 및 VoIP 제외)에 대한 네트워킹 작업을 허용하지 않습니다.

출처

2011-12-19 13:47:47

이것은 내가 의심했던 것입니다. 더 나은 대안이 없다는 것은 너무 나빴습니다. 나는 모두가 미래의 백그라운드 프로세스를 허용하지만, 규칙을 사용하면 남용 될 수 있기를 바랍니다. – Submerged

'최신 버전 만'으로 제한되는 경우 서버에서 알림 목록을 유지하여 앱이 시작을 확인할 수 있도록 할 수 있습니다. – Greg

시도 : http://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html

그것은 몇 가지 응용 프로그램 코드의 라인과 전송을 할 수있는 서버에 PHP와 JSON의 비트와 함께, 구현하기가 매우 쉽습니다. 좋은 점은 서버가 Apple에 요청을 보내고 Apple의 서버가 장치를 안전하고 안정적으로 처리한다는 것입니다. 알림은 일반적으로 전송 후 10 초 내에 전달됩니다 (기기가 오프라인 상태가 아닌 경우 기기가 온라인 상태가되면 전달됩니다).

푸시 알림에 대한 경험으로 볼 때 하나만 잃어 버리지 않았으며 성공할 때까지 계속 전달하려고하는 배달 옵션이 있으며 사용할 수있는 서버 측 콜백 API도 있습니다. 알림 상태를 확인할 수 있습니다. Urban Airship과 같은 서비스를 시도해보십시오.

또한이의 일환으로 애플의 background modes 중 하나를 사용하여 시도 할 수는 (알림으로 'BUY'를 받아 앱이 백그라운드에서 'SELL'을 기다리는이 등. 가장 큰 한계는 그 앱은 한 번에 약 10 분 동안 백그라운드에서만 실행할 수 있으므로 백그라운드에서 음악을 재생하거나 (음악 트랙과 같은 주식 공지를하는 등) 일시적인 해결책을 사용하거나 사용자에게 앱을 다시 열도록 요청해야합니다

출처

2011-12-19 13:08:59 Greg

APNS와 si를 구현했습니다. 우리는 꽤 많은 것을 보내고 있습니다. 오래된 푸시 알림이 보내지기 전에 새로운 푸시 알림이 보내지고 오버라이드되는 경우가 있습니다. 나는 도시 비행선을 조사 할 것이다. – Submerged

백업 된 API를 사용하는 경우 첫 번째 API가 ** 전달되기 전에 ** 다음 API를 전송할 수도 있습니다. 첫 번째 API가 도착할 때까지 다음 API를 기다려야합니다. 애플은 상태 검사를 허용하는 모호한 API를 가지고 있으며, 도시용 비행선은 똑같은 일을하는 다소 덜 분명한 API를 가지고있다. APNS의 아키텍처는 매우 유능하고 유연하지만 매우 모호합니다. 따라서 ** 할 수없는 일이 많지 않으므로 주위를 찾아야합니다. – Greg

알아두면 좋습니다! 나는 그것을 조사 할 것이다. 그들이 아무 것도 보증하지 않는다는 사실은 여전히 걱정 스럽지만, 이것이 내가 가졌던 최선의 해결책이라고 생각합니다. – Submerged

일부 앱은 푸시 알림 (GroupMe)을 잘하는 것처럼 보입니다. 정말 걱정된다면 Twilio와 같은 서비스를 사용하여 사용자에게 앱을 열어 정보를 제공하는 링크가있는 SMS 메시지를 보낼 수 있습니다. 그래서 SMS는 "SELL SELL SELL SELL YOLPAP : // stock = APL"또는 그와 비슷한 것을 말할 수 있습니다. 이것은 분명히 iPod touch 사용자 나 iPad 사용자에게는 도움이되지 않습니다. (사용자를 위해 문제가 될지 모르겠지만)

출처

2011-12-19 15:24:15 Randall

신뢰할 수있는 서버 대 iPhone 메시징

답변

관련 문제