在新的 iPhone 应用程序和新的 Rails 3 后端之间移动对象图

发布于 2024-09-29 01:56:45 字数 813 浏览 6 评论 0 原文

我知道这个问题多年来已经被回答了一百万次......但是时代和技术变化很快......所以寻找“新鲜”数据;-)

我正在寻求关于稳健且相对直接的建议,将相当复杂的对象从 Rails 3 后端移动到 iPhone 3(4) 应用程序的方法。没有需要遵守的预先存在的 API(xml/json/soap/etc),因此我们可以选择一个简单、灵活、快速且易于维护的领先者。妄想?!?

应用程序将从 Rails 获取实体对象,这有点复杂。每个实体都是一组嵌套的相关对象。我已经成功地使用 json 框架并来回传输简单的对象...但是我们需要一种方法来传递对象树(或根对象)及其所有肢体和分支。然后在 iOS 中反序列化它们......反之亦然(尽管在较小程度上将数据移回服务器)。

ObjectiveResource 看起来很有希望,但似乎一年多没有更新了?!?

我们可以自己推出。但哪种技术值得青睐? Rails 执行 xml 和 xml 操作。原生使用 json,而 iPhone 原生使用 plists。有用于 Rails 和 TouchJSONjson-frameworkObjectiveResourceplistplistifier gem > 适用于 iOS(以及其他)。

我对这些都没有太多经验,所以想以某种方式寻求一些建议……或者更好/更简单的东西?

I know this question has been answered a million times over the years... but times, and technologies, change quickly...so looking for "fresh" data ;-)

I'm seeking advice on a robust, and relatively straight forward, approach toward moving fairly complex objects from a Rails 3 back-end to an iPhone 3(4) app. There is no pre-existing API (xml/json/soap/etc) to adhere to so we can pick a frontrunner that's easy, flexible, fast and easy to maintain. Wishful thinking?!?

App will be getting entity objects from Rails that are somewhat complex. Each entity will be a nested group of related objects. I've had success with using json-framework and transferring simple objects back and forth... But we need a way to pass an object tree (or root object) and all its limbs and branches. and then de-serialize them back in iOS... and vice-versa (though to a lesser degree moving data back to the server).

ObjectiveResource seemed somewhat promising but doesn't appear to have been updated in over a year?!?

We could roll our own. But which technology to favor? Rails does xml & json natively while iPhone does plists natively. There are plist and plistifier gems for Rails and TouchJSON, json-framework, ObjectiveResource for iOS (among others).

I don't have much experience with any of these so looking for some advice one way or another...or something even better/easier?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

很酷又爱笑 2024-10-06 01:56:45

Meltemi

我编写了一个 iPhone 应用程序,代表一家在线零售商的商店。他们的需求包括类别树结构、带有评论和详细信息树的产品对象等。我使用 RAILS 作为 REST 服务器,并使用 JSON 来处理所有内容,因为 (1) JSON 意味着传输的字节数更少,(2) 易于序列化和反序列化NSDictionary 和 NSArrays 以及 (3) 原生 RAILS 效果很好。

使用 http://stig.github.com/json-framework/ 中的 SBJSON 库。尝试过其他但这些是最快且最可靠的。

确实研究过 XML(他们的旧服务器是 MS IIS 服务器)和 SOAP,但它们都是数据量大且速度慢的。

希尔顿

Meltemi

I wrote an iPhone app that represents a store for an online retailer. Their needs included a category tree structure, product objects with review and detail trees, etc. I used RAILS as the REST server and JSON for everything because (1) JSON meant less bytes over the wire, (2) easy to serialize and deserialize into NSDictionary and NSArrays and (3) native RAILS works great.

Used the SBJSON libraries from http://stig.github.com/json-framework/. Tried others but these are the fastest and most reliable.

Did look at XML (their old servers were MS IIS Servers) and SOAP, but they were all data heavy and slow.

Hilton

酒儿 2024-10-06 01:56:45

我同意 REST 和 JSON 将是默认方法。同样令人感兴趣的是一些新兴的二进制协议,例如 Apache Thrift 和 Google 的 协议缓冲区,如果使用IDL 不会引发 PCSD 的严重发作(Post-COM 压力障碍)。我认为只有当您的应用程序的性能和带宽确实非常重要时,这些才是一个选择。

I would agree that REST and JSON would be the default approach. Also of interest are some of the emerging binary protocols like Apache Thrift and Google's Protocol Buffers, if the idea of using IDLs in 2010 doesn't trigger raging fits of PCSD (Post-COM Stress Disorder). I would think these would only be an option if performance and bandwidth were really at a premium for your app.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文