[已回复] MobileIMSDK开发的IM中实现回执功能的问题求助-MobileIMSDK/解决方案区

1 楼: JackJiang

你所说的回执，是这个帖子里《IM群聊消息的已读回执功能该怎么实现？》，这个已读未读这个东西吗？

2 楼: JackJiang

引用：xushuhua 发表于 2018-06-13 10:09
不是，只是消息发送成功的回执，目前每次移动端发送聊天消息都会发送三遍。

理论上不可能，除非你改动了框架的代码，框架里把应答都给你处理好了，具体你看看这个贴子里的讨论：
《[已回复] 当MobileIMSDK的客户端收不到对方的ACK应答包时会发生什么？》

3 楼: JackJiang

引用：xushuhua 发表于 2018-06-13 11:38
case ProtocalType.C.FROM_CLIENT_TYPE_OF_COMMON$DATA:
{
logger.info("

首先，你一行代码都不要动的情况下，MobileIMSDK框架算法算动实现了回执ACK的功能，这个回执你能在我4楼给出的贴子里告诉你的回调里收到这个回执回调通知。

然后，框架已以实现了回执的情况下，你是在纠结什么？你要改这个回执算法呢，还是说这个回执在你测试的时候没有生效？你的描述比较混乱，没太看明白

4 楼: JackJiang

引用：xushuhua 发表于 2018-06-13 20:58
大佬，我客户端向服务端发送消息，怎样知道发送成功了

你看一眼我在4楼回复你的贴子里的内容。

5 楼: JackJiang

引用：xushuhua 发表于 2018-06-14 09:38
@Override
public boolean onTransBuffer_C2C_RealTimeSendFaild_CallBack(final String userId,
f ...

你的这个思路并不是最佳方式，离线消息无论如何应该先落地（就是存到数据库或者redis这种能持久化的东西里，而不致于被丢失），然后再来推送，因为无论是自已实现推送还是用第3方（比如ios的APNS推送通道），都不能保证百分百推的到或者不丢，也不是他们的义务），都应该是自已保证数据的可靠性。你推送前先存起来，推送成功再删除，这就不存在你说的问题，也比你现在想的这样简单多了。

6 楼: JackJiang

引用：xushuhua 发表于 2018-06-14 12:02
再请教您几个问题：1.A给B发送消息，B不在线，调用了onTransBuffer_C2C_RealTimeSendFaild_CallBack()， ...

MobileIMSDK中，当进入回调onTransBuffer_C2C_RealTimeSendFaild_CallBack这个方法的时候，意味着B不在线，那这个回执B是不可能发的出来（除非闹鬼了），但是服务端帮它把这个消息持久化存储起来了，也就相当于被B收到了（只是B还没有看而已），所以由服务端代发回执这个逻辑没有问题，总不能告诉A说消息送不到，那不就意味着不支持离线消息了吗。你试着想想如果你来写这个逻辑，你该怎么处理？就明白了

7 楼: JackJiang

引用：xushuhua 发表于 2018-06-14 17:43
这个我是可以理解的，若是对方不在线会发送为A一个伪应答包。现在是尝试向B发送三次失败之后进行推送和向 ...

是的，你的推送逻辑有问题，应答过去了，对方的QoS机制就不会重传了

8 楼: JackJiang

引用：xushuhua 发表于 2018-06-14 17:58
那我应该什么时候触发推送呢？求大神指教

你什么也不用管，只要服务端的离线回调里进行推送就行了（前提是该离线存储的还是要存储，推送只是辅助手段，因为推送的东西对方可能收不到啊，这受推送通道的影响，因为推送服务方不一定能保证百分百到达嘛），因为框架判定的需要离线存储的代码，就表示对方不在线（原因可能是对方真不在线，或在线但是app被杀死、也或者是app已退到后台等情况），那么此时就是你推送上场了。