どのように信頼性の高いプッシュメッセージサービスを達成するには？

Question

私はモバイルアプリで信頼性の高いコミュニケーションを構築したいので、サードパーティのプッシュサービス（C2DM、APN、都市飛行船）のプッシュレポート（おそらくデバイスはオフラインです）をプッシュできますか？ または自分でそれを構築する必要がありますか？

Answer 1

Android C2DMの目的は、サーバアプリケーションがモバイルデバイスに信頼性の高い通信を開始するように通知するバッテリを節約する方法です。

新しいC2DMには、サーバーとの最後の双方向のやりとり（つまり、「取得したものを取得して取得する」）以降に発生したすべてのメッセージが含まれるようにメッセージを構成できます。失敗した配信レポートは、モバイルデバイスが即座に応答しないことを暗示しています（これは、C2DMがインテントを使用してアプリをアクティブにしていることを示しているためです）。

これは、損失の大きいメディアでの各メッセージの保証配信よりも実際には悪いことですか？さて、プライマリ通信方式を実装する必要があるという点で、さらに悪いことです。しかし、C2DMは着信専用なので、とにかくやらなければなりませんでした。

Answer 2

私はプッシュ通知IBM MQTTプロトコルを提案しています。これはプッシュ通知に十分です。 デモを見るhttps://github.com/tokudu/AndroidPushNotificationsDemo

Answer 3

Vinayが言っているように、MQTTはあなたに望む機能を提供するかもしれません。クライアントがサーバーに接続すると、サーバーに「last will and testament」メッセージを登録できます。クライアントが予期せず切断された場合、サーバーは指示されたトピックにこのメッセージを送信します。

このスキームでは、クライアントは、クライアント//ステータスのようなメッセージに「オンライン」メッセージを送信し、同じトピックのLWTとしてメッセージ「オフライン」を登録できます。次に、トピックのクライアント/ +/statusを聞いたサーバーローカルクライアントを持つことができ、どのクライアントがオンラインでオフラインであるかを知ることができます。

私はtokuduのデモは、見て最適な場所ではないことをお勧めします。デール・レーンによるこのブログ記事は、Android上でMQTTを使用しての洞察を与える：http://dalelane.co.uk/blog/?p=1599とIOSとAndroidの両方を合わせてクライアントの実装がありますhttp://stephendnicholas.com/archives/219

で（再Android上）MQTTの電力使用量の見直しがあり、参照http://mqtt.org/software

Answer 4

サービスは、失敗したプッシュについてのレポートを提供しません。

失敗プッシュレポートでは、すべてのサービスがすべての状況下でプッシュメッセージを配信することを目的としているAPN/C2DM /ヘリウムを少しSENCE

になります。 現在デバイスがオフラインの場合、デバイスがオンラインになるとプッシュが配信されます。

また、iOSのプッシュメッセージは、アプリケーションの通知ではなく、ユーザーの通知です。

簡単な例で説明します。 アプリケーションの電源を切ってもプッシュが受信されたとします。その場合、ユーザーへの通知が行われます。しかし、アプリケーションがプッシュからデータを受信するのは、ユーザーがその通知をタップした場合だけです。ユーザーがアプリケーションのアイコンをタップすると、データは受信されません。

技術的には、プッシュはiOSデバイスに配信され、アプリケーションは開始されますが、データは配信されません。あなたはプッシュのために、独自のトランスポートを実装するために検討することができAPNとヘリウム

と

UrbanAirhip。 MQTTは良い選択肢のようです。 しかし、この場合、キープアライブ、デバイススリープ、バッテリーの最適化に対処する必要があります。 Apple、Google、UrbanAirshipのエンジニアがすでに頑張っています。

ビジネスニーズに応じて、既存のソリューションにアーキテクチャを適用しやすくし、プッシュサービスを再度実装し直すことができます。

UrbanAirshipを詳しく見てください。実際、C2DMにはいくつかの制限があり、プッシュメッセージの配信タイミングが大きすぎることがあります。そのため、UAは独自の輸送手段、すなわちヘリウムを実装しています。ヘリウムは有料サービスですが、UAは優れたSLAを提供します。

Answer 5

データベースを既知のサブスクライバにプッシュキューを追跡していて、失敗したときにレポートを作成したのと似たようなことをしました。それは非常に単純であり、このような何かを行ってきました...

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への結合を行い、その後それらをmessagesQueuesテーブルから削除し、failedPushMessagesテーブルにコピーします。

これは理解して維持するのが非常に簡単でしたが、別の方法で経験した経験はありません。

Answer 6

プッシュサービスは、ユーザーに警告するための効率的で信頼性の高い方法です。バックグラウンドアプリケーションでさえ、リアルタイムで新しい情報をユーザーに知らせることができます。プッシュサービスは、気象の更新、メッセージングサービス、メール通知、クーポンサービスなど、モバイルアプリケーションのさまざまな分野で広く使用されています。プッシュサービスはもはやオプションですが、必須となっています。