4

我将尽我所能将其表述为一个可以回答的问题，而不是作为讨论的开始。

我的问题的本质是，根据您的经验，将您的网站的移动 Web 版本开发为使用您的网站作为 API 的单独应用程序，还是从为您的网站提供服务的同一个 Rails 应用程序中开发更好？

我目前正在计划我们将如何实施它，这里是每个我认为的优点/缺点。

移动网络的单独应用程序

  • 好处
    • 性能：现有网站的开销更少 = 更好的性能
    • 占用空间更小：更易于组织和更清洁的应用程序来工作/开发
    • 解耦：将迫使我们为桌面/移动构建服务
  • 缺点
    • 子域：必须使用 m.thredup.com，以便将移动流量路由到单独的应用程序
    • 会话管理：必须处理多个应用程序/域的身份验证
    • 本地开发更难：为本地开发维护的另一项服务
    • 分支管理：新代码需要 Web 应用程序 + 移动应用程序的单独分支

移动网络的相同应用程序

  • 好处
    • URL 计划：能够在桌面 + 移动设备上使用相同的 URL（更易于共享）
    • 会话管理：能够使用现有的用户会话
    • 更快的实施：更短的项目时间表，因为所有后端逻辑都已经到位
  • 缺点
    • 代码膨胀：为我们已经很大的 Rails Web 应用程序提供更多代码

如果我们要在现有应用程序中开发移动网络，这里是我们呈现移动视图的方法 - http://scottwb.com/blog/2012/02/23/a-better-way-to-add-mobile -pages-to-a-rails-site/

任何见解将不胜感激。

4

2 回答 2

2

如果您设计网站以便您可以为任何设备使用相同的代码库，以便它智能地适应您的设备，并为您呈现最重要/有用的内容/功能，那么您将在 10 次中有 9 次变得更好每个设备都基于样式表或渲染/非渲染的运行时选择。请记住，与 6 年前不同，您今天对移动设备的主要关注不是缺乏处理能力，而是不同的屏幕尺寸和不同的输入。

通常，移动用户不希望看到您网站的残缺或剥离版本。他们希望看到您网站的可用版本。可用的含义各不相同，但它通常意味着最常用的功能非常容易访问，而更晦涩的选项被埋得更低一些，或者可能没有那么优化。可用可能意味着您为它们提供与桌面完全相同的功能，但其样式可以更好地在移动设备上呈现。或者你删掉了在手机上没有意义的东西。但是，如果您将其设置为必须维护两个代码流，或者一个很早就分支的代码流，或者一个根本不同的应用程序，您将变得更加困难。这是更多的测试，更多的编码，以及更多的破损可能性。

我们遵循这种方法，它适用于我们非常小的开发团队——我们已经成功使用它，因此我们可以使用相同的代码库为不同的客户运行两种不同的实现——一个非常复杂的桌面优先 UI，如以及一个非常精简的移动优先应用程序：

  • 假设所有设备都将访问相同的 URL
  • 假设 90% 的设备优化将使用 CSS 媒体查询完成，7% 将使用 jQuery hacks 完成，3% 将在早期使用浏览器检测完成
  • 构建您的应用程序，以便可以通过代码轻松启用/禁用各个 UI 组件或模块（ApplicationController 中的逻辑？Rack Midleware？）。我们通过将单独的“小部件”放入部分组件中，这些部分包含组件启用检查（在 Rails.config 中或作为 ApplicationController 端的实例变量），以便我们可以关闭是否返回相应的 HTML到浏览器
  • 使用 CSS 媒体查询不仅可以设置字体和宽度的样式，还可以重新排列菜单/功能和其他 UI 项目，以便它们适用于您需要的不同外形尺寸

通常，如果您要为移动设备构建已编译的应用程序并且将使用设备的 UI 库而不是使用设备的 UI 库对 UI 进行繁重的工作，那么 API-for-mobile 方法对您最有用。在服务器上生成的 HTML。再说一次，如果您选择使用诸如 Backbone.js 或 Angular.js 之类的方法来处理您的前端显示，那么使用仅 API 方法可能也是您遵循的良好架构。但是，你会更多地离开 Rails。

于 2013-09-16T21:48:15.103 回答
0

在我看来，一条基本信息是“为什么？” 你需要考虑工作的预算、时间表和截止日期。

为您提供类似于Matthew James Taylor的出色布局的液体布局，该布局将根据可用的屏幕尺寸调整大小我可以看到需要移动特定模板的唯一原因是为了提供特定的 css 样式以使您的视图看起来更像一个移动应用程序。

我不认为性能是一个问题。如果您有现有网站的性能开销，并且您正在为移动设备设计这些性能问题，那么为什么不也为非移动设备设计这些问题。即设计一个具有流动布局的移动网站，使其也适用于桌面/平板电脑查看。这可能是重新设计整个网站以提高性能的好机会。

我看到您确实有两种选择，具体取决于预算和时间范围

1) 设计一组全新的模板，同时使用流动布局设计出性能问题，以便随着时间的推移将现有布局切换到新布局

2) 重新设计现有的模板和功能，打造一个移动友好的网站。

无论哪种方式，您的台式机和平板电脑用户都会从中受益，但您在这方面能走多远取决于您的截止日期和预算，其中选项 1 在短期内是更便宜、更快捷的方式，而选项 2 在长期内是更便宜、更快捷的方式学期。我的看法是，如果不为移动用户和台式机/平板电脑用户提供相同的模板，你就会使某人处于不利地位，因此为所有用户提供最好的体验。

这确实是您的项目经理的决定。

更新 - 基于评论

在这种情况下，我会去开发一个单独的移动应用程序。我什至会考虑考虑使用替代技术来实时流式传输更新的数据。Rails Live Streaming 和 Node.js之间有一个很好的比较。

无论您是否选择引入新技术，通过为移动用户提供单独的应用程序，您都将提供终极的移动体验，并且能够完全专注于此。

我认为不同的域名对于 SEO 来说不是太大的问题。您应该能够利用主站点的现有可见性，并且使用单独的移动域，您可以提高您的 SEO 排名，而无需进行太多额外的推广。

我想你已经对最好的前进方式得出了自己的结论，我能给你的最好建议是告诉你给自己多一点思考时间，让你选择的解决方案更加坚定，我我敢肯定，如果它是正确的，它只会对您“感觉”正确。

没有人比您更了解您的业务，如果不参与项目和业务，真的不可能说出最终的最佳选择。

于 2013-08-01T08:41:55.833 回答