Zauważyłem, że na iOS 11 beta 2 ciche powiadomienia nie są dostarczane application:didReceiveRemoteNotification:fetchCompletionHandler
niezależnie od stanu aplikacji (tło / pierwszy plan).
Zaimplementowałem UIApplicationDelegete
metodę application:didReceiveRemoteNotification:fetchCompletionHandler
i wysyłam następujący cichy przycisk
{
"aps": {
"content-available": 1
},
"mydata": {
"foo": "bar"
}
}
ale metoda delegata nie jest wywoływana w systemie iOS 11.
Działa dobrze na innych wersjach iOS, a sekcja dokumentacji Konfigurowanie cichego powiadomienia nie wspomina, że cokolwiek innego należy zrobić.
Czy to błąd w iOS 11, czy przegapiłem coś nowego w iOS 11?
Zwróć uwagę, że nie mówię o UserNotification
frameworku, który nie powinien być potrzebny do wysyłania cichych pchnięć ani nie używam go .
Oto przykładowy projekt, który ilustruje problem (musisz ustawić własny identyfikator pakietu)
Po uruchomieniu przykładowego projektu i wysłaniu powyższego ładunku do aplikacji możesz użyć konsoli macOS, aby sprawdzić, czy wypychanie jest poprawnie dostarczane do urządzenia, ale nie do aplikacji.
AKTUALIZACJA 10.08.2018
Wygląda na to, że zachowanie jest przypadkowe. Czasami po ponownym uruchomieniu urządzenia ładunek jest dostarczany poprawnie, ale po chwili przestaje działać.
Jak widać na poniższym zrzucie ekranu, push oznaczony jako 1 jest dostarczany tylko do urządzenia, a push 2 (po restarcie urządzenia) jest również dostarczany do aplikacji.
AKTUALIZACJA 14.08 - iOS 11 Beta 6
Wciąż to samo zachowanie. Kolejna rzecz, która powinna działać, ale nie działa, jest następująca. Gdy schemat aplikacji jest ustawiony na „Czekaj na uruchomienie pliku wykonywalnego”, ciche naciśnięcie powinno obudzić aplikację i uruchomić ją w tle.
AKTUALIZACJA 21.08 - iOS 11 Beta 7
Nadal to samo zachowanie, a nie aktualizacje od Apple w raporcie o błędzie.
AKTUALIZACJA 29.08 - iOS 11 Beta 8
Wciąż ten sam problem. Kroki do odtworzenia, których teraz używam, są następujące:
- W schemacie projektu Xcode wybierz „Czekaj na uruchomienie pliku wykonywalnego”
- Dodaj punkt przerwania w
didReceiveRemoteNotification: fetchCompletionHandler
- Uruchom aplikację na urządzeniu
- Wyślij powyższe ciche pchnięcie
Oczekiwano : aplikacja jest przenoszona ze stanu zawieszenia do tła i didReceiveRemoteNotification: fetchCompletionHandler
jest wywoływana
Rzeczywiste : nic się nie dzieje
AKTUALIZACJA 06.09 - iOS 11 Beta 10
Nadal mam takie samo wadliwe zachowanie. Bilet od Apple został zaktualizowany następującą odpowiedzią:
Apple Developer Relations 6 września 2017, 22:42 Inżynierowie przekazali następującą opinię dotyczącą tego problemu:
Udało nam się uruchomić przykładową aplikację i przetestować zachowanie. Nie widzieliśmy żadnych problemów, gdy testowaliśmy to zgodnie z opisem.
Nie ma gwarancji, że wypychanie dotrze do aplikacji, gdy działa w tle, a dzienniki tutaj wskazują, że nie uważamy, że aplikacja jest używana wystarczająco, aby ją uruchomić.
Widzimy, jak od czasu do czasu dostarczamy pchnięcia, gdy warunki są dobre.
Uważamy, że działa to poprawnie.
Aktualizacja 11.09.2018
Mój raport o błędzie Apple został zamknięty i oznaczony jako duplikat, 33278611
który pozostaje otwarty
AKTUALIZACJA 13.09 - iOS 11 GM
Dzięki komentarzom kam800 (patrz poniżej) przeprowadziłem więcej testów i doszedłem do następujących spostrzeżeń:
Wygląda na to, że w iOS 11 pojawił się nowy demon, dasd DuetActivitySchedulerDaemon
który całkowicie odrzuca wypychanie danych lub opóźnia ich dostarczanie:
Dostawa odroczona
Dzienniki konsoli
default 13:11:47.177547 +0200 dasd DuetActivitySchedulerDaemon CANCELED: com.apple.pushLaunch.net.tequilaapps.daylight:C03A65 <private>! lifecycle com.apple.duetactivityscheduler
default 13:11:47.178186 +0200 dasd DuetActivitySchedulerDaemon Removing a launch request for application <private> by activity <private> default com.apple.duetactivityscheduler
default 12:49:04.426256 +0200 dasd DuetActivitySchedulerDaemon Advancing start date for <private> by 6.5 minutes to Wed Sep 13 12:55:31 2017 default com.apple.duetactivityscheduler
default 13:21:40.593012 +0200 dasd DuetActivitySchedulerDaemon Activity <private>: Optimal Score 0.6144 at <private> (Valid Until: <private>) scoring com.apple.duetactivityscheduler
default 13:21:40.594528 +0200 dasd DuetActivitySchedulerDaemon Setting timer (isWaking=1, activityRequiresWaking=0) between <private> and <private> for <private> default com.apple.duetactivityscheduler
Problemy z opóźnioną dostawą
- Gdy dostarczanie danych w trybie push zostanie odroczone i aplikacja zostanie uruchomiona, wypychanie danych jest dostarczane tylko wtedy, gdy zostanie osiągnięta data dostarczenia, która może nastąpić kilka minut w przyszłości. To całkowicie mija się z celem korzystania z wypychania danych w celu przygotowania zawartości nowej aplikacji do następnego uruchomienia. Cytuję tutaj jeszcze raz dokumentację Apple:
„Ciche powiadomienia poprawiają komfort użytkowania, pomagając w utrzymywaniu aktualności aplikacji, nawet gdy nie jest uruchomiona”.
- Gdy dwa wypychania danych są wysyłane do zawieszonej aplikacji, są one odkładane przez iOS 11 zamiast bezpośrednio budzić aplikację. Kiedy nadejdzie czas dostawy, dostarczane jest tylko ostatnie wypychanie danych! Poprzednie wypychania są tracone i nie są dostarczane za pośrednictwem metody delegata, co powoduje utratę danych.
Dostawa anulowana
Dzienniki konsoli
default 13:35:05.347078 +0200 dasd DuetActivitySchedulerDaemon com.apple.pushLaunch.net.tequilaapps.daylight:C03A65:[
{name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Must Not Proceed, Score: 0.00}}
], FinalDecision: Must Not Proceed} scoring com.apple.duetactivityscheduler
Problemy z anulowaną dostawą
W tym przypadku wypychanie danych jest całkowicie utracone i nigdy nie jest dostarczane na iOS 11, podczas gdy zostało poprawnie dostarczone na iOS 10.
AKTUALIZACJA 19.09 - iOS 11 GM
Zauważyłem też, że gdy aplikacja jest na pierwszym planie, a powiadomienie nie jest dostarczane do aplikacji, w konsoli widzę następujące logi:
default 08:28:49.354824 +0200 apsd apsd <private>: Received message for enabled topic '<private>' onInterface: NonCellular with payload '<private>' with priority 10 for device token: NO courier-oversized com.apple.apsd
fault 08:33:18.128209 +0200 dasd Foundation <NSXPCConnection: 0x151eee460> connection from pid 55: Exception caught during decoding of received message, dropping incoming message.
Exception: Exception while decoding argument 0 (#2 of invocation):
Exception: value for key 'NS.objects' was of unexpected class 'NSNull'. Allowed classes are '{(
NSArray,
NSData,
NSString,
NSNumber,
NSDictionary,
NSUUID,
_DASActivity,
NSSet,
_DASFileProtection,
NSDate,
NWParameters,
NWEndpoint
)}'. general com.apple.foundation.xpc
"content-available": 1
, a aplikacja jest na pierwszym planie, wywołanie zwrotne nie zostanie uruchomione.Odpowiedzi:
Tak mówią informacje o wydaniu iOS 11.1 beta 1
Zrobiłem kilka testów i wydaje się, że rzeczywiście zostało to naprawione:
Stan zawieszony
Kiedy uruchamiam aplikację w trybie zawieszonym i wysyłam cichy komunikat, aplikacja jest przywracana do tła i
didReceiveRemoteNotification:fetchCompletionHandler
wywoływany jest delegat.Stan pierwszoplanowy
W ten sam sposób, gdy aplikacja jest na pierwszym planie i jest wysyłane ciche wypychanie, delegat wydaje się być wywoływany zgodnie z oczekiwaniami. Losowo nie działało to w poprzednich wersjach iOS 11, więc potwierdzę to po dalszych testach.
źródło
Chciałem tylko dodać moje 2 centy, ponieważ również uderzył mnie ten problem i zauważyłem, że Apple zamknął kilka radarów w tej sprawie, mówiąc, że nie mogą się odtworzyć. Interesującą rzeczą, jaką znalazłem, jest to, że wypychania zostaną dostarczone, jeśli aplikacja będzie działać w tle, gdy jest podłączona do debugera.
Jeśli zabiję debugera, odłączę telefon, uruchomię aplikację i wyślę cichy ładunek push, widzę, że aplikacja NIE jest budzona. Widzę w dzienniku konsoli, że system anuluje dostarczanie ładunku do mojej aplikacji.
Przesłałem radar z małą przykładową aplikacją, która odtwarza problem. Wyraźnie zauważyłem również na radarze, że osoba pracująca nad moim biletem nie może uruchamiać aplikacji dołączonej do debugera, aby odtworzyć problem. Oto link: https://bugreport.apple.com/web/?problemID=34461063
Miejmy nadzieję, że spowoduje to pewien postęp w tej kwestii.
źródło
Wygląda na nowe zachowanie iOS 11. iOS 11 beta 10 zawiera kilka opisowych dzienników dotyczących tego problemu:
Wygląda na to, że każde ciche wypychanie jest dostarczane do iOS, ale demon dasd używa kilku zasad, aby zdecydować, czy ciche wypychanie powinno być dostarczane do aplikacji (np. Poziom naładowania baterii). Wczoraj wieczorem udało mi się otrzymać jedno ciche naciśnięcie, ale mój iPhone był wtedy podłączony do ładowarki - prawdopodobnie wynik BatteryLevelPolicy był wystarczająco wysoki, aby otrzymać to jedno ciche naciśnięcie.
Apple nie podaje oficjalnych informacji o tym zachowaniu po stronie iOS, są tylko informacje o ograniczaniu przepustowości po stronie serwera:
Trzymam kciuki, że zmienili to zachowanie, bo to by naprawić moją aplikację :) Z drugiej strony ta zmiana jest dobra - jedna z wielu spraw, że bateria iPhone'a wytrzyma dłużej niż telefony z Androidem.
źródło
dasd
Proces następnie rejestrujedefault 10:17:42.994236 +0200 dasd DuetActivitySchedulerDaemon Advancing start date for <private> by 6.3 minutes to Wed Sep 13 10:24:03 2017
. Wydaje się, że w tym czasie nastąpił cichy nacisk.com.apple.fetch.com.troii.timriphone:F613DA:[ {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Must Not Proceed, Score: 0.00}} ], FinalDecision: Must Not Proceed}
Informacje o wersji beta systemu iOS 11.1 obejmują: Powiadomienia Rozwiązane problemy Ciche powiadomienia push są przetwarzane częściej. (33278611)
źródło
iOS 11.1 Beta 2 zawiera również
w Uwagach do wydania - przetestuję teraz.
AKTUALIZACJA - 11.10.2017 - iOS 11.1 Beta 2
Po 2 dniach korzystania z naszej aplikacji w „rzeczywistych scenariuszach” wygląda na to, że w tej wersji iOS nastąpiła realna poprawa. Ostrożnie zaczynam wierzyć, że to zostało naprawione.
źródło
Apple Developer Relations właśnie dodał komentarz do mojego radaru:
obecnie instaluję iOS 11.2 beta - przetestuje zachowanie cichego wypychania
źródło
Miałem podobny problem z moją aplikacją, aż do iOS 10 otrzymywałem powiadomienia push i
application:didReceiveRemoteNotification:fetchCompletionHandler
dzwoniłem poprawnie, ale po aktualizacji do iOS 11 powiadomienia push przestały działać.Problem z moim kodem polegał na tym, że mimo że korzystałem z content-available: 1 i mutable-content: 1 w ładunku powiadomień wypychanych, opcja pobierania w tle nie została włączona. Ale działało idealnie do iOS 10.
Po włączeniu funkcji pobierania w tle działa teraz
źródło
iOS 11.4.1, Swift 4
Miałem problemy z nie docierającymi cichymi naciśnięciami (z CloudKit) i próbowałem wszystkiego, o czym wszyscy tutaj wspominali. Potem postanowiłem spróbować ustawić puste miejsce
alertBody
na moichCKNotificationInfo()
obiektach w następujący sposób:To sprawiło, że wypychania były wysyłane z wyższym priorytetem (ale nadal były to ciche naciśnięcia) i nie otrzymałem już błędu w dziennikach mojego urządzenia, że wypychanie było ignorowane.
Mam nadzieję, że to komuś pomoże. :)
źródło
Jest to więc rzeczywiście błąd w iOS 11 i został naprawiony w iOS 11 beta 3.
application:didReceiveRemoteNotification:fetchCompletionHandler
Teraz jest wywoływany poprawnie, gdy ciche wypychanie jest odbierane zarówno na pierwszym planie, jak iw tle.AKTUALIZACJA
Nie, nie zostało to naprawione i nadal dzieje się w iOS beta 3 i 4
źródło
Aby obejść ten problem, dodajemy klucz „powiadomienie” i wewnątrz „tytułu” z pustym ciągiem znaków jako wartością. To jest obudzenie wywołania zwrotnego didReceive w appDelegate.
źródło
Pisząc tę odpowiedź, mam dokładnie ten sam problem, co odpowiedź Billa Dunaya .
Moim wymaganiem było otrzymywanie cichych powiadomień, gdy aplikacja jest na pierwszym planie i nic, gdy aplikacja jest w tle / nie działa. A moje obejście było takie. Nie używam odznak, więc ustawienie go na zero nie jest dla mnie problemem.
Należy pamiętać, że celowo nie używam opcji „dostępne treści”. Ustawienie, które powoduje, że logika optymalizacji iOS uruchamia opóźnianie / anulowanie dostarczenia powiadomienia.
źródło
Otrzymuję ten sam problem w przypadku niektórych powiadomień (niekoniecznie cichych).
Po przejrzeniu wszystkich aktualizacji i odpowiedzi mogę dodać dwie aktualizacje, które mogą pomóc:
Odkryłem, że
UIApplication.shared.isRegisteredForRemoteNotifications
metoda dostępu podczas otrzymywania powiadomienia powoduje zawieszenie aplikacji bez zgłaszania czegokolwiek do Xcode. Sprawdź, czy uruchamiasz jakiś kod po otrzymaniu powiadomienia o dostępie do metody. ( isRegisteredForRemoteNotifications blokujący interfejs użytkownika z semaphore_wait_trap )."title-loc-args" : [3333]
braku akceptacji 3333 dosłownie, ale akceptowania go jako ciągu"title-loc-args" : ["3333"]
. To spowodowało, że cały mój interfejs utknął po uzyskaniu dostępu do powyższej metody, tylko na iOS 11 działa na iOS 12.Dowiedziałem się również, że z dokładnie tym samym kodem działa bez problemu na iOS 12.0 (16A5366a) . Ale na iOS 11 to się dzieje.
źródło
W moim przypadku ciche powiadomienia zostały użyte do aktualizacji interfejsu użytkownika po wykonaniu zadania na serwerze, więc trudno było mieć nieistotne treści w aplikacji. Ponieważ nasz ładunek dla cichego powiadomienia zawiera nawet tytuł i treść, wdrażam te metody, aby otrzymywać działające powiadomienia w aktywnej / nieaktywnej aplikacji, bez ładowania i z wyłączonym odświeżaniem aplikacji w tle, a nawet w stanie niskiego zużycia energii.
Aby to działało, dodaję delegata i tworzę rozszerzenie z
UNUserNotificationCenterDelegate
protokołem iwillPresent notification
metodą (iOS 10+), które jest uruchamiane za każdym razem z odpowiednim ładunkiem. Aby nie wyświetlać powiadomienia, gdy aplikacja jest aktywna, po prostu zadzwoń do zakończenia z odznaką lub dźwiękiem. Skończyło się na czymś takimAby uzyskać działanie tych stanów, gdy aplikacja jest w tle i ciche powiadomienia, nie wywołuj moich metod, otrzymuję powiadomienia z centrum powiadomień bezpośrednio
applicationDidBecomeActive
przez:źródło
W moim przypadku „Odświeżanie aplikacji w tle” zostało wyłączone w ustawieniach iPhone'a. Z tego powodu powiadomienie push zostało dostarczone do urządzenia, ale nie do aplikacji. Włączenie odświeżania aplikacji w tle powoduje ciche naciśnięcie w aplikacji.
Może to nie być właściwa odpowiedź na to pytanie, na wypadek gdyby ktoś chciał to sprawdzić.
źródło