[mini-blog]订阅消息的踩坑记录

有阵子没有更新我的mini-blog了,这次把推送消息那块做了些改动,小程序的模板消息即将废弃,订阅消息终于来了。

关于订阅消息

订阅消息分为一次性订阅长期订阅长期订阅就不说啦,不是个人号可以染指的。

一次性订阅消息本质和模板消息差不多,包括看了文档,接口基本上也比较相似。

一次性订阅消息最大的优势就是不再受到七天有效期的限制,同时省去了生成formId的动作,而劣势在于必须用户主动允许,且允许一次只能发送一条信息。mo

[mini-blog]订阅消息的踩坑记录_第1张图片
截图1

这样的方式其实对用户是友好的,对于自己不想要的服务通知消息都可以屏蔽,而对于自己需要的消息可以允许发送,甚至可以选择总是保持,不再询问

而对于小程序的开发和运营来说,就要考虑订阅消息的质量,是否能让用户心甘情愿的去点击允许,并能不再询问

正式接入

mini-blog做试验,准备在提交评论的时候让用户选择是否可以接受评论消息提醒。

但有点可惜的是现有模板中没有最契合这种场景的消息模板,所以只能拿留言通知这个模板凑合用了「自己申请评论提醒的模板多数是被拒的」。

[mini-blog]订阅消息的踩坑记录_第2张图片
截图2

至于接入,还是比较简单的,文档比较详细的。

首先通过wx.requestSubscribeMessage这个API来唤起订阅消息界面。注意一定要用户发生点击行为或者发起支付回调后,才可以调起订阅消息界面。

用户操作后回调结果会告诉你该模版用户是否同意订阅「值包括acceptrejectbanaccept表示用户同意订阅该条id对应的模板消息,reject表示用户拒绝订阅该条id对应的模板消息,ban表示已被后台封禁」

所以当用户accept之后,你就发送该模板的订阅消息了,用户会收到。

发送订阅消息可以通过云调用的方式「但现在看文档貌似找不到了,不懂什么情况」

const result = await cloud.openapi.subscribeMessage.send({
  touser: openId,
  page: event.page,
  data: {
    name1: {
      value: nickName
    },
    thing2: {
      value: event.content
    },
    time3: {
      value: event.createDate
    }
  },
  templateId: event.templateId
})

不出意外,服务通知里就能收到消息了。

[mini-blog]订阅消息的踩坑记录_第3张图片
截图3

重点:哪些坑

订阅消息大致流程其实和模版消息差不多,但坑还是挺多的,这里总结下,避免大家接入的时候踩坑。

1.服务类目

小程序本身的服务类目决定你只能选择该服务类目下的订阅消息模板。公共模板库只出现绑定的类目下的模板。

[mini-blog]订阅消息的踩坑记录_第4张图片
截图4

2.调试

订阅消息只能通过真机调试,开发者工具不支持。

截图5

3.本质还是formId的思路

即时用户选择了不再询问,wx.requestSubscribeMessage后台还是会默认调用,只是没有弹框,也不会生成formID,这样对于我们来说不知道用户点了几次,相对的,我们也不知道可以给用户发送多少条成功的订阅消息「所以,以前是记录formID,现在依旧要记录用户点击次数,本质没差」

4.表单提交事件不支持

这也是比较坑,原本我的评论提交按钮是通过表单提交,但无法唤起订阅消息的弹框,逛了社区才知道不支持,只能改为bindtap事件

[mini-blog]订阅消息的踩坑记录_第5张图片
截图6

5.消息内容不支持数字

这个也好奇葩,在测试留言通知这个消息模板的时候,发现偶尔会提示data.name1.value invalid的错误,一直匪夷所思,明明都已经赋值,且日志打出来也有的,怎么会报这个错误呢,后来发现我的昵称是Bug生活2048,当我把2048去掉之后就成功发送了。

后来仔细看了文档才发现,订阅消息参数值的内容有严格限制,其中姓名data.name是不能包含数字的。

[mini-blog]订阅消息的踩坑记录_第6张图片
截图7

总结

订阅消息使用场景还是很多的,后面可以利用它慢慢丰富我的小程序。

文档一定要仔细看,不然小坑不断,很浪费时间。

你可能感兴趣的:([mini-blog]订阅消息的踩坑记录)