好友關係是社交 IM 中 非常重要的一個模組， 一般意義上的理解即是成為好友關係以後。才能進行聊天溝通  但是對於融雲來說 只要你給了的 userid , 我知道了對方的 userid 就跟跟對方 發起聊天也就是發起會話。 我們不妨點選來參考一下 bob 的講解好友關係的部落格  你的 App 怎麼去定義好友關係  就看 你和你的 server 怎麼去維護這個關係 和 userid 了 下面我會通過 app 例項給大家講解一下好友關係的實現

一 : 例項展示 

下面對這個動圖做一下講解 

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": "[email protected]",
            "username": "[email protected]",
            "portrait": "http://www.gravatar.com/avatar/3f56d1043edd4b9657c465ac7a507067?s=82",
            "status": "1"
        },
        {
            "id": "19237",
            "email": "[email protected]",
            "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"}

做成一個 好友實體 展示在好友列表了 

好了 ，相信你此時如果認真仔細的研讀了上面的 gif 圖片和 和 概念 還有介面程式碼 , 我相信好友關係的實現對你來說並不是難事了！

相關資料提供:

筆者演示 gif 的開源專案地址 : https://github.com/13120241790/Seal 歡迎 star or fork 

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