一. 1.0版本和2.0版本的区别
uni-push1.0是开发者的代码直接调用个推的URL,执行消息推送,这个过程相对繁琐且难以理解。
比如:
- 不懂原生开发的开发者,无法理解什么是intent。
- 给不同的手机厂商,传递的参数字段是不同的;比如有大量的开发者希望实现语音播报功能,华为手机推送渠道需要传递
["/message/android/notification/sound"] = '/raw/' + sound,小米渠道需要传递["/extra.sound_uri"] =android.resource://{sound}`。- 角标设置:iOS设置角标传递的参数是 auto_badge = badge,华为设置角标设置的参数是 ["/message/android/notification/badge/class"] = "io.xxx.xxx";....
- ...
uni-push2.0应需而生,他就是一个nodejs版的push服务端sdk,封装了个推的服务端接口。直接调用简单的api(免鉴权),即可实现,原本要写一大堆难以理解的代码才能实现的功能。
如果你的业务逻辑使用uniCloud开发的项目,直接用云函数调用api即可。
如果业务逻辑不是使用uniCloud开发,可以直接将uni-push sdk 即引用uni-push2.0的扩展库的云函数URL化,变成http接口,再由原来的php、java、python、go...语言代码调用这个接口。此外,假如你仍然坚持要:自己直接调用个推的接口,执行消息推送。那么直接使用旧版的uni-push1.0即可。
二、1.0版本的使用
因为需要用到自己调用接口,服务器做轮询然后再通知手机。
- 在项目manifest.json中勾选Push模块。
- 在DCLOUD开发者中心开通uniPush功能。
- 申请iOS推送证书,申请一个发布证书好了,通用。
- 在DCLOUD开发者中心中配置证书
- 直接就可以测试推送,记得重新打自定义基座。
三、服务端推送
需要用到的数据就是这几个值,MasterSecret这个值只有在1.0才有。
推送api:cid单推body参数参考
{
"request_id": "请填写10到32位的id",
"audience": {
"cid": [
"请输入clientid"
]
},
"settings": {
"ttl": 3600000,
"strategy": {
"default": 1
}
},
"push_message": {
//此格式的透传消息由 unipush 做了特殊处理,会自动展示通知栏。开发者也可自定义其它格式,在客户端自己处理。
"transmission": "{title:"标题",content:"内容",payload:"自定义数据"}"
},
"push_channel": {
"android": {
"ups": {
"notification": {
"title": "安卓离线展示的标题",
"body": "安卓离线展示的内容",
"click_type": "intent",
//注意:intent参数必须按下方文档(特殊参数说明)要求的固定格式传值,intent错误会导致客户端无法收到消息
"intent": "请填写固定格式的intent"
}
}
},
"ios": {
"type": "notify",
"payload": "自定义消息",
"aps": {
"alert": {
"title": "苹果离线展示的标题",
"body": "苹果离线展示的内容"
},
"content-available": 0,
"sound": "default"
},
"auto_badge": "+1"
}
}
}
设备在线时走个推通道下发push_message信息,设备离线时走厂商通道下发push_channel信息。
参考文档:鉴权API、推送API、uniPush1.0常见问题、uniPush使用指南