• What
    • 1. 开发者需要自己实现聊天界面
    • 2. 开发者需要接入消息云安全认证
    • 3. 开发者需要自己定义消息体格式
  • Why
    • 1. 为什么不提供聊天界面
    • 2. 为什么需要开发者自定义消息格式
    • 3. 为什么开发者不需要维护帐号映射
      • 举例说明:

    What

    1. 开发者需要自己实现聊天界面
    2. 开发者需要接入消息云安全认证
    3. 开发者需要自己定义消息体格式

    Why

    1. 为什么不提供聊天界面
    1. 我们不提供统一的聊天UI,基于以下理由:
    2. 1. APP都有自己的风格,万紫千红才是春,一套UI显然不能满足大家需求
    3. 2. UI对于开发者而言,开发成本并不高
    4. 3. 开发者自行开发UI,可100%自定义界面和功能
    5. 所以,我们认为由开发者根据自己APP的风格来自定义UI比较合适
    2. 为什么需要开发者自定义消息格式
    1. 我们不提供统一的消息格式,而由开发者自定义消息格式,基于以下理由:
    2. 1. APP所需消息功能各异
    3. 有的需要已读,有的则不需要已读功能,所以我们提供了推荐的消息格式,
    4. 由开发者根据自己情况定义最适合自己的消息格式
    5. 2. MIMC(小米即时消息云)应用场景广泛
    6. IM聊天只是MIMC的一个特殊使用场景,还存在IoT信令传递等各种消息传递场景
    7. 所以,我们认为由开发者根据自己APP的实际需求,参考我们推荐的消息格式,来定义消息体格式比较合适
    3. 为什么开发者不需要维护帐号映射
    1. MIMC用户登录/消息收发等都使用APP帐号系统里的账号IDMIMC帐号体系对APP开发者透明!
    2. APP开发者接入其他IM提供商时,要访问IM提供商服务,主动为每一个appAccount注册一个新的ID
    3. 开发者还需要在自己的后台系统储存以下信息:
    4. 1. appAccount --> IM提供商系统内ID
    5. 2. IM提供商系统内ID + IM提供商系统内登录密码(明文)
    6. 这样做有以下弊端:
    7. 1. 开发者维护帐号映射成本高,一旦出错难以修正
    8. 2. 明文存储登录密码,安全性极差,开发者承担极高的安全风险
    9. 所以,MIMC(小米即时消息云)没有采取以上方案,MIMC自维护帐号映射,保证MIMC ID对开发者透明
    10. 这不仅降低了开发者负担,增强了帐号安全性,还能让开发者感觉MIMC就是"自己的"消息系统
    举例说明:
    1. 假设开发者拥有某APP"言士文学",集成了MIMC(小米即时消息云)服务
    2. 假设"言士文学"在小米开放平台注册的appId"580012345678"
    3. 某用户A登录"言士文学"所用帐号名为手机号"13800000001"
    4. 某用户B登录"言士文学"所用帐号名为手机号"13800000002"
    5. 当用户A首次登录"言士文学":
    6. userA = new User("580012345678", "13800000001");
    7. userA.login();
    8. MIMC后台服务会为A创建MIMC ID("8049600000000001"),并维护以下映射:
    9. "580012345678" + "13800000001" --> "8049600000000001"
    10. 然后,用户A给用户B发消息:
    11. userA.sendMessage("13800000002", "Hello B");
    12. 由于B还未登录过"言士文学",所以MIMC会自动为B创建创建MIMC ID("8049600000000002")
    13. 并维护以下映射:
    14. "580012345678" + "13800000002" --> "8049600000000002"
    15. 并将消息"Hello B"暂存在服务器(七天后过期)
    16. 用户B登录"言士文学"时:
    17. userB = new User("580012345678", "13800000002");
    18. userB.login();
    19. 因为BMIMC已经有了ID,所以MIMC后台服务不会再为其分配新ID
    20. MIMC后台服务检测到B登录,下发离线消息"Hello B"B