{
"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 > } > > ``` > > ```json > { > "id": "bukjsafabsj4541536$#@", > "from": "推送开发组", > "to": "user002", > "target": "user001", > "type": "text", > "content": { > "text": "" > }, > "timestamp": 1675416709033, > "isBackground": false > } > > ``` > > > > 这里需要考虑,怎么能把account和username等信息关联起来,保证查询离线消息时候,可以把其它设备的消息同步查询出来,并且不会出现错乱。 > > 注册推送服务时`username`是否可以保证唯一。 ## 和谐词配置 > ## 离线消息 ### 请求参数
json { "timeStamp": "", "account": "" }
> 返回所有缓存的离线消息,自`timeStamp`开始至当前消息 > > 返回消息的方式,是直接走接口返回值携带,还是通过im发送。 ## 历史消息 ### 请求参数
json { "startTimeStamp": "", "endTimeStamp": "", "account": "", "target":"" }
> `target`非必传,区分单个用户的消息,还是全部消息
json { "timeStamp": "当前时间戳", "account": "", "target":"", "start":1, "end":10 } ```
从当前时间戳开始,向上查找第1到10条数据。
使用场景,单聊上滑查看历史消息。
应用对接,直接调用接口发消息
系统通知
部分业务变更通知