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