提交关注和更新通讯录的前后端交互逻辑
2016-07-18 16:11:02 0 举报
前端:用户在界面上点击“提交关注”或“更新通讯录”,前端会收集相关信息(如用户ID、联系人信息等),然后发起请求,将信息发送到后端。 后端:接收到前端的请求后,后端首先验证请求的合法性和完整性,如检查用户是否有权限进行此操作,信息是否完整等。验证通过后,后端会执行相应的操作,如添加关注或更新通讯录。操作完成后,后端会返回一个响应给前端,告知操作的结果。 前端:接收到后端的响应后,前端会根据响应的结果更新界面,如显示“关注成功”或“通讯录更新成功”等提示信息。如果响应表示操作失败,前端会显示相应的错误信息,并指导用户如何操作。
作者其他创作
大纲/内容
收到新的消息(白条通知或普通消息)
弹出配对页面
Y
N
结束
是否已关注过
收到消息时,更新本地通讯录1、理论上,能收到对方消息,说明没有将对方加入黑名单2、结合必须是好友才能发消息的逻辑,基本可断定此人是我的好友3、因此如果发现对方不在通讯录里,就可以直接更新4、如果未关注过对方,则对方在我的融云黑名单里,对方消息发送会失败,提示对方,不是好友,发送失败(可在判断用户信息是否更新逻辑里一起进行)
交友卡片模块?
将目标用户加入我的好友列表加我加入目标用户的好友列表
后续操作需要redis事务操作
更新通讯录
是否在通讯录中
用户头像、昵称是否变化
App端
设置任务:同步redis数据到mysql进行持久化
目标用户是否已关注过我
有新的好友配对数据?
循环是否有关注数据
提交关注和更新通讯录的前后端交互逻辑
异步等到返回值?
Start(收消息)
提交关注数据
将目标用户加入我的关注列表加我加入目标用户的粉丝列表
Start(提交关注)
Server端
发送配对白条通知消息
避免发送多次通知如:拉取到交友卡片后,又去别的入口关注了目标用户
多个配对数据时:1、只有最后一个弹出配对页面2、其它模拟本地通知

收藏

收藏
0 条评论
下一页