请问JPUSH sdk 3.0.6 版本 [JPUSHService resetBadge]这个API的真实作用是什么?

jpush
标签: #<Tag:0x00007fb833b86328>

(狼人杀) #1

在我收到自定义消息的时候,我调用reset方法,然后杀死程序, 竟然还能收到一条推送。
具体操作流程:
步骤:1、在杀进程状态下发送一条自定义消息
2、打开应用再次发送一条自定义消息
3、杀死进程
现象:又收到了刚才推送的自定义消息


#2

这个API看名称,都是与badge 角标有关的撒

你这里发送了两条消息,那你说的又收到了的消息是什么消息?
msgid是多少,自己对应着推送的和收到的去看


(狼人杀) #3

是的, 都是和角标相关的, 我发送的两条自定义消息我是都收到了的, 问题就在于第二条消息收到以后,杀死应用,第二条消息又显示了一次,就感觉又出现了一模一样的本地通知一样


#4

那你得检查下你们的代码,就是你们在resetbadge之后, 是否创建了本地通知等等情况。


(狼人杀) #5

我已经看过了,没有调用本地通知的代码,我用了你们的demo代码,也是有一样的问题


#6

1、你在官网推送——自定义消息,这样测试的吗?

2、检查是否是后台同时推送了通知+自定义消息

3、收到这条消息后点击消息进入,获取下内容
将前后收到了两条自定义消息和这条通知 完整的客户端日志信息发上来。

4、直接在demo上做测试,在官网-推送自定义消息这样做测试。


(狼人杀) #7
----- login result -----
uid:11125872716 
registrationID:1517bfd3f7fc0f6737d
2017-09-25 10:23:59.337 | JIGUANG | D - [JIGUANGTcpSocket] Got tcp command
2017-09-25 10:23:59.337 | JIGUANG | D - [JIGUANGSessionController] Action - onAckOrRespReceived:
2017-09-25 10:23:59.338 | JIGUANG | D - [JIGUANGSessionController] Event - onLoginRespond
2017-09-25 10:23:59.343 | JIGUANG | D - [JIGUANGUtilities] JCOREPostNotificationWithUserInfo name: kJPUSHNetworkDidLoginNotification (null)
2017-09-25 10:23:59.706 | JIGUANG | D - [JIGUANGTcpSocket] Got tcp command
2017-09-25 10:23:59.713 | JIGUANG | D - [JIGUANGUtilities] JCOREPostNotificationWithUserInfo name: kJPUSHNetworkDidReceiveMessageNotification {
    content = 4;
    "content_type" = SYSTEM;
    title = "";
}
2017-09-25 10:23:59.730 | JIGUANG | D - [JIGUANGSessionController] Action - doSendTcpRequest
2017-09-25 10:24:00.289 | JIGUANG | D - [JIGUANGService] Action - resetBadge
2017-09-25 10:24:00.388 | JIGUANG | I - [JIGUANGBadgeNumberReport] set badge:0 succeed
2017-09-25 10:24:03.252 | JIGUANG | D - [JIGUANGService] Action - setTags:(null) alias: 3 callbackSelector:object:
2017-09-25 10:24:03.254 | JIGUANG | D - [JIGUANGService] Action - setTags: (null) alias: 3 callbackSelector:target:
2017-09-25 10:24:03.357 | JIGUANG | D - [JIGUANGSessionController] Action - doSendTcpRequest
2017-09-25 10:24:03.374 | JIGUANG | D - [JIGUANGTcpSocket] Got tcp command
2017-09-25 10:24:03.375 | JIGUANG | D - [JIGUANGSessionController] Action - onAckOrRespReceived:
2017-09-25 10:24:04.413 | JIGUANG | D - [JIGUANGTcpSocket] Got tcp command
2017-09-25 10:24:07.394 | JIGUANG | D - [JIGUANGTcpSocket] Got tcp command
2017-09-25 10:24:07.400 | JIGUANG | D - [JIGUANGUtilities] JCOREPostNotificationWithUserInfo name: kJPUSHNetworkDidReceiveMessageNotification {
    content = 5;
    "content_type" = SYSTEM;
    title = "";
}
2017-09-25 10:24:07.404 | JIGUANG | D - [JIGUANGService] Action - resetBadge
2017-09-25 10:24:07.464 | JIGUANG | D - [JIGUANGSessionController] Action - doSendTcpRequest
2017-09-25 10:24:07.584 | JIGUANG | I - [JIGUANGBadgeNumberReport] set badge:0 succeed
2017-09-25 10:24:09.965 | JIGUANG | D - [JIGUANGService] Action - resetBadge
2017-09-25 10:24:10.027 | JIGUANG | D - [JIGUANGPageFlow] savePageFlowWithTime
2017-09-25 10:24:10.148 | JIGUANG | D - [JIGUANGService] Action - resetBadge

(狼人杀) #8

这是完整的日志,4是在我杀掉进程状态下推送的, 然后点击icon,进入APP, 在APP内再次发送5,立即杀死进程,就会收到一条相同的5


#9

收到的相同的5的日志呢?
这条杀死后再次收到的是通知撒?
你点击一下,也看下这条消息的日志。

再就是你推送的消息的msgid,日志里面没体现出来,你在官网推送历史-详情,或者后台推送日志里面看一下msgid的值


(狼人杀) #10

其实这就是问题,我这边是没有第二个5的信息的,但是他又确实出现了。
而我删除了接收自定义消息的那个resetbadge方法以后就又OK了。


(狼人杀) #11

稍等一下,我再拉一下日志和官网内的id信息。


#12

他出现的特征是什么?
你总是看到了撒?是不是有横幅提醒?你点进去后日志打印了什么?开启下debug,看下完整的日志信息。

这个restbadge在极光这边就是一个清除角标信息的,不会引起重新推送了一消息,如果有,那肯定有个msgid之类的。
D - [JIGUANGService] Action - resetBadge
I - [JIGUANGBadgeNumberReport] set badge:0 succeed
这个API就是打印这两个,在极光这边就结束了。

需要你看这个API 是不是和你其他的某个代码 因为什么而互相有了关联,导致出现这样的情况呢?


(狼人杀) #13

是有横幅提醒的


(狼人杀) #14
2017-09-25 10:59:04.570 | JIGUANG | I - [JIGUANGService] 
--------------------------- JPush Log ----------------------------
--------------------JPush SDK Version:3.0.6--build:40----------
--------------------JCore Lib Version:1.1.5--build:25----------
-----------------AppKey:e1827d71361a0ef6ac13fdcf----------------
----------------------------------------------------------------
2017-09-25 10:59:04.573 | JIGUANG | I - [JIGUANGClientController] Action - jpush setup
2017-09-25 10:59:04.574 | JIGUANG | I - [JIGUANGClientController] Action - setup
2017-09-25 10:59:04.575 | JIGUANG | D - [JIGUANGService] remote info:
{
    "_j_business" = 1;
    "_j_msgid" = 54043196581463108;
    "_j_uid" = 11125872716;
    aps =     {
        alert = 5;
        badge = 1;
        sound = "";
    };
} 
report result: 2003 ,appState: 1
2017-09-25 10:59:04.669 | JIGUANG | D - [JIGUANGPageFlow] trySetupSession
2017-09-25 10:59:04.670 | JIGUANG | D - [JIGUANGPageFlow] setupSession
2017-09-25 10:59:04.732 | JIGUANG | D - [JIGUANGUserActiveReport] report content {
    activities =     (
    );
    date = "2017-09-25";
    duration = 111;
    itime = 1506306249;
    "session_id" = 1d0e9da02955fe7a4ff94e0657b4233d;
    time = "10:24:09";
    timezone = "+8";
    type = "active_terminate";
}
2017-09-25 10:59:04.762 | JIGUANG | D - [JIGUANGHttpSessionController] Action - setupSession
2017-09-25 10:59:04.762 | JIGUANG | D - [JIGUANGPageFlow] setupSession
2017-09-25 10:59:04.763 | JIGUANG | D - [JIGUANGPageFlow] resetCurrentPage
2017-09-25 10:59:05.115 | JIGUANG | D - [JIGUANGService] Action - resetBadge
2017-09-25 10:59:05.138 | JIGUANG | D - [JIGUANGReport] send report:(
        {
        date = "2017-09-25";
        itime = 1506308344;
        "session_id" = c44f088d8125ad9c957d4fb32c7f2924;
        time = "10:59:04";
        timezone = "+8";
        type = "active_launch";
    }
) log succed
2017-09-25 10:59:05.188 | JIGUANG | D - [JIGUANGService] Action - handleRemoteNotification: {
    "_j_business" = 1;
    "_j_msgid" = 54043196581463108;
    "_j_uid" = 11125872716;
    aps =     {
        alert = 5;
        badge = 1;
        sound = "";
    };
}
2017-09-25 10:59:05.194 | JIGUANG | I - [JIGUANGBadgeNumberReport] set badge:0 succeed
2017-09-25 10:59:05.220 | JIGUANG | D - [JIGUANGReport] send report:(
        {
        itime = 1506308344;
        "msg_id" = 54043196581463108;
        result = 2003;
        type = "msg_status";
    }
) log succed
2017-09-25 10:59:05.234 | JIGUANG | D - [JIGUANGReport] send report:(
        {
        activities =         (
        );
        date = "2017-09-25";
        duration = 111;
        itime = 1506306249;
        "session_id" = 1d0e9da02955fe7a4ff94e0657b4233d;
        time = "10:24:09";
        timezone = "+8";
        type = "active_terminate";
    }
) log succed

(狼人杀) #15

这是我点击通知再次打开APP后收到的日志


#16

这条消息你确实是推送了 通知+自定义消息

1、你去官网 仅推送自定义消息 是绝对没有这个问题的,或者你让你后台仅在代码里面写Message,去掉Notification

2、出现这样的情况应该是 通知消息晚于自定义消息到达,有个时间差。自定义消息走极光服务器,通知走Apple服务器

3、iOS10及以上的系统,在前台收到了也会展示这个通知,iOS10及以下的,在前台收到后不会展示这个通知,在后台才会展示。


(狼人杀) #17

好的, 那也就是说和resetbadgae方法无关,纯粹是一个推送和socket时间差的问题。


(狼人杀) #18

那有没有什么方法可以避免这种情况出现那?是不是有一个canclenotification的方法可用那


#19

你现在是有需求 同时推送notification和Message吗?

出于什么样的需求?Message会做一次展示?


(狼人杀) #20

我司现在是有一个自己的控台页面, 测试在做测试的时候回进行各种情况测试。 我说的这种情况他们认为是一种bug,所以才会有这个问题,并不是具体的需求。