2018年08月11日
在原来的分享接口中,用户发起分享动作之后,可以通过 success 、fail、complete等回调来判断用户是否完成了最后的分享动作。通过这个能力,开发者是可以将产品交互在分享这个能力上做得比较自然和顺畅。但却被上述情形的小程序滥用。在我们权衡了分享功能带来的利弊后,我们打算回收这个能力。调整为:我们将不再支持分享回调参数 success 、fail 、complete 。即开发者无法判断用户最终是否完成了分享动作,也无法获取到分享成功后的回调参数shareTicket 。
接下来将与大家介绍此次分享功能调整后,小程序的调整建议。
对应小程序调整建议
此次调整可能影响到两种分享功能的用法。 第一种:通过判断用户最终是否有分享来做分支逻辑的小程序。 例如,通过判断 success 回调触发,来判断用户是否分享出去了,进而给奖励,如果用户没有分享出去则不给奖励。这类功能是我们平台不倡导的,后续将没有办法实现。 如果是需要在分享完成后变更当前页面的状态,可以适当调整交互方案。例如过去赠送代金券后显示“等待领取”等应用场景,可以改成在分享后继续保留“赠送”按钮,但提示用户一个代金券只能被一人领取,重复赠送无效。 第二种:获取用户分享之后的 shareTicket ,换取群唯一标识 openGId ,进而显示对应群的相关信息的小程序。 例如,部分小程序实现了群内的排行信息,通过分享小程序到某个群里,可以查看该群内成员的排行榜。此次调整后,用户分享完成后无法立刻显示该群的排行榜信息,但仍可在用户从群消息点击进入小程序时显示该群的排行榜信息。 因此建议适当修改产品流程,在用户分享小程序之时,提示用户可进入群内查看群排行等信息。避免调整策略生效之后带来的交互不完整影响。
本文并非原创,原文来自于公众号微信开发者,作者小k、LastLeaf