ios - 从后台远程推送通知手动递增时，应用程序的角标(Badge)编号卡在 1

Question

我正在 iOS 应用程序中实现推送通知。

在从服务器发送的 PN 有效载荷中 content-available = 1 被设置为当推送通知从服务器到达时，应用程序将同时接收用户和后台通知:

aps =     {
    alert = "Hello!";
    "content-available" = 1;
    sound = default;
};

这是我处理后台通知的方式:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler {
    if ([UIApplication sharedApplication].applicationState == UIApplicationStateBackground) {
        NSInteger currentBadgeNumber = [UIApplication sharedApplication].applicationIconBadgeNumber;

        [UIApplication sharedApplication].applicationIconBadgeNumber = currentBadgeNumber + 1;

        completionHandler(UIBackgroundFetchResultNewData);

        return;
    }

    ...
}

通过编写此代码，我希望每次推送通知到达时我的应用程序的角标(Badge)编号递增 1(假设我的应用程序在后台)。

这种简单的方法非常适合我的 2 台设备:装有 iOS 7.1 的 iPhone 4 和装有 iOS 8.1.2 的 iPhone 6，但它不适用于我们的一位测试人员。我们进行了大量测试并验证它对他不起作用 - 我们的应用程序在他设备上的角标(Badge)第一次递增到 1 然后卡住 - 从那以后它始终保持 1。他是这样描述这个问题的:

The only time I consistently see the app's badge is incremented correctly is after a fresh reboot of the device and log in, which would make our app one of the few background running apps at the time. Because I have many apps running on my device, many of which also use background processing (FB, NextDoor, WhatsApp), my theory is that our app gets background cycles less and less frequently the longer the device is active, which is why we miss opportunities to be called in the background and have badge number incremented.

在采用这种从后台推送通知手动增加角标(Badge)编号的简单方法之前，我们还考虑了在服务器端跟踪角标(Badge)编号并通过 badge 参数发送其显式编号(一些 SO 主题建议这样做所以)但是为了简单起见，我们决定尝试更简单的方法并实现我上面描述的非常简单的策略。

所以问题是:

1) 对我实现这个可能为我们的测试人员产生不稳定结果的简单策略有什么见解吗？

2) 如果答案 1 是否定的，我们是否应该 100% 考虑服务器端实现来跟踪角标(Badge)编号以便为我们提供稳定的结果？

附言目前，我正在添加额外的日志记录字符串以向我们的测试人员发布新的测试版本，以了解此问题是否与 application:didReceiveRemoteNotification:fetchCompletionHandler 有关，每次推送通知到达时可能不会调用它。

Answer 1

自从我问了这个问题之后，当我们尝试在客户端使用 content-available=1 控制应用程序角标(Badge)时，我们仍然没有获得稳定的结果。

这就是我们将此责任转移到服务器端的原因:现在我们在服务器上跟踪了未读通知的数量，以便服务器通过 badge 参数。这为我们带来了应用程序角标(Badge)正确增量所需的稳定性。

现在我强烈建议大家对应用程序的角标(Badge)进行服务器端管理!这个服务器端实现非常简单，可以让您完全控制此功能。