5

Web サービスと通信する iOS アプリがあるとします。一部のリクエストは別の Web サービスに委任されるため、反対側で操作が進行している間、HTTP 200 ステータス コードがすぐに返されます。

|iOS app|          |Main service|    |Delegate service|   
    |     request        |                    |
    |------------------->|_      delegate     |_
    |                    | |----------------->| |
    |     HTTP 200       | |     accepted     | |
    |<-------------------|_|<-----------------| |
    |                    |                    | |
    |                    |                    | | 
    |     status?        |                    | |
    |------------------->|_                   | |
    |                    | |                  | |
    |     pending        | |                  | |
    |<-------------------|_|                  | |
    |                    |                    | |
    |                    |      finished      | |
    |                    |<-------------------|_|
    |                    |                    |
    |     status?        |                    |
    |------------------->|_                   |
    |                    | |                  |
    |     finished       | |                  |
    |<-------------------|_|                  |
    |                    |                    |
    |                    |                    |

これらのリクエストは 20 秒から最大 2 分間持続するため、15 ～ 20 秒ごとにサーバーをポーリングする余裕があります。

そのようなシナリオを実装するためのベスト プラクティスはどれですか? 20 秒ごとに 1 つのリクエストを 6 つのリクエストに制限するというポーリング戦略を実装することを決定した場合、Apple はアプリを拒否できますか?

残念ながら、長いポーリング戦略に対するサーバーのサポートはありません (私たちの管理下にはありません)。サーバーは、リクエストごとにステータス JSON を返すだけです。

これらのリクエストは一種の低レベルのタスクであり、ユーザーが明示的に関与する必要がないため、プッシュ通知の使用を避けようとしています。

4

1 に答える 1

2

以前のスレッドで説明したロング ポーリング戦略を試すことをお勧めします:目標 C でのロング ポーリング。また 、iOS/Android アプリ通信用の TCP ベースの RPC サーバー (Erlang など) も参照してください。

于 2013-04-10T09:21:48.490 に答える