作者:
刀枪Blue
Apple 确实为 iPhone 应用的开发定了条与众不同的道路－－如 Jobs 大嘴巴所说－－iPhone 上八成不再有什么第三方 native code 了，唯有 web app 才是 iPhone 第三方应用的正道－－不过我猜如果哪个 ISV 面子够硬的话还是能有 SDK 来写 native 应用的
Apple 的开发者网站 Developer Connection 上已经推出了
iPhone 部分。只有一个内容，就是 Web Development for iPhone。按照 Apple 的设想和许诺，开发者能够写出和 iPhone 内置应用在外观和功能上差不多的第三方程序–这是暗示内置程序亦是 web app 呢还是只是夸耀 apple 提供给第三方的开发能力使外人也能写出和内置的 native 程序同样等级的软件？这些第三方程序能与 iPhone 内置应用和服务无缝集成－－包括拨打电话，发送 email 和在 Google Maps 上显示位置。
我想这种安排相比暴露一堆 API 的好处是：
- 引导了开发者把重心放到设计有创意的产品上，开发真正创新的有竞争力的应用，而不是继续鸡毛蒜皮的小修补，才是 iPhone 最需要的–大家可对 Windows Mobile 上 500 个第三方日历程序心有余悸？谁让 Microsoft 恨不得把自家牙缝里的东西都写进 MSDN 呢。对易用性大师 Apple 来说，暴露 API 似乎没有太多现实意义–出自这帮这帮家伙之手的 iPhone 内置应用基本没什么余地/缺陷留给第三方开发者填充或者弥补了，所以，你们不需要 OS 或者某种传统 framework 的 API 来再次开发，再所以，你们还是打起精神，为编写真正配得上 iPhone 的 cool app 整装待发吧。
- 再者，web app 开发好歹也算在标准接口上工作，绝大多数相关技术都是开放的，开发 iPhone 需要的参考资料–xml，html，javascript，rfc 里的协议等等等等–差不多全是 ISO，IEEE 等的标准。design house 为一百个手机写他妈的一百个的 phonebook 的黑暗日子总算有个头了– 哦，又忘了，iPhone 根本没打算让你为他重写 phonebook。
ADC 的 iPhone 开发准备内容只有两节：WebKit （或者 Safari，随便你） 和 Development Guidelines。WebKit 的内容不依 iPhone 的开发早就有了，不表。和其他手持系统上的开发不同，iPhone 上没有什么鸟 SDK 和 host 上的模拟器，如果说有的话，那 SDK 就是所有 web 开发相关标准–因为这是和 iPhone 打交道的接口，而模拟器就是 host 上的 Safari 啦，要不 Jobs 费劲地移植个 Safari Windows 版干嘛。
Guideline 是一对一和 iPhone 挂钩的东西，需要编写应用时阅读参考。不过先打个招呼，基于你的视角和观点，你会觉得 iPhone 上开发应用程序“居然沦落到”或者“终于进化到”这样的地步：If you are a seasoned web developer, there are probably just a few refinements you can make to ensure that your site looks great and works best on iPhone。
早先说了，在 Apple 的选择下，没有必要有类似 API 列表的 reference manual 了，因为 html，css 和 javascript 等内容本来就是开放的，所以只需说明应用与 iPhone 时的注意事项。
按 Apple 的表述，iPhone 的 Safari 和桌面系统 Safari 使用一样的 WebKit－－这话其实言之不详，似是而非，虽然我们宁愿已是精确表述。换做老式应用开发，我们只需要知道系统底层机制的描述，再有文档可以查阅 API 变化（比如有无增减，参数类型含义有无变更）即可，而所谓使用同一 WebKit 并不明确，因为 WebKit 至少包含 WebCore 和 JavaScriptCore 两部分，细节颇多，随便挑个 DOM 对象比比，都有可能不同。
对开发者甚至一般 iPhone 用户来说，最重要的是，如 guideline 里一句话所说，It’s tempting to think that using an iPhone is like using a computer. But it isn’t. 体现在用户交互上，表现很明显。
通常的网页–其实是我们的电脑了–当然只考虑到最常用的交互设备是鼠标键盘等，iPhone 的输入设备–手指–在精确度，可识别性乃至可产生的 event 上不同于鼠标。guideline 上为此专门提供了 “Know Which Events You Can Handle” 和 “Design for Double Tap.”两节内容。不过当然记住，在 iPhone 那光滑性感的表面上游走的两根手指可没法实现什么复制粘贴，拖放和选中；另外，手指是有宽度的，设计过于密集的交互对象（比如网页上的超链接）会让人吐血的。
既然是些 Web app，那相关标准就要随时能涌上心头了，iPhone 伟大的 WebKit 引擎支持的标准“应该”和桌面 Safari 一样，包括：
* HTML 4.01
* XHTML 1.0
* CSS 2.1，部分 CSS 3.xx
* JavaScript 1.4, 包括 DOM 支持
* AJAX 技术, 包括 XMLHTTPRequest
又因为 Apple 让 iPhone 上的 WebKit 和桌面一样，所以 iPhone 会另类地不支持 WML (Wireless Markup Language)，不过支持 XHTML mobile profile。开发适合 iPhone 浏览的页面和开发适用于通常浏览器的页面有很多详细之处，如果感兴趣，ADC 里也列出了相关参考资料。
下面，终于是有点入题的内容了–怎么实用 iPhone 上的服务。
电话：
[url=tel:1-408-555-5555]
1-408-555-5555[/url]
吐血，也可以理解，一切都是协议。这下好了，你连炫耀一下知道 MO call，MT call 的机会都没了。
Safari 也可以自动把一串数字解释成电话号码。
至于 mail 和 google map，和通常网页也无区别啦：mailto: 协议以及通常的 google map url 就行了。
在编写为 iPhone 优化的页面是，再一个参考是 Safari 发送的 agent 字符串：
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3
和桌面平台的 Safari 很像，但是多了
platform 描述：(iPhone; U; CPU like Mac OS X; en)
mobile 版本：Version/3.0 Mobile/1A543a Safari/419.3
在使用 CSS 时，要考虑到 iPhone 只支持 screen –你没看错哈–而不支持 print 和 handheld media query–这些都是 CSS3 的特性。所以，编写 iPhone 优化的页面时，可以这样引用 css 文件：
使用 only 关键字。这样也不会影响其他浏览器。
小插曲：在我如火如荼地整理 ADC 上的 iPhone 开发资料并在昨天抛出了 part 1 之后，我发现……网站挂了。那种精心筹划并准备接受鲜花掌声和顶礼膜拜却发现因为一个愚蠢的原因而未果的感觉和上周末在伦敦 Tiger Tiger 俱乐部前放汽车炸弹却被人因运气而发现最后如意算盘落空的菜鸟恐怖分子一样。
在发现网站挂掉的那个第一秒，我自鸣得意地以为是被“类digg”了，不过很快发现有点不对头，之后到服务商 media temple 看了下，果然是他们出了问题。我那篇心血文章陷入了藏在深闺无人问的地步。后继报道显示，伦敦人对未遂的汽车炸弹心平气和，戴安娜演唱会照开不误，所以，网站挂就挂呗，part 2 照写。
在开始看 part 2 前， mashable 的这则消息你可能会感兴趣：
8 Coolest iPhone Apps at iPhoneDevCamp。这个话题这周有空可以细说–不是戏说，谢谢。
今天又想了想 Apple 死活都不想公开 OS API 甚至是经过 SDK 包装过再提供的 API 的原因，我猜和 Apple 宣称 iPhone 采用的是“完全的 OS X”有关。
我早先–并且到现在一直–认为，Apple 这个说法实在很猪头–如果哪天事实证其实我是猪头那也挺好–衡量这个说法是否靠谱，iPhone 的 OS 是不是所谓“完全的 OS X”有几个准则，其中一个是看其提供的 API。而现在 Apple 只给大家一个开发 web app 的机会从而避免了必须在开发者面前宽衣解带的尴尬，就没人能知道这个侏儒 OS X 到底是什么构成，自然也就没法 challenge 那个“完全的 OS X”的谎言了。
Microsoft 在 WinCE/Windows Mobile 中还是引入了不少桌面 Windows 的概念的，窗口，事件驱动，消息，注册表，相似的大量 API，甚至 .NET Compact（不过当然没有 MFC 和 ATL 等），即便这样 Microsoft 也谨慎或者明智地没有宣称 Windows Mobile 和桌面 Windows 有什么暧昧关系。Redmond 的工程师们太朴实了，他们不像 Apple 的家伙那样会撩拨挑逗不明就里的处男处女消费者。
继续：此后 ADC 关于 iPhone 开发的内容是页面布局，字体的东西了，好烦人，而且没有实际东西就很难写得形象，这就不罗嗦了。留心几点，iPhone 上的 Safari 不提供滚动条，也不做所谓窗口缩放（根本就没 窗口 概念）。核心是 viewport 那个矩形区域（如图）。大页面又没滚动条怎么办？当然是使出 iPhone 最炫招数，手指头拖动啦。
iPhone Safari 支持的图片类型：GIF，PNG，TIFF，JPG。前三种格式的 decoded image size 最大 8M，也就是 宽x长x4 < 8 M。GIF 则必需 < 4M。原始 JPG 图片最大可以 128M－－足够了吧。
如果页面上有 form，比如输入文本框，那就要考虑弹出的软键盘--它会消耗屏幕空间，如下图。
多媒体–打住，跟最开始一样，目前看来你可没机会写什么第三方多媒体程序，这里的多媒体是仅仅指页面里的媒体内容。
第一要义是别忘了，如果是网络媒体，iPhone 的承载只有 EDGE 和 WiFi。对视频来说，码率和尺寸是最重要的，iPhone 支持 H.264/AAC。
再者，使用 reference movie，这样 iPhone 能根据当前链接是 EDGE 还是 WiFi，自动选择不同质量的内容。这种媒体包含多个 movie url，每个 url 包含一组测试内容。连接到 reference move 时，播放器只会选择最近的通过了其所有测试的 url，播放这个 url 的媒体内容，这样就保证了不同能力的设备选择合适自己的内容，在视频质量和链接速度之间取得均衡。Apple 提供
MakeRefMovie 工具。
其他内容，以及媒体制作工具自己取细看哈。从最终 Apple 推荐结果看：
为适合 WiFi 连接制作的 H.264 内容，视频可以达到 900 kbit/sec, 480 x 360，EDGE 是 64 kbit, 176 x 144。
这里有个好玩的地方大家可能意识到了：缺少 Flash 支持。这限制了媒体制作者能使用的媒体格式和播放手段，甚至进一步限制了能编写的 web app 类型–或者要实现类似功能，需要花费更多代价，所以我们只有期待
flash 支持的传闻尽快成真。
在开头 Part 1 说了，Apple 声称 iPhone 有和桌面 Safari 一样的 WebKit，不过在实践上，开发者还是得考虑两者实际存在的区别。iPhone Safar 提供的 feature 才是可以依赖的标准，对那些不支持的东西，Apple 承认，得想办法 workaround。
一个差别是资源方面的。所有被下载的资源，包括 HTML, CSS, JavaScript, 图象, 非流媒体,都得小于 10M。JavaScript 的 top-level entry point 执行时间必须小于 5 秒，否则会抛出异常。这个要求是为了保证用户能体验到足够好的响应性。Apple 还列出了支持的 MIME 类型（都是些媒体格式）。
另外是 iPhone Safari 和桌面版本表兄在行为上有些不同，iPhone Safari 缺省是 block 弹出窗口，不过用户可以改变这个设置。还不支持的有：
window.showModalDialog() 方法
Mouse-over 事件：这条说得过去，手持设备上，目前根本没办法 hover 东西，要么就干看，要么就触摸了。不过在 Pocket IE， NetFront 等浏览器上，焦点是可以移动的，如果把当前焦点视作 mouse over，也有得做。iPhone 上没什么按钮，无法做移动焦点，那就免谈了。
Hover styles：同上道理
Tool tips：其实也同上
Java applets：根本不支持
Flash：前面说了
Plug-in：桌面版本支持的怎么样？
Custom x.509 certificates：不知道用不用得上
不过 cookie 是支持的，SSL 实现和桌面版本一样，支持 SSL2, SSL3, TLS，RSA key 最高 4096 位。
用户发起的新建窗口也支持。可惜没上手试试的机会，不知道这样的多窗口支持如何，Windows Mobile 的 IE 是不支持的，NetFront 支持的还不错。iPhone Safari 支持最多 8 个窗口。
网页里链接的 PDF 文件能被 Safari 识别，在 iPhone 上阅读也没问题。
Part 2 里说了，Flash 目前不在 iPhone 支持范围内，这显然有那么点影响 iPhone 的可用性，让 iPhone web app 上的开发也有点微妙。除此之外，Java 同样不支持。
所有关于 iPhone 开发的东西就这么点了，说多也不多，因为本来就是基于已有技术和标准的 web app 嘛。
Apple 让 web app 成为手机应用的通用形式的目标让我想起 Adobe 正在推的 AIR，他们纵然手段差别挺大，却很有神似之处。AIR 让人使用 web 开发技术制作桌面－－应该说快赶上 universal－－应用，也就是在某种程序上达到让 web app 和本地应用拥有类似的功能以及 UI。
AIR 做到的是，使用一种技术，即可制作原来泾渭分明分属不同问题域的 web app 和 desktop app，AIR 也是这个问题的正解之一。Apple 推测起来也挺喜欢的这个想法，不过 Apple 的做法基本是 workaround－－限制开发者只能开发 web 页面，以此充当 iPhone “里”的应用。纵然如此，iPhone 的积极意义可能在于，在满世界都急得屁股冒烟地寻找 web 2.0 正途的时候，Jobs 开口，就在手机里。
Web 2.0 需要或者推崇的属性，用户参与，个性化，面向服务，连通（最好是随时随地的），iPhone 都提供了不错的平台，当然其他手机也能提供这些，可 iPhone 硬逼着本来半推半就还在考虑是要写 native code 还是做 web service 的好汉们上了 web 的梁山，加之 Safari 和 iPhone 对 web app 的开发支持够好，开发者们得到到比 J2ME 一次开发，到处到处调试 更爽的体验后，后继的英雄们会在此汇聚得越来越多。
