6

私は RestKit フレームワークを使用しており、POST HTTP リクエストを作成したいと考えています。応答は JSON です。JSON レスポンスを自動的に CoreData に入れたい。

リクエストを行うためにどのメソッドを呼び出すべきか正確にはわかりません。のメソッドを使用する必要があることはわかってRKObjectManagerいますが、適切なメソッドが見つかりませんでした。

このメソッドを見つけましpostObject:delegate:たが、オブジェクトをパラメーターとして渡す方法がわかりません。ドキュメントにもこの方法がありますloadObjectsAtResourcePath:usingBlock:が、次のように表示されるため使用できません。

No visible @interface for 'RKObjectManager' declares the selector 'loadObjectsAtResourcePath:usingBlock:'
4

1 に答える 1

53

Vlad - まず最初に、元の質問に対する適切な回答を得ましょう:

あなたは RestKit 0.20.0 で作業していると思いますが、RestKit 0.10.x API には精通しており、古い情報を調べています。最初に確認する必要があるのはRKObjectManager.h、ヘッダーは常に最新の状態であり、使用可能なメソッドに関するドキュメントが含まれていることです。次に、最新の API ドキュメント サイトで、ソース コードから構築された最新のドキュメントをいつでも表示できます。

ここでやりたいことは、次を作成することですRKObjectRequestOperation。

NSDictionary *dictionary = @{ @"firstParam": @(12345), @"secondParam": @"whatever"};
NSMutableURLRequest *request = [objectManager requestWithObject:nil method:RKRequestMethodPOST path:@"/whatever" parameters:parameters];
RKObjectRequestOperation *operation = [objectManager objectRequestOperationWithRequest:request success:^(RKObjectRequestOperation *operation, RKMappingResult *result) {
    NSLog(@"Loading mapping result: %@", result);
} failure:nil];

Core Data をターゲットにしようとしている場合は、 と を使用する必要がRKManagedObjectRequestOperationありmanagedObjectRequestOperationWithRequest:success:failure:ます。RestKit Github サイトの README.md とヘッダー ドキュメントには追加の例があり、参照用の単体テストにも大量のコードがあります。

次に、JRG-Developer からのコメントに応えて:

ええと、これはいくつかの理由から本当にひどい答えです。(免責事項: 私は RestKit の主な開発者です)

まず、使用しているRestKitのバージョンは何ですか? 最近のバージョン (つまり、0.20.x プレリリース シリーズ) を使用している場合、オブジェクトのコレクションをロードするメソッドは、より適切な名前に置き換えられています: getObjectsAtPath:. これは、API ドキュメント ( Making Requests by Path ) と0.10 から 0.20 への移行ガイドの両方で完全に文書化されています。

ここでの元の問題は、古いドキュメントと最近のコードを参照したことが原因であると思われます。

次に、あなたが推奨しているテクノロジーのスタックは、ライブラリを実際に理解すると、RestKit が提供するのと同じことを達成するためにセットアップして使用するのがはるかに複雑です。

これをポイントごとに見てみましょう。

  1. AFネットワーキング

    • AFN は、非同期ネットワーク操作を実行するための優れた軽量ライブラリです。RestKit を、クライアント側の API を実装するための多数のツールを含むツールボックスと考えるなら、AFN はハンマーです。
    • 私は AFN に多大な敬意を払っており、RestKit 0.20.x では、iOS 3.0 からぶらぶらしていた RestKit カスタム ネットワーク スタックよりも設計が優れていたため、AFNetworking を優先して古い自家製ネットワーク ライブラリを破棄しました。ただし、AFN だけでは、Core Data に関する深い知識がなく、大量の同期コードを自分で実装しなければ、Core Data と統合する API を完全に実装するのに十分な火力を提供できません。
    • RestKit のオブジェクト マッピング システムは、これらの同期アクティビティを自分で実装するのではなく、設定するための高性能で一貫した API を提供します。これにより、パフォーマンスの大幅な最適化が可能になりますが、これについては後で説明します。

  2. JSONKit

    • JSONKit は、私が高く評価しているもう 1 つのライブラリですが、おそらく時間をかける価値はありません。と比較するとNSJSONSerialization、JSONKit の JSON 解析速度は優れていますが、ミリ秒単位でしかありません。
    • 広く展開されているアプリに大規模な API クライアントを実装した経験のある人として、あなたの時間は JSON のシリアル化/逆シリアル化ではなく、逆シリアル化された JSON を処理するコードに費やされることになると言えます。

  3. マジカルレコード

    • MagicalRecord は、Core Data の既存の機能の簡略アクセサーを提供する Core Data 便利なライブラリです。HTTP から Core Data への同期スキームを実装するために実際に必要なことを理解したところで、生活が改善されることはありません。Core Data フェッチ リクエストの構文が冗長すぎる、管理対象オブジェクト コンテキストへの参照を維持するのが不便である、または Core Data スタック セットアップを取得することが問題とは関係ありません。

それでは、API を Core Data にモデル化する iOS / OS X アプリケーションを実装する際の実際の問題について少しお話しましょう。

  1. 非同期アクセス
    • 最初に遭遇する問題は、同期のメイン スレッド指向の方法でプログラミングすることに慣れているが、JSON をロードする AFNetworking リクエストを起動する必要があるが、それをオブジェクト モデルにロードする必要があることです。AFJSONRequestOperation問題ありません。成功ブロックで が戻ってきて Core Data を更新するのを待ってください。違う。ここで、ネットワーク I/O を非同期で実行していますが、メイン スレッドでデータ モデルを更新するというCPU 集中型のタスクを実行しています。アプリのパフォーマンスが低下し、どうすればよいかわかりません。その同期をバックグラウンドに移動するにはどうすればよいですか? 完了したら、UI にどのように通知しますか?
  2. エラー処理
    • エラーが発生するとどうなりますか? ネットワークエラーが発生したときはどうしますか? ネットワーク操作は完了したが、Core Data アクセス中にエラーが発生した場合はどうしますか? どのように対処しますか？このエラー処理コードをすべてのコントローラーに入れるつもりですか? そのすべてのロジックをどのようにカプセル化しますか?
    • サーバーから返されたエラーをどのように処理しますか?
  3. 一意のオブジェクト識別
    • さて、JSON を読み込んだので、それを Core Data に入れたいと思います。偉大な。ストア内の既存のオブジェクトと作成する必要がある新しいオブジェクトをどのように区別しますか?
    • これを間違えると、オブジェクトが重複してしまいます。
    • これを正しく行っても、メイン スレッド コンテキストから実行すると、UI がブロックされ、パフォーマンスが低下します。
    • これを正しく行っても、バックグラウンド スレッドで実行すると、同時実行性の問題が発生する可能性があります。
    • これを正しく行っても、一意のオブジェクトを識別するために永続ストアにフェッチ リクエストを送信すると、パフォーマンスの問題が発生します。
  4. 孤立したオブジェクトの削除
    • データ セットをサーバーと同期したら、ローカル ストアからサーバー上に存在しなくなったデッド オブジェクトをどのように削除するのでしょうか?
  5. パフォーマンス
    • この暴言の前のいくつかの部分でほのめかしたように、すべての道は最終的にパフォーマンスにつながります。大規模に機能し、ユーザーを喜ばせるものを実際に構築しようとしている場合は、重大なパフォーマンスの問題に対処する必要があります。目がくらむ。

アプリケーションが成功すると、テスト容易性、保守容易性など、対処しなければならない追加の問題がいくつかあります。これらのことについてどの程度考えていますか?

ここでの私の主なポイントは、(私の観点からは) 基本的なエンジニアリングの問題に取り組む方法について、ピーナッツ ギャラリーから発せられる非常識な歓声や嘲笑を聞くのはあまりにも一般的だということだと思います。現実には、本質的に複雑な問題の解決には、アプローチする問題の学習曲線に関連する学習曲線があります。

より大きな、しかしより興味深い問題にアプローチしようとするよりも、機能の個別のスライスを取り、満足のいく解決策を突き止める方がはるかに簡単です。

しかし、それは、集合問題へのより大きなアプローチよりも、問題のサブセットの優れた実装を提供すると聞いた多数のライブラリをまとめることによって、より堅牢なソリューションを作成しようとしているという意味ではありません。

独自の AFN/JSONKit/Core Data/MagicalRecord マッシュアップをオープンソース化し、RestKit よりもはるかに優れているのに、RestKit を水から吹き飛ばさないのはなぜですか?

残念ながら、それは簡単なことではありません。

乾杯！

于 2012-12-20T05:08:05.957 に答える