{
"uuid": "设备唯一码,第一次安装应用时,生成存储与用户存储,后续开启查找该文档,如果存在则直接使用,不存在则重新生成存储。该方案可避免出现获取设备信息权限。",
"device": "Android、ios、pc、web、小程序...",
"username": "用户标识,该服务不对接用户体系,所以改标识作为用户唯一码使用。",
"pushToken": "厂商通道的推送id。"
}
注册推送服务时
username
是否可以保证唯一。
{
"account": "根据请求参数生成,用于登录im和声网"
}
服务端删除(假)该uuid对应的account以及pushToken
保证当前设备不再收到消息,但是其它设备可以
关闭后,所有消息只走im,不再走厂商推送。
直观表现在与,app端如果不打开应用,则无法收到消息。
其实可以理解为过滤,也是和谐功能的入口。
也是群消息的重组转发所在。
{ "id": "bukjsafabsj4541536$#@", "from": "user001", "to": "推送开发组", "target": "user001", "type": "text", "content": { "text": "" }, "timestamp": 1675416709033, "isBackground": false }
{ "id": "bukjsafabsj4541536$#@", "from": "推送开发组", "to": "user002", "target": "user001", "type": "text", "content": { "text": "" }, "timestamp": 1675416709033, "isBackground": false }
这里需要考虑,怎么能把account和username等信息关联起来,保证查询离线消息时候,可以把其它设备的消息同步查询出来,并且不会出现错乱。
注册推送服务时
username
是否可以保证唯一。
{
"timeStamp": "",
"account": ""
}
返回所有缓存的离线消息,自
timeStamp
开始至当前消息返回消息的方式,是直接走接口返回值携带,还是通过im发送。
{
"startTimeStamp": "",
"endTimeStamp": "",
"account": "",
"target": ""
}
target
非必传,区分单个用户的消息,还是全部消息
{
"timeStamp": "当前时间戳",
"account": "",
"target": "",
"start": 1,
"end": 10
}
从当前时间戳开始,向上查找第1到10条数据。
使用场景,单聊上滑查看历史消息。
应用对接,直接调用接口发消息
系统通知
部分业务变更通知