During this period, the team has been doing some product design and development on the WeChat side, which of course also includes certain operational work. I have done a lot of things, including micro business cards, micro ticket grabbing, micro activities, micro recruitment and other small cases.
What I want to talk about today is the most active light game we play in WeChat - micro-scratch prizes. This thing can be used to scratch books, tickets, packages, and is also used by customers. Scratch the phone bill.
Let’s take a look at the picture first and get a feel for the specific appearance:
## And what I want to share is our specific development and implementation process based on WeChat. Some pitfalls that Html5 WebApp needs to overcome:
The basic rules of this mini-game are: users are limited to 2 scraping times per day (free scraping once and scratching again after sharing), and they can scrape prizes every day
To this end, the idea we hope to achieve is to first limit the game to only WeChat. The implementation code is as follows:
if (!HttpContext.Current.Request.Browser.IsMobileDevice) { var result = new RedirectResult("url", true); filterContext.Result = result; return; } if (string.IsNullOrEmpty(HttpContext.Current.Request.UserAgent)) { var result = new RedirectResult("url", true); filterContext.Result = result; return; } if (HttpContext.Current.Request.UserAgent.IndexOf("MicroMessenger") == -1) { var result = new RedirectResult("url", true); filterContext.Result = result; return; }
This trick passed UserAgent's judgment idea seems to be used by many people on the Internet, but there are still many pitfalls if it is not used:
1. Basic problem: There is no problem with IOS and mainstream Android machines, but when it comes to Windows phone, just use WeChat directly Unable to play after jumping out. The reason is that the default UserAgent in WeChat is MicroMessenger
, which does not exist in the WeChat version of these machines, so in order to solve the problem of windows phone, we added the following code:
var useragent = HttpContext.Current.Request.UserAgent.ToLower(); if (useragent.IndexOf("Windows Phone".ToLower()) != -1) { base.OnActionExecuting(filterContext); return; }
2. Advanced question: Some experts directly use some plug-in tools to forge the UserAgent of MicroMessenger, so that theoretically it can be played in any browser that can open web pages (thanks to group friend @Abao's Selfless), to solve this problem, we use the interface in WeChat's SDK: only when the user uses it in WeChat, the control initialization and scratching operation is performed, otherwise other terminal browsing will always be in the loading state.
dataForWeixin.callback = function () { //一些初始化的操作 }
Regarding the interface of WeChat, please read the original text directly. I will not post the code directly here, otherwise it will not be posted.
The above idea has done a lot, but there is still a very fatal bug that has not been solved for our business rules. Thank you also for the positive feedback from @冰milkteachildren's shoes.
This bug is that as long as the user manually clears the cookies and cached information in WeChat, and then re-enters the event, he can scratch the prizes unlimited times. In theory, he is 100% sure to win. This is because my rules put the basis for judging whether the current WeChat user has scratched the prize in the cookie. It seems that there is no other way. We want to use openid, but our WeChat subscription account cannot get openid if we come from Moments. There is still an appeal problem.
In order to solve this problem, we finally found an idea, borrowing the authorization interface of the WeChat service account. The basic idea is as follows:
The user enters the page loading=》The program calls our other WeChat service The authorization interface of the number, returns openid => Store the openid in the cookie (if it does not exist or expires, re-execute the previous steps) => Determine how many times the current activity has been scraped from the database based on the openid. At the same time, this process will automatically determine the user Whether to play games in WeChat, otherwise the callback will always be in the loading state. The whole process is relatively smooth after using it. Here is the authorization-related code:
#region 微信授权 public ActionResult WeixinLogin(string CurrentUrl) { string url = WeixinOAuth2.Authorize(Server.UrlEncode(CurrentUrl)); return RedirectPermanent(url); } public ActionResult WeixinCallback() { if (!string.IsNullOrEmpty(Request["code"])) { // 获取AccessToken参数 var param = WeixinOAuth2.GetAccessToken(Request["code"]); string url = string.Format("{0}#access_token={1}&openid={2}&expires_in={3}&state={4}", ConfigHelper.GetValue("Weixin_Callback"), param.access_token,param.openid,param.expires_in, Server.UrlDecode(Request.QueryString["state"])); //重新跳转到回调页面,保持腾讯登录相同风格 return Redirect(url); } return View(); } ////// 授权请求页面 /// /// 0为获取微信基本信息 1为获取微信openid接口 ///public static string Authorize(string ReturnUrl) { string url=string.Format("//m.sbmmt.com/{0}&redirect_uri={1}&response_type=code&scope=snsapi_base&state={2}#wechat_redirect", Weixin_AppKey, Weixin_GetOpenIDCallback, ReturnUrl); return url; } #endregion
At this point, it is basically possible to solve the problem of how to determine the uniqueness of the current user in WeChat. The only risk to this solution is the smoothness and stability of WeChat’s interface.
Of course, there are many other problems that need to be overcome one by one during the entire development process. For example, the implementation of callback after sharing on WeChat is used by many friends. For example, we even need to support grps for this small game. The next step is to access the process. It is impossible to deal with those big game frameworks, how to do this, etc. I plan to write some articles to share these later. I have enough things today, so I will take a rest for now.
To share more about several pitfalls in developing Html5 light games on WeChat, please pay attention to the PHP Chinese website for related articles!