專案地址
主專案：github.com/boredream/B…
依賴主model：github.com/boredream/b…
服務端程式碼：github.com/boredream/B…
歡迎 Star和Follow~
注意：
- 網路框架、常用工具類封裝在了依賴主model：bdcodehelper中了，是單獨放在一個git專案裡的，因此需要手動下載然後複製到主專案目錄下。
- 服務端程式碼需要登入LeanCloud才能部署，因此如果需要自定義修改重新部署請參考LeanCloud相關文件自行申請賬號替換配置然後部署。
專案總結
開發週期：2.5周
7.3 ~ 7.20
（實際開發天數：10 天）
頁面：15個
- Splash頁面
- 登入頁面
- 忘記密碼
- 註冊頁面
- 會話列表（融雲）
- 通訊錄
- 我的
- 會話頁面（融雲基礎上稍微修改）
- 會話詳情
- 成員列表修改頁面
- 新的朋友
- 新增好友
- 好友詳情
- 修改資訊
- 修改暱稱
介面：14個
其中雲引擎方法5個（服務端需要些程式碼）
存在的問題
- 類似的頁面比如通訊錄和新增好友時候的好友列表，不知道咋提取封裝更好。
是直接複用同一個頁面？同一個Adapter？還是隻同一個ViewHolder - RxJava使用不夠熟練
- 資料返回頁面如果不在了，怎麼處理更好？不太想用RxLifeCycler的那套
- 圖片壓縮的東西，因為是用到了Glide所以需要Context物件，咋放到presetner裡呢~
複雜的業務分析
最核心的部分其實是會話列表聊天頁面啥的，但是融雲已經封裝好了，這裡本著實用的角度就不重複造輪子了，直接使用~
個人覺得最麻煩的點在於好友關係的處理
就是申請新增、接受、新的好友等相關業務上
好友關係設計
服務端儲存一個好友關係FriendRelation表，仨欄位，srcUser, targetUser, relation
其中relation欄位：
- -1 src申請加target好友
- 1 互相為好友關係
【新增好友流程】
情景一，新的新增
- A通過暱稱或其他資訊搜尋到使用者B
- A呼叫介面申請新增好友B
- 服務端先判斷好友關聯式資料庫中AB是否有關係
- 如果已經是好友，則返回已新增提示
- 如果A曾經向B提交過申請，則返回成功申請提示，但是資料庫中不再重複新增好友關係
- 如果是B已經向A提交過申請，則直接relation=1雙方改為好友
- 如果雙方沒關係，則表中插入一條資訊 AUser BUser -1，代表A向B發出了好友申請。同時向B傳送一條IM系統訊息“xxx申請新增您為好友”
情景二，同意
- B收到A的好友申請，在新的好友中顯示
- 同意新增好友
服務端接受到B的同意請求後，將A和B的關係修改為好友，即表中的對應資料修改為 AUser BUser 1
【新的好友】
只有兩種情況：對方加我了，顯示“同意”、同意後顯示“已新增”
注意，我申請加別人不在新的好友中顯示
所以獲取新的好友列表的服務端設計為：
- 查詢tarUser是我的所有關係列表資料，且relation=-1代表其他人對當前使用者提交的好友申請，然後返回所有的申請使用者
- “已新增”情況來源於本地資料庫，只有在收到請求且同意後才修改展示（本功能2.0實現）
展示頁面
