创建Silverlight用户控件 (Creating and Using Silverlight and WPF User Controls)

Scott Guthrie的文章总是那么简单易懂，有时候还有丰富的插图，简直就如看连环画一般容易，因此作为入门级别的英语阅读练习文章就最适合不过了。这次Scott讲的是如何创建Silverlight（或WPF）的用户控件，不过用的不是VS2008，而是Expression Blend。

文章开头应该只有一个词是需要查字典的，也就是“encapsulate”，而这正是重点。为什么我们需要用户控件？因为我们需要对重复的逻辑进行“封装”，这样才能复用描述这些逻辑的代码，“encapsulate”正是“封装”的意思。在看懂了这个词之后，就是看图说话了，文章一步一步地教你如何将一组已有的控件圈选出来，然后生成一个用户控件。我想你看完图片，就一定能读懂图片下方对应的文字，甚至你可以为这张图配上更好的英文描述。

在完成了用户控件的创建后，Scott以数据绑定为例介绍了其使用方式。首先，你要定义待绑定的类型，实例化并填充数据，最后在XAML中加上绑定语句，之后就是继续看图说话了。在此问大家一个问题，知道阅读英语文章时你的障碍除了来自于你个人的英语能力，还来自于什么吗？答案是文化背景的差异，甚至是文章结构风格的差异，中国人喜欢把重点（或者是真正要表述的意思）放到文章的最后，并称之为“压轴”，然而美国人的思维习惯恰好是相反的，打个比喻就是——“重点请先说，后面的可能我没时间听下去”。

文化背景差异造成的障碍就更大了，一些约定俗成的东西可能你无法理解，从而某些幽默可能你当成了事实，这就导致更大范围的误解了。举一个简单的例子，知道Scott这篇文章中的这张图片有什么好笑吗？

如果你理解使用信用卡时“ship to”和“bill to”的用途，并且你知道上述两个地址分别是哪里，那么你看到这样图就会哈哈大笑——“货物送往Microsoft，并请Apple买单”，这太恶搞了！（如果你还是不明白的话，请点击Microsoft与Apple上面的链接。）

在这里，你就看到了文化背景的影响。然而英语是一个不能逃避的问题，要说因为背景不同从而避免阅读英文文章，还不如多读从而逐步了解这些背景。在新东方，我碰到过一个教TOEFL的老师，他说他从来没到过美国读大学，但却对美国大学里面的生活情景了如指掌，例如如何申请宿舍，停车场是区分教工车位和学生车位，代号101的课程通常是入门课程，等等。为什么呢？他说因为他做了大量的TOEFL听力题，而一般听力题都是这类情景下的对话，因此即使你不是生活在那种文化中你也可以对它有所掌握。

A*路径搜索中使用二叉堆 (Using Binary Heaps in A* Pathfinding)

如果你要深入研究某些技术，不可不勉地你必须阅读一些很学术的英文文章，这篇文章就是一个例子。

在这篇文章中，首先说的是一维列表的解决方案，并且说明为什么效率是问题。然后解决方案自然是binary heap，这就要说说binary heap的二叉树结构如何能够保存在一维数组中。接下来是对binary heap添加删除元素操作的简单说明，并且解释了为什么binary heap的效率比简单的一维列表要高。请注意，到此为止文章都没有深入binary heap的实线细节，这就是美国人比较习惯的写法，先briefing一次，再深入，因此后面的部分你看不懂也至少懂了一般。如果在前面就直接引入细节，你看不懂，就算后面还是有显浅的内容你可能也会错过。

在文章的后半部分中，作者深入地解释了binary heap的数据结构、操作算法，读完这一部分你就知道如何在自己的程序中实现binary heap了。并且在文章的最后，还有若干个延伸阅读的链接。通过读这篇文章，你就能了解到美国人一般是如何组织科学类文章的主干是如何安排的。

最后，如果你觉得Random Clipping的推荐不错，可以考虑长期订阅Cat in dotNET，这样你将不会错过将来的任何一篇推荐。

为了支持这个campaign，我特意为他们做了一个中文翻译。我本来是想和aw一起做的，不过他们把内容发给我的那个晚上找不到aw，于是有翻译问题就直接找Junyu问了，最后在Junyu的帮忙下把翻译搞定了。我在想是不是应该多做一个粤语翻译，这样会比较好玩，反正也就一个晚上的事情而已。

在这次的讲座上，讲的主要是Silverlight 2.0的新特性，而上次Silverlight 1.0所讲过的内容没有再次重复。不过在问答环节，现在还是有一部分的听众比较关心之前Silverlight 1.0讲过的内容，例如为什么需要RIA，或者是如何实现动画等等。建议大家如果没有听过上次Silverlight 1.0的讲座，可以先看看上次的pptx，讲座资源：Silverlight In Action。

最后，如果大家对活动有什么反馈信息，欢迎直接留言。

虽然我们要动态创建控件，但实际上这部分控件仍然属于View的部分，我们应该尽量采用ASPX的声明性名义来描述这些控件，避免用C#代码来创建控件、设置属性并添加为子控件。就拿最简单的例子来说，创建一个LinkButton，通常我们都需要设置它的ID、Text、OnClick属性/事件，甚至还要设置OnCommand、CommandName、CommandArgument等属性/事件，那就是大概3到5个属性了，用ASPX来声明只需要1~2行代码，而用C#代码则需要写至少5行（把new和Add()也算上的话），由此可见在定义控件这类声明上ASPX比C#代码的可读性要高。

接下来，我们来研究一下TemplateControl是如何工作的，这自然要从如何编写一个TemplateControl讲起。

编写模板控件

在这里，我们假设要编写一个SimpleRepeater控件，自身不支持数据绑定，只有唯一一个名为ItemTemplate的模板，并且就按照Count属性指定的次数重复出现该模板。首先，让我们来定义这两个属性：
public ITemplate ItemTemplate { get; set; }
public int Count { get; set; }

因为ItemTemplate属性不是以键值对的形式在SimpleRepeater的声明中给出的，而是以内嵌一对标签的方式定义的，因此我们需要让解释器去把<ItemTemplate>...</ItemTemplate>中间的内容读取出来，并把解释结果作为ItemTemplate属性的值处理。这时候，我们就需要为SimpleRepeater类加上ParseChildrenAttribute，也就是这样子：
[ParseChildren(true)] public class SimpleRepeater {...}

最后，我们需要重载一下CreateChildControl()方法，把ItemTemplate的内容作为子控件添加到SimpleRepeater之内：
protected override void CreateChildControls()
{
  if (ItemTemplate != null)
  {
    Controls.Clear();
    for (int i = 0; i < Count; i++)
    {
      Control control = new Control();
      ItemTemplate.InstantiateIn(control);
      Controls.Add(control);
    }
  }
}

这段代码的用意应该是相当清晰的了，就是循环Count指定那么多次，每次循环创建一个空白的Control，用ItemTemplate.InstantiateIn()方法填充它，最后把它添加到SimpleRepeater.Controls里面，就那么简单。那么这个神秘的InstantiateIn()方法到底是干什么的呢？后面来解释。

编译模板控件

在之前的《深入理解 ASP.NET 动态控件 (Part 2 - 编译过程)》里面，我详细地解释了ASP.NET 2.0的编译模型。在《深入理解 ASP.NET 动态控件 (Part 5 - 编译实验)》中，我们又做了一个动手实验，亲眼看到了ASPX和C#代码是如何编译到一起的。现在让我们来看看当碰上模板控件时，代码会被如何编译吧。我们把上面编写的SimpleRepeater注册到页面上，前缀为ctrl，并且编写如下一段代码：
<ctrl:SimpleRepeater ID="SimpleRepeater1" Count="10" runat="server">
  <ItemTemplate>
    <asp:Button ID="Button1" Text="Button" runat="server" />
  </ItemTemplate>
</ctrl:SimpleRepeater>

然后还是用aspnet_compiler编译一下，并且用Reflector打开编译出来的dll看看。我们可以看到构造SimpleRepeater实例是通过这样一个语句完成的：
return new SimpleRepeater { ItemTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control1)), Count = 10 };

这个语句其实就是一个普通的new语句，并且给ItemTemplate和Count两个属性赋值了，唯一值得关注的就是ItemTemplate的值。ItemTemplate的类型是ITemplate，因此任何实现了ITemplate接口的类都可以复制给它，然而我们却从来没指定过到底要赋值什么类型的实例给它，因为这已经由ASP.NET帮我们想好了，假若我们不指定的话，那就是CompiledTemplateBuilder类型。还是熟悉的Builder模式，它只需要已委托的形式接受一个实例化ITemplate的函数，然后就能返回实例化好的ITemplate控件子树。可能你会问，既然我已经有实例化ITemplate的函数，干什么要先传给你CompiledTemplateBuilder，让你来调用一下，再把实例化好的给我？我自己实例化不好吗？在此，ASP.NET引擎的做法只是为了保持Builder模式的一致性，处处用Builder模式来分离逻辑而已。

那么这个用于实例化ITemplate的函数从哪来呢？在解释器进入到<ItemTemplate>...</ItemTemplate>内部时，它会继续层层构建Builder模式，就如同在整个页面内执行的一样。因此，整个<ItemTemplate>...</ItemTemplate>会被解释器转化为一个函数，它也是通过层层调用内部函数完成自身的控件子树的构建，传递给BuilderTemplateBuilder构造函数的委托正是指向此函数。

因此，模板控件里面的内容将如同模板外的内容一样，被无缝地解释和构建到一起来。

INamingContainer

如果你查看SimpleRepeater输出的HTML代码，你会发现里面有10个<input id="Button1" name="Button1" type="button" value="Button" />。我们都知道，重复的id是不符合标准的，因此我们需要通过INamingContainer把这个问题解决掉。因为重复的控件是ITemplate，所以应该对它加上INamingContainer，然而它的实例编译时自动使用了CompiledTemplateBuilder，我们如何把INamingContainer加上去呢？我们就只能把INamingContainer加到它的父控件上面去。此时，我们需要一个实现了INamingContainer的简单控件：
public class SimpleRepeaterItem : System.Web.UI.Control, System.Web.UI.INamingContainer {}

然后我们把SimpleRepeater.CreateChildControls()方法的这个语句：Control control = new Control()，替换为：SimpleRepeaterItem control = new SimpleRepeaterItem()。这样，ITemplate的容器就变成了一个具有INamingContainer接口的控件，这时候各个Button的客户端id就会自动加上其容器的id作为前缀，因为容器的服务器端ID是自动变好的，所以必然是各不相同的，这样就解决了Button客户端id相同的问题。

通过这个例子，我们了解到了编写模板控件时必须为模板的容器加上INamingContainer，因为模板内的控件ID命名是可能重复的，加上INamingContainer就可以避免它们的客户端id重复。

小结

这次的文章解释了为什么我们应该尽量使用模板控件来实现动态控件，并且也说明了如何编写自己的模板控件，以及模板控件最终是被如何编译为Builder模式的代码的。

• Cat in Chinese (feed: http://feeds.feedburner.com/CatChen/Chinese)
• Cat in dotNET (feed: http://feeds.feedburner.com/CatChen/dotNET)

在实验开始之前，首先来一个小问题：如果不允许你使用ASPX，要你完全使用C#代码写一个具备复杂控件树的页面你会怎么写？把声明控件的代码都放在Page_Load里面吗？或者有更好的代码编写方法？先想想这个问题，然后继续往下看。

实验的第一步，也就是在Visual Studio里面创建一个ASP.NET项目，并编写一个简单的ASPX页面。例如下面这个例子：（以下代码仅包括HtmlForm内的主体部分）
<asp:MultiView ID="MultiView1" runat="server">
  <asp:View ID="View1" runat="server">
    <div>Please choose either of the followings:</div>
    <asp:RadioButton ID="RadioButton1" runat="server" />
    <asp:RadioButton ID="RadioButton2" runat="server" />
  </asp:View>
  <asp:View ID="View2" runat="server">
    <div>Please choose any of the following:</div>
    <asp:CheckBox ID="CheckBox1" runat="server" />
    <asp:CheckBox ID="CheckBox2" runat="server" />
  </asp:View>
</asp:MultiView>

在这个例子中，我们构建了一个简单的控件树，同时又不至于过于复杂，确保了编译出来的代码相对简单一些。接下来我们就需要将它编译了，最简单的手动编译方法就是用ASP.NET 2.0自带的aspnet_compiler.exe，这个文件默认会在这个目录中：C:\Windows\Microsoft.NET\Framework\v2.0.50727。你可以使用aspnet_compiler -h来查看完整的帮助，例如编译一个IIS默认站点中的ASP.NET子站点可以使用这样的代码：
aspnet_compiler  -v / -p C:\inetpub\wwwroot\site C:\output\site

接下来，我们到输出目录的bin子目录里把dll抓到Reflector里面看看吧。你会看到这个dll里面有三个namespace，分别是-（在Reflector中代表没有namespace）、__ASP、ASP。假设你编译的站点有一个Default.aspx，那么在无namespace的类当中就会有一个_Default的类，对应的就是Default.aspx.cs编译出来的类。大家应该还记得《深入理解 ASP.NET 动态控件 (Part 2 - 编译过程)》里面提到的，直接继承自Page的类是用后台代码编译出来的，_Default类就是这样一个具体例子了。我们打开_Default类来看看，就会发现MultiView1已经是其成员了，为什么呢？MultiView1仅仅在ASPX中声明，没有在C#中声明啊。回头看看《深入理解 ASP.NET 动态控件 (Part 2 - 编译过程)》就能解释了这种现象——Default.aspx.cs是标记为partial的，而在你手动编辑的文件中，这是唯一一个partial，另外一个partial由编译器根据Default.aspx自动生成，编译器解释完Default.aspx后在自动生成的partial中定义了MultiView1，因此两个partial合并编译后，_Default类自然就有了MultiView1这个成员了。

接下来，我们再看看ASP这个namespace下的default_aspx类，这个是ASPX文件继承自上述_Default类后编译的结果，它完整表述了ASPX文件中整个控件树的逻辑，而不仅仅是一个包含一堆成员控件定义的Page派生类。这个类的执行入口是FrameworkInitialize()方法，它通过调用__BuildControlTree()方法来构建控件树。在这个方法里面，你可以看到<!DOCTYPE ...>这样的字符串是被解释为LiteralControl的，LiteralControl在Render()时就会把这段文本原样输出。同时你还可以看到，它调用了另外两个方法，分别用来构建HtmlHead和HtmlForm，这两个方法通过类似的形式继续调用其他方法来构建更深层次的控件。

通过阅读default_aspx类的代码，你已经能够理解ASPX的控件树是如何转化为C#代码的了——采用的正是Builder模式。了解到这一点，这次动手试验的目的也就达到了。如果你看到文章开头的那个问题时，你已经想到了使用Builder模式，那么此时也就验证了你的想法是完全正确的。

下一次的文章将是与TemplateControl相关的，我们将继续动手做一些小实验，敬请期待。欢迎订阅我的blog：

• Cat in Chinese (feed: http://feeds.feedburner.com/CatChen/Chinese)
• Cat in dotNET (feed: http://feeds.feedburner.com/CatChen/dotNET)

信息获取

最先想到的，也是最重要的，是你想干什么，而不是你父母想你去干什么，或者哪个赚钱之类的。在计算机系里面，你总能碰到一些对这个行业没什么感觉的人，他们会说当年填报志愿的时候根本没什么喜欢不喜欢可言，于是在父母驱使下或者金钱诱惑下就报了计算机系。显然你不想犯这类错误，因此第一步是弄清楚你想要什么，或者说，有什么是你可以选择不要的。世界上没有十全十美的事情，所以一切都是权衡取舍（trade off），这个思想贯穿着计算机体系设计的方方面面，缺乏这种思想肯定会导致你在这个行业里发展受到限制，所以首先你要想好的就是你将来的职业发展取什么而舍什么。

在你先清晰了解自己之后，才有如何了解企业实际情况的问题。如果说第一个问题严重依赖于你个人悟性的话，那么第二个问题就依赖于你的人脉了，至少是你的外向程度和活跃程度。

一个企业，其自身对外的公关肯定只会说好话，就算没有任何夸张成分，也不会让你看到这个企业内部任何的不足。因此，如果你需要知道一些细节，看看这企业是否如你想象中那么好，你就必须认识在这家企业里面的员工，通过他们好好了解一下。如果你是一个在学校里已经很活跃的学生，整天在BBS上板聊，或者参加各种学生社团的活动，那么你肯定有机会认识到不少比你高一两个年级的同学，看看他们里面有没有一些正好在你想去的企业工作的，联系他们了解一下企业的情况，例如工资和各种福利怎么算啊，工作与学习的氛围如何啊，以及他们是否也认为你适合这个企业。

如果有机会多问几个人的话，最好都问问，并且以人生经历和价值取向与你相近的人的说法为主要参考。这是因为，在同一家企业里面，不同的员工看到它不同的方面，并且都带有自己的主观想法，因此得出的评价可能截然不同。这就好像假如你问我北京是否好住，我肯定说不好住，因为我看重的是商业环境，我觉得北京的服务业经常让我失望，因此就这样说。但肯定也有人很喜欢住北京的，他看重其他一些因素，并且觉得我看重的那些因素可以忽略不计。如果你确实很想去一家企业，就应该多找几个员工了解情况，特别是头脑清晰能看清楚自己所在企业优劣势的人。如果你碰到一个已经被洗脑的员工，那么问什么也没用，反正他就只能帮你洗脑……

联系途径

根据往年的经验，现在正是2009年毕业的学生找实习的时候，甚至有2010年毕业的学生也提前开始找实习了。积极的人肯定早已开始四处打听消息，包括各大公司招聘什么实习职位，往年难度如何，转正比例多少，等等。在这里，我就要“曝光”我身边的一些朋友了，大家不要怪我“出卖”朋友了哦，因为谁都知道成功把有才华的人推荐给自己公司的意义所在。

在这里，我主要说的是BGM（Baidu、Google、Microsoft的意思，不是background music），如果你对其他IT企业有兴趣的话，也可以找我帮忙，只要我认识该企业的人，我会充当一下“路由”的角色为你“尽力服务”的。

Baidu

如果分别把BGM比作人的话，Baidu是一个典型的中国年轻人，一点都不张扬。就如同在中国随手抓一个ASP.NET MVP问他，“你是不是很熟悉页面生命周期”，他可能回答道，“懂一点吧，有什么问题你先说说看。”虽然从资源（resources）的级别来说，Baidu是很难和Google、Microsoft去比的，但是开放程度（openness）还是是相当高的，你可以做自己喜欢做的项目，可以获取到项目所需的资源。

想去Baidu的可以找我，或者布丁，先了解一下。当然，如果你来找我的话，最好你也能说服我为什么值得推荐你。我主要做Web前端开发的，而布丁则是做后端开发的，所以如果你想申请这两个方面的职位，可以直接找我们了解Baidu现在所采用的技术或者流程。如果是其他职位，也可以帮你联系其他同事问问。完整的实习职位列表，请看这里。

Google

Google是一个典型的美国年轻人，你不问他也会很主动地把他的优势展示给你看。在我看来，Google最大的诱惑不在于公司内的“饮食娱乐”项目（虽然这些也很吸引），而是作为一般的中国员工也可以随便跑到美国总部去，顺道参加美国举行的一些会议或者讲座。看看Junyu同学就跑到Austin去开SXSW了。

如果想去Google的话，去找Junyu问问吧。别告诉我找不到他的联系方式，我通常只链接别人的blog，因为该URL就是个人的标识（即使抛开OpenID不谈），拿着这个URL你手上就已经掌握了搜索他联系方式的一切资料。Junyu喜欢把人拐卖进Google里，想了解招聘职位什么的，找他就好了。

Microsoft

Microsoft是个稳重的美国中年男人，Google所晒的东西，Microsoft会暗自想着“我当年又不是没晒过，现在我已经不屑于晒了”。很成熟的流程，健全的管理体制，都很好地说明了这一点。

貌似我没有很熟的朋友在Microsoft，不算太熟那些又不敢晒出来，所以想找人推荐的话还是联系我，然后我再帮你联系吧。想了解的话，可以找Jeffrey或者Dflying这两位老员工加现任MVP，他们现在不再是员工了，可能观点会更加客观一些。

其他事情

据我所知，很多人也是准备找实习了，才想到要写简历的。这是一项需要创意的工作，在此我提供我的简历和Junyu的简历给大家作为参考。虽然我们的网站下方都写着Creative Commons License，不过不建议你直接使用别人设计好的模板。特别是，假如你想申请Web Developer/Designer类别的职位的话，你可不能够错过这个机会好好展示你的设计风格和编码艺术。

最后，祝大家在08年里都能找到自己喜欢的工作学习环境，好好享受生活。

Thread.Sleep(30 * 1000);

然而问题是，我们不是要等30秒然后看看是否有事件需要返回，而是在这30秒内随时有事件随时返回。因此，我们需要一套机制来在等待的过程中检查是否有事件发生了。

Monitor模型

在.NET里面，大家最熟悉的线程同步模型应该就是Monitor模型了。没听说过？就是C#的那个lock关键字，实际上它编译出来就是一对Monitor.Enter()和Monitor.Exit()。

通过lock命令，我们可以针对一个对象创建一个临界区，代码执行到临界区入口时必须获取到该对象的锁才能执行下去，并且在临界区的出口释放该锁。然而这种模型不太适用于解决我们的问题，因为我们需要等待一个事件，如果使用lock来等待的话，那就是说要先在Web Service外部把对象锁上，然后等事件触发了就解锁，这时候Web Service才顺利进入临界区域。

事实上，要进行这类型的阻塞，还有一个更好的选择，那就是Mutex。

Mutex模型

Mutex，也就是mutual exclusive的缩写，“互斥”的意思。Mutex是如何运作的？这有点像是银行的排队叫号系统，所有等待服务的人都坐在大厅里等候（wait）被叫，当一个服务窗口空闲时它就会发出一个信号（signal）来通知下一位等候服务的人。总之，所有执行wait指令的线程都在等候，而每一个signal能够让一个线程结束等候继续执行。

在.NET里面，wait和signal这两个操作分别对应Mutex.WaitOne()和Mutex.ReleaseMutex()这两个方法。我们可以让Web Service的线程使用Mutex.WaitOne()进入等候状态，而在事件发生时使用Mutex.ReleaseMutex()来通知Web Service线程。因为必须在Mutex.ReleaseMutex()发生后Mutex.WaitOne()才可能继续执行下去，因此能够执行下去就证明必然有事件发生了并且调用了Mutex.ReleaseMutext()，这时候就可以放心地去读取事件消息了。

简单示例

在选定使用Mutex模型后，我们来编写一个简单的示例。首先，我们要在WebService派生类内定义一个Mutex，还有一个代表消息的字符串。

Mutex mutex = new Mutex();
string message;

然后，我们定义两个WebMethod。为了把问题简单化，我们选用上一篇文章中开头所说的两个函数签名，也就说只能在一个Web Service内自己发自己收，没有发送目标的概念，也没有超时的概念，还没有可靠性设计。同时，我们将Message类型替换为普通字符串，以便于我们测试。

我们先编写发送消息的函数：

public void Send(string message) {
  this.message = message;
  this.mutex.ReleaseMutex();
}

在这个发送函数里，首先我们把消息放进了类内全局的变量中，然后让全局的Mutex类释放一个signal。这时候，如果有线程在等待，它可以马上执行下去。如果此时没有线程在等待，那么下一个wait的线程执行到该阻塞的地方就能够不受阻塞继续执行下去。

现在我们来编写接收消息的函数：

public string Wait() {
  this.mutex.WaitOne();
  return this.message;
}

接收函数一开始就进入wait状态。在得到signal后，需要做的事情就是把全局的消息返回给客户端。

亲身体验

最后，我们可以通过ASP.NET Web Service本身支持的Web测试界面来测试一下我们的代码。我们开两个浏览器窗口，一个进入Send()调用，一个进入Wait()调用。然后我们按照如下方法来测试：

1. 首先执行Send("Hello")，然后执行Wait()。这时候你可以马上看到"Hello"。
2. 首先执行Wait()，让它等待返回，这时候执行Send("Hello")。随后你可以看到Wait()那段返回"Hello"了。
3. 按如下顺序执行：Send("Hello");Wait();Send("World");Wait();
4. 按如下顺序执行：Send("Hello");Send("World");Wait();Wait();
5. 按如下顺序执行：Wait();Wait();Send("Hello");Send("World");
6. 按如下顺序执行：Wait();Send("Hello");Wait();Send("World");

你会发现这样一些奇怪的结果：第3个测试返回的是"World"和"World"。第5个测试先返回"Hello"的并不一定是先执行的那个Wait()线程。后者在某些情况下不是什么问题，特别是长连接中一般之后一个Wait()线程在等待中，所以我们可以不管。而前者，则是因为没有消息队列所造成的，我们只有长度为1的消息窗口，所以只能缓存最后一个消息。这个问题我们将在下一篇文章中解决。

小结

在本文中，我们看到了不同的线程同步模型的差异。Monitor模型的lock本质上是一个Semaphore，也就是一个不能连续signal的Mutex，一个signal发出去后必须被一个wait接收了才能进行下一次的signal。同时，Semaphore也限制了signal和wait必须在同一个线程内成对执行，而Mutex则没有此限制。虽然.NET是针对Monitor模型优化的，但在我们的需求当中，只能通过Mutex模型来解决。

接着，我们便写了一个小小的消协发送与接收函数，实现了我们想要的阻塞式Web Service。同时我们也看到了没有消息队列造成的问题，因此确定接下来我们要做一个消息队列。如果你想知道消息队列如何编写，欢迎订阅我的blog：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

我们接着开始讨论如何使用.NET实现这个模型。首先我们能想到的是，我们需要一个Web Service，可以是ASP.NET Web Service，也可以是WCF Web Service，ASP.NET AJAX Library两者都支持。在这里，为了简单起见，就选择大家更熟悉的ASP.NET Web Service举例。然后，我们写下以下两个函数签名：

public void Send(Message message);
public Message Wait();

其中，Send函数用来发送一个Message对象，而Wait函数用来等待一个Message对象。然后，让我们来讨论一些细节问题。

无事件导致超时

首先，长期保持连接时不行的。对于服务器和客户端来说，这不是个问题，但我们永远都要记住中间可能存在各式各样配置怪异的网关和代理，它们上面可能有各式各样的超时规则，因此Comet最好设计为定期重连。一般情况下，如果30秒没有任何事件发生，服务器端就应该通知客户端确实没有事件发生，结束掉本次请求，然后重新开始一次新的请求以便继续等待。

那么上述函数签名可否用来返回一个无事件的消息呢？这是显然可以的，我们可以选择返回null表示无事件，或者返回一个EmptyMessage常量，这视乎我们使用class还是struct来定义Message。（甚至，我们还可以做一个名为NoMessageMessage的Message派生类来做这个事情。）

定义发送目标

上述函数签名确实能用来收发消息，但是没指名发给谁。可能有人会说，发送给谁可以在Message类里面通过一个属性来定义啊。但是Wait()方法没有说明接受方是谁，服务器端依然不知道哪些消息应该让你接收。

因此，我们引入Channel的概念，Channel使用其名称来标识，相同名称的就必然是同一个Channel。在发送与接受时，通过名称指定要发送到哪个Channel，这样问题就解决了。此时，函数签名修改如下：

public void Send(string channelName, Message message);
public Message Wait(string channelName);

可靠的消息队列

想象一个可能发生的情况，服务器端向你发送一个消息，你没有成功接收，但是服务器端认为发送了就成功了，消息从队列删除了，然后这个消息就永久丢失掉了。可能有人会强调TCP多么可靠，服务器端发送的消息如果在TCP的层面发生问题了，肯定会引发Socket级别的Exception，这个Exception冒泡上来，服务器端就能截获，从而得知发送失败，然后先不删除队首消息。可是别忘了，中间是可能存在代理的，如果代理成功把消息收回去了，可是代理发送到客户端这一步失败了，服务器端就不一定会发生异常了。

因此，我们需要制定一种策略，来确保下行消息总能发送到客户端。在这里，我们选择了引入逐个ACK的机制，来确认消息的接收。也就是说，服务器端发送给客户端的消息带有一个序号，在客户端收到消息后就将该序号发回给服务器端，已确认它受到了该消息。这时候，函数签名更改如下：

public int Send(string channelName, Message message);
public Message Wait(string channelName, int sequence);

我们使用Wait()接收到的Message中，应该有一个Sequence的属性，标记它的序号。然后，再我们执行下一次Wait()时就将该序号加1的值通过sequence参数传递回去，让服务器知道我们期望下一条消息的编号是这个。例如我们收到Message，其Sequence属性为836，那么下一次调用Wait()的时候就传给服务器837。服务器端此时应该保留了编号为836的Message在对首，如果客户端继续请求836号消息，证明它上次没收到，这次仍然发送836号消息给它；如果客户端请求837号消息，证明它成功收到836号消息的，这次就发送837号消息给它。

如果都不是，那该怎么办？那意味着，这是一个错误的请求，甚至可能是攻击请求，因为正常情况下不应该出现这样的请求的，服务器端可以考虑抛个无关紧要的Exception（不要告诉攻击者你知道他在攻击了），甚至直接给个400 （bad request）的响应代号。

与Wait()类似的，Send()也可以加入ACK机制，只需要将返回类型从void改为int就可以了，这个值就专门用于传递消息编号，实现方式和Wait()是一样的，不过Send()是由客户端保存待发送消息的队列。

小结

到此为止。我们的Web Service就写好了。这就写好了？只有签名没有函数体？是的，复杂的工作留给model去做，Web Service在这里只是相当于一个view，用于将model的接口暴露出来。

在下一次的文章中，我们将开始讨论如何实现服务器端的消息传递机制。如果你对本文章系列感兴趣的话，欢迎订阅我的blog：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

用一个对程序员来说比较友善的比喻来说，以面向过程的方式来写一大堆函数，然后再分别塞到几个类里面，这就是Windows了。而Mac是真正的面向对象思想下设计的。

在Windows当中，我们貌似在操作一个“文档”、一段“文本”、一张“图片”，但实际上我们都不是在操作对象本身，而是类似于在操作handle——你不知道对象在哪里，你不能直接传递或操作对象，你只能借助仅有的API对handle进行操作，所有能对handle进行的操作都由API限制了。例如即使你在操作的是一张“图片”，你也很清楚那是一个存放为文件的图片，或者暂存在剪贴板的图片，总之你必须清楚handle在哪，否则你就算看到了那张图片也无法操作——图片在网站上，你先另存或者复制到剪贴板吧。

这种体验不就完全是面向过程的映射？每一个操作相当于调用一个或几个API。Windows发展了那么久，在人机交互方面还是脱离不了对DOS的简单封装。在这方面，Windows从前落后于Mac，现在还是这样。Mac虽然不能达到最理想的面向对象操作方式，但至少系统本身提供的体验要比Windows好，同时主流软件也比Windows的主流软件在体验上要好一个等次。

例如Skitch这个轻量级的图片处理软件，你可以抓起正在编辑的图片扔到桌面上，这就自动另存为一个图片文件了。文件与内存中的图片数据对用户来说已经无缝连接起来了。

再举一个例子，在Windows我们都知道回收站是个很好的比喻，不用的文件当然扔那里面。不过说真的，你多少次把文件扔里面了？你用得更多的是delete按钮，对吧？这是显然的，因为Windows用户习惯最大化窗口，这当然就把回收站遮住了，傻瓜才会选择在窗口里拖动文件的同时回到桌面接着再把文件扔到回收站里。Mac的回收站叫做废纸瘘，它出现在Dock上，Dock类似于Windows的任务栏，永远不会消失，就算自动隐藏也可以在鼠标靠近后自动跳出来，因此你永远可以把你看到的不想要的东西拖到废纸瘘上面去。

这也说明了一个问题，Microsoft这样去仿造Apple发明的交互方式是没用的，因为一点点的差异就可能导致可用性完全不同。Windows Mobile 7泄露的文档中，透露了Windows Mobile 7将可能有一些类似iPhone + Wiimote的功能，例如用手指拨动CD封面从而跳到下一张或上一张CD，甚至晃动手机从而跳到随机抽选的一张CD，这样的交互到底是否好用，真的很难说。

最后，无论你在开发Windows应用还是Web应用，我都建议你去弄个Mac来用一段时间吧，不要给一直以来Windows及Windows主流应用程序的交互设计方式禁锢了你的思路，你应该看一点新鲜点的东西。在以前，我认为Scriptaculous的拖放库完全是多余的，真该好像Atlas转变为ASP.NET AJAX时那样把拖放库丢一边，但在使用Mac之后，我才真正觉得在Web应用中推广拖放操作是非常有意义的。

Update: 这篇文章只是讨论交互，关于Win vs Mac的问 题，可以参考这篇文章：我 为什么偏爱苹果电脑和Mac OS X，里面强调了Mac设计的哲学──“简单”。

样式

我们继续说iUI这个框架。这个框架所做的事情，就是提供iPhone Friendly的交互方式与样式。为了简单起见，我们先来说说样式方面，iUI提供的不仅仅是一个CSS文件，基于这个CSS文件你所创建的页面能够符合iPhone的人机界面指引，并且看起来的效果贴近iPhone原生的应用程序，从而降低用户学习门槛，避免你自己设计的Web应用对iPhone操作不友善（例如按钮不够大，手指难以点击）。

交互

至于交互方面，iUI提供一个基于page的换页导航机制。这里所说的page不是一个Web页面，而是一个<body />内的顶级DOM元素，每一个这样的DOM元素都可以作为一个page，同一时间上仅显示一个page。页面上的所有链接，要么导致page转跳，要么导致整个页面转跳。这种转跳有如下几种情况。

转跳

如果链接的href指向的是一个锚点，例如#somePage，那么iUI就会在页面中寻找id="somePage"的page对象，然后进行转跳。

如果链接的href指向的是站内地址，例如/somePage.html，那么iUI就会使用AJAX的方法加载/somePage.html的内容并追加到<body />内，注意，/somePage.html必然是一个文档片段而不可能是完整的XHTML文档，否则把<html />追加到<body />下就是错误的了。追加的内容内可以有多个page，如果其中一个有selected="true"的属性，那么接下来将显示该page，否则显示追加内容中的第一个page。

最后一种情况是指向站内地址，但是有target="_replace"属性。iUI在看到target="_replace"属性后，就会知道该<a />所在的page内直属元素要被删除，并且替换为目标页面的内容。在这里用CSS来解释一下所谓的直属元素，body > ul#somePage > li > a[target="_replace"]，这里<li />就是<ul id="somePage />的直属元素了。这种转跳通常用于曾亮加载，例如iPhone内置的Mail打开邮箱后自动加载50封邮件，点击more之后再加载50封，Web界面上就可以通过这种方式实现——一个<ul />内包含51个<li />，前面50个对应50封邮件，最后一个<li />包含<a target="_replace" />的more链接，目标页面就是下50封邮件的<li />。

在转跳的时候，iUI提供了一种很好看的效果，你能够看到当前page从屏幕左边移出去，新的page从屏幕右边移进来，好像PowerPoint的某种幻灯片切换动画那样。如果添加了axis="y"属性，page还能够子底向下滚动。

历史记录

AJAX式的页内内容更新不是不好，问题就在于浏览器无法自动保存历史记录，导致前进后退按钮实效。iUI已经解决了这个问题，上述3种转跳中的前两种iUI都会自动创建新的hash以便创建历史记录，hash默认就是#_pageId的形式，如果当前显示的page没有id，那么hash就按照增量自动分配id。

在拥有历史记录之后，用户就可以通过浏览器的后退按钮向前翻页了，此时相当于加载前面的page，iUI知道这是一个后退操作，就会提供反向的滚动效果（自左向右或自上向下）。

如果我访问页面的顺序是A > B > C > D > B，那么历史记录会如何呢？历史记录会变成A > C > D > B，也就是说第一次访问B时B从历史记录中删除并重新添加到最前的位置了。

演示

说了那么多，我们来看看iUI的实战效果吧！又是Facebook或者Digg的iPhone版？不是，我们来看看自己利用iUI开发一个小应用的效果以及成本如何。就在上个周末，我花了不到20小时做了个名为iBaidu的小东西，自动抓取Baidu的搜索结果与排行榜并以iPhone friendly的方式显示出来。以下是发布到YouTube的演示视频：

服务器端使用的技术是Ruby on Rails以及ASP.NET。为什么需要ASP.NET？这是一个很郁闷的问题，因为Baidu是基于GBK的，而RoR的编码转换能力其若无比，我懒得花时间去寻找适合的转码库，因此直接拿了ASP.NET来做抓去代理，抓取的时候顺便做一下编码转换。如果不是编码问题，那么只需要RoR就能轻松完成任务。

小结

在这篇文章中，我们已经看到了如果使用RoR搭配Prototype，不好意思，iUI才对，要设计一个iPhone friendly的Web应用程序是多么地容易，开发过程也相当敏捷。如果你喜欢iPhone开发系列的文章，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

1. 根据PC World的统计，2007年IE7与FF的增长相当，这意味着从IE6转分别转到IE7与FF的比例为50/50。
2. Mac效果般的Lightbox效果 - 来自CandyBar软件首页（留意页面底部的软件截图）
3. 纯粹用C#编写的SharpOS发布了第一个里程碑版本 - 0.0.1
4. NeoSmart Technologies报道，Microsoft将使用Silverlight重新设计其官方网站
5. 国内的Silverlight网站 - 百度MP3
6. 在Windows Mobile手机上使用Windows Vista的Side Show功能！
7. Design - 一个很cool的纯JavaScript的Web页面设计辅助工具
8. 使用来自webkit团队的Sunspider测试各种浏览器的JavaScript引擎性能
9. HTML 5 Preview - XHTML 2.0还有发展前途吗？

直接下载地址：http://www.podtrac.com/pts/redirect.mp3?http://downloads.cnblogs.com/netcast/mvp-on-dot-net-1-40bit.mp3

Update: 本期已将采样率改为22.050kHz，使用Google Reader订阅的用户应该能够直接使用Web上的播放控件正常播放而不会出现快进的问题。如果大家在播放上还碰到什么问题了，请留言告诉我们，谢谢。

首先，请打开iTunes。由于我是在Mac上使用iTunes，所以如果你是PC用户，您所看到的界面细节会和下面的截图略有不同。如果您还没有iTunes，但希望在iPod（包括iPhone）上收听播客，那么请先下载iTunes。

然后请点击“高级”菜单下的“订购 Podcast...”。

输入MVP on dot NET的RSS地址。

之后您可以在“Podcast”视图看到MVP on dot NET已被添加到列表上，并且正在更新。

同时，您也可以在“下载”视图看到节目已经在下载中了。请等候下载的完成。

下载完成后，您可以直接返回“Podcast”视图，双击MVP on dot NET以播放节目。

如果您希望把节目同步到iPod（包括iPhone）上，此时请把iPod连接到电脑上，并且进入iPod对应视图，并翻到“Podcast”页。请选择同步“所有 podcast”，或在“所选 podcast”中钩选MVP on dot NET，并点击“应用”按钮以便与iTunes与您的iPod重新同步。

1. 8 + 2 = ☺ - IE8通过了Acid2测试
2. gOS发布，日后我们仅仅使用Web也能生存下去吗？客户端过剩的CPU资源用来干什么？
3. 文档都放上线！我们用Adobe SHARE还是Office Live Workspace？
4. Linq to SQL、ADO.NET Entity Framewor，以及关于ORM的更多……
5. ASP.NET MVC Framework发布，与ASP.NET WebForm对比又如何？
6. iPhone Web App开发 - 有点点像WPF噢！

P.S.podcast订阅的图片教程稍后发布。

直接下载地址：http://www.podtrac.com/pts/redirect.mp3?http://downloads.cnblogs.com/netcast/mvp-on-dot-net-0-40bit.mp3

首先，我介绍一下podcast为什么叫做podcast。过往，我们能够订阅feed，从而好像收取email那样收取网上的信息。例如，我订阅了ABC World New，设置了我的电脑每天早上7:00自动开机并打开feed reader下载feed，那么当我准备好早餐后，我就可以一边享受早餐，一边阅读新闻了，这和传统的喝早茶看早报没什么区别。

然而，ABC World New的新文章，附带了一个新闻视频片段，以龟速的下载速度，我可不能等下载完看完再去上班，因此我希望我的feed reader能够识别视频音频片段并且自动下载。RSS 2.0的<enclosure />标签是第一个出来把问题解决掉的，只要把这一个feed entry相关的文件放到<enclosure />链接内，feed reader就应该懂得自动去下载。之后，我把电脑自动开机时间改为早上5:00，预留两个小时，什么龟速也能把几分钟的视频片段拉下来吧。然后，我还是边喝着早茶（或者咖啡），边看新闻，不过这次不用读文字了，视频里面有人说给我听。

随后，iPod和iTunes又把这个应用提升到了一个全新的层次。如果你使用iTunes订阅新闻，起床后我只需要按一下同步按钮，视频音频都传到iPod上面去了，然后专心吃我的早餐，出门口时记得把iPod从同步底座上拔下来带走就是了。我在地铁或公交上有足够多的时间，把iPod拿出来看看或者听听头条新闻的时间是绝对是有的，甚至还能听听有声电子书。

由于这个功能在iTunes与iPod上就被命名为podcast，而且iPod在美国相当普及，所以大家就都叫podcast了。不过，Microsoft貌似避忌所有pod字开头的东西，以保持和Apple之间的距离，所以就坚持把同样的东西叫做netcast，这样显得中立一些。不过Zune2里面的功能菜单就写着podcast，看来负责整理Zune2菜单字符串资源的人有被炒鱿鱼的危险了……另外，国内有一些名为播客的东西其实不是播客，土豆一开始就给人如此批评了——不支持RSS订阅，也不允许下载，更别说放到iPod上了，这也想带上播客的头衔？

好吧，对podcast的介绍到此结束，稍后MVP博客的第0集将会发布到netcast.cnblogs.com，并且我还会另外发贴详细说明如何订阅podcast。敬请期待！

Update: MVP on dot NET已上线，请通过netcast.cnblogs.com访问。

Update again: 教程已发布：如何订阅MVP on dot NET（或其它播客） - iTunes版

點解成個博客園都喺度講“我嘅2007”，仲要大部分都差唔多……好，咁我就寫啲唔同啲嘅嘢，例如話……人脈啦。我要話，技術唔係最重要嘅，亦都唔係管理，而係人脈。

2007年，個人發展上嘅兩個重要事件，一係攞咗微軟嘅MVP，二係賣咗畀B家，兩樣都係要靠人脈嘅（要多謝嘅人自然非常多）。亦就係話，第一係你要認識人際網絡中充當關鍵節點嘅嗰個人，第二係嗰個人要睇得起你。簡單嚟講，如果你有能力，無論係技術定係管理，首先你要識得渠道（或者叫中間商），其次佢要覺得你超值，咁你先有機會賣得出去，而且賣個好價錢。喺冇渠道嘅前提下，大家都明白廠家直接向客戶銷售嘅成本有幾高，你一個人能夠聯係嘅買家數量就非常有限嘞。

如果一開始，我唔係喺Dflying同埋Jeffrey嘅blog上評論，佢哋亦唔會嚟睇我個blog，亦就唔會有佢哋鼓勵我將文章發到首頁，咁嘅話，可能dudu亦就唔會知道我嘅存在，咁dudu推薦我去攞MVP就唔知從何談起嘞。所以，攞MVP呢件事係一定要多謝Dflying、Jeffrey同埋dudu嘅。當然，仲要多謝所有嘅讀者，特別係有留言嘅嗰啲，因爲有留言自然激發思考。

然而，攞MVP並唔係終點，只係另一個起點嗟。之後，有中國嘅MVP峰會，Bean介紹我識咗唔少微軟嘅人同埋其他MVP，咁先有后嚟嘅一啲合作項目，例如話netcast啦。所以話，認人先有得做，因爲好多嘢係唔熟唔做嘅。係呢度，我要多謝Bean、Jeffrey、dudu，特別係dudu，完全唔講求回報咁支持我哋做netcast。

另外一件事，就係關於賣身㗎嘞，我嘅意思係搵工。寫“我嘅2007”嘅人入邊，咁多人寫自己今年畢業搵工如何如何，我又點可以唔寫啊。搵實習嘅事就唔講嘞，全職申咗好幾間有噃咁上吓大嘅IT公司，包括BGM，其中B家同G家都搵過人做推薦（多謝布丁同埋Junyu）。B家係最早畀offer嘅，所以就賣咗畀B家算嘞，G家同M家嘅申請算係“無疾而終”（冇拒信，hold咗喺唔知邊個環節度）。但係，我想講嘅唔係點樣賣畀大公司囉，而係推薦有幾重要囉。

如果冇人推薦，你份簡歷好可能石沉大海都冇人話畀你知，而且石沉大海嘅概率仲唔細添。但係，有人推薦嘅話，你就好清楚個流程嘞，其中每個環節對你評價如何亦都透明一啲，咁你就可以不斷調整自己嘞。推薦人熟悉公司内各個職位嘅差別嘅話，對你選擇職位亦有幫助，好似高考選專業咁蠱蠱吓就唔好啦。（如果你高考嗰時已經識得搵師兄問清楚個專業係讀咩嘅，咁你可以跳過呢段嘞。）

當然，最重要嘅係推薦你嘅嗰個人真係認爲你值得擁有呢個職位，而唔係應付你。佢有幾積極幫你，就反映咗呢一點，亦影響住佢份推薦嘅效力。唔好以爲佢幫你喺ERP或者HR之類嘅系統填吓就掂，佢越落力幫你跟呢件事，幫你同你嘅面試官溝通你嘅情況，你嘅成數就越大。如果你搵到個人，只係礙于人情而推薦你，根本唔覺得你將來成爲佢同事嘅話對佢對同公司都有好處，咁你得到嘅好處無非就係免筆試，對促進你同公司之間嘅互相了解一啲作用都冇。

免筆試……免筆試又有咩用呢？其實筆試過後離offer仲有十萬八千里咁遠。聼講G家喺美國本來就冇筆試，只係中國應屆畢業生實在太多嘞，咁就筆一筆，篩一篩。有時甚至亦就唔筆嘞，咁樣推薦唔推薦都係一面起步，你希望你嘅優勢更好咁傳達畀面試官知嘅話，除咗面試嘅時候表現要好啲，就靠推薦人嘅溝通嘞。

最後，通過一個故事結束本文。曾經，Mary總係好有激情咁同人講佢個仔同埋佢個仔間新公司，其中一個聽衆就係Unity Way嘅董事會成員：John Opel。五年之後，John Opel，亦就係IBM嘅董事長，要為IBM嘅機器搵一個操作系統。佢去咗邊度搵？去咗Washington嘅Redmond會見Mary個仔，即係Bill Gates。多謝同埋IBM嗰單生意，Bill Gates做咗首富。如果John Opel從嚟未聽講過佢個名嘅話，IBM絕對唔會派人去Redmond睇一間當時幾乎同Microsoft一樣默默無聞嘅公司。

无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进入Add是一个view切换，不过因为Add这个view的内容是固定的，因此一早就包含在页面里，不用AJAX请求直接加载就行了。另外一种情况，就是好像加载Browse那样，是需要AJAX把view请求过来才能加载的。除了切换view，我们还需要action，例如提交数据就一定需要action的。说到这里，感觉是不是和RoR或者类似框架扯上关系了？事实上，RoR，或者类似框架，确实很适合用来做iPhone Web Apps。

以客户端为中心的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。欢迎订阅本系列文章：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

<link media="only screen and (max-device-width: 480px)" href="small-device.css" type= "text/css" rel="stylesheet" />

Safari是支持media选择的，only screen声明该CSS仅用于屏幕显示（不用于打印），同时Safari还支持max-device-width这样的选项，限定屏幕宽度小于480的设备才采用该样式表，这就把iPhone与桌面浏览器划分开来了。

另一个做法是在服务器端就判断当前浏览器是否是iPhone上的Safari，从而选择返回哪个CSS文件，这可以通过user-agent进行判断，iPhone的如下：

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543 Safari/419.3

判断了浏览器之后，就可以开始针对Safari编写CSS了。Safari比较爽的一点是对CSS3的支持，设计PC端网页时总是要兼顾那个“后进”的IE，从而避免使用CSS3，或者需要确保IE在无视CSS3规则后仍然正确显示，现在不用为此而头痛啦，只要是Safari支持的就能用，针对一个浏览器设计就是比针对一堆浏览器设计要爽！

CSS3

接下来我们就列举一下Safari支持的CSS3属性吧：

边框

• -webkit-border-image - 让边框支持图片（iPhone上支持存在bug）
• -webkit-border-radius - 让边框支持远角
• -webkit-box-shadow - 让盒区域支持阴影（iPhone上不支持）

背景

• -webkit-background-origin / -webkit-background-clip - 控制背景的定位与剪裁
• -webkit-background-size - 控制背景的大小
• background - 多背景，如同单背景一样定义一个背景图片，多个图片定义之间用逗号分隔（未经测试）

色彩

• HSL - HSL色彩
• HSLA - 带Alpha通道的HSL色彩
• opacity - 透明度
• RGBA - 带Alpha通道的RGB色彩

文本特效

• text-shadow - 让文本支持阴影
• text-overflow - 控制文本溢出时的裁剪与视觉反馈
• word-wrap - 控制长单词换行

用户界面

• -webkit-box-sizing - 可以让盒模型变得基于边框而非内容
• resize - 让用户可以更改盒的大小（iPhone上不支持）
• outline - 设置盒的外边框

选择器

Safari支持大部分的CSS3选择器，你可以自己使用桌面端或iPhone上的Safari打开CSS Selectors Test进行测试，桌面端与iPhone上的Safari测试结果是一致的。Safari完全通过测试的CSS3选择器包括：

*, E, .class, #id, E F, E > F, E + F, E[attribute], :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支持对<input />元素比较高自由度的CSS定义，例如这样的：

实现所需的CSS属性上面已经列举了，所以不再详细说明，灵活运用就是了。值得注意的是，某些<input />的默认背景并非纯白色的，而是半透明的，这使得这些元素能够更好地和不同的背景颜色进行颜色混合。为了说明这一点，请先看白色背景下的示例：

然后再看看蓝色背景下的：

小结

CSS相关的话题也说完了，很简单是不是？大部分针对桌面浏览器进行符合Web Standards页面设计的设计师都能轻易掌握这部分内容，然而这只是实现设计的手段，到底如何设计一个界面，在iPhone上才算是拥有高度易用性的，这才是真正的问题。这个问题我们将在以后探讨，至少现在你能够将你自己的设计在iPhone上准确无误的实现出来了，那么我们下一步就进入JavaScript的讨论环节了。

本iPhone Friendly专题的订阅地址如下：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

• HTML 4.01
• XHTML 1.0
• CSS 2.1 以及部分 CSS 3
• JavaScript (ES3)
• DOM (Level 2)
• AJAX (XMLHttpRequest)

熟悉这些标准并且平常也坚持Web Standards实践的朋友估计要笑出来了——就这些吗？我们天天在用啊，还有必要专门写文章来说明吗？事实上，Safari之前作为一款无PC版的浏览器，一直用户数量就不高，因此对它的研究也就不多，然而Safari其实有不少自己的扩展，因此还是很值得研究的。既然我们是针对iPhone设置，其实就是针对Safari设计，无需考虑兼容其它浏览器，这时候为什么不好好利用这些扩展增强自己的应用程序的可用性呢？

好吧，不说废话了，进入Safari对XHTML支持的介绍吧！

链接

iPhone对一下这样一些链接有特殊支持：

邮件

传统的mailto:地址iPhone将能自动使用内含的邮件程序处理，直接进入编写邮件的界面。完整的mailto:格式请参考RFC 2368。

电话

iPhone上的Safari会自动对看起来像是电话号码的数字串（包括已经加入连字符或括号格式化过的）添加电话链接，点击之后会询问用户是否想要拨打该号码。如果你不希望开启这个自动识别，可以将它关闭：

<meta name="format-detection" content="telephone=no" />

如果你关闭自动识别后，又希望某些电话号码能够链接到iPhone的拨号功能，那么可以通过这样来声明电话链接：

<a href="tel:13800138000">13800138000</a>

Google Maps

Google Maps的地图链接会自动调用内置的Google Maps客户端软件打开，而非在浏览器内浏览。链接可以是一个地点查询：

<a href="http://maps.google.com/maps?q=cupertino">Cupertino</a>

也可以是一个路线查询：

<a href="http://maps.google.com/maps?daddr=San+Francisco,+CA&saddr=cupertino">Directions</a>

YouTube

如果链接是指向YouTube视频地址的，将会自动调用内置的YouTube客户端打开播放。能够识别的YouTube地址格式为：

http://www.youtube.com/watch?v=<video identifier>

http://www.youtube.com/v/<video identifier>

其中<video identifier>替换为视频的id。

图片

由于用户浏览时有可能使用Wi-Fi，也有可能使用EDGE(GPRS)，因此你必须优化你的图片以确保即使是在使用EDGE访问你的网站的用户也能流畅的打开页面。因此你必须优化页面上的图片，尽量减少它们占用的传输带宽。另外Safari本身还对图片有如下的限制：

• GIF（包括GIF动画）、PNG与TIFF解压后的体积小于2m。意思是，原图的长度乘以宽度再乘以每一个像素的位数，得出来的大小要小于2m。
• JPEG解压后最大的体积是32m。解压体积大于2m的JPG会被进行二次抽样，最终显示给用户的是二次抽样后的结果。这使得Safari能够显示数码相机直接拍摄出来的照片，但显示时实际上是降低了精度的，以提高程序的执行效率。

为了尽量提高效率，例如你要将100*100的图片显示为10*10，就要在服务器端执行压缩操作，而不要直接用10*10的<img />来引用100*100的原始图片。

表单

text, password, textarea

在设计文本框的时候，必须记住用户点击后会出现软键盘，这时候可视区域就减少了：

另外在文本框中输入时，iPhone提供了自动大写与自动更正两项功能。自动大写的意思是，在输入开始的时候，以及在一个句号并空一个格后，自动会启用shift，输入一个字母后该shift自动消失。自动修正的意思是，iPhone会自动根据词库，包括自带的以及从你过往输入分析而来的，来对你的输入进行自动更正。我们都知道用手指点击那么小一个软键盘很容易误按旁边的键，这时候你可以不用忙于修正，只要iPhone提示的自动修正的词正是你想要的，你就可以按空格然后输入下一个词，iPhone会自动修正前面那个词。

要关闭这两项功能，可以通过autocapitalize与autocorrect这两个选项：

<input type="text" autocapitalize="off" autocorrect="off" />

select

必须留意到的是，iPhone上的<select />以不同的方式显示，以便于用户操作：

upload

iPhone不支持任何的文件上传下载，因此<input type="upload" />总是会显示出来，并且是……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个子窗口（同时浏览的页面）。

小结

XHTML部分到这里就讲完了，可以看出iPhone对XHTML的支持与桌面端的Safari是类似的，只是加入了更多扩展功能而已。下一期将开始讲CSS，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

首先要说的就是viewport，也就是可视区域。对于桌面浏览器，我们都很清楚viewport是什么，就是出去了所有工具栏、状态栏、滚动条等等之后用于看网页的区域，这是真正有效的区域。（无论你屏幕多大，如果你装足够多的toolbar，你的viewport最终也会消失掉。）在桌面浏览器中，viewport的大小是与浏览器窗口大小直接相关的，窗口大了viewport自然就大，同时随着viewport的改变，页面布局可能也跟着变。例如width: 100%的页面宽度就总是和viewport宽度一致。

然而iPhone的Safari不是这样理解viewport的，它基于viewport呈现页面，然后用户缩放页面后viewport保持不变，仅仅是页面内容按比例缩放了。举个例子，在不设置viewport的情况下，默认viewport为宽度980（单位是像素），这时候页面的呈现出来的布局和在桌面短viewport宽度为980时呈现的结果一致，然而因为iPhone屏幕宽度为320，因此按比例缩小了。因此，一张宽度为320的图片，在默认viewport下会这样显示：

可以看到，图片按比例缩小了，这对于传统Web页面直接在iPhone上面显示来说是很好的事情，因为如果传统Web页面在980宽度的桌面浏览器viewport中显示正常的话，iPhone上显示也绝对正常。然而这对于Web应用程序来说则不是好事，因为我们需要按照980宽度来设计将来会以320宽度显示的页面，一个应该显示为320*80的元素，必须设计为980*245，这多麻烦！

因此我们需要改变viewport，让它变成这样：

实际上应该怎么做呢？我们有几个选择，因此先让我们看看到底我们能够设置哪些属性吧。我们可以操作的属性有4个：

• width - viewport的宽度
• height - viewport的高度
• initial-scale - 初始的缩放比例
• minimum-scale - 允许用户缩放到的最小比例
• maximum-scale - 允许用户缩放到的最大比例
• user-scalable - 用户是否可以手动缩放

这6个属性，我们可以设置其中的一个或者多个，iPhone会根据你设置的属性自动推算其他属性值，而非直接采用默认值。这点很重要，在完全不设置的时候有默认viewport，在你设置一个属性后其它值是自动推算出来的，不再是默认的。

如果你把initial-scale=1，那么width和height在竖屏时自动为320*356（不是320*480因为地址栏等都占据空间），横屏时自动为480*208。

类似地，如果你仅仅设置了width，就会自动推算出initial-scale以及height。例如你设置了width=320，竖屏时initial-scale就是1，横屏时则变成1.5了。

那么到底这些设置如何让Safari知道？其实很简单，就一个meta，形如：

<meta id="viewport" name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>

在设置了initial-scale=1之后，我们终于可以以1:1的比例进行页面设计了。下一步我们就可以正式进入页面布局的细节设计了，如果你想继续关注iPhone开发话题的话，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

好吧，在我们正是进入布局的讨论之前，先来赏析一下已有的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) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3

使用Firefox的User Agent Switcher修改一下user-agent就行了，然后你就能看到iPhone上看到的GMail了。仍然和上面的网站一样，可点击区域是一大个宽度为100%的块区。

小结

实际上，设计iPhone friendly的界面，在CSS的层面上来说一点也不难，甚至可以说是非常简单，因为基本上就是宽度为100%的块区，少数时候要用到按百分比划分的块区，但实际上我们也应该避免这种情况。为什么呢？别忘记了，iPhone的用户是没有鼠标的，他们必须通过手指来操作页面上的一切，因此可点击区域必须尽量大。

既然他们看不到鼠标指针，你也就不用考虑可点击区域必须是链接或者cursor: pointer，因为用户无法通过鼠标指针的改变来判断一个区域是否能点击。然而这同时也就引入了另一个问题，如何让用户了解一个区域能否点击呢？这时候你必须给出明确的视觉暗示，例如看起来是链接的文本，蓝色的文本有无下划线通常都挺诱惑人去点，这方面Facebook是一个例子。另一种做法是让界面看起来是菜单式的，好像AppsMarker和Newsgator那样，菜单右侧的符号让人挺熟悉不是吗？只要我点击这个菜单项，就会展开下一级菜单。最后一种做法就是基于用户已经熟悉的独创暗示来提示用户，习惯使用GMail的用户一看到邮件标题那个大大的蓝色区域，就知道点击是打开邮件，这是不需要任何指引的，最坏的情况下，用户不知道点击什么还是会点击邮件标题，之后他也就会用了。

到此为止，就已经把设计iPhone friendly应用界面的一些布局因素解释清楚了，我们下一步就要进入交互的环节，让我们的应用程序真正执行起来，并且是在客户端JavaScript环境中执行起来。如果你想继续关注本话题的话，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

因此，使用fluid layout时，要加上min-width属性，加在哪个具体元素上看具体情况而言，但是凡是你不希望被缩得太窄的列，你都应该加上min-width属性。这时候，Opera Mini会发现无法压缩页面宽度，就只能显示横向滚动了，不过这看起来至少会好一些。

在Silverlight发布的时候，大多数Flash拥有的功能Silverlight都做到了（嵌入字体除外），当然也包括上述的视频与文档支持。只不过，视频支持变成了WMV，因此也就直接支持DRM了，而文档支持则变成了XPS。这个XPS支持能做什么？我们还是先来看看Adobe SHARE的示例文档吧，这个文档其实就是一个PDF，然而你无需安装任何客户端的PDF阅读软件，也不需要为浏览器加装任何PDF插件，就能够直接在浏览器中以Flash的形式阅读。

考虑一下，以往Sharepoint里面的文档要在浏览器中直接以只读方式打开阅读，可以转换为HTML版本再显示，Sharepoint内置了这一功能，然而这转换肯定会存在一定的失真。现在可以考虑转换为XPS了，然后使用Silverlight作为阅读器就可以了，和HTML版本一样不需要客户端安装有Office，然而用户体验却比HTML版