Тихое уведомление pu sh не доставляется с UIBackgroundRefreshStatusDenied, но приложение на переднем плане

Question

С UIBackgroundRefreshStatusAvailable мое приложение получает беззвучные уведомления pu sh, как и ожидалось, как в фоновом, так и в переднем плане.

Название этой функции - Фон App Refre sh - подсказывает мне, что это не влияет на Foreground поведение приложения, когда оно отключено.

К сожалению, мое приложение не получает беззвучные уведомления pu sh, пока оно находится на переднем плане с отключенным обновлением sh фонового приложения, т.е. UIBackgroundRefreshStatusDenied.

Я не использую видимые пользователем sh уведомления, поэтому не задействованы UNUserNotificationCenter et c.

Можно ли получать тихие sh -уведомления с обновлением фонового приложения sh отключено, т.е. UIBackgroundRefreshStatusDenied?

Objective- C, Xcode 11.3.1, цель развертывания iOS 10.3. iPhone 6 с установленным iOS 12.4.5.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [application registerForRemoteNotifications];
    return YES;
}

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler {
    // not called when app in foreground but bg app refresh turned off
}

Вот пример userInfo dict, что didReceiveRemoteNotification получено при включении bg app refre sh:

{
aps =     {
    "content-available" = 1;
};
ck =     {
    ce = 2;
    cid = "iCloud.de.udo-thiel.DiskBench";
    ckuserid = "_56bd97c2eb1e52d09756163efaab6b02";
    nid = "e70e4a8d-d77b-4315-8b3e-d9de229cf083";
    qry =         {
        dbs = 2;
        fo = 2;
        rid = "Res-iPad 2-16";
        sid = "public-results2";
        zid = "_defaultZone";
        zoid = "_defaultOwner";
    };
};

}

Answer 1

Это интересный вопрос, поскольку он в основном касается проблемы наименования этой довольно сложной функции.

Короче говоря, я боюсь, что ответ отрицательный. Хотя мне самому не приходилось сталкиваться с этим, я был свидетелем многих других в том же положении, что и вы.

Мне помогает думать, что вся «функция тихого удаленного уведомления» имеет меньшее отношение к приложение находится на переднем плане или в фоновом режиме, и многое другое с «вводом удаленного приложения»:

Если оно активировано, т. е. у вас есть UIBackgroundRefreshStatusAvailable, ваш сервер может отправлять ему, в этом случае, сообщения, в которых это реагирует. По сути, сервер вводит данные аналогично тому, как нажимает пользователь (хотя, очевидно, через другие вызываемые функции). Неважно, находится ли приложение на переднем плане или в фоновом режиме, этот ввод происходит .

Если функция неактивна, т.е. у вас есть UIBackgroundRefreshStatusDenied или UIBackgroundRefreshStatusRestricted, вся функция отключается . Это означает, что такой способ получения ввода не работает, application:didReceiveRemoteNotification:fetchCompletionHandler: вообще не вызывается. По общему признанию, это имя метода отражает проблему лучше, чем случаи перечисления состояний.

---

Два обходных пути :

1. Самый очевидный: регистр и отменить регистрацию для удаленных уведомлений в applicationDidBecomeActive: и applicationWillResignActive:. К сожалению, это может стать уродливым, поскольку в результате на вашем сервере постоянно меняются токены для пользователей, но если вы хотите избежать получения уведомлений в фоновом режиме любой ценой, go таким образом.
2. Зарегистрируйтесь для получения уведомлений один раз и действительно пусть ваш logi c обрабатывает уведомления на переднем плане и , как вы (кажется) уже делаете, но просто сделайте так, чтобы он игнорировал уведомления, пока он находится в фоновом режиме (используя UIApplication.shared.applicationState). Технически это «тратит впустую» немного времени выполнения, так как ваше приложение может проснуться, а затем не сделать ничего значимого, но я думаю, что это не так уж плохо.

Я бы go с вариантом 2 сам так как я редко вижу случай, когда мне больно получать тихое уведомление в фоновом режиме.

Как правило, я бы не стал делать ничего, что полагается на включенные уведомления (фоновый или передний план). Другими словами: да, если мое приложение находится на переднем плане, и мне нужно отреагировать на что-то, происходящее на моем сервере, я боюсь, что мне нужно «проверить» указанный сервер, то есть получить от него в какой-то форме.

Или я бы, в зависимости от сценария, проинформировал пользователя, что они должны включить его, иначе приложение не будет иметь особого смысла ... Хм ...

---

В качестве примечания : Ага, Apple SDK немного сбивает с толку с именами и объяснением всех различных фоновых вещей и уведомлений. Даже само состояние приложения (активно, неактивно, фон, передний план, приостановлено, ...) сложнее, чем кажется по названиям. Я думаю, что причина тому исторический характер. До того, как у нас вообще появились фоновые режимы и уведомления, люди просто опрашивали данные, чтобы получить что-то вроде «тихих уведомлений переднего плана», то есть то, что вам нужно. В итоге они захотели иметь возможность делать это и тогда, когда приложение не было на переднем плане, громко запрашивая выполнение в фоновом режиме. Apple на самом деле не хотела предоставлять это без ограничений, поэтому постепенно развивалась концепция уведомлений, но поскольку это было связано, термин «фон» проник туда (кроме того, у нас также была фоновая выборка ...), даже если это не обязательно имеет смысл. Можно также возразить, что это все еще действует, потому что это более важно, когда приложение находится в фоновом режиме / приостановлено. Вариант использования «получить тихое уведомление только на переднем плане» все еще можно охватить простым опросом (хотя я согласен, что это некрасиво), а если вы используете pu sh, это не так больно , чтобы они тоже были в фоновом режиме.