基于【LeanCloud + 融云】的IM聊天应用 v1.0

项目地址

主项目: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 互相为好友关系

【添加好友流程】
情景一,新的添加

  1. A通过昵称或其他信息搜索到用户B
  2. A调用接口申请添加好友B
  3. 服务端先判断好友关系数据库中AB是否有关系
  4. 如果已经是好友,则返回已添加提示
  5. 如果A曾经向B提交过申请,则返回成功申请提示,但是数据库中不再重复添加好友关系
  6. 如果是B已经向A提交过申请,则直接relation=1双方改为好友
  7. 如果双方没关系,则表中插入一条信息 AUser BUser -1,代表A向B发出了好友申请。同时向B发送一条IM系统消息“xxx申请添加您为好友”

情景二,同意

  1. B收到A的好友申请,在新的好友中显示
  2. 同意添加好友
    服务端接受到B的同意请求后,将A和B的关系修改为好友,即表中的对应数据修改为 AUser BUser 1

【新的好友】
只有两种情况:对方加我了,显示“同意”、同意后显示“已添加”
注意,我申请加别人不在新的好友中显示
所以获取新的好友列表的服务端设计为:

  • 查询tarUser是我的所有关系列表数据,且relation=-1代表其他人对当前用户提交的好友申请,然后返回所有的申请用户
  • “已添加”情况来源于本地数据库,只有在收到请求且同意后才修改展示(本功能2.0实现)

展示页面

基于【LeanCloud + 融云】的IM聊天应用 v1.0_第1张图片
登陆.png
基于【LeanCloud + 融云】的IM聊天应用 v1.0_第2张图片
会话列表.png
基于【LeanCloud + 融云】的IM聊天应用 v1.0_第3张图片
会话页面.png
基于【LeanCloud + 融云】的IM聊天应用 v1.0_第4张图片
会话详情.png
基于【LeanCloud + 融云】的IM聊天应用 v1.0_第5张图片
发起群聊.png
基于【LeanCloud + 融云】的IM聊天应用 v1.0_第6张图片
搜索好友.png
基于【LeanCloud + 融云】的IM聊天应用 v1.0_第7张图片
新的朋友.png
基于【LeanCloud + 融云】的IM聊天应用 v1.0_第8张图片
详细资料.png
基于【LeanCloud + 融云】的IM聊天应用 v1.0_第9张图片
我的.png

你可能感兴趣的:(基于【LeanCloud + 融云】的IM聊天应用 v1.0)