『听风且吟』技术版

Windows Phone Background Agent杂谈

Windie Chai — Thu, 17 May 2012 23:40:56 +0800

Windows Phone从Mango开始开放了Background Agent，使得我们可以实现后台运行的任务。出于兴趣，我在第一时间使用这套API开发了一个应用——Human Calendar。随着时间的推移、功能的增加，Human Calendar越来越依赖于Background Agent，也逐渐遇到了更多让人头疼的问题。经过许多摸索和撞墙后，绝大多数问题都解决了，Human Calendar目前运行良好。所以我就用这篇文章来记录一下开发Background Agent过程中的一些事情，但我不会完整地介绍一个Background Agent的开发过程，你大可将本文看成一篇“吐槽”文。

限制

在开发Background Agent之前，必须要考虑到它的限制，因为这些限制极其严格，对于定期代理（PeriodicTask）来说，限制了：

有一些API不能使用，并不是说你不调用就可以了，只要你在同一个程序集里使用了这些API，就不会通过验证；
内存占用不能超过6MB，否则立即终止；
生效时间最长只有14天，过期后就需要重新计划。Human Calendar和一些天气应用都属于那种只要有Tile就可以一辈子不去打开的应用，但是由于这个限制，我还得想办法提醒用户：“亲，记住两周内重新打开应用一次哦，不然Tile就没法更新了哦”；
连续两次崩溃之后会被禁用，做好准备捕捉一切异常吧；
每30分钟运行一次，每次最多执行25秒，超时后立即终止，所以如果在后台任务里下载文件的话，要特别注意文件的大小；
节电模式会阻止执行；
手机中的后台任务数量是有上限的，最少为6个，当手机中已启用的后台任务达到上限后，就无法再启用新的后台任务了，这时候你还得提醒用户：“亲，到这里的这里的这里看看后台任务是不是超过6个了，是的话，挑一个禁用了，然后回来再试试”……

资源密集型代理

除了定期代理之外，Windows Phone还支持另外一种后台任务——资源密集型代理（ResourceIntensiveTask），不过我们通常都不会用到它，因为它简直就是个杯具，它的限制不仅多，而且都很变态，除了拥有定期代理的前4挑限制之外，它还限制了：

电池电量不得低于90%，而且需要连接外部电源；
需要非手机网络连接，连着WIFI或PC吧，亲；
屏幕必须锁定，也不能接打电话，否则不执行；
最多执行10分钟，超时立即终止；

想像一下，假如有个应用使用了资源密集型代理，它该怎么向用户解释？

“亲，想要使用我们的XXX功能，您得先充满电，再连着WIFI，锁住屏幕，安静的等待10分钟，期间千万别拔开电源线，也别解锁屏幕和接打电话哦。”

用户“哦”了一声，然后随手卸载了应用。

调试

可以使用ScheduledActionService.LaunchForTest方法来随时随地执行后台任务，籍此来进行调试。此方法在Debug和Release模式下均可执行，但在用户下载的应用中是无效的，所以不要妄想用它来突破Background Agent的时间限制。

虽然在Visual Studio中进行调试非常方便，但不可过于相信调试器。简单来说，附加了调试器的Background Agent就像被提升了权限一样，可以执行一些正常状态下不能执行的任务，譬如可以调用BitmapImage.SetSource方法，而在没有附加调试器的后台任务中调用这个方法是会抛出异常的（可以使用WriteableBitmapImage来代替）。

所以很有必要在不附加调试器的情况下检查Background Agent的运行情况。

这时就可以利用ScheduledActionService.LaunchForTest来将Background Agent安排在一段时间后执行，然后退出应用，关闭调试器（早期的SDK会在退出应用时自动关闭调试器），观察效果。

假如发现后台任务出现了问题，该怎么定位问题？有两种特别原始的方法：第一种是在执行后台任务的的同时写日志；第二种是Toast通知（我想起了史前程序员使用alert调试JavaScript的故事）。

由于第4条限制，所以很有必要勤快的使用try-catch，但比较不幸的是并不是所有异常都会被捕捉到，所有因为超出限制而导致的终止行为都无法捕捉到，而且在某些情况下，一些看起来很正常的异常也会跳过catch直接杀死后台任务。

所以日志和Toast通知就相当重要，你可以根据最后一条消息的位置来推断代码执行到了何处，从而找到出问题的代码，然后再研究为什么会出问题。

这里还有一个插曲，在早期的SDK中有这样一个问题，如果附加了调试器，Background Agent就永远不会执行，于是我眼睁睁的盯着模拟器浪费了一个大好的下午，人生苦短啊，还好这个问题现在已经修复了。

检测时间和内存占用

Background Agent在时间上有许多限制，对于第3条限制，我们别无他法，因为添加后台任务的API属于受限API，不能在Background Agent中调用，所以只能提醒用户每14天内至少要打开一次应用，然后在每次打开应用的时候自动重新启用后台任务（这样它就又能活14天了）。

对于第2条和第5条限制，我们只能想办法控制执行时间，尽量把任务细化成小任务，让每个小任务都有自己的唯一标识和完成状态，并且可以被持久化，然后用递归或者遍历的方式依次执行这些小任务，每次执行时都要检查当前已执行的时间和已占用的内存，如果发现接近某个临界值，就NotifyComplete，然后期待半小时后继续。

临界值可以根据第2条和第5条限制以及小任务们的平均执行时间和内存占用来设定，留出一定的空档以防不测。

此外，如果应用中使用了本地数据库，最好不要在后台任务中初始化甚至使用，它会带来极大的内存消耗。就拿Human Calendar来说，用IsolatedStorageSettings取代了本地数据库之后，内存竟然节省了一半（而且这个数据库还无比简单，只有一张表、五个列和七八条数据）。

资源

应用：Human Calendar，我承认这个应用很宅，不过还是欢迎捧场……

MSDN：《Windows Phone的后台代理》，写本文时候发现这篇文章在年初还更新了一次，增加了不少内容，MSDN上的Windows Phone文章更新速度还是蛮快的。

最后吐槽一次，MSDN上把Reference翻译成“书评”这种事情是哪个实习生干的？

Linq to SharePoint，看上去很美

Windie Chai — Wed, 11 Apr 2012 14:32:44 +0800

Linq to SharePoint是SharePoint 2010引入的一组新API，在这之前，如果我们想要按照条件过滤SharePoint列表中的数据，只能通过CAML。

但使用CAML并不是件令人身心愉悦的事情，至少我是这么认为的。我觉得在代码中嵌入一块冗长的XML字符串非常破坏美感，我尤其喜欢强类型，所以一直很难接受SPListItem用字符串作为键值去获取Field值的方式，更别提这些值都是Object类型，还得再经过一次转换。

所以我比较喜欢将SPListItem转换成实体类来使用，只不过一直以来的做法都是自己写实体类和转换方法。而Linq to SharePoint则可以自动将列表映射为实体类，并且可以使用Linq语句来进行查询，看上去很美！

那么Linq to SharePoint能不能帮我彻底拜托CAML呢，趁着重构代码的机会研究了一下，在这里简单总结一下。

前面说过Linq to SharePoint可以自动生成列表的实体类，这是通过一个叫做SPMetal的工具来实现的，具体的用法请查阅这里。

SPMetal会根据实际的列名来生成实体类中的属性名，所以如果你的列名是中文的话（譬如你安装了中文版SharePoint），你会得到一份非常诡异且冗长的代码文件。

当然，如果你能接受中英文混排的代码的话，这倒也不是什么问题。

SPMetal生成的属性大多是下面这个样子的：

[ColumnAttribute(Name = "Body", Storage = "_body", FieldType = "Note")]
public string Body
{
  get
  {
    return this._body;
  }
  set
  {
    if ((value != this._body))
    {
       this.OnPropertyChanging("Body", this._body);
       this._body = value;
       this.OnPropertyChanged("Body");
    }
  }
}
protected string _body;

Body属性被附加了一个ColumnAttribute，它的作用是将属性和SharePoint中的某一列关联起来。在它的命名参数中，Name表示的就是SharePoint中的列名，FieldType指列的类型，Storage表示的是实体类中用来存放列值的变量，可以看到这里为它指定的是一个变量，而不是Body属性，也就是说，在初始化这一实体的时候，该列的值会直接赋给_body变量，而不经过Body属性。那么Body属性的set访问器又是用来干什么的呢？实际上它的作用只是为了提供一种更改列值的机制，这一点从它复杂的内部流程也能看出端倪。

如果你只是为了查询方便，并不需要修改和提交数据的话，完全可以使用下面的只读版本：

[Column(Name = "Body", Storage = "_body", FieldType = "Note")]
public string Body
{
  get
  {
    return this._body;
  }
}
protected string _body;

此外，如果列表的包含一些设置为可空值的列的话，它们会被映射成一个Nullable<T>类型，如下所示：

[ColumnAttribute(Name="RatingCount", Storage="_ratingCount", FieldType="Number")]
public System.Nullable<double> RatingCount{
  get {
    return this._ratingCount;
  }
  set {
    if ((value != this._ratingCount)) {
      this.OnPropertyChanging("RatingCount", this._ratingCount);
      this._ratingCount= value;
      this.OnPropertyChanged("RatingCount");
    }
  }
}
private System.Nullable<double> _ratingCount;

虽然可以理解这么做的原因，但是却很难接受这种代码。尤其是在HTML中做绑定时，你不得不针对Nullable属性额外写一些代码来处理它的非空情况。

好在我们可以将属性本身改成非空的类型，然后在get访问器里根据情况返回真实的值或者默认值：

[Column(Name="RatingCount", Storage="_ratingCount", FieldType="Counter")]
public double RatingCount{
  get {
    return this._ratingCount ?? 0;
  }
}
private double? _ratingCount;

但要注意Storage指向的变量还得是Nullable类型，以保存列的真实的值（包括空值）；属性的类型虽然可以改为非空类型，但要注意类型一定要和对应的变量相同，因为ColumnAttribute会在初始化时检查属性的实际类型。我曾尝试写过下面这样的属性，结果只收获了一个异常：

[Column(Name="RatingCount", Storage="_ratingCount", FieldType="Counter")]
public int RatingCount{
  get {
    return this._id ? (int)this._id.Value : 0;
  }
}
private double? _ratingCount;

为什么想要这么做呢？因为我实在想不出投票总数为什么会是一个小数？

如果你刚巧需要使用Linq语句查询列表，而且查询条件刚巧也是一个包含可空值的列的话，就不能用上面提到的方法来修改属性的类型了，否则Linq to SharePoint将无法生成CAML，结果也是以异常告终。

如果想让可空值列的映射属性既能在Linq语句里作为条件，又能让调用者方便使用的话，只能像下面这样定义它们，对，是它们：

[ColumnAttribute(Name = "RatingCount", Storage = "_ratingCount", FieldType = "Number")]
public double? RatingCountField
{
  get { return _ratingCount; }
}
protected double? _ratingCount;
public int RatingCount { get { return this._ratingCount.HasValue ? (int)this._ratingCount.Value : 0; } }

平常使用int类型的RatingCount，在Lambda表达式里查询时使用double?类型的RatingCountField。

坦白说，我很讨厌这样的代码，两个含义相同的属性必然会让其他阅读者感到困惑。

此外，如果列是一个查阅项（譬如Author列），我们可以做到映射这个查阅项的完整字符串（譬如“12;#windstyle\chai”），或者查阅项的ID（譬如“12”），或者查阅项的值（譬如“windstyle\chai”），所做的仅仅是在ColumnAttribute里指定IsLookupId或IsLookupValue（如果要拿到完整字符串，则什么都别指定）：

[Column(Name = "Author", Storage = "_authorId", FieldType = "Text", IsLookupId = true)]
public int AuthorId
{
  get { return _authorId; }
}
protected int _authorId;

而且如果指定了IsLookupId，就可以在Linq语句中使用这一属性来做查询了。

以上提到的都是关于列与属性的映射，然而有一些列很难通过简单的映射变成属性，那就需要另外一种机制：自定义映射。

自定义映射需要实体类实现ICustomMapping接口，并实现它的三个成员方法MapFrom、MapTo和Resolve，我们这里只讨论只读实体类的情况，只需实现MapFrom即可：

[CustomMapping(Columns = new string[] { Attachments" })]
public override void MapFrom(object listItem)
{
  var item = listItem as Microsoft.SharePoint.SPListItem;
  this.IsRootPost = item["IsRootPost"].ToString();
  if (this.IsRootPost == "1")
    this.Url = item.Web.Url + "/" + item.Folder.Url;
  else
    this.Url = new Uri(new Uri(item.Web.Url), item.ParentList.DefaultDisplayFormUrl + "?id=" + item.ID).ToString();
}

MapFrom方法包含一个listItem参数，可以通过它来拿到SPListItem的列值，具体能拿到哪些列，需要在修饰MapFrom的CustomMappingAttribute中指定。

在使用Lambda表达式进行查询时，CustomMappingAttribute中指定的列名以及之前属性映射时指定的列名都会成为ViewFields的一员。

但需要注意的是，如果你在Lambda表达式中使用了通过MapFrom映射而来的属性，那么它将不会出现在CAML的Query语句中，Linq to SharePoint采取的方法是把所有SPlistItem都获取并转换成实体类，然后通过Linq to Objects来进行第二次查询（而普通的映射属性则不存在这个问题）。

这当然是极大的性能隐患，然而在Linq to SharePoint中，类似的性能隐患还不止这一处，而且稍不注意就会中招。

譬如根据ID来查找某一Item，我们通常会写出这样的代码：

var item = list.First(i => i.Id == root.ID);

或者

var item = list.Where(i => i.Id == root.ID).First();

或者

var item = list.Where(i => i.Id == root.ID).Single();

这三行代码看起来没有任何问题，而且最终也会被翻译成一模一样的CAML（我省去了ViewFields）：

<View>
  <Query>
    <Where>
      <Eq>
        <FieldRef Name="ID" />
        <Value Type="Counter">16</Value>
      </Eq>
    </Where>
  </Query>
  <RowLimit Paged="TRUE">2147483647</RowLimit>
</View>

注意RowLimit，它的值居然是2147483647，这表示查询会返回列表中的所有条目，并将它们都转换成实体类，然后再使用Linq to Objects来进行查询。

MSDN的这篇文档中的“Additional Performance Considerations”一节虽然明确了哪些方法会导致这种行为，但First和Single这两个方法居然都被标记为Efficient。

那么正确的获取单个条目的查询表达式该怎么写呢？使用Take方法，只有Take方法才会正确的翻译成RowLimit：

this.Root = list.Where(i => i.Id == root.ID).Take(1).Single();

它会被翻译成（同样省去了ViewFields）：

<View>
  <Query>
    <Where>
      <Eq>
        <FieldRef Name="ID" />
        <Value Type="Counter">16</Value>
      </Eq>
    </Where>
  </Query>
  <RowLimit Paged="TRUE">1</RowLimit>
</View>

同样的试验还可以参考这里。

此外，我们知道Linq可以使用Take和Skip方法来进行数据分页，但在Linq to SharePoint中，Skip方法并不会翻译成CAML的分页语句，它还是会拿到所有条目。

写到这里，基本上已经把我所遇到的所有难以接受的部分都介绍完了，其实前面几条，若不是有严重的代码洁癖的话，也可以不必在意。

最后提到的性能问题才是关键所在，而且你很难通过阅读代码来发现问题所在，微软的官方文档对性能问题的解释也模棱两可，一会儿说性能很棒，一会儿又说可能会导致极差的性能。所以最好还是检查一下每一条查询语句生成的CAML是否有问题（DataContext的Log属性会输出所有翻译后的CAML）。

现在你应该明白标题的含义了。

Windows Phone自定义主题

Windie Chai — Thu, 08 Mar 2012 09:29:40 +0800

我们知道Windows Phone默认的主题系统是由黑白两色为背景和一些强调色组成的，用户可以随意切换。通常来说，应用开发者无需关心这一部分，系统会去更新相关的资源，然后再体现在应用中。

但有一些时候，我们基于品牌等因素的考量，可能不想使用Windows Phone的默认主题。比如我开发的“豆芽”是豆瓣网的一个客户端，我希望尽可能贴近豆瓣网本身清新的风格，而不是给用户呈现一个和豆瓣网风格大相径庭的黑色背景的界面；再比如我想让应用使用Windows Phone的默认字体（等线），而不是SDK的默认字体（雅黑）。

这些都需要我们去自定义应用的主题。

在介绍如何创建自定义主题之前，先来简单的描述一下Windows Phone主题的原理。

在Windows Phone中，系统预定义了许多资源，这些资源包括了画笔、颜色、字体、粗细、字号、文本样式等等最基本的元素（详细的资源名称可以查看这里）。此外，Windows Phone中的所有控件都会有自己的样式，样式中还包括了定义控件布局的模板，而模板又利用系统内置的资源定义了控件在各种状态下的外观（所以我们在XAML中随处可以见类似{StaticResource PhoneBackgroundBrush}这样的对内置资源的引用）。

所以我们可以想到，修改内置资源或者修改控件的样式都可以达到自定义主题的效果。

在早期的Windows Phone v7.0），我们可以使用前一种方式，只需要在应用中增加一个ResourceDictionary的XAML文件，里边添加若干和系统资源相同键名的资源，即可实现对系统资源的覆盖。

但这种方法在Mango （v7.1）中无效了，它被当作一个Bug修复了，所以我们只能另寻方法。代价最小的一种方法是在App初始化的时候动态的读取我们定义的ResourceDictionary，并替换系统内置资源。具体的步骤可以参考这里，我就不赘述了。

此外，还可以利用Mango带来的另外一个变化，新的Silverlight 4带来的“隐式样式”(Implicit Style)。隐式样式是指只有TargetType却没有指定Key的Style，在Silverlight 4中，会将这个Style应用到所有匹配的TargetType对象上。

我们可以利用“隐式样式”来更改内置控件的样式，只需要将需要修改的控件的样式添加到应用的ResourceDictionary中，将其Key值去掉即可（当然不去掉也可以，这就需要手工设置所有匹配控件的Style属性）。

但一般情况下，既然我们想要更改应用级别的主题，基本上我们会修改整套配色方案，如果单纯用“隐式样式”来实现的话，我们就需要实现所有控件的隐式样式，看起来似乎也不是一件简单的事情。

本文来介绍另外一种方法，这种方法不仅实现了所有控件的样式，还一并接管了所有的内置资源，但它的实现过程却一点儿也不复杂。

首先

我们在项目中添加一个XAML文件，用来存放新的主题，这里将文件名定为“CustomTheme.xaml”，下面是它的内容：

<ResourceDictionary

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:System="clr-namespace:System;assembly=mscorlib">

</ResourceDictionary>

然后编辑App.xaml，添加相应的ResourceDictionary：

<Application.Resources>

<ResourceDictionary>

<ResourceDictionary.MergedDictionaries>

<ResourceDictionary Source="CustomTheme.xaml"/>

</ResourceDictionary.MergedDictionaries>

</ResourceDictionary>

</Application.Resources>

接着打开Windows Phone SDK附带的设计资源文件夹：C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Design。我们会看到若干文件夹，这些文件夹都对应于Windows Phone中的一个主题搭配，譬如LightGreen表示浅色背景色和绿色强调色的搭配。

挑选一个最贴近我们想要的主题配色的文件夹打开，我们会看到两个XAML文件，其中ThemeResources.xaml中定义了系统资源，System.Windows.xaml中定义了大多数控件的样式。

将ThemeResources.xaml和System.Windows.xaml添加到项目中，由于System.Windows.xaml引用了ThemeResources.xaml中定义的资源，所以在System.Windows.xaml的根元素下添加一个ResourceDictionary来引用ThemeResources.xaml（否则在运行时会抛出找不到资源的异常）：

<ResourceDictionary.MergedDictionaries>

<ResourceDictionary Source="ThemeResources.xaml"/>

</ResourceDictionary.MergedDictionaries>

然后在我们的CustomTheme.xaml中也添加一个对System.Windows.xaml引用的ResourceDictionary：

<ResourceDictionary.MergedDictionaries>

<ResourceDictionary Source="System.Windows.xaml"/>

</ResourceDictionary.MergedDictionaries>

现在这几个文件的关系是：App.xaml引用了CustomTheme.xaml,CustomTheme.xaml引用了System.Windows.xaml，System.Windows.xaml引用了ThemeResources.xaml。也就是说，在应用运行时，这几个XAML会被全部加载。

至此，我们的应用中已经包含了Windows Phone的几乎所有资源和样式，但无论我们怎么修改它们的值，都不会影响应用在运行时呈现的外观。因为我们所有的模版和页面元素依然引用了系统内置的资源，而这些资源是不可覆盖的。

这里有个奇怪的现象，如果我们修改了这些资源的值，是可以在设计器中看到效果的，但丝毫不会影响运行时的效果，我相信这也是一个迟早要修复的Bug。

回到正题，既然我们已经包含了Windows Phone的几乎所有的资源和样式，那还何必去覆盖系统预置的资源和模版呢？直接使用我们自己的不就好了吗？

没错，就是这样。

我们观察到Windows Phone内置的资源和样式的名称都以“Phone”开头，非常有规律，也就非常容易替换。所以接下来我们在整个项目（或解决方案，取决于你的实际情况）里搜索x:Key=”Phone这个字符串，将其替换为x:Key=”Custom，这样会将所有资源的名称修改为CustomXXX；然后在搜索{StaticResource Phone开头的字符串，将其替换为{StaticResource Custom，这样会把所有对系统资源的引用修改为对应用内资源的引用。

如下图所示：

完成这步操作之后，我们的应用就已经基本和Windows Phone内置主题说再见了，这时我们可以修改一些资源的值，运行一下看看效果：

不仅仅是颜色，因为我们已经将系统内置的绝大多数样式都包含了进来了，所以还可以修改控件的布局。譬如我们想更改CheckBox的对钩的样式，没有问题，它在模版中使用一个名为CheckMark的Path来表示的，直接修改就好：

前面我一直在强调我们只包含了“绝大多数模版”，是因为还有一些控件的模版并未在System.Windows.xaml中定义，譬如Panorama和Pivot，对于这两个控件的样式我们该如何自定义呢？

需要一些小手段，我们用.NET Reflector这个工具打开C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Libraries\Silverlight\Microsoft.Phone.Controls.dll，查看它的Resources，将MicrosoftPhone.Controls.g.resources中的themes/generic.xaml保存下来。

这个文件定义了Panorama和Pivot控件的样式，同样将其添加到项目中。

然后在项目中添加对Microsoft.Phone.Controls.dll的引用并将generic.xaml文件根元素中定义的两个命名空间（local和localPrimitives）的值修改一下：

xmlns:local="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls"

xmlns:localPrimitives="clr-namespace:Microsoft.Phone.Controls.Primitives;assembly=Microsoft.Phone.Controls"

现在我们需要把generic.xaml插入到之前创建好的“资源引用链”中，先在generic.xaml文件的根元素下增加对System.Windows.xaml的引用：

<ResourceDictionary.MergedDictionaries>

<ResourceDictionary Source="System.Windows.xaml"/>

</ResourceDictionary.MergedDictionaries>

再将CustomTheme.xaml中对System.Windows.xaml的引用改为对generic.xaml的引用。

现在这几个文件的关系变成了：App.xaml应用了CustomTheme.xaml,CustomTheme.xaml引用了generic.xaml，generic.xaml引用了System.Windows.xaml，System.Windows.xaml引用了ThemeResources.xaml。

OK，现在再添加一个Panorama页面，修改一下布局（Title的尺寸），试试效果：

方法介绍完了，简单归纳一下，就是找出系统内置的资源和样式，添加到应用的项目中，修改所有资源和样式的Key值，修改所有对系统内置资源和样式的引用，听起来似乎工程浩大，其实只是几步简单的复制粘贴和查找替换。

唯一比较麻烦的是要维护几个xaml文件之间的互相引用，还要保持一定的顺序，其实你也可以不必这么做，如果你愿意的话，完全可以把ThemeResources.xaml、System.Windows.xaml和generic.xaml文件根元素中的内容依次复制到CustomTheme.xaml文件中，这样只需要CustomTheme.xaml一个文件就可以了，但我个人认为把这几个文件混在一块并不利于维护。

当然，这种方法也并不是十分完美的，在我看来，它存在如下一些缺陷：

每次添加一个新的页面，都要检查其中对系统内置资源的引用，将其修改为引用我们接管的资源
假如微软在将来的版本中修改了内置样式的模板，我们也得做对应的修改，这就会比较棘手，我的方法是，在修改这些资源的值的时候，在其旁边加一个注释来表明这个值被修改过（譬如<!–Changed–>），将来微软升级了SDK，我们可以先备份一下现有XAML文件，然后重复之前的步骤接管系统内置资源和样式，再根据备份文件中的特定注释来逐一修改。

此外，你可能会担心最后在接管Panorama和Pivot样式的时候使用了一点Hack的手段，会不会被市场拒绝，对此我也不能给出确切的答案，我只能说，“豆芽”也使用了这种方法，目前还没有遇到这方面的问题。

轻触这里下载源码。

SharePoint 2010 JavaScript技巧两则

Windie Chai — Sun, 26 Feb 2012 10:57:15 +0800

SharePoint开发，从某种程度上，也可以认为是Web开发，所以也就不可避免的要使用JavaScript，本文就来介绍SharePoint 2010上的两则JavaScript小技巧。

1.禁用Ribbon，保留导航

SharePoint 2010在UI上最大的变化就是和Office一致的Ribbon界面，Ribbon虽然有各种好处，但对于有些类型的网站（譬如面向互联网的网站）来说，Ribbon可能一个令人困扰的东西，那么我们怎么去掉Ribbon呢？

首先，我们可以观察到，Ribbon分为两个部分，一部分是上方的Tab，它是一个id为“s4-ribbonrow”的div；另一部分是下面的容器（包含导航和实际的操作按钮），它是一个id为“s4-titlerow”的div。

对于s4-ribbonrow来说，我们可以直接将其隐藏。但对于s4-titlerow来说，直接隐藏却不是一个很好的方法。一来s4-titlerow还包含这导航，二来就算隐藏了，我们的一些触发Ribbon Tab切换的操作（譬如选中某个条目）依然会让Ribbon显示出来，所以我们需要另外一种方法。

通过跟踪Ribbon相关的JavaScript代码可以发现，触发Ribbon Tab切换的所有事件都会调用一个叫做“_ribbonStartInit”的方法，而且大多数调用之前都会判断_ribbonStartInit的存在性以及类型（只有直接点击Ribbon Tab时不会判断，但Ribbon Tab已经通过s4-ribbonrow隐藏了，所以不会出现脚本错误），所以我们可以将这个变量去掉或者换一个类型，这样切换Ribbon的代码就无法继续执行，Ribbon也就相当于被禁用了，如下面的代码所示：

_ribbonStartInit = "Ribbon Disabled";

2.让Rating只读

Rating也是SharePoint 2010新增的一个功能，但这个功能一旦启用之后，便对所有用户开放，哪怕是只有查看权限的用户也可以进行打分。有时候我们并不喜欢这种默认行为，而是想让Rating信息对某些用户只读，想要实现这个功能，我们先来分析一下Rating控件。

SharePoint 2010的Rating控件会Render成一个span，它的ID以“RatingsCtrl_”开头，内部包含一个a和一个span。除此之外，每一个Rating控件都会在页面上注册一段JavaScript，用来初始化一个RatingsControl对象，而这个对象在初始化的时候又会向Rating控件这个span添加一些事件绑定（mouseover、mouseout、keypress）。

所以我们只需要把这个span上的这几个事件绑定去掉，就可以让Rating控件变为只读了，如下面的代码所示：

function ids_ratingDisabling(){{

var rc =$get('Rating控件ID');

if(rc != null)

$clearHandlers(rc);

}}

_spBodyOnLoadFunctionNames.push('ids_ratingDisabling');

如果页面上有多个Rating控件，可以想办法先把这些控件都找出来，然后遍历它们依次执行$clearHandlers方法。

需要注意的是Rating控件注册的JavaScript会在rating.js加载完成后执行，所以我们的这段代码务必不能过早执行，这里将禁用Rating的函数添加到_spBodyOnLoadFunctionNames中，可以保证我们的代码在执行时，Rating控件自己的代码已经执行完毕了。

CSS文字围绕效果

Windie Chai — Fri, 10 Feb 2012 20:16:37 +0800

前两天同事问我能不能用CSS实现这样一个效果，页面上有一段文本，但文本的左下方有一个图片，他希望文本在遇到图片时，能绕开图片。如果图片位于左上方的话，其实很容易做到，我同事遇到的这种情况我之前也没有处理过，研究了一下，发现了一种方法。

先来看看最终效果，红色的方块用来模拟图片：

完整的HTML如下：

<html>
<head>
<title>Untitled Page</title>
<style>
.left div
{
float: left;
clear: left;
margin-right:5px
}
.left .placeholder
{
margin-right:0px;
width:1px
}
.text
{
line-height: 20px
}
</style>
</head>
<body>
<div>
<div class="left">
<div class="placeholder" style="height: 60px">
</div>
<div style="width: 100px; height: 40px; background-color: red">
</div>
</div>
<div class="text">
Windows Phone是微软发布的一款手机操作系统，它将微软旗下的Xbox LIVE游戏、Zune音乐与独特的视频体验整合至手机中。2010年10月11日晚上9点30分，微软公司正式发布了智能手机操作系统Windows Phone，同时将谷歌的Android和苹果的IOS列为主要竞争对手。2011年2月，诺基亚与微软达成全球战略同盟并深度合作共同研发，建立庞大的生态系统。
</div>
</div>
</body>
</html>

简单解释一下，.left中的所有div都默认将float和clear都设置为left，这样做一方面能保证其他与这些div视觉上相邻的元素都会贴着它们，同时这些div自身又能保证独处一行。所以.text中的文本就会围绕.left中的所有div来呈现。

.text设置了line-height为20px，这样做是为了给.left中的div带来计算高度上的便利。.left中的第一个div是一个占位符，它的作用是把红色方块向下推一段距离，所以它设置了height为60px，即.text行高的3倍，也就是三行文本（同理红色方块的高度是两行文本）。此外，它的width是1px，而不是0px，这是为了兼容IE7所做的让步。

如果将这段代码拓展一下，我们还可以实现两边边框都扭曲的文本段，如下图所示：

完整的HTML代码如下：

<html>
<head>
<title>Untitled Page</title>
<style>
.border
{
padding:0px;
margin:0px;
list-style:none
}
.border .left
{
float: left;
clear: left;
margin-right:5px;
height:20px;
background-color:Red
}
.border .right
{
float: right;
clear: right;
margin-left:5px;
height:20px;
background-color:Blue
}
.border .placeholder
{
margin-left:0px;
margin-right:0px;
width:1px
}
.text
{
line-height: 20px
}
</style>
</head>
<body>
<div>
<ul class="border">
<li class="left placeholder">
</li>
<li class="right" style="width: 30px">
</li>
<li class="left" style="width: 10px">
</li>
<li class="right" style="width: 20px">
</li>
<li class="left" style="width: 20px">
</li>
<li class="right" style="width: 10px">
</li>
<li class="left" style="width: 30px">
</li>
<li class="right placeholder">
</li>
<li class="left" style="width: 20px">
</li>
<li class="right" style="width: 10px">
</li>
<li class="left" style="width: 10px">
</li>
<li class="right" style="width: 20px">
</li>
<li class="left placeholder">
</li>
<li class="right" style="width: 30px">
</li>
</ul>
<div class="text">
Windows Phone是微软发布的一款手机操作系统，它将微软旗下的Xbox LIVE游戏、Zune音乐与独特的视频体验整合至手机中。2010年10月11日晚上9点30分，微软公司正式发布了智能手机操作系统Windows Phone，同时将谷歌的Android和苹果的IOS列为主要竞争对手。2011年2月，诺基亚与微软达成全球战略同盟并深度合作共同研发，建立庞大的生态系统。
</div>
</div>
</body>
</html>

以上代码均在IE7、IE8以及Chrome16中表现良好。

Windows Phone WebBrowser的技巧

Windie Chai — Thu, 09 Feb 2012 21:46:59 +0800

无论是在桌面级开发中，还是在手机端开发中，WebBrowser都是一个经常会用到的控件；Windows Phone中的WebBrowser虽然远远没有桌面版那么强大，但依然足够应付常规用途。本文就来介绍几则Windows Phone中的WebBrowser控件的小技巧。

1.显示HTML片段

WebBrowser的NavigateToString方法可以用来将一段HTML片段显示在WebBrowser中。利用这个方法可以把WebBrowser当作一个增强版的RichTextBox来使用，京东商城的Windows Phone客户端在展示商品信息时就使用了这种技术。而且这种技术还有助于解决Windows Phone中TextBlock显示长文本的一个bug，具体表现为当文本过长时，TextBlock只显示文本的前半段内容，后半段内容不予显示，但却留出了位置（滚动条还能到达，非常诡异），而WebBrowser在显示长文本时就没有这种困扰。

但NavigateToString并不是完美的，假若传入的字符串中包含中文（或其他UTF-8字符）的话，就会显示为乱码。

解决这个问题的方法之一是提前对字符串进行转码，可以参考这篇文章。但这样做的代价是需要遍历所有字符，其实只要把需要显示的HTML片段简单构造成HTML文件，存储到独立存储中，然后再用WebBrowser以常规的方式打开即可解决这个问题。如下面的代码所示：

using (IsolatedStorageFile file = IsolatedStorageFile.GetUserStoreForApplication())
 {
 if (!file.DirectoryExists("temp"))
 file.CreateDirectory("temp");
 using (IsolatedStorageFileStream fs = new IsolatedStorageFileStream("temp\\review.html", FileMode.Create, file))
 {
 string html = "<!DOCTYPE html><html lang='zh-CN'><head><meta http-equiv='Content-Type' content='text/html; charset=utf-8'></head><body>";
 html += e.Review.Summary;
 html += "</body></html>";
 byte[] bytes = Encoding.UTF8.GetBytes(html);
 fs.Write(bytes, 0, bytes.Length);
 }
 }
 this.wb.Navigate(new Uri("temp\\review.html", UriKind.Relative));

2.禁止缩放

WebBrowser支持缩放，但有时我们并不需要缩放功能，譬如在用它来解决TextBlock的长文本bug时。

如果需要禁用一切手势，可以将WebBrowser的IsHitTestVisible设置为False，但这样做的后果是WebBrowser滑动显示内容的功能都会失去。但如果仅仅想要禁用缩放功能，可以在WebBrowser将要显示的HTML的Head中加入这样下面的脚本：

<meta name='viewport' content='width=device-width, initial-scale=1.0, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0' />

关于viewport的更多细节可以参考MSDN Blog的这篇文章。值得注意的是原文在发表时，Windows Phone中的IE还不支持initial-scale、minimum-scale和maximum-scale，而在最新的Windows Phone Mango更新中，除了initial-scale之外的其余属性都已经可以很好的支持了。

3.接管横向滑动

如果用WebBrowser来解决TextBlock的bug，那么还有一个问题需要注意，WebBrowser会接管横向滑动手势，用来移动页面位置，也就是说，假如你把WebBrowser方知道Pivot或Panorama控件中时，就没有办法切换到其他Item了（除非从Header部分横向滑动）。

不过一般在用WebBrowser代替TextBlock时，并需要它内置的横向滑动功能（通常会禁用缩放），所以我们可以想办法侦测发生在WebBrowser上的横向滑动手势，并用来修改Pivot或Panorama的SelectedIndex。所幸的是，Silverlight Toolkit For Windows Phone中有一个组件可以帮我们轻松的完成这项工作。

首先在Xaml中添加GestureService.GestureListener：

<phone:WebBrowser Name="wb" Loaded="wb_Loaded" LoadCompleted="wb_LoadCompleted">
 <toolkit:GestureService.GestureListener>
 <toolkit:GestureListener Flick="GestureListener_Flick" />
 </toolkit:GestureService.GestureListener>
 </phone:WebBrowser>

在GestureService.GestureListener的Flick事件中修改Pivot或Panorama的SelectedIndex：

private void GestureListener_Flick(object sender, FlickGestureEventArgs e)
 {
 if (e.Direction.ToString() == "Horizontal")
 {
 this.p.SelectedIndex = 1;
 }

}

除了Flick之外，GestureService还支持Tap、Double Tap、Touch and Hold、Pan、以及Pinch and Stretch多种手势。关于GestureService的更多信息请参考这篇文章。

隐藏SharePoint User Profile页面中的提示文本

Windie Chai — Wed, 01 Feb 2012 22:42:52 +0800

在SharePoint 2010的User Profile页面中存在一些提示，本文的内容就是如何去掉这些提示而又不影响其他功能，这是一件简单而又意义不大的事情，但我却不小心想复杂了，前后花了几个小时，用jQuery写了几行代码，中间还发现bug修改了一遍，终于发现走了弯路，用区区3行CSS搞定。

首先是“标签和注释”页面（thoughts.aspx）中的提示文本，位于标签云的下方，如图所示：

最下面几行提示文本的标签既没有id也没有class，还好标签云是有class的，可以用它来定位到之后的元素，并将其隐藏，只需一句Style：

.ms-TagCloud.ms-socialThoughtBoxTags ~ div {display:none;}

其中~表示“之后的所有元素”，IE6不支持这个选择器，不过没关系，SharePoint 2010 不支持IE6。

接着是“概述”页面（person.aspx）的记事板提示文本，这段提示文本是通过AJAX技术动态填充的，仅在没有Notes的情况下显示（包括将Notes全部删除之后）。

没有Notes时的样子：

有Notes时的样子：

这段提示文本的标签也没有id和class，而且多层嵌套，可以依靠有class的分页元素（“上一步”和“下一步”的功能居然是为Notes翻页，我还以为是引导提示文本的向导按钮）来定位它。值得注意的是提示文本和Notes位于同一个div中，但结构却大相径庭，还好Notes的元素具有id，所以可以先将该层的所有div隐藏，然后再将具有id的div显示出来，籍此来隐藏提示文本，而又不影响Notes本身：

.ms-socialCommentPaging + div > div {display:none}
.ms-socialCommentPaging + div > div[id] {display:block;}

其中+表示相邻的下一个元素，>表示第一级子元素，[id]表示包含id属性的元素。

最终的CSS样式如下：

<style>
.ms-socialCommentPaging + div > div {display:none}
.ms-socialCommentPaging + div > div[id] {display:block;}
.ms-TagCloud.ms-socialThoughtBoxTags ~ div {display:none;}
</style>

将这段CSS添加到MySite Host的Custom Master Page中即可（默认为MySite.master）。

SharePoint HttpModule和SharePoint Designer的冲突

Windie Chai — Fri, 23 Dec 2011 19:00:18 +0800

前段时间为SharePoint写了一个HttpModule来将对重定向对某些页面的请求,结果发现有一个副作用,会和SharePoint Designer有冲突.

具体表现为启用了这个HttpModule之后,SharePoint Designer在打开aspx页面时会报以下错误:

服务器不能完成您的请求.

soap:Server服务器无法处理请求。 —> 无法完成此操作。请重试。 —> 无法完成此操作。请重试。<nativehr>0×80004005</nativehr><nativestack></nativestack>

排除了HttpModule代码对该文件路径的影响之后,开始考虑是不是事件顺序的缘故.

之前这个HttpModule是在PostAuthorizeRequest事件中处理重定向逻辑的,经过一番尝试,最后发现只要使用的事件早于PostRequestHandlerExecute,就会引发SharePoint Designer出错.

具体原因未知.

另附上HttpApplication中的事件触发顺序：

BeginRequest
AuthenticateRequest
PostAuthenticateRequest
AuthorizeRequest
PostAuthorizeRequest
ResolveRequestCache
PostResolveRequestCache
PostMapRequestHandler
AcquireRequestState
PostAcquireRequestState
PreRequestHandlerExecute
PostRequestHandlerExecute
ReleaseRequestState
PostReleaseRequestState
UpdateRequestCache
PostUpdateRequestCache
EndReques

另：据说事件过于靠前还会使SharePoint无法上传文件。

版本历史

Windie Chai — Thu, 08 Dec 2011 10:34:24 +0800

« Tagging Contacts 钛金联系人 for Windows Phone 7

v1.1.0.0 2011-12-03

+ 支持查看拥有同一标签的所有联系人
+ 支持将联系人固定到“开始屏幕”

v1.0.0.0 2011-11-24

+ 自动显示“人脉”中的所有联系人
+ 查看联系人的详细信息
+ 管理联系人的标签
+ 通过各种途径与联系人联络
+ 可以向联系人的任何电话号码发送短信
+ 查看所有标签
+ 支持各种主题

Tagging Contacts 钛金联系人 for Windows Phone

Windie Chai — Thu, 08 Dec 2011 10:28:30 +0800

钛金联系人是一个增强版的联系人应用。
您可以通过它来为您的联系人打标签，标签的内容没有任何限制，可以是他（她）最喜爱的食物、特长、昵称，也可以是你们认识的地方、你们的关系等等……
通过标签，您可以在瞬间回忆起他（她)的点点滴滴。
在未来的更新中，您还可以给拥有同一个标签的所有联系人群发短信和邮件，可以完全取代“人脉”的分组功能，而且没有联系人数量限制。

试用版功能

自动显示“人脉”中的所有联系人，并按照首字母分组。
查看联系人的详细信息。
为联系人添加和删除标签。
通过各种途径与联系人联络。
可以向联系人的任何电话号码发送短信。
查看所有标签。
浏览拥有同一个标签的所有联系人。
支持各种主题。

收费版功能

将联系人固定在开始屏幕

系统要求

Windows Phone 7.1（Mango）以及更新的系统

版本

当前版本：1.1.0.0
版本历史»

截图&预览：

下载

前往Windows Phone Marketplace下载安装

『 听 风 且 吟 』技术版