3

背景

我需要创建一个可能非常大的HTML/JS 移动网络应用程序，该应用程序将作为移动网站交付，并在本地使用Phonegap。我目前正在努力确定组织应用程序本身的最佳方式。

基本计划是有许多模块，每个模块都侧重于不同的兴趣主题。其中一些模块非常基础（例如，公告/新闻），而另一些则非常复杂（例如，运动：团队球员、赛程表、视频等）。将有一个适用于大多数页面的侧抽屉式导航，因此用户可以快速导航到不同的模块。需要有在模块内进行深度链接的能力。这些模块将由各种开发人员和供应商创建。

单页应用

我看到的大多数移动解决方案都涉及Single Pages，在这种情况下，这对我来说似乎是个坏主意，因为可能会占用大量内存。似乎很难协调模块之间的哈希导航和模块内部分之间的哈希导航。模块开发必须在考虑应用程序框架的情况下完成，并限制供应商和开发人员完成工作的方式。另一方面，事情并没有那么频繁地被加载，并且一切都可以轻松地相互通信。

多页应用

使用多个页面，似乎每个模块都可以使用供应商熟悉的任何技术轻松创建（并且可以快速且廉价地完成）。它会减少内存使用，但也会消除模块通信的能力（我不知道目前我们需要的功能）。我可以看到制作一个每个模块都将用于共同处理各种事件（如记录错误、导航等）的javascript库。模块之间的每个应用导航都将是一个新的页面调用，重置DOM。如果愿意，每个模块都可以使用单页设计。

请帮帮我

那么，对于应该如何设计这样的东西，是否有任何共同的或新的知识？我渴望开始工作，但不想重写可能已经存在的东西。我的推理有什么明显的缺陷吗？我很想听听任何有洞察力的人的意见。

4

3 回答 3

0

您的第一步是确定这些要求。

如果您是为自己或您自己的公司这样做，那么请确定这些模块（合作）如何运作。

如果你是为你的雇主做这件事，那么那里的人应该知道他们想看到什么，否则，你将如何建造它？

支持多个页面、打开和关闭模块且没有通信的解决方案将需要与负责同时维护多个小部件的框架不同的东西，后者可能通过系统调用或服务进行通信，也可能不通信。

没有办法解决这个问题——为模块构建服务/沙盒/等比将每个模块都视为页面更改（或使它们成为文字页面更改）需要更多的工作。

当你弄清楚你想让你的程序做什么时，开始构建你希望其他人拥有的 API 的想法。
你是要为他们提供一个 API 来构建 UI 组件，还是要让他们随心所欲？

就个人而言，我会避免每个模块更改只是替换 iFrames 的情况，然后最终用户可以在那里做他们想做的任何事情。
同样，我会避免您允许模块创建者在非沙盒环境中运行他们想要的任何情况......对于您的最终用户（或者您，在英国法院）来说，结果很糟糕。但这还不是问题。

首先关心的是你的平台做什么。

然后弄清楚你的后端通信会是什么样子，你要为模块创建者提供什么接口，以及你将如何从你的一端获取数据（基于 http 的 API、REST 或无论如何... ...但是如果您还没有的话，请好好解决）。

然后，当你知道你的平台应该做什么，并且你有一个可以很好地服务于各种任务的后端时，弄清楚你要为内容创建者提供什么服务，制作他们的小部件，并上传/从您的服务和沙箱等下载数据。

于 2012-12-13T23:46:43.363 回答
0

老实说，如果您正在考虑构建任何您认为将是大容量和高复杂性的应用程序，您真的应该考虑进行原生开发，或者至少使用 Appcelerator 之类的东西，将应用程序“编译”为原生代码更好的性能。如果您打算让任意数量的开发人员构建他们自己的 javascript 组件，这些组件可能会或可能不会很好地管理有限的系统资源，那么很快就会遇到应用程序性能问题。

另一方面，如果您只是为了概念验证，并且不介意在获得足够的复杂性时可能不得不大幅重构您的应用程序架构，那么您可能只想简单地使用 Web 应用程序方法.

确实，您还需要考虑与前端架构一样多或更多的后端服务架构。这确实是您在尝试集成其他开发人员的产品时会遇到问题的地方。

于 2012-12-13T22:29:13.500 回答
0

几年前我有一个类似的架构问题需要解决。它不是移动的，但也不是完全基于网络的。目标应用程序是网站和桌面应用程序的混合体，未来有可能成为移动应用程序。

有趣的是，之前有两次尝试创建一个可以在各种情况下使用的框架。问题以及两次尝试都失败的原因是开发人员将其视为用户体验问题空间。他们使用几种不同的技术来接近它，但几个月后就陷入了困境，因为他们事先做出了假设，并在他们的裤子座位上进行了这个项目。

我的方法是完全避开所有 UI 讨论，并专注于可以从任何角度接近的后端架构。为此，我创建了一个具有双向数据传输的 Web 服务，并最终为数学模型提供服务。使用不同技术从各种来源访问该服务：Flash、Unity、Google Earth 插件，最后，从提供良好 HTML 的不相关 Web 架构访问。

我对你的建议是，不要把注意力集中在前端映射上，而要让你的后端正确。一旦你有了一个数据结构，你就可以向外构建，内存管理、单体应用程序与否等几个问题，即一页与多页，几乎都会自行解决。努力创建一个有很多好的接口的优秀 API，你就不会陷入“很多厨师”的坑。另一方面，给一群分散的开发人员足够的绳索，你将永远找不到所有的结在哪里！

最终是否通过基于 HTML5 的技术（例如 Sencha Touch、jQuery Mobile 或 Phonegap）采用原生 API 的决定是一个福音派黑洞，将在未来数月和数年内上演。在某些情况下，原生应用程序可能更加流畅和快速，但资源投资是应该考虑的。另一方面，JavaScript 开发人员潜伏在各个角落，而且并不短缺。

于 2012-12-13T22:45:46.257 回答