J'ai remarqué que sur iOS 11 bêta 2, les notifications silencieuses ne sont pas livrées au application:didReceiveRemoteNotification:fetchCompletionHandler
quel que soit l'état de l'application (arrière-plan / premier plan).
J'ai implémenté la UIApplicationDelegete
méthode application:didReceiveRemoteNotification:fetchCompletionHandler
et j'envoie le push silencieux suivant
{
"aps": {
"content-available": 1
},
"mydata": {
"foo": "bar"
}
}
mais la méthode déléguée n'est pas appelée sur iOS 11.
Cela fonctionne bien sur les autres versions d'iOS et la section de documentation Configurer une notification silencieuse ne mentionne pas que quoi que ce soit d'autre doit être fait.
Est-ce un bogue dans iOS 11 ou ai-je manqué quelque chose de nouveau dans iOS 11?
Veuillez noter que je ne parle pas ou n'utilise pas le UserNotification
framework qui ne devrait pas être nécessaire pour envoyer des push silencieux.
Voici un exemple de projet qui illustre le problème (vous devrez définir votre propre identifiant de bundle)
Lorsque vous exécutez l'exemple de projet et envoyez une charge utile ci-dessus à l'application, vous pouvez utiliser la console macOS pour voir que le push est correctement transmis à l'appareil mais pas à l'application.
MISE À JOUR 10.08
Il semble que le comportement soit aléatoire. Parfois, après le redémarrage de l'appareil, la charge utile est livrée correctement mais elle cesse de fonctionner après un certain temps.
Comme vous pouvez le voir sur la capture d'écran suivante, le push marqué comme 1 est envoyé uniquement à l'appareil et le push 2 (après le redémarrage de l'appareil) est également livré à l'application.
MISE À JOUR 14.08 - iOS 11 Bêta 6
Toujours le même comportement. Une autre chose qui est censée fonctionner mais qui ne fonctionne pas est la suivante. Lorsque le schéma de l'application est défini sur «Attendre le lancement de l'exécutable», un push silencieux est censé réveiller l'application et la démarrer en arrière-plan.
MISE À JOUR 21.08 - iOS 11 Bêta 7
Toujours le même comportement et pas les mises à jour d'Apple dans le rapport de bogue.
MISE À JOUR 29.08 - iOS 11 Bêta 8
Toujours le même problème. Les étapes à reproduire que j'utilise maintenant sont les suivantes:
- Dans le schéma de projet Xcode, sélectionnez "Attendre le lancement de l'exécutable"
- Ajouter un point d'arrêt dans le
didReceiveRemoteNotification: fetchCompletionHandler
- Démarrez l'application sur l'appareil
- Envoyez la poussée silencieuse ci-dessus
Attendu : l'application passe de l'état suspendu à l'arrière-plan et didReceiveRemoteNotification: fetchCompletionHandler
est appelée
Réel : rien ne se passe
MISE À JOUR 06.09 - iOS 11 Bêta 10
J'ai toujours le même comportement de buggy. Le ticket d'Apple a été mis à jour avec la réponse suivante:
Relations avec les développeurs Apple 6 septembre 2017, 22:42 Le service technique a fourni les commentaires suivants concernant ce problème:
Nous avons pu exécuter l'exemple d'application et tester le comportement. Nous n'avons vu aucun problème lorsque nous avons testé cela comme décrit.
Les poussées ne sont pas garanties d'arriver à l'application lorsqu'elle s'exécute en arrière-plan, et les journaux ici indiquent que nous ne pensons pas que l'application est suffisamment utilisée pour la lancer.
Nous nous voyons livrer des poussées de temps en temps lorsque les conditions sont bonnes.
Nous pensons que cela se comporte correctement.
Mise à jour 11.09
Mon rapport de bogue Apple a été fermé et marqué comme doublon 33278611
dont reste ouvert
MISE À JOUR 13.09 - iOS 11 GM
Grâce aux commentaires de kam800 (voir ci-dessous), j'ai fait plus de tests et suis venu avec ces observations:
Il semble y avoir un nouveau démon dans iOS 11 dasd DuetActivitySchedulerDaemon
qui rejette complètement le push de données ou retarde la livraison de push de données:
Livraison reportée
Journaux de la console
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
Problèmes de livraison différée
- Lorsque la livraison push de données est reportée et que l'application est lancée, la poussée de données n'est livrée que lorsque la date de livraison est atteinte, ce qui peut être plusieurs minutes dans le futur. Cela va complètement à l'encontre de l'objectif d'utiliser les poussées de données pour garder le contenu de la nouvelle application prêt pour le prochain lancement. Je cite ici encore une fois la documentation d'Apple:
"Les notifications silencieuses améliorent l'expérience utilisateur en vous aidant à maintenir votre application à jour, même lorsqu'elle n'est pas en cours d'exécution."
- Lorsque deux poussées de données sont envoyées à une application suspendue, elles sont reportées par iOS 11 au lieu de réveiller l'application directement. Lorsque le délai de livraison est atteint, seule la dernière poussée de données est livrée! Les push précédents sont perdus et ne sont pas livrés via la méthode déléguée, ce qui entraîne une perte de données.
Livraison annulée
Journaux de la console
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
Problèmes de livraison annulés
Eh bien dans ce cas, la poussée de données est complètement perdue et jamais livrée sur iOS 11 alors qu'elle était correctement livrée sur iOS 10.
MISE À JOUR 19.09 - iOS 11 GM
J'ai également remarqué que lorsque l'application est au premier plan et que la notification n'est pas envoyée à l'application, je vois les journaux suivants dans la console:
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
et que l'application est au premier plan, le rappel ne sera pas déclenché.Réponses:
Ainsi, les notes de publication d'iOS 11.1 bêta 1 disent
J'ai fait quelques tests et cela semble effectivement corrigé:
État suspendu
Lorsque je lance l'application en mode suspendu et envoie un push silencieux, l'application est ramenée en arrière-plan et le
didReceiveRemoteNotification:fetchCompletionHandler
délégué est appelé.État de premier plan
De la même manière, lorsque l'application est au premier plan et qu'un push silencieux est envoyé, le délégué semble être appelé comme prévu. Cela ne fonctionnait pas au hasard dans les versions précédentes d'iOS 11, je vais donc le confirmer après plus de tests.
la source
Je voulais juste ajouter mes 2 cents ici car j'ai également été touché par ce problème et j'ai remarqué qu'Apple a fermé plusieurs radars sur ce problème en disant qu'ils ne pouvaient pas se reproduire. Une chose intéressante que j'ai trouvée est que les poussées seront livrées si l'application est en arrière-plan alors qu'elle est attachée au débogueur.
Si je tue le débogueur, débranche mon téléphone, lance l'application et envoie la charge utile push silencieuse, je vois que l'application ne se réveille PAS. Je vois dans le journal de la console que le système annule la livraison de la charge utile à mon application.
J'ai soumis un radar avec un petit exemple d'application qui reproduit le problème. J'ai également noté explicitement dans le radar que la personne travaillant sur mon ticket ne doit pas exécuter l'application associée au débogueur pour reproduire le problème. Voici le lien: https://bugreport.apple.com/web/?problemID=34461063
Espérons que cela entraînera des progrès sur cette question.
la source
On dirait un nouveau comportement d'iOS 11. iOS 11 beta 10 fournit quelques journaux descriptifs concernant ce problème:
On dirait que chaque push silencieux est livré à iOS, mais le démon dasd utilise quelques politiques pour décider si le push silencieux doit être livré à l'application (par exemple, niveau de batterie). J'ai réussi à recevoir une poussée silencieuse hier soir, mais mon iPhone était connecté au chargeur à ce moment-là - probablement le score BatteryLevelPolicy était suffisamment élevé pour recevoir cette poussée silencieuse.
Apple ne donne aucune information officielle sur ce comportement côté iOS, il n'y a que des informations sur la limitation côté serveur:
Je garde les doigts croisés, ils ont changé ce comportement, car cela réparerait mon application :) D'un autre côté, ce changement est bon - une parmi tant d'autres qui fait que la batterie de l'iPhone dure plus longtemps que les téléphones Android.
la source
dasd
processus enregistre ensuitedefault 10:17:42.994236 +0200 dasd DuetActivitySchedulerDaemon Advancing start date for <private> by 6.3 minutes to Wed Sep 13 10:24:03 2017
. La poussée silencieuse semble être délivrée à ce moment-là.com.apple.fetch.com.troii.timriphone:F613DA:[ {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Must Not Proceed, Score: 0.00}} ], FinalDecision: Must Not Proceed}
Les notes de version bêta d'iOS 11.1 incluent: Notifications Problèmes résolus Les notifications push silencieuses sont traitées plus fréquemment. (33278611)
la source
iOS 11.1 Beta 2 contient également
dans les notes de version - va le tester maintenant.
MISE À JOUR - 11.10.2017 - iOS 11.1 Bêta 2
Après avoir utilisé notre application pendant 2 jours dans des «scénarios du monde réel», il semble qu'il y ait une réelle amélioration dans cette version d'iOS. Je commence prudemment à croire que c'est réglé.
la source
Les relations avec les développeurs Apple viennent d'ajouter un commentaire à mon radar:
installer actuellement iOS 11.2 beta - testera le comportement de push silencieux
la source
J'ai eu un problème similaire avec mon application, jusqu'à iOS 10, je recevais des notifications push et
application:didReceiveRemoteNotification:fetchCompletionHandler
recevais un appel correct.Mais lors de la mise à jour vers iOS 11, les notifications push ont cessé de fonctionner.Le problème avec mon code était, même si j'utilisais content-available: 1 et mutable-content: 1 dans la charge de notification push, l'option de récupération en arrière-plan n'était pas activée. Mais cela fonctionnait parfaitement jusqu'à iOS 10.
Après avoir activé la fonction de récupération en arrière-plan, elle fonctionne maintenant
la source
iOS 11.4.1, Swift 4
J'avais des problèmes avec les poussées silencieuses qui n'arrivaient pas (de CloudKit) et j'ai essayé tout ce que tout le monde a mentionné ici. Ensuite, j'ai décidé d'essayer de mettre un blanc
alertBody
à mesCKNotificationInfo()
objets comme ceci:Cela a fait que les poussées étaient envoyées à une priorité plus élevée (mais elles étaient toujours des poussées silencieuses) et je n'ai plus eu l'erreur dans les journaux de mon appareil indiquant que la poussée était ignorée.
J'espère que cela aide quelqu'un. :)
la source
Il s'agit donc bien d'un bogue dans iOS 11 et il est maintenant corrigé dans iOS 11 beta 3. Le
application:didReceiveRemoteNotification:fetchCompletionHandler
s'appelle désormais correctement lorsqu'un push silencieux est reçu à la fois au premier plan ou en arrière-plan.METTRE À JOUR
Non, ce n'est pas corrigé et se produit toujours dans iOS beta 3 et 4
la source
Comme solution de contournement, nous ajoutons une clé "notification" et à l'intérieur d'un "titre" avec une chaîne vide comme valeur. C'est réveiller le rappel didReceive dans l'appDelegate.
la source
Au moment d'écrire cette réponse, je suis confronté au même problème que celui de Bill Dunay. réponse de .
Mon exigence était de recevoir des notifications silencieuses lorsque l'application est au premier plan et rien lorsque l'application est en arrière-plan / ne fonctionne pas. Et ma solution de contournement était la suivante. Je n'utilise pas de badges, donc le mettre à zéro n'est pas un problème pour moi.
Veuillez noter que je n'utilise délibérément pas «contenu disponible». Paramètre qui amène la logique d'optimisation iOS à retarder / annuler la livraison de la notification.
la source
J'ai eu le même problème pour certaines notifications (pas nécessairement silencieuses).
Après avoir examiné toutes les mises à jour et les réponses, je suis en mesure d'ajouter deux mises à jour qui peuvent aider:
J'ai trouvé que l'accès à la
UIApplication.shared.isRegisteredForRemoteNotifications
méthode lors de la réception d'une notification provoquait le blocage de l'application sans rien signaler à Xcode. Vérifiez si vous exécutez du code après avoir reçu la notification qui accède à la méthode. ( isRegisteredForRemoteNotifications verrouillant l'interface utilisateur avec semaphore_wait_trap )."title-loc-args" : [3333]
3333 n'acceptait pas littéralement mais l'acceptait comme une chaîne"title-loc-args" : ["3333"]
. Cela a rendu toute mon interface bloquée après avoir accédé à la méthode ci-dessus, uniquement sur iOS 11, cela fonctionne sur iOS 12.J'ai également découvert que, avec exactement le même code, cela fonctionne sans aucun problème sur iOS 12.0 (16A5366a) . Mais sur iOS 11, cela se produit.
la source
Dans mon cas, des notifications silencieuses ont été utilisées pour mettre à jour l'interface utilisateur après que le travail ait été effectué sur le site du serveur, il était donc pénible d'avoir un contenu non pertinent dans l'application. Parce que notre charge utile pour la notification silencieuse contient même le titre et le corps, j'implémente ces méthodes pour obtenir des notifications de travail dans l'application active / inactive, sans charger et avec l'actualisation de l'application en arrière-plan désactivée et même en état de faible consommation.
Pour que cela fonctionne, j'ajoute un délégué et crée une extension avec le
UNUserNotificationCenterDelegate
protocole et lawillPresent notification
méthode (iOS 10+), qui est déclenchée à chaque fois avec une charge utile correcte. Pour ne pas afficher de notification lorsque l'application est active, appelez simplement la fin avec un badge ou un son. J'ai fini avec quelque chose comme çaEt pour faire fonctionner ces états lorsque l'application est en arrière-plan et que la notification silencieuse n'appelle pas mes méthodes, je reçois des notifications du centre de notification directement
applicationDidBecomeActive
par:la source
Dans mon cas, "Actualisation de l'application en arrière-plan" a été désactivé dans les paramètres de l'iPhone. En raison de cette notification push a été envoyée à l'appareil mais pas sur l'application. L'activation de l'actualisation de l'application en arrière-plan reçoit le push silencieux dans l'application.
Ce n'est peut-être pas la vraie réponse à cette question, juste au cas où quelqu'un aurait besoin de vérifier.
la source