Ciche wypchnięcia nie są dostarczane do aplikacji w systemie iOS 11

168

Zauważyłem, że na iOS 11 beta 2 ciche powiadomienia nie są dostarczane application:didReceiveRemoteNotification:fetchCompletionHandlerniezależnie od stanu aplikacji (tło / pierwszy plan).

Zaimplementowałem UIApplicationDelegetemetodę application:didReceiveRemoteNotification:fetchCompletionHandleri 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 UserNotificationframeworku, 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.

wprowadź opis obrazu tutaj

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.

wprowadź opis obrazu tutaj

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: fetchCompletionHandlerjest 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, 33278611któ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 DuetActivitySchedulerDaemonktó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
Jan
źródło
1
nadal nie naprawiono w Beta 8, kiedy patrzę w konsolę, widzę następujący błąd: <NSXPCConnection: 0x123f43620> połączenie z pid 58: Wyjątek przechwycony podczas dekodowania odebranej wiadomości, porzucenie wiadomości przychodzącej. Wyjątek: wyjątek podczas dekodowania argumentu 0 (nr 2 wywołania): Wyjątek: wartość klucza „NS.objects” była nieoczekiwanej klasy „NSNull”. Dozwolone klasy to „{(NWParameters, NWEndpoint, NSArray, NSData, NSString, NSNumber, NSDictionary, NSUUID, _DASActivity, NSSet, _DASFileProtection, NSDate)}”.
Thomas Einwaller
2
Otrzymuję ten sam wynik z iOS 11 (nie wcześniej), jeśli wyślę z push "content-available": 1, a aplikacja jest na pierwszym planie, wywołanie zwrotne nie zostanie uruchomione.
GoRoS
4
Po testach z nowym iOS11.1 beta 1 wydaje się, że zostało to naprawione i działa tak jak wcześniej na iOS 10
Lee
3
WhatsApp wydają się mieć podobny problem whatsappen.com/news/5465/... Coś o użytkownikach, że „zwykle zmuszają blisko swoich aplikacji”, który jest większość deweloperów ...
toxaq
3
I dokładnie to samo z publicznym wydaniem wersji 11.1. Jeśli używasz cichego naciśnięcia, a Twoja aplikacja znajduje się na pierwszym planie, nie oczekuj, że zostaną dostarczone w zależności od kilku rzeczy, ale przede wszystkim poziomu baterii, nawet jeśli urządzenie jest podłączone do źródła zasilania.
Gruntcakes

Odpowiedzi:

31

Tak mówią informacje o wydaniu iOS 11.1 beta 1

iOS 11.1 beta 1 został właśnie wydany i wspominają: „Powiadomienia rozwiązane problemy • Ciche powiadomienia push są przetwarzane częściej. (33278611)

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:fetchCompletionHandlerwywoł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.

Jan
źródło
3
Podczas moich pierwszych testów myślałem, że to zostało naprawione. To działało przez chwilę. Ale po ciężkich testach sprawy zaczęły się częściowo układać. Nagle przestał dzwonić do delegata po każdym cichym naciśnięciu, nawet gdy aplikacja była na pierwszym planie. Najwyraźniej ten nowy system „duetu” blokuje delegatowi mojej aplikacji możliwość wywołania z powodu braku „budżetu energii”. Tak więc niestety nadal nie zostało naprawione.
Abras
niewiarygodne :(
Thomas Einwaller
Moje doświadczenie jest takie samo jak Abras powyżej. Pracował przez chwilę, a potem się rozpadł, a przewodnik nie był już wzywany - to jest do bani,
Lee
Po kolejnych testach udało mi się znaleźć sposób, aby urządzenie ponownie otrzymywało powiadomienia. Podłącz go do zasilania. Jak tylko podłączysz urządzenie do zasilania, zacznie ono ponownie otrzymywać wszystkie zdalne powiadomienia. Jeśli go odłączysz, to się zatrzyma. Nie ma to sensu, ponieważ we wszystkich moich testach aplikacja była na pierwszym planie. A aplikacje z pierwszym planem gwarantują otrzymywanie zdalnych powiadomień.
Abras
dla mnie wszystko działa dobrze, nawet gdy korzystasz z połączenia komórkowego bez podłączenia do zasilania. Dopiero gdy ustawię urządzenie w tryb oszczędzania energii, nie dostaję pchnięć, nawet na pierwszym planie. Ale to coś, co bym zrozumiał
stycznia
18

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.

Bill Dunay
źródło
2
Dzięki za raport. Przy okazji, powiązanie błędu Apple nie pomoże tutaj, ponieważ są one prywatne i tylko reporter i Apple mogą je zobaczyć
Jan
Chciałbym, aby więcej osób korzystało z openradar.appspot.com , abyśmy mogli śledzić radary innych ludzi
Thomas Einwaller
czy są jakieś aktualizacje w Twoim zgłoszeniu błędu z Apple @bill
MagicFlow,
Nie otrzymałem żadnych aktualizacji mojego radaru od Apple, ale zainstalowaliśmy wersję beta iOS 11.1 i wygląda na to, że problem został rozwiązany.
Bill Dunay,
Tak, mamy też ten sam problem w iOS 11.2.6, jakieś rozwiązanie lub aktualizacje?
Gopik
14

Wygląda na nowe zachowanie iOS 11. iOS 11 beta 10 zawiera kilka opisowych dzienników dotyczących tego problemu:

default 23:18:51.806011 +0200   dasd    com.apple.pushLaunch.com.acme.Acme:F7E7D0:[
    {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Can Proceed, Score: 0.50}}
    {name: BatteryLevelPolicy, policyWeight: 1.000, response: {Decision: Can Proceed, Score: 0.87, Rationale: [{batteryLevel == 62}]}}
    {name: DeviceActivityPolicy, policyWeight: 5.000, response: {Decision: Can Proceed, Score: 0.20}}
 ] sumScores:52.279483, denominator:81.410000, FinalDecision: Can Proceed FinalScore: 0.642175}
default 23:18:51.806386 +0200   dasd    'com.apple.pushLaunch.com.acme.Acme:F7E7D0' has compatibility score of 1.000000 with 'com.apple.CFNetwork-cc-111-79:E7272D'. Relaxing scores.
default 23:18:51.806855 +0200   dasd    'com.apple.pushLaunch.com.acme.Acme:F7E7D0' CurrentScore: 0.642175, ThresholdScore: 0.738454 DecisionToRun:0

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:

Ciche powiadomienia nie służą do utrzymywania aplikacji w stanie czuwania w tle ani nie są przeznaczone do aktualizacji o wysokim priorytecie. APN traktują ciche powiadomienia jako niski priorytet i mogą całkowicie ograniczyć ich dostarczanie, jeśli łączna liczba stanie się nadmierna. Rzeczywiste limity są dynamiczne i mogą się zmieniać w zależności od warunków, ale staraj się nie wysyłać więcej niż kilka powiadomień na godzinę.

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.

kam800
źródło
1
Tak, pushy są dostarczane do urządzenia, ale nie do aplikacji. To właśnie napisałem w moim oryginalnym poście. „Ciche powiadomienia nie służą do utrzymywania aplikacji w tle”. Jest to w porządku, o ile są dostarczane „czasami”. Duży problem polega na tym, że ciche powiadomienia nigdy nie są dostarczane do aplikacji w systemie iOS 11, gdy działają one w tle. To całkowicie niweczy cel przepychania danych.
Sty
Tak, już to napisałeś, chciałem tylko przedstawić pełne wyjaśnienie dotyczące tych nowych zasad push. Zacytowałem dokumenty firmy Apple, aby pokazać, że ostrzegali już przed niepewnością dostarczania w trybie push. Jak napisałem: „Udało mi się wczoraj wieczorem dostać jeden cichy push” (w aplikacji miałem na myśli), a aplikacja była w tle. Ale w ciągu dnia - moja aplikacja nie otrzymuje pushów :( Moim zdaniem Apple poluzuje te polityki push w wersji RC. Z drugiej strony mogą przywrócić pierwotne zachowanie push - już wcześniej pozbywały się funkcji dostępnych tylko w wersje beta (np. automatyczne usuwanie pęku kluczy 10.3)
kam800
Widzę podobne dzienniki, gdy otrzymuję push, a aplikacja jest zawieszona. dasd Proces następnie rejestruje default 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.
Jan
już zaczął testować z iOS 11 GM, wciąż widzę dziwne zachowanie, logi takie jak com.apple.fetch.com.troii.timriphone:F613DA:[ {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Must Not Proceed, Score: 0.00}} ], FinalDecision: Must Not Proceed}
Thomas Einwaller
1
Ponadto - udało mi się rozwiązać moją aplikację, wysyłając cichy push z powiadomieniem o skrótach i wypełniając powiadomienie odpowiednią treścią za pomocą rozszerzenia usługi powiadomień.
kam800
9

Informacje o wersji beta systemu iOS 11.1 obejmują: Powiadomienia Rozwiązane problemy Ciche powiadomienia push są przetwarzane częściej. (33278611)

Andrew Gould
źródło
7

iOS 11.1 Beta 2 zawiera również

Notifications
Resolved Issues
 Silent push notifications are processed more frequently. (33278611)

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.

Thomas Einwaller
źródło
1
Przetestowałem różne scenariusze: działało na pierwszym planie iw tle. Niestety nie działa, jeśli aplikacja została zamknięta przez użytkownika. Po zamknięciu urządzenie nie otrzymuje żadnego cichego naciśnięcia, o ile aplikacja nie zostanie ponownie uruchomiona przez użytkownika. Czy doświadczyłeś tego samego?
AlexWoe89
teraz działa ... po „przestoju” trwającym ok. 5 do 10 minut ciche powiadomienia działają zgodnie z oczekiwaniami ... przepraszam za moje poprzednie. komentarz :)
AlexWoe89
1
Silent pushy nigdy nie działały, gdy użytkownik zamyka aplikację - patrz developer.apple.com/documentation/uikit/uiapplicationdelegate/ ... „Jednak system nie uruchamia automatycznie aplikacji, jeśli użytkownik wymusił jej zamknięcie”.
Thomas Einwaller,
1
Widzę, że iOS11.1 beta 3 działa podobnie jak iOS10 i dużo lepiej niż iOS11.1 beta 2.
Lee,
1
@Olecramoak dla mnie iOS11.1 beta 4 działa jak iOS 10.
AlexWoe89
7

Apple Developer Relations właśnie dodał komentarz do mojego radaru:

Uważamy, że ten problem został rozwiązany w najnowszej wersji beta systemu iOS 11.2.

Przetestuj z najnowszą wersją beta systemu iOS. Jeśli nadal masz problemy, zaktualizuj swój raport o błędzie o odpowiednie dzienniki lub informacje, które mogą nam pomóc w zbadaniu sprawy.

https://developer.apple.com/download/

obecnie instaluję iOS 11.2 beta - przetestuje zachowanie cichego wypychania

Thomas Einwaller
źródło
Czy to oznacza, że ​​iOS 11.1 GM nie rozwiąże problemu? :(
Olecramoak
Dobrze to słyszeć, kiedy właściwie możemy spodziewać się oficjalnego wydania iOS11.1?
AlexWoe89
Informuj nas o tym, nie mogę obecnie zainstalować mojej aplikacji, ponieważ nie ma Xcode dla 11.2. (i usunąłem aplikację z mojego urządzenia)
Rool Paap
3

Miałem podobny problem z moją aplikacją, aż do iOS 10 otrzymywałem powiadomienia push i application:didReceiveRemoteNotification:fetchCompletionHandlerdzwonił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.

Upewnij się, że włączyłeś obie te funkcje.

Po włączeniu funkcji pobierania w tle działa teraz

Sudeep George
źródło
nie, to nie działa na iOS11 - po prostu zakończ aplikację raz, a następnie przestanie się budzić. po prostu przeczytaj odpowiedzi i komentarze w tym temacie
AlexWoe89
2
W przypadku zakończonej aplikacji żadne powiadomienia wypychane (pojedyncze lub ogólne wypychanie) nie będą wyzwalać metody delegata w delegacie aplikacji. to jest domyślne zachowanie. Nie ma specjalnego przypadku dla iOS 11.0.
Sudeep george
3

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 alertBodyna moich CKNotificationInfo()obiektach w następujący sposób:

let info = CKNotificationInfo()
info.shouldSendContentAvailable = true
info.alertBody = ""

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. :)

Clifton Labrum
źródło
U mnie działa również z CloudKit. Bez elementu alertBody musisz podłączyć urządzenie, aby uzyskać zdalne powiadomienia. Bardzo dziwne zachowanie ...
powertoold
2

Jest to więc rzeczywiście błąd w iOS 11 i został naprawiony w iOS 11 beta 3. application:didReceiveRemoteNotification:fetchCompletionHandlerTeraz 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

Jan
źródło
1
W rzeczywistości tak nie jest :( Nadal dzieje się to w iOS 11 beta 3
styczeń
1
Apple również ponownie otworzył raport o błędzie. Dam ci znać
sty
1
Nie otrzymuję cichych pushów w iOS 11 beta 4. Co więcej, jeśli aplikacja nie jest na pierwszym planie, czasami pojawiają się jako zwykłe powiadomienia. Zdecydowanie coś fajnego!
Ben Dodson
1
Właśnie zainstalowałem iOS 11 beta 5 i wygląda lepiej, a ciche powiadomienia są dostarczane, gdy aplikacja jest na pierwszym planie lub w tle za pośrednictwem delegata didReceiveRemoteNotification na chwilę, a potem przestała działać bez względu na to, co zrobię: / Czy masz to samo zachowanie?
stycznia
1
byłoby fajnie, gdybyś przetestował i przyprawia mnie o ból głowy. Ciche naciśnięcia działają lub nie działają losowo po ponownym uruchomieniu urządzenia. Zaktualizowałem mój oryginalny post przykładowym projektem, abyśmy wszyscy używali tego samego
stycznia
2

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.

elkorb
źródło
1
Wydawało się, że działa to dla mnie, a także obejście, aby DuetActivitySchedulerDaemon zezwolił powiadomieniu na wybudzenie aplikacji, dopóki Apple nie naprawi błędu.
Joe Benton
Podczas wypychania JSON-a zawierającego pusty tytuł nadal otrzymuję komunikat na konsoli „Ignorowanie powiadomienia bez alertu, dźwięku lub znaczka ...” {"aps": {"alert": {"title": ""}, "content-available": "1"}, "gcm.message_id": "0 ... bb"} Czy ta struktura JSON działa dla Ciebie?
Olecramoak
czy nie należy wysyłać 1 (wartość dostępnej treści) bez cudzysłowu?
elkorb
W ten sposób Google Firebase formatuje Json („1”) i zawsze działało. Tylko iOS 11 z bzdurami dasd stwarza problem. Czy mógłbyś opublikować przykład Json, który pracuje dla Ciebie?
Olecramoak
Więc to, co obserwuję na iOS 11.1, to to, że ciche naciśnięcia nie są dostarczane, jeśli urządzenie działa na baterii (nie ładuje się), a poziom baterii jest mniejszy niż 20%, nawet gdy tryb niskiego zużycia energii NIE jest włączony. To jest złe. Ciche pchnięcia na iOS 11 nie są w ogóle niezawodne, prawie bezużyteczne.
Olecramoak
1

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.

{
    "aps" : {
        "badge" : 0,
        "sound" : ""
    },
    "mydata": {  
        "foo": "bar"  
    }  
}

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.

Rammohan Raja
źródło
1

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.isRegisteredForRemoteNotificationsmetoda 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 ).

    • Odkryłem, że wystąpił błąd analizowania powiadomień push na konsoli z powodu "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.

Rageofflames
źródło
1

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 UNUserNotificationCenterDelegateprotokołem i willPresent notificationmetodą (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ś takim

    import UserNotifications

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
    var window: UIWindow?

    // MARK: - Lifecycle
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        UNUserNotificationCenter.current().delegate = self
        return true
    }

    //this was only method to handle notifications before
    func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any],
                     fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
        //process silent notification
        completionHandler(UIBackgroundFetchResult.newData)
    }
}

extension AppDelegate : UNUserNotificationCenterDelegate {
    func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) {
        //proces notification when app is active with `notification.request.content.userInfo`
        if UIApplication.shared.applicationState == .active {
            completionHandler(.badge)
        }else {
            completionHandler(.alert)
        }
    }
}

Aby 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 applicationDidBecomeActiveprzez:

UNUserNotificationCenter.current().getDeliveredNotifications { (notifications) in
            debugLog(message: "unprocessed notification count: \(notifications.count)")
            if notifications.count > 0 {
                notifications.forEach({ (notification) in
                    DispatchQueue.main.async {
                        //handle `notification.request.content.userInfo`
                    }
                })
            }
        }
Pacyjent
źródło
0

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ć.

Anish
źródło