尝试使用RestKit发出POST请求并将响应映射到Core Data

Question

我正在使用RestKit框架,我想发出一个POST HTTP请求.响应是JSON.我想将JSON响应自动放入CoreData中.

我不知道确切地调用什么方法来发出请求.我知道我应该使用RKObjectManager的方法,但我找不到合适的方法.

我找到了这个方法,postObject:delegate:但我不知道作为参数传递的对象.我也在文档中找到了这个方法:loadObjectsAtResourcePath:usingBlock:但是我不能使用它,因为它告诉我:

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

Answer 1

弗拉德 - 首先,让我们回答你原来的问题:

我假设您正在使用RestKit 0.20.0,但熟悉RestKit 0.10.x API并且正在咨询过时的信息.您应该转向的第一个地方是RKObjectManager.h- 标题始终是最新的,并且将包含有关可用方法的文档.接下来,您始终可以在最新的API docs站点上查看从源代码构建的最新文档.

你想要做的是创建一个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文档(按路径发出请求)和0.10到0.20迁移指南中都有详细记录.

我怀疑这里的原始问题源于引用过时的文档以及最近的代码.

接下来,你推荐的技术堆栈是远远更为复杂的设置和使用来实现这一目标RestKit为您提供的,一旦你真正了解图书馆同样的事情.

让我们逐点看看:

1. AFNetworking

   • AFN是一个出色的轻量级库,用于执行异步网络操作.如果您认为RestKit是一个包含许多实现客户端API的工具的工具箱,那么AFN就是锤子.
   • 我非常尊重AFN,在RestKit 0.20.x中,我们抛弃了老化的自制网络库,转而支持AFNetworking,因为它的设计优于自iOS 3.0以来一直存在的RestKit自定义网络堆栈.但是,仅AFN并不能为您提供足够的火力来完全实现与Core Data集成的API,而无需深入了解Core Data并自行实现大量同步代码.
   • RestKit的对象映射系统为您提供了一个高性能,一致的API,用于配置这些同步活动,而不是自己实现它们.这样可以实现一些严格的性能优化,我将在稍后返回.

2. JSONKit

   • JSONKit是我高度重视的另一个库,但它可能不值得你花时间.NSJSONSerialization与之相比,JSONKit的JSON解析速度更高 - 但只有毫秒.
   • 作为为广泛部署的应用程序实现了大型API客户端的人,我可以告诉您,您的时间不会用于JSON序列化/反序列化,而是用于在反序列化后处理JSON的代码.

3. MagicalRecord

   • MagicalRecord是一个核心数据便利库,为Core Data中的现有功能提供速记访问器.一旦你深入了解实现HTTP到核心数据同步方案真正需要的东西,它就不会改善你的生活.您的问题将有什么核心数据的语法做撷取要求过于冗长,但暂时不方便保持你的管理对象上下文,或者与获得核心数据堆栈设置的参考.

那么让我们来谈谈实现iOS/OS X应用程序的真正问题是什么,该应用程序暂时将API建模到Core Data中:

1. 异步访问
   • 您将遇到的第一个问题是您习惯于以面向主线程的同步方式进行编程,但现在您需要触发加载JSON的AFNetworking请求,然后将其加载到对象模型中.没问题,只需等待AFJSONRequestOperation在成功块中回击并更新Core Data,对吧？错误.现在,您正在异步进行网络I/O,但随后执行CPU强化任务,即在主线程上更新数据模型.现在你的应用程序性能糟透了,你不知道该怎么做.如何将同步移到后台？一旦完成,你如何通知用户界面？
2. 错误处理
   • 遇到错误会发生什么？当您收到网络错误时,您会怎么做？网络操作完成后您会怎么做,但在Core Data访问期间遇到错误？你打算如何处理它？您是否要将此错误处理代码放入所有控制器中？你打算如何封装所有逻辑？
   • 您将如何处理服务器返回的错误？
3. 唯一对象识别
   • 好的,现在你已经加载了你的JSON,你想把它放入Core Data.大.您如何区分商店中的现有对象与需要创建的新对象？
   • 如果你弄错了,你现在有了重复的对象.
   • 如果你做对了,但是从主线程上下文中做到这一点,你的用户界面就会被阻止,你的表现很糟糕.
   • 如果你做对了,但是在后台线程上做,你可能会遇到并发问题.
   • 如果你做对了,但是使用获取请求命中持久存储以识别你的唯一对象,你现在就遇到了性能问题.
4. 删除孤立对象
   • 一旦将数据集与服务器同步,您将如何处理从服务器上不再存在的本地存储中删除死对象？
5. 性能
   • 正如我在这个咆哮的早期部分中提到的那样,所有道路最终都将导致表现.如果您实际上正在尝试构建可以大规模工作并使用户满意的内容,那么您将不得不应对严重的性能问题.头晕目眩.

一旦您的申请成功,您将不得不面对许多其他问题,包括可测试性,可维护性等.您对这些事情的看法是多少？

我想我的主要观点是(从我的角度来看)听到疯狂的欢呼或嘲笑来自花生画廊关于如何解决基本的工程问题.现实情况是,基本复杂性问题的解决方案将具有与所接近的问题相关的学习曲线.

与试图解决更大但更有趣的问题相比,采用不连续的功能并确定一个令人满意的解决方案要容易得多.

但这并不意味着你要通过捆绑一堆你已经听说过提供一个问题子集的良好实现而不是一个更大的聚合问题方法的库来产生一个更强大的解决方案.

为什么没有人开源他们自己的AFN/JSONKit /核心数据/ MagicalRecord mashup并且如果他们比RestKit好得多的话就把RestKit吹出水面？

我担心这个清醒的事实是:它并不那么容易.

干杯!