WindowsPhone进修系列添加Application Bar及多语言撑持 (转载)

　　Windows Phone进修系列(一)：添加Application Bar及多语言撑持

　　天翼空间按利用工场（/）欢送各人前去！！

　　一、创建Application Bar

　　Application Bar和WinForm界面中菜单栏、形态栏等界面构成部门一样，是挪动运用界面的一个构成部门，只是默认情状下是空的不成见的，开发人员能够根据需要创建Application Bar的实例并添加功用按钮。

　　为运用添加Application Bar有两种体例，Xmal体例和后台代码的体例。

　　Xmal体例很简单，创建一个Windows Phone项目后，翻开MainPage.xaml文件，可以发现默认就有phone:PhoneApplicationPage.ApplicationBar那一段Xaml，只是被正文掉了，我们只需要往掉正文即可。

　　假设通过代码的体例来添加办法如下，查看MainPage的基类PhoneApplicationPage，

　　发现ApplicationBar现实上是界面的一个构成部门，只是在我们不定义的情状下为Null罢了。

　　进一步查看IApplicationBar的基类,发现ApplicationBar现实上由两部门构成:Buttons和MenuItems。

　　所以我们只需要给ApplicationBar属性赋值即可。代码如下：

　　View Code

　　ApplicationBar = new ApplicationBar();ApplicationBar.Buttons.Add(new ApplicationBarIconButton(new Uri("/Images/appbar.feature.email.rest.png", UriKind.Relative)) { Text = "按钮1" });ApplicationBar.MenuItems.Add(new ApplicationBarMenuItem("目次项1"));

　　需要重视的处所

　　固然添加Application Bar的体例很简单，但是仍是有几个处所是我们随便漠视的。

　　Buttons的个数是有限造的，最多为4个，多于4个会编译出错。当Buttons不敷用时，能够用MenuItems来扩展，而MenuItems的个数是没有限造,当大于5个时，会呈现滚动条。

　　图片添加到项目后必需将Build Action设置成Content而且将Copy to Output Directory设置成Copy if newer或者Copy always，不然图片展现不了

　　安拆完Windows Phone SDK，系统默认供给了一组更优化的图标供开发人员利用，在类似如下位置：C:\Program Files\Microsoft SDKs\Windows Phone\v7.1\Icons

　　假设需要自定义图标，为了到达好的效果，需要称心必然的前提，详细可查询MSDN,

　　二、当地化和多语言

　　和.net停止桌面等开发一样，能够操纵资本文件实现当地化的需求。

　　我们先来实现界面中TextBlock文本的当地化，通用的步调如下：

　　1. 项目中添加一个默认的资本文件，取名AppResource.resx，那个文件的名称是能够本身定义的，接着添加3个字符串资本，重视必需将拜候润色符设置成public,不然界面绑定的时候编译会呈现反常，如下图：

　　为了表现当地化的效果，我们再添加一个资本文件，取名AppResource.en-US.resx，重视那里的文件名形式，AppResource与默认资本文件名称一样，en-US代表English (United States)，如下图：

　　Windows Phone撑持的语言表和语言的代码表能够参考如下材料：

　　

　　2. 创建资本文件的包拆类LocalizedStrings.cs，供界面元素绑定（后面介绍为什么要包拆类以及怎么样往掉那个包拆类），代码如下：

　　View Code

　　public class LocalizedStrings{private static WPDemo.AppResource localizedresources = new WPDemo.AppResource(); public WPDemo.AppResource Localizedresources 　　{ get { return localizedresources; } 　　}}

　　也有类似如下版本的：

　　View Code

　　public class LocalizedStrings { public string ContentText { get { return AppResource.ContentText; } } public string ButtonText { get { return AppResource.ButtonText; } } public string MenuItemText { get { return AppResource.MenuItemText; } } }

　　第二种体例相当于将详细的资本包拆成详细的属性，利用起来更间接，但是资本太多了写起来比力繁琐，也有点多此一举，我选举第一种体例。

　　3. 为了界面中能绑定，需要将LocalizedStrings类做为资本加载进来，因为资本多个界面城市利用，所以做为全局资本比力适宜，因而翻开App.xaml文件，添加如下代码：

　　View Code

　　Application.Resources local:LocalizedStrings xmlns:local="clr-namespace:WPDemo" x:Key="LocalizedStrings" //Application.Resources

　　4. 用文本东西如记事本翻开项目文件WPDemo.csproj，在SupportedCultures元素中添加要撑持的语言，在本实例中，默认的资本文件AppResource.resx现实为中文版资本，在SupportedCultures元素中只需要加进en-US;即可，代码如下：

　　SupportedCulturesen-US;/SupportedCultures

　　那么设置后现实上准确的说，系统应该撑持英语和非英语，听着各人觉得废话，我的意思是想说，当我们将我们的设备设置成英语时, AppResource.en-US.resx文件的资本会起感化，当设置成其他一切语言时默认资本文件AppResource.resx会起感化。设置界面如下：

　　假设在项目文件的SupportedCultures节点中，不设置装备摆设任何内容语言，那么即便在如上界面中设置装备摆设成English(United States)，界面仍然展现成中文而不会主动读取AppResource.en-US.resx文件的资本，因为没设置装备摆设的情状下阐明，阐明系统不撑持英文，系统只会从默认的资本文件AppResource.resx中读取资本。我觉得微软在那个处所也答应以改进一下，记事本翻开项目文件再设置装备摆设的过程是不是能够免了，因为假设用户语言选的是English(United States)，完全能够主动查找有没有AppResource.en-US.resx那个资本文件，有的话当然就读那个文件，没有就读AppResource.resx完事！各人觉得呢？当然设想者如许做也可能是基于其他方面的考虑！

　　5. 最初就是界面中利用绑定的体例加载资本文件中的字符串了，翻开默认主界面文件MainPage.xaml，在名为ContentPanel的Grid元素中添加一个TextBlock元素后代码如下：

　　View Code

　　Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0"TextBlock x:Name="txtRes" Text="{Binding Path=Localizedresources.ContentText, Source={StaticResource LocalizedStrings}}"/TextBlock/Grid

　　重视，假设包拆类LocalizedStrings摘用的是第二种写法，代码就应该是如下形式：

　　Text="{Binding Path=ContentText, Source={StaticResource LocalizedStrings}}"

　　好了，如上步调就是当地化的通用体例，下面运行法式，测试一下，发现已经到达了我们的预期！

　　上面提到包拆类LocalizedStrings，各人可能会迷惘，那玩意儿有什么用，有点多此一举的觉得，其实我也那么认为，但往网上一搜，发现根本上当地化的示例全都原封不动的那么搞的！

　　为什么？

　　现实操做一下吧，先把LocalizedStrings.cs文件从项目中肃清，然后翻开App.xaml文件，往掉包拆类的引用，加上如下语句：

　　local:AppResource xmlns:local="clr-namespace:WPDemo" x:Key="LocalizedStrings" /

　　目标很明白，欠亨过包拆类间接引用资本文件类AppResource，与之对应，界面的元素就应该改成如下：

　　TextBlock x:Name="txtRes" Text="{Binding Path=ContentText, Source={StaticResource LocalizedStrings}}"/TextBlock

　　假设摘用的是包拆类的第二种写法，那里就不消管了，因为ContentText在包拆类中和类AppResource中一样，间接是成员属性。详细能够翻开AppResource.Designer.cs文件查看。

　　到如今，觉得差不多了，编译，OK，没有任何错误。F5运行法式，却抛出了反常：

　　No matching constructor found on type 'WPDemo.AppResource'

　　提醒资本类型中没有婚配的构造函数，我们翻开AppResource.Designer.cs，发现有如下默认构造函数

　　View Code

　　[global::System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode")] internal AppResource() { }

　　你应该已经发现了，原因就在于构造函数默认的拜候润色符是internal，资本文件和法式文件编译后不在统一个法式集，将internal该成public后从头运行，发现和有包拆类时效果一样了。

　　三、Application Bar的当地化和多语言

　　有人必定会纳闷为什么要把Application Bar零丁拿出来，其实原因很简单，它和界面中其他内容元素的当地化有些纷歧样。查看Msdn，明白阐明Application Bar不是silverlight控件，其属性不克不及像TextBlock等其他控件一样停止数据绑定，要实现是当地化，只能是编码的体例了。

　　先在界面中添加如下代码

　　View Code

　　phone:PhoneApplicationPage.ApplicationBar shell:ApplicationBar IsVisible="True" IsMenuEnabled="True" shell:ApplicationBarIconButton IconUri="/Images/appbar.feature.email.rest.png" Text="btn1"/ shell:ApplicationBarIconButton IconUri="/Images/appbar.refresh.rest.png" Text="btn2"/ shell:ApplicationBar.MenuItems shell:ApplicationBarMenuItem Text="mi1"/ shell:ApplicationBarMenuItem Text="mi2"/ /shell:ApplicationBar.MenuItems /shell:ApplicationBar /phone:PhoneApplicationPage.ApplicationBar

　　按钮和目次的Text属性假设写成如下形式编译将无法通过：

　　Text=Localizedresources.ContentText, Source={StaticResource LocalizedStrings}}"

　　看来只能在代码中通过属性来当地化了，我们拿第一个按钮来测试一下我们的设法，按常规思维，我们给按钮加上x:Name属性，如下：

　　shell:ApplicationBarIconButton Text="btn1" IconUri="/Images/appbar.feature.email.rest.png" Text="btn1"/

　　在MainPage()函数中添加如下代码：

　　btn1.Text = AppResource.ButtonText;

　　编译没有问题，运行后发现抛出NullReferenceException反常，为什么？Google一下，能看的资本有限（就Google能搜点有用的工具，关键时候总被协调，上火！），可能意思就是说ApplicationBar不是派生自FrameworkElement，因而不是页面visual tree的一部门，代码中无法通过x:Name来引用。实不晓得是不是Bug？归正是不克不及如许搞那只能换个构想了，竟然我们明明晓得ApplicationBar是有两个按钮的，那么我们能够测验考试一下如下体例：

　　((ApplicationBarIconButton)ApplicationBar.Buttons[0]).Text = AppResource.ButtonText;

　　运行代码，发现公然能够！

　　第一末节中我们提到添加ApplicatonBar有两种体例，适才当地化是用的只是第一种体例，假设用第二种体例也就是代码的体例添加ApplicatonBar就不存在上面的问题了，把MainPage.xaml中ApplicationBar部门的代码正文掉，在MainPage()函数中添加如下代码：

　　ApplicationBar = new ApplicationBar();ApplicationBar.Buttons.Add(new ApplicationBarIconButton(new Uri("/Images/appbar.feature.email.rest.png", UriKind.Relative)) { Text = AppResource.Button1Text });ApplicationBar.MenuItems.Add(new ApplicationBarMenuItem(AppResource.MenuItem1Text));

　　下面的或者对你们有用！！！

　　平台简介

　　天翼空间是由面向用户的利用商城和面向开发者的利用工场（开发者社区）构成。

　　天翼空间.利用工场是办事于天翼空间的开发者社区，为天翼空间的开发者办事。在天翼空间营业全流程中发掘聚合包罗手机软件开发者、最末用户、和API利用开发者等角色的原始需求，并根据原始需求逐渐将天翼空间本身包罗数据、客服、用户等一系列资本开放。并聚合一批API开发者将原始开放接口开发成成熟可用的利用，最末使手机利用开发者能愈加高效的通过天翼空间平台获取更多的最末用户。

　　通过成立开发者社区全流程撑持平台旨在处理开发者在利用天翼空间时包罗客服，开发，测试，上架，开店等全流程中的利用问题，并通过论坛等交互式版块成立升引户的交互平台，最末到达进步用户称心度，进步开发者效率，为开发者办事的大旨。

　　天翼空间才能开放特征

　　1、开放接口丰富

　　开放包罗利用商铺数据、电信级通信和基于云计算的才能开放等多种多样的办事和API接口，为开发者供给多种多样的办事和才能。

　　2、挪用次数多

　　丰富的API+开发者无限的创意=挪用频次高，开放平台挪用次数已到达均匀每日300万次。

　　3、赚钱体例多

　　才能开放平台旨在为开发者打造一个需乞降实现的桥梁，供给清晰且多样的盈利形式，与协做伙伴配合生长，协做共赢。

　　4、协做形式开放

　　以宽大、自在的立场、不竭的摸索新协做形式，不限语言、不限平台，驱逐广阔的互联网开发者，普遍的聚合互联网开发者的力量。

　　开放平台营业

　　1、天翼空间API

　　中国电信天翼空间利用商铺将以天翼3G挪动互联网利用为核心，通过开放电信末端和收集才能，聚合强大的互联网才能，引领国内挪动互联网生活，带来3G无限超卓！

　　中国电信天翼空间在国内初创“前店后厂”营业形式，努力于摸索电信才能与互联网才能的合成，以天翼空间利用工场为窗口率先开放了运营商的根底才能接口，聚合起大量协做伙伴，构成了一多量表现互联网与电信网合效果能的才能接口，才能开放与合成那两大主体是天翼空间区别于业界其他利用商铺的核心合作力。

　　如：利用分类、利用详情、利用排行等

　　2、电信才能API

　　电信才能指电信开发的才能接口API接口的总称，也称电信API。

　　API是供给利用法式与开发人员基于某软件或硬件的以拜候一组例程的才能，而又无需拜候源码，或理解内 部工做机造的细节。只需要做简单的代码嵌进，就可以实现诸多冗杂的电信才能，好比短信群发、多方语音 、在线点歌等。

　　如：短信、语音、验证码、彩信等

　　3、云计算API

　　以中国电信云数据中心为支持，将可供给云计算主机治理平台、自办事门户治理平台、云数据治理中心以及云计算主机营业托管等相关的计算、存储及智能收集资本综合办事。吸引强大的开发者团队，构成引领国内挪动互联网生活的开发平台。

　　如：分词API、QQ机器人、云图像处置等

　　4、手机告白API

　　我们将供给开放的手机告白平台，有效的整合法式开发者、网站发布者、告白商、代办署理机构，打造多条理、全方位的手机告白API办事，妥帖利用法式并实现盈利；供给多种告白格局、优良的告白资本、将网站的流量循序改变为现金；为品牌和绩效告白商供给高效切确的处理计划，以此来吸引您的目标受寡并提拔销量。手机告白API以一流的平台，绝佳的赞扬案办法，立异的告白形式，实现多方的互利共赢。

　　如：Android法式SDK、Windows Mobile法式SDK、Brew法式SDK等