iOS Why I loved building Basecamp for iPhone in RubyMotion

Rei · 2013年02月15日 · 最后由 xds2000 回复于 2013年02月17日 · 2417 次阅读

http://37signals.com/svn/posts/3439-design-decisions-projects-on-basecamp-for-iphone

To cut this down we used a hybrid approach. The page stacking behavior and navigation menus are native, while the rest of the screens are web views.

混合方案,页栈和菜单用本地代码,剩下的是 RubyMotion 包裹的 webview。

共收到 8 条回复

native和RubyMotion生成,不是一样原生的吗?没理解意思。谁来讲讲。

2楼 已删除

我又迷惑了,现在看意思好像是都是用 RubyMotion,只是一部分是本地控件,一部分是 webview。

#3楼 @Rei 有些东西必须用原生的oc来实现,这部分用RubyMotion,这样说你可明白?

#4楼 @shiren1118 这是一种可能,“page stacking behavior and navigation menus” 不像是 RubyMotion 实现不了的东西。

The word native here is opposite to webview. native does not mean use Objective-C

In other words, RubyMotion is native

我猜作者的意思是,相对于一般的 app,Basecamp for iPhone 的核心部分是在 WebViews 里的,只有 page stacking 和 navigation menus 等是用 UIKit 来实现的。换句话说,project 和 discussion 等视图是直接用 html 来实现并通过 WebView 来展现的(这个其实只要用一下 app 就能判断出来)。

如 6 楼所说,这里的 native 是相对于 webview 来说的。但 WebView 也是 native 的,只是 WebView 里加载和显示的内容是 html 而非 naitve 的:)

如果完全用 native 来实现是怎么做的呢?现在放 WebView 的地方,按需求放上各种 UIControl,具体点来说,头象可能会用 UIImageView,显示的人名、讨论内容等会用 UILabel 或是 UITextView,用户输入内容的地方会用 UITextView。写过 iOS 应用的开发者都知道,要用这种方式来展现 Basecamp 那样丰富的内容,代码实现起来是非常耗时间精力的,而且有个致命的问题:要修改布局或修复 bug 非常麻烦,做完之后还要等待漫长又无法预估的审核期。

而 WebView 里加载的 html,对于 Basecamp 这样的 app 来说显示是在 server 端生成的。app 上架后,这些核心功能可以象 web app 一样随时改进并发布。37Signals 在 AppSotre 上要做的,就是把整体性能、bug 等控制好,并完善 page stacking 和 navigation menus 等功能(个人认为这个 app 做的非常棒,它的 page stacking 的方式其实并没有脱离 Path、Facebook 等带动并流行起来的侧边栏的使用方式,但 stacking 外观以最后划出时斜掉下去的效果都相当舒服漂亮)。

我个人认为,这个 app 的好坏跟是否使用了 RubyMotion 是没有直接关系的。一是,既然大部分功能是在 WebView 里完成的,那么在 App 端实现的代码量应该不是太大。二是,作者如果之前不是用 Ruby 的话,在这里选择 RubyMotion 在生产力上不见得会有多少提升(作者也提到在调用 Cocoa API 的时候,他们一般遵循 Objective-C 的习惯而非 Ruby 的)。

@ashchan 还是你讲的比较清楚。这样,完全可以作为一个成功范式了。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册