开发移动网页应用的一些技术指导

在咱们开发网页应用时须要使用许多技术工具。我最近已经从新开始写网页应用程序了，而且想把我之前在开发周期过程里所记录的零散想法都联系起来。这篇帖子主要介绍我找到的几个框架，它们对于我最近的几个项目都很是有帮助。我接下来主要讲解最关键的一些框架，它们每个都能扩展成独立的文章。我并非要对当前存在的各类框架进行大范围的比较，仅仅是把我最近尝试过的技术分享一下。

虽然本文的主题主要针对移动开发，不过我认为这些技术也适用于通常的网页应用。个人全部决定和数据点都符合如下几点：

• 只支持JavaScript(CoffeeScript和Dart是否兼容还有待观察，不过我会尽可能避免选择它们而引起的异常)
• 在最新的移动浏览器里运行正常（如iOS 5, Android 4）

选择MVC(模型－视图－控制器)方案

模型－视图－控制器方案用在天然界面的应用的开发里已经数十年了。其基本思路是分离数据层（存储，通信，数据）和表示层（用户界面，动画，输入）。虽然有其它相似的模式，例如MVVM（Model View ViewModel），可是最主要的想法是要在表示层和数据层之间有明确区别，使得代码可以更加简洁和稳定运行。

目前已经有众多JavaScript模型—视图—控制器框架可使用。其中一些，如Backbone.js和Spine.js，都使用纯代码编写，而另一些，像Knockout.js和Angular则须要DOM数据绑定属性。对分离视图和数据的MVC系统来讲，依托HTML5的数据和DOM属性彷佛有些不妥。所以我不使用Knockout和Angular框架。基于个人原始需求，Spine.js用CoffeeScript来写比较简单。

对于大部分框架来讲，Backbone.js的使用时间更长（可能除了JavaScriptMVC，一个停用的项目），还拥有愈来愈多的开源社区。个人应用程序栈一直使用Backbone.js。为了获得更多选择MVC的信息，我查看了TodoMVC，它实现了相同的Todo应用程序使用不一样的MVC框架。你也能够看看 MVC framework comparison这篇文章，它推荐Ember.js这个场景里的新文件。我尚未机会使用它，可是它在个人计划之中。

选择一个模板引擎

若是想要在网络上创建一个真正的应用程序，你不可避免地要创建大型DOM树。相对使用JavaScript API操做DOM，它能够更简洁高效地使用基于字符串的模板，而不是写HTML。通常来讲，JS模板已经发展到使用奇怪的常规脚本，它在脚本标记内嵌入模板内容：<script id="my-template" type="text/my-template-language">...</script>。使用全部模板引擎的基本模式是把模板做为一个字符串来加载并构建模板参数，而后经过模板引擎运行模板和相关参数。

Backbone.js依赖于Underscore.js，它是一种复杂语法写的受限模板引擎。此外，还有其它模板可供选择，例如jQuery Templates，Handlebars.js，Mustache.js。JQuery团队开发的jQuery模板已通过时了，因此我没有考虑它。Mustache是一个跨语言的模板系统，它的特色是简单而且成熟，能够支持尽量简单的逻辑。事实上，Mustache中最复杂的构造是一种遍历对象数组的方法。Handlebars.js至关依赖Mustache，它加入了一些不错的功能，如预编译模板和模板表达式。对我而言，我并不须要这些附加功能，也没必要选择Mustache.js做为个人模板平台。

通常来讲，我认为现有的模板框架在功能上差异都不大，所以选择哪一个在很大程度上是我的喜爱问题。

选择一个CSS框架

CSS框架是必不可少的工具，它使用便利功能（如变量）扩展CSS的功能集。这是一种建立分层CSS选择器和一些更先进的功能的方法。这样作实质上是建立了一种新的语言：CSS加强版（暂且叫它CSS++）。为便于开发，一些框架在浏览器中执行一个JavaScript编写的CSS++解释器，而其余框架则让你监控一个CSS++文件，并在有任何更改的时候编译它。全部的CSS框架都应提供命令行工具把CSS++编译成CSS来部署。

就像模板语言同样有不少功能类似的选择。个人选择是出于我的的语法偏好。我更喜欢SCSS，由于它避免了怪异的语法（如@）。SCSS的缺点之一是：它并无附带一个JavaScript解释器（有一个非官方的解释器，可是我没有试过），只使用一个命令行观察器。其它相似的CSS框架，包括LESS和Stylus。

如何布置视图

HTML5提供了多种方式来布置内容，但MVC框架并无提供使用这些布局技术的建议，这有时让程序员们很难作出决定。

通常来讲，相对定位比较适合文档，但不适用于应用。显然，绝对定位应尽可能避免，尤为是表格布局。许多Web开发人员已经转向使用浮动属性对齐元素，但这并非构建应用程序视图的最佳方法，由于它没有优化相似于应用程序的布局，从而致使许多奇怪的问题和infamous clearfix hacks。

多年来，通过对各类网络布局技术的实验，我认为一个固定位置和flexbox模型相结合的移动互联网应用是一个理想的选择。我使用的固定位置是固定在屏幕上的界面元素（标题，侧边栏，页脚等等）。Flexbox模型则很是适合在页面（水平或垂直方向）上布置层叠视图。它是惟一为界面设计明确优化的CSS盒模型，与Android的Linearout管理颇为类似。有关flexbox模型的更多信息，请阅读Paul的文章，并注意该规范被替换为一个新的且不向下兼容的版本。

自适应Web应用程序

最后一节是关于这一问题：我大力提倡建立设备特定的用户界面。这意味着须要根据不一样的状况从新编写视图代码部分。幸运的是，MVC模式使得重复使用多个视图（如平板电脑和手机）的单一模式更加简单。

IOS上的Flipboard软件很好的演示了这一设想，它为平板电脑和手机用户的不一样设备尺寸提供了相应的开发经验。

手机界面进行优化以便单手垂直滑动。

平板电脑的界面方便双手从不一样方向操做。

输入注意事项

处于移动状态时，用户与应用程序的主要交互方式是用手指触摸屏幕。这与使用鼠标的交互不一样，因为屏幕上有额外的9点须要跟踪，开发人员在编写移动应用程序时尽可能少使用鼠标事件。此外，鼠标事件在移动中点击有300ms延迟的问题（有一个著名的touch-based解决方法）。有关使用移动浏览器时这些事件的更多详细信息，请参阅my touch events article这篇文章。

仅仅靠s/mousedown/touchstart/使用你全部的事件处理程序是不够的。用户但愿可以靠一套全新的手势使用触摸设备，好比在屏幕上滑动，例如浏览图像列表。虽然苹果公司有一个不为人知的gesturesAPI，但却没有一套网络上开放的手势检测规范。事实上咱们须要一个JavaScript库以便于识别一些经常使用手势。

如何使其脱机工做

为了让一个应用程序脱机工做，你须要作两件事情：

1.资源可用（经过AppCache，Filesystem API等等实现）

2.数据可用（经过LocalStorage，WebSQL，IndexedDB等等实现）

实践中，在网络上构建脱机应用是一个棘手的问题。通常来讲脱机功能一开始就应该在应用程序中构建。若是不重写重要代码很难让现有的网络应用程序脱机工做。此外，各类脱机运行技术经常受到未知存储的限制，而且没法肯定超出限制时会发生什么不可预料的状况。最后，还有一些脱机技术问题，尤为是AppCache，正像我在先前的文章中描述的。

编写可以真正脱机运行的应用程序有一个很是有趣的方法：“先脱机”。换句话说，你写的一切都是在没有网络链接的状况下运行的，只有同步数据须要网络链接。在Backbone.js MVC模型中，这能够很好地适应自定义Backbone.sync适配器。

单元测试

通常来讲，你的用户界面很难进行单元测试。但若是你使用MVC模型彻底隔离用户界面，那么测试将变得简单。Qunit是一个至关不错的选择，特别是它容许使用它的start()和stop()方法对异步代码进行单元测试。

总结

总之，我使用Backbone.js MVC，Mustache.js模板，SCSS做为CSS框架，CSS Flexbox渲染视图，自定义触摸事件，Qunit完成单元测试。经过这些编写个人移动网络应用程序。关于脱机支持，我仍将尝试使用各类技术实现，并在之后的文章中介绍它们。虽然我相信这里列出的每类工具（如MVC）十分必要，但我也认可本文中描述的许多技术是通用的（如Handlebars和Mustache）。