Phonegap相关
1. 隐藏顶部的状态栏
         在xxx-Info.plist中新增一项属性："Status bar is initially hidden" = YES；此外，还可以增加其他的属性，例如Launch image等。
2. 用户滑动Webview时，正常情况下会超出边界然后弹回来，也就是Bounce，可以通过以下方式禁止这种行为：

        去年曾对Phonegap做过一次调研，当时还是1.1版本，印象也一般。对他的性能以及真实的跨平台能力都不太确定。今年过完春节至今正好有机会参与了一个纯Phonegap + HTML5开发的项目，项目至今已经完成了一期的App Store提交，所以也正好能抽时间来小结一下。一个月左右的开发过程让我对这种开发模式有了更深的认识，这对于前端开发人员而言绝对是一个大的机会。Phonegap Native API + Plugin基本能访问移动设备绝大部分本地功能，除此之外就是HTML5了，迁移成本非常的低，而开发效率也是很高的。
        与传统Web开发相比，在移动设备进行Web开发有着自己的特点，例如不同设备的屏幕尺寸以及分辨率都有可能不同，因此开发时需要考虑灵活性；移动设备上基本上都是使用webkit来跑Web，因此你的脚本和框架可以放心的使用一些高级的特性，以及可以彻底抛弃兼容IE的那些恶心代码；当今移动设备的性能与PC相比还有很大的差距，因此性能问题在移动设备上更值得重视，尤其是脚本性能（DOM操作、Redraw、Reflow）。

桌面通知功能能够让浏览器即使是最小化状态也能将消息通知给用户。这和WebIM是最为天然的结合。不过，目前支持Desktop Notification功能的浏览器只有Chrome5+。
关于通知的基础知识可以参考以下文档：
W3C标准:https://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications/
使用教程:https://www/5rocks.com/en/tutorials/notifications/quick/
本文主要记录通知功能在Web IM中实际使用时的一些经验。

在实际使用的过程中，应该尽量减少通知功能对用户的干扰，最大程度的减少通知功能的出现，这就需要解决以下几个问题：
1. 收到多条消息时确保只出现一条通知；
2. 当用户处于IM出现的页面中时(页面处于Focus状态)将不出现通知；
3. 当用户使用多Tab开启多个存在IM的页面时，只要有一个页面处于Focus状态将不出现通知；
此外，还需要解决一个便利性问题
4. 如何让用户点击通知浮动层即可定位到具体的聊天窗口

在实际上项目当中，经常需要使用短轮询(每隔一定时间就向服务器发送一次请求，请求通常会立即返回)和长轮询(每次请求服务器会Hold一段时间直到有新数据或者超时，客户端收到数据后会立即进行下一次请求）来从服务器拉取数据，然后动态的更新页面。随着功能的增加，一个页面中往往存在不止一个这样的轮询请求，而且在用户开启多个Tab页面时，总得请求数会翻倍。而“请求同步”指的是在以上场景中，即使是开启多个Tab也只有一个Tab页面维持轮询连接，一旦数据返回后，就将数据同步到其他无连接的页面，最大程度的减少请求。实现的思路也很简单，先解决由谁来进行请求的问题，之后基于本地存储将数据进行同步即可。具体的实现则有不少细节需要注意的，以下详细阐明。

本文介绍Tab之间的操作同步的实现，所谓操作同步是指将用户在某个Tab窗口中的操作同步到所有其他同一站点得Tab中。例如IM窗口的操作（打开、最大化、最小化、关闭、设置等），由于很多用户会在多个Tab之间切换，而IM在每个页面中都存在，因此对于数据同步的要求是比较高的，以前的做法是使用服务器方式来同步，即所有操作都向服务器发请求，然后广播，Tab收到消息后再响应。缺点是比较浪费资源，另外延时也比较严重。

很早之前调研过HTML5的本地存储-《DOM Storage全解析》，大致上对localStorage、sessionStorage等API做了下了解，但是一直没有机会真正的在项目中使用。终于这次借重构Web IM的机会，对本地存储做了更深入的使用，除了基本的API使用之外还在次基础上封装了一些应用层的库，例如Tab之间的操作同步、Tab之间的请求同步等。本文主要做一个阶段性的经验总结。

图片上传在当今的Web应用中是一个非常常用的功能，如果不需要在上传前进行图片预览则可以简单的使用HTML+Javascript来实现，但如果一定要在上传之前提供图片预览功能则需要求助于Flash来实现。不过，随着HTML5 File API的诞生这一状况终于有了改观，本文将介绍如何使用HTML5 File API快速的实现图片预览功能。

Web应用的发展，使得客户端存储使用得也越来越多，而实现客户端存储的方式则是多种多样。最简单而且兼容性最佳的方案是Cookie，但是作为真正的客户端存储，Cookie则存在很多致命伤。此外，在IE6及以上版本中还可以使用userData Behavior、在Firefox下可以使用globalStorage、在有Flash插件的环境中可以使用Flash Local Storage，但是这几种方式都存在兼容性方面的局限性，因此真正使用起来并不理想。针对以上情况，HTML5中给出了更加理想的解决方案：假如你需要存储复杂的数据则可以使用Web Database，可以像客户端程序一样使用SQL（不过Web Database标准当前正陷于僵局之中，而且目前已经实现的浏览器很有限）；假如你需要存储的只是简单的用key/value对即可解决的数据则可以使用Web Storage。 本文主要从各个方面介绍一下Web Storage的具体情况。

FORM在HTML5中的变化算是比较大的，一方面体现在新增了大量的2.0时代的控件，另一方面则是整个FORM结构的变化。与新增的控件相比，新的FORM结构一样为将来的开发工作提供了很大的便利性。

在WEB页面中，为了配合Javascript的交互功能，很多时候都需要给HTML标签添加自定义属性（虽然标准不支持这么做），而关于自定义属性的名字则大都也是各自为战的自定义的，或根据功能、或根据项目等等，例如：

<!-来自贴吧—>

<div cid="count_ayjpb" st_type="toupiao"></div>

<!-来自有啊—>

<a href="#" favo_type="x" favo_obj_id="x" favo_title="x"></a>

这样的会造成自定义属性名混乱的问题，而且更为重要的是假如新的HTML标准中需要使用这个自定义属性，而且其含义与你的自定义属性中含义并不相同，这是一个大家都不希望看到的情况。于是在HTML5中给出了解决方案：只要是自定义属性都需要带上"data-"前缀。

The
data-*
collection of author-defined attributes. Authors can define any attribute they want as long as they prefix it with
data-
to avoid clashes with future versions of HTML.

因此，按照这个规范可以改写上面两个例子以获得更好的兼容性：

<!-来自贴吧—>

<div data-cid="count_ayjpb" data-st_type="toupiao"></div>

<!-来自有啊—>

<a href="#" data-favo_type="x" data-favo_obj_id="x" data-favo_title="x"></a>

实际上在淘宝的机票已经有看到这样的使用

<span data-display="inline" data-tnick="x" data-nick="x"></span>

-本文到此结束-