ポーリング対プッシュ - プッシュ通知を避ける理由はありますか？

Question

Android App Projectを継承しました（技術的な）Product Managerとして、 5秒のタイマーを使用して、アプリによって開始された作業が終了したかどうかを確認するためにリモートURL をポーリングします。もちろんの最初の反応は、これをプッシュ/通知メカニズム、好ましくはAndroidに組み込まれているGCMでこれを置換することを提案することでしたので、作業は電話機のアプリから削除されてサーバー側に置かれます。< / P>

驚くべきことに、私は開発チームからの抵抗性を満たしています。元製品マネージャ（私の前任者）は、このように機能するために実装を明示的に要求したようです。残念ながら、彼は彼の決断を文書化することに大きくはなかったので、私は現在、実装の変化を正当化するためにこの意思決定につながる可能性があるのを遡ったのです。私は次のProとContraのリストを思いついた：

CONTA PUSH / PROポーリング

1. -
2. -
3. プッシュ通知を実装するために必要なサーバーサイドの作業
4. -
5. プッシュ通知が正常に配信されたかどうかを知るための直接的な方法
6. スケーリングプッシュ通知配信は痛みになる可能性があります

Proプッシュ/コントラポール

1. 作業はデバイスから削除されます
   • 下限帯域
   • バッテリーの使用量
   • より応答的なアプリケーションとデバイス
2. 機器が変更されていなくてもX秒ごとにポーリングされないため、サーバーのロードが低下します（DDOS）
3. -
4. プッシュは5秒以上（現在のタイマー）
より速い（より反応深い）
5. プッシュ通知の納入証明は、リモートURLの投票（ここでは意味がある）
の調査で実装するのが簡単です。
6. スケーリングプッシュ通知配信は、メッセージキュー
の多数のオープンソースプロジェクトと些細な実装に関する解決された問題です。

---

• プッシュ通知を避け、このUSECASEのポーリングを使用する他の理由はありますか？
• このUSECASEのポーリングを避け、プッシュ通知を使用しないような他の理由はありますか？
• 私が忘れた他の重要なこと？

Answer 1

プッシュ通知が正常に配信されたかどうかを知る方法

必ず存在する：プッシュメッセージを受信したときにデバイスがサーバーに命中します。ペイロードが4Kより大きい場合は、とにかくそれをする必要があるかもしれません。

スケーリングプッシュ通知配信は痛みになる可能性があります

は、かなり大きなユーザー基盤（例えば、e. rememberthemilk）で機能し、XMPPベースの永続ソケットソリューションの前でさえありました。

プッシュ通知を避け、このUSECASEのポーリングを使用しないような他の理由はありますか？

GCMにはサービスレベルの保証がありません。 GCMはAndroid固有です。他のクライアントオペレーティングシステムを扱うものを探している場合は、Amazon SNSのように、それの周りのラッパーを検討するかもしれません。 Googleのような第三者を含むプッシュソリューションは、Raw Pushメッセージペイロードがそれらの第三者のサーバーに表示されることを意味します。これが懸念の場合は適切なアプリレベルの暗号化を使用してください（そしてそれはそうはあるはずです）。

このUSECASEのプッシュ通知を使用しないような他の理由はありますか？

5秒の投票は$BABY_DEITY Cryを作ります。