正常に動作するプッシュベースの呼び出しを実装しましたが、バックグラウンド呼び出しが完全に壊れているようです。
バックグラウンドでアプリを持っているが閉じていないときに別のユーザーを呼び出すと、期待どおりにローカル通知を受け取ります。
この通知からアプリを起動すると、ローカル通知をリレーした直後に、発信者アプリはすぐに代わりに shouldSendPushNotifications を介してプッシュ呼び出しを開始しようとします。
これは受信者に渡されます。これで、処理する呼び出しが 2 つになり、UI が少し壊れてしまいます。アプリの破損を防ぐためにハッキングしました。クライアントが既に初期化されているかどうかを確認しました（ローカル通知を処理するときであり、プッシュを処理するときではありません）。これは、この問題を回避するようです。
なぜこれが起こっているのか誰にも分かりますか？これは、Sinch クライアントでプッシュとローカルの両方が有効になっている場合にのみ発生します。
shouldSendPushNotifications:同じデータ提供 (同じプッシュ データとプッシュ ペイロード) で複数回呼び出される問題は、そのような各ペアが特定のユーザー ID の 1 つのアプリのインストールを表している可能性があることに起因します。したがって、同じデバイスでアプリを何度もアンインストール/インストールし、異なるオプションを設定した場合SINClient(たとえばsetSupportPushNotifications、NO と YES)、それが問題の一部である可能性があります。Sinch ではその解決策に取り組んでいますが、それにより、同一の情報を持つコールバックがなくなります。
shouldSendPushNotifications:他のクライアントが呼び出しへの応答を開始したにもかかわらず、呼び出されていることがわかる場合があるという事実は、プッシュ メカニズムが、特定の時間枠内に他のクライアントによる応答/確認の欠如に基づいてトリガーされることを意図しているためです。他のクライアントがバックグラウンドにあり、VoIP モードが有効になっている場合は、できるだけ早く ACK を送信するため、プッシュ メカニズムがトリガーされません。しかし、その ACK がタイム ウィンドウで受信されない場合、プッシュ メカニズムがトリガーされます。したがって、プッシュ メカニズムは、VoIP モードと組み合わせて使用すると、ベスト エフォート型のフォールバック メカニズムと見なすことができます。あなたの場合、前のセクションで説明したアプリごとのインストール機能に関連していると思われますが、これを改善するために取り組んでいます.
それでも、プッシュ メカニズムは、ネットワーク状態が異常に遅い場合や、別のクライアントからの ACK が「予想される最悪のケース」(現在は 4 秒) よりも長くかかる場合にもトリガーされる可能性があるため、アプリで処理する必要があります。 didReceiveIncomingCall-callback を受信した直後でも、リモート プッシュ通知を受信する場合。ここで重要なのは、実際には 2 つの異なる呼び出しではなく、SINNotificationResultとを使用-[SINCallNotificationResult callId]して同じ呼び出しであることを識別できることです。たとえば、最初にdidReceiveIncomingCall:-callback を受け取り、最終的に を使用する-[SINClient relayLocalNotification:]と、プッシュ通知を受け取って ] に渡した直後に、-[SINClient relayRemotePushNotificationPayload:両方の「通知結果」に同じものが含まれていることがわかり、それcallIdを使用して UI を適切に管理できます。
Sinch SDK に関する貴重なフィードバックをお寄せいただきありがとうございます。Sinch では、プッシュ通知とローカル通知全般の処理を簡素化する方法を検討しています。