1

イメージのローカル ディレクトリを提供する MacOSX アプリ (サーバー) でCocoaHTTPServerを使用しています。AFHTTPRequestOperation (AFNetworking) を使用してローカル ネットワーク経由で Mac から画像ファイルを取得する、対応する iOS アプリ (クライアント) があります。これはうまく機能しています。

次にやりたいことは、ユーザーが Mac アプリで特定の画像を選択すると、その画像をダウンロードして表示するように iPad アプリに通知することです。

私が現在採用している方法は、表示する画像のファイル名を含む単純な imageToDisplay.txt ファイルを提供することです。iPad アプリは常にこのファイルをポーリングしており、ファイル名が変更された場合はダウンロードなどを行います。動作しますが、扱いにくいようです。ファイル名も返すGETメソッドをサーバーに実装することを考えました。このアプローチでも、クライアントによるポーリングが必要です。

既に配置されている部分を使用して (ポーリングなしで) ダウンロードをトリガーするよりエレガントな方法はありますか? 基本的に、サーバーからクライアントにメッセージを送信する- 「image27.jpg を今すぐダウンロード」

4

1 に答える 1

1

WebSocket (SocketRocket)

これを実装する方法はいくつかあります。コメントで述べたように、WebSockets はその 1 つです。無料で入手できる iOS 用の最も堅牢な WebSocket ライブラリは、SocketRocket (韻を踏む) です。リンク先のページには十分なサンプル (韻も踏む) コードがあるので、ここには含めません。

AFネットワーキング

すでに AFNetworking を使用しているので、新しい AFNetworking 2.0 (近日リリース予定) を検討することもできます。これには、Rocketを介したリアルタイム ネットワーキングのサポートが含まれています。

これにより、アプリは開いた接続を維持できるようになり、次のようになります。

[client SUBSCRIBE:@"/currentImage" usingBlock:^(NSArray *operations, NSError *error) {
    for (AFJSONPatchOperation *operation in operations) {
        switch (operation.type) {
            case AFJSONReplaceOperationType:
                // replace old image with new image
                break;
            default:
                break;
        }
    }
} error:nil];

クライアントがキャンセルしない限り、更新が発生するたびにサーバーから更新を受信し続けます。

サーバーは適切な形式でデータを送信する必要があり、これを行うRack::Scaffold の実験的なブランチがあります。

ノート

週に 1 回だけイメージを変更する場合、これらのアプローチはやり過ぎかもしれません。その場合、妥当な期間、画像をキャッシュする必要があります。

于 2013-08-30T00:04:57.287 に答える