【Win 10 应用开发】在代码中加载文本资源

记得前一次，老周给大伙，不，小伙伴们介绍了如何填写 .resw 文件，并且在 XAML 中使用 x:Uid 标记来加载。也顺便给大伙儿分析了运行时是如何解析 .resw 文件的。

本来说好了，后续老周会写一篇关于如何在代码里面手动加载文本资源的博文，但一直拖到今天，因为老周前阵子在忙着开发自己的 UWP 应用，已经向应用商店提交了一个版本，昨天刚提交完一次更新。

好，今天咱们就聊聊代码加载文本资源的事情。

在 XAML 中使用 uid 加载资源虽然方便，但是它有个缺点——不同控件有不同的属性，有时候不太方便匹配，当然了，如果你的资源所针对的控件类型不多，那是无所谓的。

为了弥补 uid 加载的不足，我们完全可以自己来编写资源加载代码。这种做法向来是老周惯用的。大家应该还记得当年的 WinForm 应用吧，它也是可以在设计器中直接翻译和编辑资源的（.resx），然后 VS 会帮我们生成一个管理资源的类。

在实际开发中，老周一向不用这一招的，一般是自己写资源类的，这样很灵活，可以自由控制，再让资源类公开一些属性，然后与 UI 进行绑定即可。在WPF中老周并没有开发过多语言的应用，所以没怎么去弄。

同样的道理，在UWP应用中我们也照样可以自己去封装，然后与 UI 绑定即可，这样自己管理起来也方便，而且可以同时用于 XAML 与非 XAML 代码上。故，还是很有意义的。有时候，多折腾一下也是好的，爱折腾的人生更精彩。所以，去年春天老周学 PR，夏天学AE，秋天学CAD，冬天学葫芦丝。今年过年时学单反相机，清明节后学巴乌，劳动节后学电器维修，请在煤气公司工作的同学教我安装燃气灶，七月份学陶笛，九月份去看老师傅做丝绸卷画，十月份临摹柳公权的《玄秘塔碑》。

人一旦有事情可做，就不会胡思乱想了。

下面老周演示一个例子。

项目中放两个资源文件，一个是英文资源，一个是中文资源。

在中文资源中，输入以下三项内容。

在英文资源中，输入以下三项。

资源准备完成后，咱们开始封装。其实，在UWP中，加载资源有个很NND简单的方法，就是用 Windows.ApplicationModel.Resources 命名空间下的

ResourceLoader 类。这个类很好用，调用静态的 GetForCurrentView 方法就能得到一个实例，然后用 GetString 方法就可以加载到字符串资源了。

注意，GetForCurrentView 方法有两个重载，一个是带参数的，参数指定你的.resw 文件名，不带路径和扩展名，这个在前一篇鸟文中老周介绍过的，比如，本例中，资源文件为 Goods.<language tag>.resw，所以传递的参数就是 Goods。另一个是不带参数的 GetForCurrentView方法，如果调用这个版本的重载，那么，你的 .resw 文件必须命名为 Resources.resw，如 Resources.lang-zh-cn.resw，Resources.lang-zh-tw.resw 等。

先看看封装好的类。

    public class ResourcesItems : INotifyPropertyChanged
    {
        static readonly ResourcesItems mInstance = new ResourcesItems();
        public static ResourcesItems Current { get { return mInstance; } }

        private ResourcesItems()
        {
            // 构造时加载一下，填充默认值
            Load();
        }

        public event PropertyChangedEventHandler PropertyChanged;

        private void OnPropertyChanged(string propname)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propname));
        }

        public void Load()
        {
            var loader = ResourceLoader.GetForCurrentView("Goods");
            Item1 = loader.GetString("t1");
            Item2 = loader.GetString("t2");
            Item3 = loader.GetString("t3");
        }

        #region 属性
        string _it1, _it2, _it3;
        public string Item1
        {
            get { return _it1; }
            set
            {
                if (value != _it1)
                {
                    _it1 = value;
                    OnPropertyChanged(nameof(Item1));
                }
            }
        }
        public string Item2
        {
            get { return _it2; }
            set
            {
                if (_it2 != value)
                {
                    _it2 = value;
                    OnPropertyChanged(nameof(Item2));
                }
            }
        }
        public string Item3
        {
            get { return _it3; }
            set
            {
                if (_it3 != value)
                {
                    _it3 = value;
                    OnPropertyChanged(nameof(Item3));
                }
            }
        }
        #endregion
    }

这里我用 Item1、Item2和 Item3 三个属性分别对应资源文件中的三个项。实现 INotifyPropertyChanged 接口是很有划时代战略意义的，这样当语言改变时，从资源文件中重新加载文本时，UI 上的绑定可以实时获得最新的值。

在 99.99986% 的应用场景中，我们只需要实例化一次资源类就行了，所以，保持它在应用生命周期中只有一个实例即可，没必要创建那么实例，浪费食物链资源。故而可以把构造函数私有化，然后用一个静态的、只读的属性来公开当前类的实例。即

        static readonly ResourcesItems mInstance = new ResourcesItems();
        public static ResourcesItems Current { get { return mInstance; } }

这个类可以公开一个方法，让外部调用，来加载资源。

        public void Load()
        {
            var loader = ResourceLoader.GetForCurrentView("Goods");
            Item1 = loader.GetString("t1");
            Item2 = loader.GetString("t2");
            Item3 = loader.GetString("t3");
        }

回到应用程序页面类，比如项目模板生成的 MainPage 类，把这个资源管理类作为一个属性公开一下。

        ResourcesItems TheRes
        {
            get { return ResourcesItems.Current; }
        }

有人会说，老周，你干吗这么多此一举？因为待会儿我要用 x:Bind 来绑定，但是，XAML 编译有个“八阿哥”，当你用x:Bind间接绑到实例上时，会发生编译错误。据说在今年 7 月份时，SDK开发团队已收到这个问题报告，将来会修复的。反正秋季更新1709，16299 中还没修复。

就是，如果你这样绑定会出错。

<Pig Head = "{x:Bind ResourceItems.Current.Item1}" ... />

所以，为了避开这个缺陷，可以在页面类中封一下，然后我们可以把 x bind 的源指向页面类的这个属性，这样就不会报错了。

   <TextBlock>
       <Run Text="{x:Bind TheRes.Item1,Mode=OneWay}" FontSize="16" Foreground="Blue"/>
       <Run Text="{x:Bind TheRes.Item2,Mode=OneWay}" FontSize="16" Foreground="Red"/>
       <Run Text="{x:Bind TheRes.Item3,Mode=OneWay}" FontSize="16" Foreground="DarkBlue"/>
    </TextBlock>

这样绑定之后，我们就可以在代码中实时修改应用程序的语言，然后再让刚刚封装的资源类重新加载文本就行了。

这里，刻意封装了一个方法，用改应用程序的当前语言。

        private void SetLang(string lang)
        {
            var context = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView();
            var qs = context.QualifierValues;
            // 这样也可以修改当前应用的语言
            qs["Language"] = lang;
        }

ResourceContext 负责应用上下文的资源设定，其中，我们有两个办法来改语言，一个是改  Languages 属性，注意它是个列表，也就是说你可以同时设置一串语言组合，默认应用的应该是列表中的第一个（提前是它与当前 Win 10 系统的语言相同）。

不过，我选择用第二种方法，就是从 QualifierValues 属性中获得一个字典，这个字典里面的条目是用于描述当前应用程序资源的限定符，Key 是限定符名称，Value 当然是对应的值。啥是限定符呢。比如当前应用的语言，屏幕缩放比例，是否高对比度，是否旋转屏幕等。

你如果好奇里面有些啥玩意儿，可以用以下代码来输出一下。

#if DEBUG
            var strbd = new System.Text.StringBuilder();
            foreach (var item in qs)
            {
                string ts = $"{item.Key} = {item.Value}";
                strbd.AppendLine(ts);
            }
            System.Diagnostics.Debug.WriteLine($"\n\n{strbd}\n\n");
#endif

然后你会看到类似以下这样的输出。

Language = zh-cn
Contrast = standard
Scale = 100
HomeRegion = CN
TargetSize =
LayoutDirection = LTR
Theme = dark
AlternateForm =
DXFeatureLevel =
Configuration =
DeviceFamily = Desktop
Custom =

看到以上输出，你懂了吧。如果还不懂，那撞墙吧。

我们这里只需要改 Language 的值就行了。所以

            var qs = context.QualifierValues;
            // 这样也可以修改当前应用的语言
            qs["Language"] = lang;

于是，有人肯定又问老周了，老周你是不是失忆了？上一篇中你不是介绍了一个 Windows.Globalization.ApplicationLanguages 类吗，里面只要改一下 PrimaryLanguageOverride 属性就可以了。对的，那个属性确实爽用，一行代码完成。但是，那个属性只适合于非实时更改，就是，可能只是应用运行时，或者用户在设置时改一下。因为那个属性修改了以后，不会马上生效的，可能要等 3 秒钟后才会刷新，除非你故意让程序卡 3 秒钟。不然的话，你要是想让切换语言马上生效，就要改资源限定符了。改限定符 Language 是很管用的，一改就灵，实时刷新。

好了，大功告成，看看效果如何。

示例源代码下载地址

OK，今天的文章就写到这里了，改天有新的发现，老周会及时分享。我现在是越来越喜欢 UWP 应用了，性能高，能够很好适应高分屏，以及各操作方式，最重要的是它安全。