【Asp.net精品源码栏目提醒】:网学会员鉴于大家对Asp.net精品源码十分关注,论文会员在此为大家搜集整理了“(精品文档)iphone上的web开发(整理) - 培训教程”一文,供大家参考学习
第一部分 编写 iPhone Friendly 的 Web 应用程序 Part 1 - 布局入门 收藏 用过iPhone的朋友应该知道iPhone上面的一些应用程序是能够随机器转动自动适应的也就是说竖着拿的时候就竖着显示横着拿的话就横着显示iPhone中至关重要的Safari浏览器当然也支持这一点了因此我们考虑设计iPhone friendly的应用程序时首先要考虑兼容这种情况不能把页面定死在一个宽度上。
且慢我们不是说设计自己的应用程序吗这和内置的Safari有何关系iPhone被设计为不允许安装任何第三方应用程序破解不在讨论范围之内一切第三方应用程序必须以Web的形式来跑小到一个国际象棋的游戏也如此因此我们现在说的应用程序就是指Web但是与传统意义上以提供信息为核心的Web又不同我们所说的是以提供交互操作为主的应用。
好吧在我们正是进入布局的讨论之前先来赏析一下已有的iPhone应用 Facebook iPhone Edition Facebook的iPhone版。
如果你已经习惯了在iPhone上使用过Facebook第一次在PC上浏览这个页面会被它的“肥大”吓坏的。
从这个页面我们能够得知让页面自动适应iPhone屏幕的方法就是尽量使用百分比来定义宽度特别是全页宽度一律用100如果是导航栏里面4个项目并排的就每个25。
AppMarks AppMarks可以说是一个应用程序的书签当然也有人把它作为Safari的首页那就相当于桌面了因为你收藏的应用程序就在这个页面直接显示以大图标的方式。
AppMarks以前是可以直接在PC上浏览的现在已经自动将非iPhone的请求重定向到介绍页了不过这里有一个AppMarks Demo能在PC上看看。
我们能够看得到图片是4个一行地排列的共12个然而横屏会怎样了当然是变成6个一行仍然能够在一屏内显示完并且不会有不满行的图标。
其实这是一个很tricky的做法12是4和6的公倍数因此虽然竖屏和横屏的显示方式不一样但你不会觉得有什么缺陷。
Newsgator Mobile iPhone Edition 终于有一个
ASP.NET写的iPhone应用了其实和上面的Facebook看起来差不多同样采用了宽度为100的做法同时页面上的元素要么向左对齐要么向右对齐。
这听起来很废话其实意思是中间尽管留空不要想把整个宽度为100的块区都利用起来说明性文字可以放左边操作及视觉反馈放右边这样无论屏幕怎么旋转都好看。
如果中间塞满了内容只会让Safari进行比例缩放操作把页面整个缩小这其实是不利于操作的。
GMail 这不是普通的GMail吗怎样才能看到iPhone版这就需要通过修改user-agent属性欺骗它了。
iPhone上的Safari所用的user-agent如下所示 Mozilla/5.0 iPhone U CPU like Mac OS X en使用Firefox的User Agent Switcher修改一下user-agent就行了然后你就能看到iPhone上看到的GMail了。
仍然和上面的网站一样可点击区域是一大个宽度为100的块区。
小结 实际上设计iPhone friendly的界面在CSS的层面上来说一点也不难甚至可以说是非常简单因为基本上就是宽度为100的块区少数时候要用到按百分比划分的块区但实际上我们也应该避免这种情况。
为什么呢别忘记了iPhone的用户是没有鼠标的他们必须通过手指来操作页面上的一切因此可点击区域必须尽量大。
既然他们看不到鼠标指针你也就不用考虑可点击区域必须是链接或者cursor: pointer因为用户无法通过鼠标指针的改变来判断一个区域是否能点击。
然而这同时也就引入了另一个问题如何让用户了解一个区域能否点击呢这时候你必须给出明确的视觉暗示例如看起来是链接的文本蓝色的文本有无下划线通常都挺诱惑人去点这方面Facebook是一个例子。
另一种做法是让界面看起来是菜单式的好像AppsMarker和Newsgator那样菜单右侧的符号让人挺熟悉不是吗只要我点击这个菜单项就会展开下一级菜单。
最后一种做法就是基于用户已经熟悉的独创暗示来提示用户习惯使用GMail的用户一看到邮件标题那个大大的蓝色区域就知道点击是打开邮件这是不需要任何指引的最坏的情况下用户不知道点击什么还是会点击邮件标题之后他也就会用了。
第二部门 编写 iPhone Friendly 的 Web 应用程序 Part 2 - Viewport 收藏 在了解到iPhone的一些常见布局法后我们就可以开始着手编写一个真正能在iPhone上跑的页面了。
小声说一句之前我说要布局讨论完了要进入交互逻辑开发后来细心一想发现不行有些东西不讲的话将会对布局带来问题绕过去的话并不怎么优雅因此继续讲布局。
首先要说的就是viewport也就是可视区域。
对于桌面浏览器我们都很清楚viewport是什么就是出去了所有工具栏、状态栏、滚动条等等之后用于看网页的区域这是真正有效的区域。
无论你屏幕多大如果你装足够多的toolbar你的viewport最终也会消失掉。
在桌面浏览器中viewport的大小是与浏览器窗口大小直接相关的窗口大了viewport自然就大同时随着viewport的改变页面布局可能也跟着变。
例如width: 100的页面宽度就总是和viewport宽度一致。
然而iPhone的Safari不是这样理解viewport的它基于viewport呈现页面然后用户缩放页面后viewport保持不变仅仅是页面内容按比例缩放了。
举个例子在不设置viewport的情况下 可以看到图片按比例缩小了这对于传统Web页面直接在iPhone上面显示来说是很好的事情因为如果传统Web页面在980宽度的桌面浏览器viewport中显示正常的话iPhone上显示也绝对正常。
然而这对于Web应用程序来说则不是好事因为我们需要按照980宽度来设计将来会以320宽度显示的页面一个应该显示为32080的元素必须设计为980245这多麻烦 因此我们需要改变viewport让它变成这样 实际上应该怎么做呢我们有几个选择因此先让我们看看到底我们能够设置哪些属性吧。
我们可以操作的属性有4个 width - viewport的宽度 height - viewport的高度 initial-scale - 初始的缩放比例 minimum-scale - 允许用户缩放到的最小比例 maximum-scale - 允许用户缩放到的最大比例 user-scalable - 用户是否可以手动缩放 这6个属性我们可以设置其中的一个或者多个iPhone会根据你设置的属性自动推算其他属性值而非直接采用默认值。
这点很重要在完全不设置的时候有默认viewport在你设置一个属性后其它值是自动推算出来的不再是默认的。
如果你把initial-scale1那么width和height在竖屏时自动为320356不是320480因为地址栏等都占据空间横屏时自动为480208。
类似地如果你仅仅设置了width就会自动推算出initial-scale以及height。
例如你设置了width320竖屏时initial-scale就是1横屏时则变成1.5了。
那么到底这些设置如何让Safari知道其实很简单就一个meta形如 在设置了initial-scale1之后我们终于可以以1:1的比例进行页面设计了。
下一步我们就可以正式进入页面布局的细节设计了如果你想继续关注iPhone开发话题的话欢迎订阅 第三部分 在接下来的两篇文章中我们将探讨iPhone上的Safari所支持的XHTML与CSS之后才进入JavaScript的讨论。
作为一款现代化的浏览器Safari当然是基于标准的那就让我们看看Safari支持哪些标准吧 HTML 4.01 XHTML 1.0 CSS 2.1 以及部分 CSS 3 JavaScript ES3 DOM Level 2 AJAX XMLHttpRequest 熟悉这些标准并且平常也坚持Web Standards实践的朋友估计要笑出来了——就这些吗我们天天在用啊还有必要专门写文章来说明吗事实上Safari之前作为一款无PC版的浏览器一直用户数量就不高因此对它的研究也就不多然而S好吧不说废话了进入Safari对XHTML支持的介绍吧 链接 iPhone对一下这样一些链接有特殊支持 邮件 传统的mailto:地址iPhone将能自动使用内含的邮件程序处理直接进入编写邮件的界面。
完整的mailto:格式请参考RFC 2368。
电话 iPhone上的Safari会自动对看起来像是电话号码的数字串包括已经加入连字符或括号格式化过的添加电话链接点击之后会询问用户是否想要拨打该号码。
如果你不希望开启这个自动识别可以将它关闭 如果你关闭自动识别后又希望某些电话号码能够链接到iPhone的拨号功能那么可以通过这样来声明电话链接 Google Maps Google Maps的地图链接会自动调用内置的Google Maps客户端软件打开而非在浏览器内浏览。
链接可以是一个地点查询 Cupertino 也可以是一个路线查询 Directions YouTube 如果链接是指向YouTube视频地址的将会自动调用内置的YouTube客户端打开播放。
能够识别的YouTube地址格式为 http://www.youtube.com/watchv http://www.youtube.com/v/ 其中替换为视频的id。
图片 由于用户浏览时有可能使用Wi-Fi也有可能使用EDGEGPRS因此你必须优化你的图片以确保即使是在使用EDGE访问你的网站的用户也能流畅的打开页面。
因此你必须优化页面上的图片尽量减少它们占用的传输带宽。
另外Safari本身还对图片有如下的限制 GIF包括GIF动画、PNG与TIFF解压后的体积小于2m。
意思是原图的长度乘以宽度再乘以每一个像素的位数得出来的大小要小于2m。
JPEG解压后最大的体积是32m。
解压体积大于2m的JPG会被进行二次抽样最终显示给用户的是二次抽样后的结果。
这使得Safari能够显示数码相机直接拍摄出来的照片但显示时实际上是降低了精度的以提高程序的执行效率。
为了尽量提高效率例如你要将100100的图片显示为1010就要在服务器端执行压缩操作而不要直接用1010的来引用100100的原始图片。
表单 text password textarea 在设计文本框的时候必须记住用户点击后会出现软键盘这时候可视区域就减少了 另外在文本框中输入时iPhone提供了自动大写与自动更正两项功能。
自动大要关闭这两项功能可以通过autocapitalize与autocorrect这两个选项 select 必须留意到的是iPhone上的以不同的方式显示以便于用户操作 upload iPhone不支持任何的文件上传下载因此总是会显示出来并且是????disabled的 多媒体内容 iPhone上支持显示的多媒体内容除了图片还包括QuickTime音频视频以及PDF。
如果需要创建视频可以使用QuickTime Pro。
如果你正在使用一台MacBook或者iMac并且已经将QuickTime升级为QuickTime Pro可以马上就试一试你需要做的就是打开QuickTime Pro然后开始录像接着请对着镜头傻笑3秒或者做点别的最后选择Export for Web。
其中iPhone格式与iPhone cellular格式分别适用于Wi-Fi与EDGE环境iPhone在播放时会自动根据当前的环境选择适合的流媒体文件进行下载与播放另外poster是指影片播放之前在页面上显示的那一帧静态图片。
导出后文件夹里ReadMe.html说明了如何将这些文件添加到XHTML中。
事实上导出结果中QuickTime控件引用的那个mov文件不包含任何视频数据它只是一个引用类似我们编程时所说的引用用于指向真正的视频文件。
不过这个引用指向的是多个视频文件客户端根据当前的状态自动选择正确的视频文件来播放。
其他琐事 虽然说是琐事但也必须注意到这样才能让你的页面更好地受到Safari的支持。
这包括 声明正确的doctype 避免使用frameset 每一个独立的资源文件HTML、CSS、JavaScript、以及非流媒体的其他多媒体文件限制在10m之内 顶级入口的JavaScript执行时间限制为5秒超时将自动终止。
JavaScript分配内存上限为10m。
同一时间最多在Safari内打开8个子窗口同时浏览的页面。
第四章 说到编写CSS大家的第一反应肯定是——有没有选择性CSS。
有我们可以设计一个CSS使得只有iPhone上的Safari会采用它其他浏览器都会无视它这样我们就可能可以复用现有的XHTML页面代码仅仅为它们引入新的CSS就能够适用于iPhone无须重新编写页面。
这个选择性CSS链接语句如下 F E F Eattribute :link :visited :before ::before :after ::after :first-letter ::first-letter :first-line ::first-line E - F :root :not :target :enabled :disabled :checked 其它 media - 根据media选择性加载CSS multi-column - 内容分栏支持iPhone上不支持 还有一些Safari自己做的CSS扩展没有列举出来。
Safari完整的CSS属性支持列表请看这里Supported CSS Properties。
表单 Safari支持对元素比较高自由度的CSS定义例如这样的 实现所需的CSS属性上面已经列举了所以不再详细说明灵活运用就是了。
然后再看看蓝色背景下的 小结 CSS相关的话题也说完了很简单是不是大部分针对桌面浏览器进行符合Web Standards页面设计的设计师都能轻易掌握这部分内容然而这只是实现设计的手段到底如何设计一个界面在iPhone上才算是拥有高度易用性的这才是真正的问题。
这个问题我们将在以后探讨至少现在你能够将你自己的设计在iPhone上准确无误的实现出来了那么我们下一步就进入JavaScript的讨论环节了。
第五章 编写 iPhone Friendly 的 Web 应用程序 Part 5 - 交互入门 收藏 我们已经研究过XHTML和CSS了现在开始看看最后一部分也就是JavaScript以及它所提供的交互能力。
无AJAX交互 第一种我们要看的交互是完全不使用JavaScript这其中一个例子就是GMail。
GMail的iPhone版其实就是由普通的GMail移动版修改过来的界面上更贴近桌面版GMail了然而交互性并没有怎么提高每一个点击都对应一次刷新没有任何AJAX可言。
事实上不用任何AJAX效果并不会让你的iPhone Web App低人一等如果有人讥笑你的应用没有引入任何AJAX功能你可以直接跟他说“GMail也没有”。
因此如果你在开发的过程中决定不把任何时间投入到AJAX相关技术的研究这是没问题的确保你的服务器响应速度并且交互设计得当那就行了。
以服务器端为中心的AJAX 接下来我们看看另外一些应用例如之前说到的几个就拿最简单的AppMarks来说说吧。
首先使用User Agent Switch更改你的Firefox的user-agent属性伪装为iPhone然后打开AppMarks并且打开Firebug。
接着点Menu - Add - Browse看到出现AJAX请求了吧猜猜这个请求是什么类型的面向内容传输更新上去的XHTML、面向脚本传输进行更新操作的JavaScript还是面向数据传输更新相关的JSON答案是——面向内容的 这可是Web App哦不是一般带有一点点AJAX的网页哦我们要MVC我们要“先进”的面向数据为什么要“落后”的面向内容呢至今为止我们能够看到的大部分iPhone Web Apps都将MVC保留在服务器端了客户端唯一需要知道的就是内容更新不存在任何的客户端MVC模型。
暂时我还没看到有面向脚本或者面向数据的如果你见到有应用这样做了请告诉我。
我们继续说MVC的事情。
现在大多应用的设计方式是这样的每一个应拥有一个view framework然后每一次点击所作的操作就是切换view。
例如刚才说到的AppMarks从Menu进入以客户端为中心的AJAX 那么除了RoR我们还有别的选择吗我们可以选择使用一些客户端框架来实现类似的效果。
这样说吧类似RoR那样每一个view都是一个模板但不是rhtml而是普通的html没有复杂逻辑点击连接后不是由RoR引擎调在服务器端用rhtml而是客户端自己直接拦截了链接点击并用AJAX的方法去请求该html然后更新内容。
这样一个框架可以在Wrox的Professional iPhone and iPod touch Programming : Building Applications for Mobile Safari一书中见到。
这本书写着2008年1月出版但实际上已经出版并且可以下载源代码。
我暂时还没办法买到这本书但源代码中就包括了这样一个客户端框架。
然而这种以客户端为中心的做法并没有真正在客户端引入一个MVC它只是简单地把服务器端的MVC裁减掉了服务器端只能简单的发送内容或响应提交因此只适用于比上面的以服务器端为中心的模型更简单的情景。
如果你正在编写的应用不涉及大量的提交操作或者根本就是Web1.0网站我的意思是单向传递信息不接受任何用户提交的网站那么这种轻量级的模型就非常适用了。
小结 在这次的文章里我们介绍了三种常见的iPhone Web Apps交互方案没有哪一个是绝对更好或者更坏的按照你当前开发的应用做出选择吧。
将来我们写文章深入探讨其中的一些实现细节或者是交互模式但前提是我先完成了几个iPhone Web Apps。
欢迎订阅本系列文章
上一篇:
【精品】Flexpaper二次开发入门教程
下一篇:
Function GetIp(IP) 获得ip asp