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;
    }

    ...
}

通过编写本文，我希望每次推送通知到达时（我的应用程序处于后台），我的应用程序的徽章编号将增加1。

这种简单的方法在我的2台设备上完美适用于我：iPhone 4配备iOS 7.1和iPhone 6配备iOS 8.1.2，但它不适用于我们的测试人员。我们进行了大量的测试，并确认它对他不起作用 - 我们的设备上的应用程序徽章第一次增加到1然后冻结 - 从那时起它始终保持为1。以下是他如何描述这个问题：

我一直看到应用程序徽章正确递增的唯一一次是在重新启动设备并登录后，这将使我们的应用程序成为当时为数不多的后台运行应用程序之一。因为我的设备上运行了很多应用程序，其中许多也使用后台处理（FB，NextDoor，WhatsApp），我的理论是我们的应用程序在设备处于活动状态的时间越来越短，后台周期越来越少，这就是我们错过的原因在后台调用机会并增加徽章编号。

在采用这种简单方法手动从背景推送通知递增徽章编号之前，我们还考虑在服务器端跟踪徽章编号并通过badge参数发送其显式编号（正如一些SO主题建议这样做）但为了简单起见，我们决定尝试更简单的方法，并实现我上面描述的死简单策略。

所以问题是：

1）我对这个简单策略的实现有什么见解可能会给我们的测试人员带来不稳定的结果吗？

2）如果答案1变为否定，我们是否应该100％考虑服务器端实施来跟踪徽章编号，以便给我们带来稳定的结果？

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

Answer 1

自从我提出这个问题以来，当我们尝试使用content-available=1在客户端进行操作时，我们仍然无法获得稳定的控制应用徽章的结果。

这就是我们将此职责移至服务器端的原因：现在我们在服务器上跟踪了大量未读通知，以便服务器通过aps参数在badge有效负载内发送此号码。这为我们提供了正确增加应用徽章所需的稳定性。

现在我强烈建议大家对应用程序徽章进行服务器端管理!!这种服务器端实现相当简单，可以让您完全控制此功能。

Answer 2

首先尝试将设置设置为1，然后设置为0.有时它会在我的应用中解决此问题。

    [[UIApplication sharedApplication] setApplicationIconBadgeNumber:1];
    [[UIApplication sharedApplication] setApplicationIconBadgeNumber:0];

当从后台远程推送通知手动递增时，应用程序的徽章编号卡在1

2 个答案: