项目地址
主项目：https://github.com/boredream/BDChat
依赖主model：https://github.com/boredream/bdcodehelper
服务端代码：https://github.com/boredream/BoreIMCloud
欢迎 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实现）
展示页面
登陆.png
会话列表.png
会话页面.png
会话详情.png
发起群聊.png
搜索好友.png
新的朋友.png
详细资料.png
我的.png
