Push-Benachrichtigungstests auf dem Gerät durchführen mit Xcode und Entwicklung-SSL-Zertifikat

Question

Meine App ist bereits im App Store und mit aktiven und funktionierenden Push-Benachrichtigungen (unter Verwendung des Produktzertifikats). Jetzt muss ich Abzeichen hinzufügen (bisher gab es nur Benachrichtigungen) in der Anwendung (die bereits auf der Serverseite implementiert ist). Für Tests benötige ich also ein Entwicklung-SSL-Zertifikat. Hier sind also meine Anfragen:

1. Muss ich das Entwicklung-SSL-Zertifikat auf meinem Server installieren, damit ich mit dem Entwicklungszertifikat auf dem iPhone testen kann?
2. Kommt es nicht zu Konflikten mit dem bereits installierten Produktions-SSL-Zertifikat auf dem Server?
3. Muss ich Abzeichen sowohl in den Delegaten didReceiveRemoteNotification: als auch didFinishLaunchingWithOptions: mit folgendem Code hinzufügen:

Codebereich:

NSString* alertValue = [[userInfo valueForKey:@"aps"] valueForKey:@"badge"];  
NSLog(@"Meine Nachricht-- %@",alertValue);  
int badgeValue= [alertValue intValue];  
[[UIApplication sharedApplication] setApplicationIconBadgeNumber:badgeValue];

Irgendwelche Vorschläge?

Answer 1

Nur um noch etwas zusätzliche Farbe zu den Fragen und Antworten zum Zertifikat/Server/SSL hinzuzufügen, die vorgeschlagen wurden:

Prod/Sandbox APNS basierend auf Codesign-Einstellungen ausgewählt

Zum Zwecke der Gründlichkeit wollen wir mit einer kurzen Übersicht der APNS-Umgebung beginnen:

• Anwendungen, die mit einem iOS-Entwicklungs-Zertifikat signiert sind, verbinden sich mit der Sandbox-APNS-Umgebung und warten darauf, dass Push-Benachrichtigungen geliefert werden.
• Anwendungen, die mit einem iOS-Verteilungs-Zertifikat signiert sind (AppStore oder Verteilung > Ad-Hoc), verbinden sich mit der Produktions-APNS-Umgebung und warten darauf, dass Push-Benachrichtigungen geliefert werden.
• Diese Einstellung wird automatisch von Xcode während des Build-Prozesses bestimmt und kann nur konfiguriert werden, indem der Typ des im CodeSign-Schritt verwendeten Zertifikats ausgewählt wird.

Frage 1: Muss ich das Entwicklung-SSL-Zertifikat auf meinem Server installieren, um Push-Benachrichtigungen von mit einem Entwicklungszertifikat signierten Apps zu testen?

Ja, sobald eine App signiert ist, wird ihre APNS-Einstellung anhand der Regeln im vorherigen Abschnitt im Binärcode versiegelt. Es liegt dann an dem Servercode des Entwicklers zu wissen, dass das APNS-Token, das das Gerät generieren wird, zur Sandbox-APNS-Umgebung gehört und dass der Server diese Anforderung für eine Push-Benachrichtigung an gateway.sandbox.push.apple.com weiterleiten sollte.

Einige Entwickler entscheiden sich dafür, einen Server einzurichten, der diese Unterscheidungen treffen kann, während andere sich dafür entscheiden, nebeneinander Instanzen ihrer Server einzurichten, wobei einer auf die Produktion und ein anderer auf die Sandbox sendet.

Wie auch immer, die Entscheidung liegt beim individuellen Entwickler und was der Serverseitige Code leisten kann und der relativen Komplexität beim Einrichten eines zweiten Servers. Auf jeden Fall könnten Benutzer verärgert sein, wenn Sie versehentlich die Produktions-Push-Benachrichtigungen deaktiviert haben, während Sie neue Funktionen testen, und vergessen haben, sie später wieder zu aktivieren, also seien Sie unbedingt vorsichtig, wenn Sie in der Produktionsumgebung herumexperimentieren!

Frage #2: Werden sich das Entwicklungszertifikat und das Produktionszertifikat widersprechen?

Vom reinen SSL-Standpunkt aus werden sie sich nicht widersprechen - Sie sollten in der Lage sein, beide Zertifikate auf einem anderen als dem Server installierten Computer herunterzuladen, zu öffnen und zu prüfen, dass die Inhalte der Zertifikate tatsächlich unterschiedlich sind. Das Importieren in dieselbe Serverumgebung (wieder vom SSL-Standpunkt aus gesehen) ist völlig zulässig. Um sicherzustellen, dass sie unterschiedlich sind, stellen Sie bei der Anforderung der Zertifikate unbedingt sicher, dass Sie zwei verschiedene certificateSigningRequests erstellen und Sie werden zwangsläufig mit unterschiedlichen Daten enden.

Vom Standpunkt des serverseitigen Push-Codes des Entwicklers aus - Es kommt darauf an. Sehen Sie das Gespräch in Frage 1 über die Fähigkeiten des serverseitigen Codes. Wenn der Servercode mit diesem Gedanken entworfen wurde, dann ist die theoretische Antwort ebenfalls 'Nein, sie werden sich nicht widersprechen', aber das ist eine Entscheidung, die der einzelne Entwickler über die Fähigkeiten seines eigenen serverseitigen Codes treffen muss.

Answer 2

1. Ja, Sie sollten das Entwicklung-SSL-Zertifikat auf dem Server installieren. Sie müssen auch den Sandbox-Push-Benachrichtigungsdienst (gateway.sandbox.push.apple.com) mit diesem Zertifikat verwenden.

2. Ich denke, sie werden sich nicht gegenseitig beeinträchtigen. Sie sollten einfach das Produktions-SSL für die App im AppStore und das Entwicklung-SSL für die Test-App verwenden.

3. Es ist besser, den Badge-Wert nicht im Code zu erhöhen oder zu verringern oder festzulegen. Ihr Server sollte den Badge-Wert im Benachrichtigungstext zurückgeben. Zum Beispiel können Sie Push-Nachrichten nicht verarbeiten, wenn Ihre App nicht läuft, daher können Sie den Badge-Wert im Code nicht ändern. Aber wenn Ihr Push-Nachricht den Badge-Wert enthält, wird er auf jede Weise korrekt gesetzt und angezeigt.

Hier ist ein Beispiel für den Benachrichtigungstext. Übergeben Sie den Badge-Wert für den Schlüssel "badge": {"aps":{"alert":"Dies ist die Nachricht.","badge":7}}

Übrigens, die Methode didReceiveRemoteNotification: wird immer aufgerufen, wenn Ihre App eine Push-Nachricht empfängt. Selbst wenn die App gestoppt ist, wird sie aufgerufen, wenn Sie die App aus der Push-Nachricht starten.

Answer 3

Ich wollte nur etwas zu den bereits vorhandenen Antworten hinzufügen. Während das Entwicklungszertifikat nicht mit dem Produktionszertifikat in Konflikt gerät, das auf dem gleichen Server installiert ist, können Konflikte mit den Geräte-Token auftreten, die in Ihrer Datenbank gespeichert sind. Wenn Sie ein Entwicklungszertifikat verwenden, erhalten Sie Entwicklungsgleichte Geräte-Token von Apple, die nicht mit den Produktionsgerätetoken übereinstimmen, die Sie für Ihr Produktionszertifikat erhalten. Wenn Sie sowohl Entwicklungsgleichte als auch Produktionsgeräte-Token in der gleichen Datenbank speichern (was Sie wahrscheinlich tun, wenn Sie denselben Server sowohl für Entwicklung als auch für Produktion verwenden), werden Sie Probleme haben, wenn Sie Benachrichtigungen mit Entwicklungsgleichtetoken unter Verwendung des Produktionszertifikats oder umgekehrt senden.

Deshalb empfiehlt Apple, separate Server für Entwicklung und Produktion zu verwenden.

Dieses Zitat stammt aus Fehlerbehebung bei Push-Benachrichtigungen, das ein sehr nützliches Dokument ist:

Das häufigste Problem ist ein ungültiges Geräte-Token. Wenn das Token aus der Sandbox-Umgebung stammt, z.B. wenn Sie eine Entwicklungsversion intern testen, können Sie es nicht an den Produktions-Push-Dienst senden. Jede Push-Umgebung gibt für dasselbe Gerät oder Computer ein anderes Token aus. Wenn Sie ein Geräte-Token an die falsche Umgebung senden, erkennt der Push-Dienst dies als ungültiges Token und verwirft die Benachrichtigung.

Hinweis: Es wird empfohlen, für jede Push-Umgebung eine separate Instanz Ihres Anbieters auszuführen, um das Problem des Sendens von Geräte-Token an die falsche Umgebung zu vermeiden.