モバイルアプリで信頼性の高い通信を構築したいので、サードパーティのプッシュサービス(C2DM、APN、都市飛行船)からプッシュ失敗レポート(デバイスがオフラインになっている可能性があります)を受け取ることはできますか?それとも私たちは自分たちでそれを構築する必要がありますか?
6 に答える
Android C2DMの目的は、サーバーアプリが、信頼性の高い通信を開始することをモバイルデバイスに通知するためのバッテリー節約方法です。
新しいC2DMごとに、サーバーとの最後の双方向の対話以降に発生したすべてのものが含まれるようにメッセージを構成できます(つまり、「私が持っているものは何でも入手してください」)。配信の失敗レポートは、モバイルデバイスがすぐに応答しないことで暗黙的に示されます(C2DMがインテントでアプリをアクティブ化することがわかっているため、これを行うことができます)。
それは、損失のある媒体での各メッセージの保証された配信よりも本当に悪いですか?さて、あなたはまた、主要な通信方法を実装しなければならないという点でさらに悪いです。しかし、C2DMはインバウンド専用であるため、とにかくそれを行う必要がありましたね。
Vinayが言うように、MQTTはあなたが望む機能を提供するかもしれません。クライアントがサーバーに接続すると、「遺言と遺言」メッセージをサーバーに登録できます。クライアントが予期せず切断した場合、サーバーはこのメッセージを指示されたトピックに送信します。
このスキームでは、クライアントはクライアント//ステータスなどに「オンライン」メッセージを送信し、同じトピックのLWTとして「オフライン」メッセージを登録できます。次に、トピックclient / + / statusをリッスンするサーバーローカルクライアントを作成すると、どのクライアントがオンラインで、どのクライアントがオフラインであるかがわかります。
トクドゥのデモは見るのに最適な場所ではないことをお勧めします。Dale Laneによるこのブログ投稿は、AndroidでのMQTTの使用に関する洞察を提供します: http ://dalelane.co.uk/blog/?p = 1599そしてhttp:// stephendnicholasでMQTT電力使用量のレビューがあります(これもAndroidで).com / archives / 219
IOSとAndroidの両方に適合するクライアント実装があります。http://mqtt.org/softwareを参照してください。
失敗したプッシュに関するレポートを提供しないサービスはありません。
失敗したプッシュ レポートは、APN/C2DM/Helium ではほとんど意味がありません
すべてのサービスは、あらゆる状況でプッシュ メッセージを配信することを目的としています。デバイスが現在オフラインの場合、デバイスがオンラインになったときにプッシュが配信されます。
さらに、iOS の場合、プッシュ メッセージはユーザーへの通知であり、アプリケーションへの通知ではありません。
簡単なケースで説明します: アプリケーションがオフになっているときにプッシュが受信されたとします。その場合、ユーザーへの通知が発生します。ただし、ユーザーがその通知をタップした場合にのみ、アプリケーションはプッシュからデータを受信します! ユーザーがアプリケーションのアイコンをタップした場合、データは受信されません。
技術的には、プッシュが iOS デバイスに配信され、アプリケーションが起動されますが、データは配信されません。
APN とヘリウムを備えた UrbanAirhip
プッシュ用に独自のトランスポートを実装することを検討できます。MQTT は良いオプションのようです。ただし、この場合、キープアライブ、デバイスのスリープ、およびバッテリーの最適化に対処する必要があります。こうした大変な作業はすべて、Apple、Google、UrbanAirship のエンジニアによってすでに行われています。
ビジネス ニーズによっては、アーキテクチャを既存のソリューションに適合させてから、プッシュ サービスを再実装する方が簡単な場合があります。
UrbanAirship を詳しく見てみましょう。実際、C2DM にはいくつかの制限があり、プッシュ メッセージの配信のタイミングが大きすぎる場合があります。そのため、UA は独自のトランスポートである Helium を実装しており、かなりうまく機能します。Helium は有料サービスですが、UA は優れた SLA を提供します。
プッシュ通知 IBM MQTT プロトコルを提案しています。プッシュ通知としてはこれで十分です。https://github.com/tokudu/AndroidPushNotificationsDemoからデモを参照してください
データベースに既知のサブスクライバーへのプッシュキューを追跡させ、失敗したときにレポートを作成するという同様のことを行いました。それは非常に簡単で、このようなものでした...
The schema was like so:
pushMessages
messageID , GUID, PK
message , nvarchar (256),
expires , datetime
messageQueues
subscriberID , GUID, PK
messageID , GUID PK
failedPushMessages
subscriberID, GUID, PK
messageID , GUID PK
(subscriber table omitted)
クライアントがメッセージを正常に受信すると、クライアントはプッシュ サーバーに ping を返し、プッシュ通知で受信した一意の queueItems ID を介して通知します。期限切れのプッシュ メッセージをチェックする毎日のデータベース プロセスもあります。見つかった場合、messageID に一致する queueMessages で結合を行い、messageQueues テーブルからそれらを削除して、failedPushMessages テーブルにコピーします。
これは理解と維持が非常に簡単でしたが、別の方法で行った経験はありません。
プッシュ サービスは、ユーザーに警告するための効率的で信頼性の高い方法です。これにより、バックグラウンド アプリケーションであっても、ユーザーに新しい情報をリアルタイムで通知できます。プッシュ サービスは、天気予報、メッセージング サービス、メール通知、クーポン サービスなど、モバイル アプリケーションのさまざまな分野で広く使用されています。プッシュ サービスはもはやオプションではありませんが、必須になっています。