基于融云的好友关系实现

好友关系是社交 IM 中 非常重要的一个模块， 一般意义上的理解即是成为好友关系以后。才能进行聊天沟通  但是对于融云来说 只要你给了的 userid , 我知道了对方的 userid 就跟跟对方 发起聊天也就是发起会话。 我们不妨点击来参考一下 bob 的讲解好友关系的博客  你的 App 怎么去定义好友关系  就看 你和你的 server 怎么去维护这个关系 和 userid 了 下面我会通过 app 实例给大家讲解一下好友关系的实现

一 : 实例展示 

gif 无法预览的同学请点击右边链接 : 这边不得不吐槽一下涛哥的平台,我上传的gif才1.7MB就死活上传不上去.辛苦大家点我

下面对这个动图做一下讲解 

1 我们首先可以清晰的看到 两个端的的用户信息 然后我点击了好友 目前可以清晰的看到现在好友列表里面的是空的没有一个好友数据

2 接下来 我点击了社交 社交里面有个 添加好友 我输入 shenzhen  模糊查询出了两个好友点击我们正在登陆的 shenzhen 添加好友 输入我需要添加的好友信息 shenzhen ni hao

3 这个时候重点来了 beijing 给 shenzhen 发送好友请求同意后 我们可见 验证消息上面的 未读消息小红点出现了 我们点击进去 看到 beijing 申请添加我为好友了

4 此时我们来看看 beijieng 端的 验证消息模块里面 有什么变化 第一次是展示的 请求添加 也就是我申请添加发出去了 等待对方响应 当 shenzhen 点击同意添加以后 此时我再 下拉刷新了 我发出去的 申请添加状态编程了 已添加 目前应该算是整个好友添加以及被同意的完整流程走完了

5 我们再来点击 好友列表  发现两个端彼此的好友列表里面都有了对方 其实整个好友列表 item 下面就是藏了一个 userid 点击后 会调用 stratPrivatechat 这就是所谓的 怎么控制 userid 的出现来维护和实现好友关系

6 最后我们再来看会话列表 会话列表 此时也收到了服务端发来的同意对方成为好友的消息 以及我添加对方时候的验证消息  

注: 好友关系是非常灵活的 建议大家不要盲目被上面的概念固定死了思维 也可以自己有更好的方式去实现, 用目前的接口实现的好友关系 没有立即拒绝添加  只有 同意添加 和 默认不处理 如果你的产品需求有立即拒绝添加 这个需要你和你的后台看怎么去设计接口了

二 : 代码实现

相信大家看了上面的 gif 和 1-6 点的概念 脑海里面已经比较清楚好友关系的实现了  方便大家理解得更加深刻 这边再对代码 和 接口做一下梳理(接口为 Demo server的 接口) 自己的 App 应该有自己的接口

http://webim.demo.rong.io/ request_friend

请求方式：POST
参数：(Integer $id  String message)
返回成功json：

{"code":200}

{"code":304,"message":"unknow error"}

你应该必须有个请求加对方为好友的接口 当然搜索查询用户的接口肯定也得有 上面的代码片段是请求加对方为好友 我们再来看看接收到 这个好友申请的时候 服务端做了什么事

服务端有个 好友列表  

http://webim.demo.rong.io/get_friend

请求方式：GET
参数：
返回成功json：
//status : 1 好友, 2 请求添加, 3 请求被添加, 4 请求被拒绝, 5 我被对方删除

{
    "code": 200,
    "result": [
        {
            "id": "6754",
            "email": "yangpan@feinno.com",
            "username": "Ariel@iPhone",
            "portrait": "http://www.gravatar.com/avatar/3f56d1043edd4b9657c465ac7a507067?s=82",
            "status": "1"
        },
        {
            "id": "19237",
            "email": "18919026893@163.com",
            "username": "hahajaj",
            "portrait": "http://www.gravatar.com/avatar/6405153265d25fd4b6dccfacf0fe410c?s=82",
            "status": "1"
        }
    ]
}

这里主要看维护的状态的变化  当你发起 添加对方的好友申请以后 服务端 好友表的 status 这个字段有就有值了 目前是在两个端看到的是不一样 请求端是 请求添加 接收到这个被添加的请求端的 状态是 请求被添加  此时服务端还做了一件事 发了一个 添加好友的消息(这里的消息为融云内置消息) 给被请求好友端 被请求好友端 收到这个消息(接收消息的监听) 去刷新好友列表的 status 状态

1

 @Override
    public boolean onReceived(Message message, int i) {
        MessageContent messageCOntent= message.getContent();
        if (messageContent instanceof ContactNotificationMessage) {
            BroadcastManager.getInstance(mContext).sendBroadcast(FRIEND_MESSAGE);
        }

上面的代码片段是接收消息的监听 收到 服务端推来的好友消息后 发送一个广播去通知刷新好友列表 在上面的 gif 图当中也就是点开验证消息后的界面

http://webim.demo.rong.io/process_request_friend

请求方式：POST
参数：(Integer $id, Boolean $is_access)
O false 不接收
1 true接收
返回成功json：

{"code":200}
{"code":111,"message":"credential is error"}
{"code":306,"message":"unknow error"}

上面的 接口也有是当我收到对方加我为好友的消息后 在服务端存储的状态为 3 也就是请求被添加时候使用的 这个时候 我可以发个请求同意对方添加我为好友 去改变服务端 存储的 status 这个时候状态的 1 也就是你们互相为好友关系了 其实说白了也就是 我请求 和 被请求都是去即使的查询服务端存储的好友关系的 status 如果为 1 我们就把对方的 userid 

做成一个 好友实体 展示在好友列表了 

好了 ，相信你此时如果认真仔细的研读了上面的 gif 图片和 和 概念 还有接口代码 , 我相信好友关系的实现对你来说并不是难事了！

相关资料提供:

笔者演示 gif 的开源项目地址 : https://github.com/13120241790/Seal 欢迎 star or fork 

融云 Demo server 地址：https://github.com/rongcloud/demo-server-php