有陣子沒有更新我的
mini-blog
了,這次把推送消息那塊做了些改動,小程序的模板消息即將廢棄,訂閱消息終於來了。
關於訂閱消息
訂閱消息分爲一次性訂閱
和長期訂閱
,長期訂閱
就不說啦,不是個人號可以染指的。
而一次性訂閱消息
本質和模板消息
差不多,包括看了文檔,接口基本上也比較相似。
一次性訂閱消息
最大的優勢就是不再受到七天有效期
的限制,同時省去了生成formId
的動作,而劣勢在於必須用戶主動允許,且允許一次只能發送一條信息。mo
這樣的方式其實對用戶是友好的,對於自己不想要的服務通知消息都可以屏蔽,而對於自己需要的消息可以允許發送,甚至可以選擇總是保持,不再詢問
。
而對於小程序的開發和運營來說,就要考慮訂閱消息的質量,是否能讓用戶心甘情願的去點擊允許
,並能不再詢問
。
正式接入
拿mini-blog
做試驗,準備在提交評論的時候讓用戶選擇是否可以接受評論消息提醒。
但有點可惜的是現有模板中沒有最契合這種場景的消息模板,所以只能拿留言通知
這個模板湊合用了「自己申請評論提醒的模板多數是被拒的」。
至於接入,還是比較簡單的,文檔比較詳細的。
首先通過wx.requestSubscribeMessage這個API來喚起訂閱消息界面。注意一定要用戶發生點擊行爲或者發起支付回調後,纔可以調起訂閱消息界面。
用戶操作後回調結果會告訴你該模版用戶是否同意訂閱「值包括accept
、reject
、ban
。accept
表示用戶同意訂閱該條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
})
不出意外,服務通知裏就能收到消息了。
重點:哪些坑
訂閱消息大致流程其實和模版消息差不多,但坑還是挺多的,這裏總結下,避免大家接入的時候踩坑。
1.服務類目
小程序本身的服務類目決定你只能選擇該服務類目下的訂閱消息模板。公共模板庫只出現綁定的類目下的模板。
2.調試
訂閱消息只能通過真機調試,開發者工具不支持。
3.本質還是formId的思路
即時用戶選擇了不再詢問
,wx.requestSubscribeMessage後臺還是會默認調用,只是沒有彈框,也不會生成formID
,這樣對於我們來說不知道用戶點了幾次,相對的,我們也不知道可以給用戶發送多少條成功的訂閱消息「所以,以前是記錄formID,現在依舊要記錄用戶點擊次數,本質沒差」
4.表單提交事件不支持
這也是比較坑,原本我的評論提交按鈕是通過表單提交,但無法喚起訂閱消息的彈框,逛了社區才知道不支持,只能改爲bindtap事件
。
5.消息內容不支持數字
這個也好奇葩,在測試留言通知
這個消息模板的時候,發現偶爾會提示data.name1.value invalid
的錯誤,一直匪夷所思,明明都已經賦值,且日誌打出來也有的,怎麼會報這個錯誤呢,後來發現我的暱稱是Bug生活2048
,當我把2048
去掉之後就成功發送了。
後來仔細看了文檔才發現,訂閱消息參數值的內容有嚴格限制,其中姓名data.name
是不能包含數字的。
總結
訂閱消息使用場景還是很多的,後面可以利用它慢慢豐富我的小程序。
文檔一定要仔細看,不然小坑不斷,很浪費時間。