Google Play上线的游戏,C#服务端如何校验内购订单

准备工作

  1. 在Google Play Console中启用API权限
  2. 在Google Cloud中准备好服务账号
  3. 坑:如果游戏内购商品早于服务账号创建,需要修改一下内购商品的信息,更新一下,才能真的获得权限

1. 在Google Play Console中启用API权限

打开Google Play Console后台的首页(注意:不是某个游戏管理的首页)。

如果你是第一次打开这个页面,会提示你是否启用。点击启用按钮,会问你是否绑定Google Cloud、Google Developer等等,一路确定就好了。

2. 在Google Cloud中准备服务账号

然后点击 创建新的服务账号,根据指引进入 Google Cloud 的后台进行创建,名字取好,其他都默认就可以了。

创建完以后,很重要的一步,是要创建密钥。

选择默认的json密钥就可以了。点击创建以后,会自动下载一个json文件。这个json文件待会在代码中会用到。这个文件就是这个账号的密钥了,一定要保存好,因为之后就没有机会让你再下载第二次了。

这个时候返回 Google Play Console 刚刚的页面,刷新一下服务账号,就可以看到刚刚创建的服务账号了。然后根据你自己的需要对这个账号进行授权,就可以了。

3. 没有权限的问题解决

如果做完了以上两步,直接进行下面的代码测试,发现返回错误

那恭喜你,遇到了Google的坑。这是由于你的服务账号创建以及绑定权限晚于内购商品的创建造成的。不过问题也比较容易解决,只要修改一下内购商品的信息,更新一下,就能真的获得权限了。

代码以及测试

API

我先找到了这个API文档,
https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.products

它一上来就告诉我,会返回什么值,但是就是不告诉我怎么发起请求。

于是我又找到了Google Api的C#封装:https://github.com/google/google-api-dotnet-client

并且提供了nuget支持:https://www.nuget.org/packages/Google.Apis.AndroidPublisher.v3

那一切就好办了

代码

测试

包名和商品ID都是固定的,所以我们只要拿到一个 PurchaseToken 就可以进行测试了。如果你以为测试一定要集成到app中,才能得到 PurchaseToken,那就错了。其实我们在Google Play Console的后台,就能获得这个 PurchaseToken 了。打开Console默认页(非单款游戏管理页面),左边的菜单中,有个 订单管理,进入 订单管理,选择你想测试的游戏的订单,点击箭头,进入订单详情,在详情中,就可以复制 PurchaseToken 进行测试了。

参考

  1. https://stackoverflow.com/questions/64217553/purchases-products-get-is-ignoring-productid-value-and-returns-null-in-productpu
  2. https://stackoverflow.com/questions/43536904/google-play-developer-api-the-current-user-has-insufficient-permissions-to-pe

C#中使用Pomelo进行MySql的原生Json查询

Mysql已经原生支持json,有5年多了。但我还没有用过,搜了一圈,MySql本身的语法还是很好写的

但是有些语言偏偏搞了很复杂的封装,比如C#。我做过的项目,主要用Pomelo库来连接MySql。而Pomelo库曾经做了一套JsonObject的方案来使用MySql的json,后来又弃用了。但是网上大量留下了JsonObject的教程,这是多么尴尬的局面。最尴尬的是Pomelo库本身并没有编写完整的文档,所以能搜到的信息,基本都是误导信息。经过一番探索,我总结一下目前正统的方案。

方案开始

首先安装必要的库,我这里使用的是Microsoft的Json序列化方案,因为它支持递归引用的序列化,所以更推荐用它来做序列化。

经过验证,以下代码是无意义的,并且可能导致运行时异常。
然后需要在Startup.cs中的ConfigureServices,添加以下代码

完整示例

最后,在需要使用json查询的位置,使用

就能生成这样的Sql代码

参考

在WinForm项目中使用Windows Runtime的方法

在WinForm项目中使用Windows Runtime的方法

最近需要在Winform项目中使用蓝牙,蓝牙模块是同事负责的,找了好多版本的蓝牙库,对BLE的支持都不好。最后发现系统直接提供了Windows.Devices.Bluetooth这个库可以用,但是只能在Universal项目中使用。试过在nuget中找到的Target.WindowsRuntime,但是根本不能用。经过一番google,发现可以用hack的方法在Winform中使用,特此记录。

PS: 我用的是vs2015,win10,.net 4.5,据说win8 vs2013也是可以的,我没有测试过。如果使用其他版本的操作系统,或者.net版本,请自行修改对应参数测试。

步骤说明

  1. 手工修改csproj项目文件
  2. 添加对Windows.XXXXX库的引用
  3. 添加project.json配置文件
  4. 添加对WindowsRuntime库的引用

修改项目文件

需要关闭项目工程文件,手工在目标csproj文件中添加如下代码

你期望编译的目标操作系统是win10,就写10.0,如果是win8,就写8.0,以此类推。

上个截图,更容易理解

添加对库的引用

这个时候,启动sln工程文件,然后右键点击引用-添加引用...,会发现,左侧的分类,多了一类Universal Windows

赶紧把需要的库加进来吧,加进来以后,发现代码中可以正常引用了。

但是会编译不过,提示

添加project.json文件

上面的错误,提示我们需要project.json,在项目中新建这个名称的json文件,然后复制下面的内容

其中的v4.5可以改成任意你需要的.net版本号。

再编译一次试试,大功告成,这样就可以顺利编译通过了。

添加对WindowsRuntime库的引用

这个时候虽然编译通过了,但是实际使用Windows相关类库的时候,还是会有问题,需要做最后一步操作来解决这个问题。

继续添加引用,并选择从文件添加,在下面的目录中,找到System.Runtime.WindowsRuntime.dll,并加入引用。

如果需要用到async/await,还需要添加对Windows.winmd的引用,在下面的目录中

这样,就可以在WinForm项目中使用Universal的类库啦。

参考资料

王翔的《设计模式》读书笔记

今天读王翔的《设计模式 - 基于C#的工程化实现及扩展》,刚把第一章读完。作为一个C#初学者和工作者,发现了55页,也就是第一章的最后一段关于依赖注入的实例代码中有一个很明显的错误。本来想直接联系作者的,可是实在找不到他的联系方式,就发在自己博客上了。如果同样读过这本书的人能看到,不胜荣幸。
代码如下:

这段代码是依赖注入。使用Attribute把外部对接口的实现注入到类中。通过修改Attribute来改变依赖。
其中第29行和第35行中,有一个明显的错误。
先从第35行说起

这行代码说明要注入ITimeProvider类型,但是我们知道接口是不能被直接实例化的。所以这里的ITimeProvider应该改成TimeProvider。
但是这个时候第35行的条件判断就出现问题了,因为我们要得到的是ITimeProvider,而Decorator给的参数是TimeProvider,这两个类型是不会相等的。
这个时候我们还必须修改第35行的代码为

通过寻找实现接口的实例,才能够真正找到我们要的Decorator。

C#动态加载DLL

利用反射进行动态加载和调用.
Assembly ass=Assembly.LoadFrom(DllPath); //利用dll的路径加载,同时将此程序集所依赖的程序集加载进来,需后辍名.dll
Assembly.LoadFile 只加载指定文件,并不会自动加载依赖程序集.Assmbly.Load无需后辍名
加载dll后,需要使用dll中某类.
Type type=ass.GetType(“TypeName”);//利用类型的命名空间和名称获得类型
需要实例化类型,才可以使用,参数可以人为的指定,也可以无参数,静态实例可以省略
Object obj = Activator.CreateInstance(type,params[]);//利用指定的参数实例话类型
调用类型中的某个方法:
需要首先得到此方法
MethodInfo mi=type.GetMethod(“MehtodName”);//通过方法名称获得方法
然后对方法进行调用,多态性利用参数进行控制
mi.Invoke(obj,params[]);//根据参数直线方法,返回值就是原方法的返回值

C#的疑问

一个C#睡前故事

从 前,在南方一块奇异的土地上,有个工人名叫彼得,他非常勤奋,对他的老板总是百依百顺。但是他的老板是个吝啬的人,从不信任别人,坚决要求随时知道彼得的 工作进度,以防止他偷懒。但是彼得又不想让老板呆在他的办公室里站在背后盯着他,于是就对老板做出承诺:无论何时,只要我的工作取得了一点进展我都会及时 让你知道。彼得通过周期性地使用“带类型的引用”(原文为:“typed reference” 也就是delegate??)“回调”他的老板来实现他的承诺,如下:

接口

现在,彼得成了一个特殊的人,他不但能容忍吝啬的老板,而且和他周围的宇宙也有了密切的联系,以至于他认为宇宙对他的工作进度也感兴趣。不幸的是,他必须也给宇宙添加一个特殊的回调函数Advise来实现同时向他老板和宇宙报告工作进度。彼得想要把潜在的通知的列表和这些通知的实现方法分离开来,于是他决定把方法分离为一个接口:

委托

不幸的是,每当彼得忙于通过接口的实现和老板交流时,就没有机会及时通知宇宙了。至少他应该忽略身在远方的老板的引用,好让其他实现了IWorkerEvents的对象得到他的工作报告。(”At least he'd abstracted the reference of his boss far away from him so that others who implemented the IWorkerEvents interface could be notified of his work progress” 原话如此,不理解到底是什么意思:))

他的老板还是抱怨得很厉害。“彼得!”他老板吼道,“你为什么在工作一开始和工作进行中都来烦我?!我不关心这些事件。你不但强迫我实现了这些方法,而且还在浪费我宝贵的工作时间来处理你的事件,特别是当我外出的时候更是如此!你能不能不再来烦我?”

于是,彼得意识到接口虽然在很多情况都很有用,但是当用作事件时,“粒度”不够好。他希望能够仅在别人想要时才通知他们,于是他决定把接口的方法分离为单独的委托,每个委托都像一个小的接口方法:

静态监听者

这样,彼得不会再拿他老板不想要的事件来烦他老板了,但是他还没有把宇宙放到他的监听者列表中。因为宇宙是个包涵一切的实体,看来不适合使用实例方法的委托(想像一下,实例化一个“宇宙”要花费多少资源…..),于是彼得就需要能够对静态委托进行挂钩,委托对这一点支持得很好:

事件

不幸的是,宇宙太忙了,也不习惯时刻关注它里面的个体,它可以用自己的委托替换了彼得老板的委托。这是把彼得的Worker类的的委托字段做成public的一个无意识的副作用。同样,如果彼得的老板不耐烦了,也可以决定自己来激发彼得的委托(真是一个粗鲁的老板):

彼得不想让这些事发生,他意识到需要给每个委托提供“注册”和“反注册”功能,这样监听者就可以自己添加和移除委托,但同时又不能清空整个列表也不能随意激发彼得的事件了。彼得并没有来自己实现这些功能,相反,他使用了event关键字让C#编译器为他构建这些方法:

彼得知道event关键字在委托的外边包装了一个property,仅让C#客户通过+= 和 -=操作符来添加和移除,强迫他的老板和宇宙正确地使用事件。

收获所有结果

到这时,彼得终于可以送一口气了,他成功地满足了所有监听者的需求,同时避免了与特定实现的紧耦合。但是他注意到他的老板和宇宙都为它的工作打了分,但是他仅仅接收了一个分数。面对多个监听者,他想要“收获”所有的结果,于是他深入到代理里面,轮询监听者列表,手工一个个调用:

异步通知:激发 & 忘掉

同时,他的老板和宇宙还要忙于处理其他事情,也就是说他们给彼得打分所花费的事件变得非常长:

很不幸,彼得每次通知一个监听者后必须等待它给自己打分,现在这些通知花费了他太多的工作事件。于是他决定忘掉分数,仅仅异步激发事件:

异步通知:轮询

这使得彼得可以通知他的监听者,然后立即返回工作,让进程的线程池来调用这些代理。随着时间的过去,彼得发现他丢失了他工作的反馈,他知道听取别人的赞扬和努力工作一样重要,于是他异步激发事件,但是周期性地轮询,取得可用的分数。

异步通知:委托

不幸地,彼得有回到了一开始就想避免的情况中来,比如,老板站在背后盯着他工作。于是,他决定使用自己的委托作为他调用的异步委托完成的通知,让他自己立即回到工作,但是仍可以在别人给他的工作打分后得到通知:

宇宙中的幸福

彼得、他的老板和宇宙最终都满足了。彼得的老板和宇宙可以收到他们感兴趣的事件通知,减少了实现的负担和非必需的往返“差旅费”。彼得可以通知他们,而不管他们要花多长时间来从目的方法中返回,同时又可以异步地得到他的结果。彼得知道,这并不*十分*简单,因为当他异步激发事件时,方法要在另外一个线程中执行,彼得的目的方法完成的通知也是一样的道理。但是,迈克和彼得是好朋友,他很熟悉线程的事情,可以在这个领域提供指导。

他们永远幸福地生活下去……<完>