Wir arbeiten hart daran, sicherzustellen, dass sich alle unsere SDKs konsistent verhalten und PubNub-Entwicklern die bestmögliche Erfahrung bieten. Wir haben kürzlich eine Reihe von Änderungen eingeführt, die als Updates der "Event Engine" bekannt sind, sowie eine neue Reihe von "Event Listener"-APIs, die eine größere Kontrolle darüber bieten, wie Sie PubNub-Events empfangen.

Dieser Artikel erklärt die verschiedenen Updates und gibt einen Überblick über unsere neuen "Event Listener".

SDK-Unterstützung

Zum Zeitpunkt der Erstellung dieses Artikels sind die neuesten Versionen unserer Java, Swift, Javascript, Kotlinund Rust SDKs unterstützen die neue Event Engine und Event Listener, weitere SDKs werden in Kürze folgen.

Was wird sich ändern?

Im Großen und Ganzen nehmen wir die folgenden Änderungen an unseren SDKs vor:

• Überarbeitung unserer Event-Listener-APIs, so dass Sie nicht mehr ein einziges, globales PubNub-Objekt an Ihre gesamte Anwendung weitergeben müssen. Von den vier Punkten auf dieser Liste werden die neuen Event-Listener-APIs den größten Nutzen für PubNub-Entwickler bringen, daher ist der größte Teil dieses Artikels diesen gewidmet.

• Aktualisierung und Harmonisierung der Logik, die die Kommunikation mit dem PubNub-Backend verwaltet und Ereignisse wie Nachrichten oder Anwesenheit empfängt. Dies ist die 'Event Engine'.

• Verbesserte Verwaltung des Präsenzstatus', was durch Verbesserungen an der 'Event Engine' ermöglicht wurde.

• Harmonisierung unserer Wiederholungsrichtlinien, um sie über alle SDKs hinweg konsistent zu machen. Dies wurde ebenfalls durch Verbesserungen an der 'Event Engine' möglich gemacht.

Änderung Nr. 1: Überarbeitung der Event Listener APIs

Wir verbessern unsere SDKs, um granularere Ereignis-Listener bereitzustellen, die es Ihnen ermöglichen, der spezifischen Entität zuzuordnen, welche (s) Ereignis(e ) Sie empfangen möchten.

Was ist eine Entität? Eine Entität kann eine der folgenden sein: "Kanal", "Kanalgruppe", "Benutzer-Metadaten" und "Kanal-Metadaten".

Was ist ein*Ereignis in diesem Zusammenhang?* Eine Nachricht, ein Präsenzereignis, ein Signal, ein Objektereignis, eine Nachrichtenaktion oder eine Datei.

Diese Verbesserungen ermöglichen es Ihnen unter anderem, separate Nachrichten-Handler für verschiedene Kanäle zu spezifizieren. Das bedeutet, dass Sie nicht mehr den globalen Zustand Ihrer Anwendung verfolgen und einen einzigen Listener für alle PubNub-Ereignisse pflegen müssen.

Zum Zeitpunkt des Verfassens dieses Artikels sind wir noch dabei, diese Aktualisierungen in allen unseren SDKs einzuführen. Für die Codebeispiele in den folgenden Abschnitten habe ich JavaScript verwendet, aber Sie werden die entsprechende Funktionalität in jedem der SDKs finden, die ich oben in diesem Artikel aufgeführt habe.

Was ändert sich mit Event Listeners?

Bis vor kurzem enthielten alle unsere SDKs ein einziges monolithisches Objekt, in der Regel PubNub genannt, im Zentrum des SDKs, das Einstiegspunkte für alle möglichen Interaktionen bot, z. B. Abonnieren, Abbestellen, Veröffentlichen usw. Wenn Sie eine dieser Aktionen durchführen möchten, z. B. das Abonnieren eines bestimmten Kanals in einem bestimmten Bildschirm Ihrer Anwendung, müssen Sie in Ihrer gesamten Anwendung einen Verweis auf dieses globale PubNub-Objekt übergeben.

Neben der Initiierung von Aktionen ermöglicht das PubNub-Objekt dem Benutzer auch, Statusaktualisierungen (die sich hauptsächlich auf den Status der abonnierten Verbindung beziehen) und Echtzeit-Ereignisse aus dem PN-Netzwerk, wie Nachrichten, Signale, Präsenzereignisse, Objekte, Dateien und Aktionen, über die addListener()- und removeListener() -Methoden abzuhören. Dieser addListener() -Code wird in der Regel durch die große Anzahl von Bedingungsblöcken aufgebläht, um alle Ereignistypen und -quellen zu behandeln - sehen Sie sich nur den Code für eine unserer Demo-Anwendungen als ein Beispiel dafür(!)

Darüber hinaus ist es wichtig zu verstehen, dass alles im globalen Bereich des PubNub-Objekts passiert, d.h.:

• Die Abonnementliste des Kanals/derKanalgruppe ist global (d.h. auf das PubNub-Objekt skaliert), und die globale Liste wird durch subscribe/unsubscribe-Aufrufe beeinflusst.

• Die Status- und Ereignis-Listener sind global und geben Ereignisse aus, die sich auf alleKanäle/Kanalgruppen beziehen, die derzeit abonniert sind.

Wenn Sie also mehrere Bildschirme in Ihrer Anwendung haben, von denen jeder eine Verbindung zu verschiedenen PubNub-Kanälen benötigt, müssen Sie manuell nachverfolgen, welche Verbindungen benötigt werden, während Ihr Benutzer durch Ihre Anwendung navigiert. Dieser Prozess wird fehleranfällig, wenn Sie sich von Kanälen abmelden, die nicht mehr benötigt werden.

Neue Architektur für Event-Listener

Die neue Architektur, die derzeit in allen unseren SDKs eingeführt wird, bietet neue, enger gefasste Möglichkeiten für den Umgang mit Abonnements und das Abhören von Ereignissen. Diese aktualisierten SDKs sind derzeit abwärtskompatibel, obwohl die Veralterung später in diesem Artikel behandelt wird. Die neue Architektur bietet zusätzliche Methoden zur Erstellung von so genannten 'Entität' Objekte:

• Channels

• Kanal-Gruppen

• Benutzer-Metadaten

• Kanal-Metadaten

Diese Entitäten enthalten eine subscription() -Methode, die ein Subscription-Objekt zurückgibt. Unsere JavaScript-API kann zum Beispiel wie folgt aufgerufen werden:

const channel = pubnub.channel('channel_1');
const channelSubscription = channel.subscription({receivePresenceEvents: true});
channelSubscription.subscribe()
channelSubscription.onMessage = function (message) {
    console.log(message);
}
channelSubscription.onPresence = function (presenceEvent) {
    console.log(presenceEvent);
}

Sie können sich das zurückgegebene Subscription-Objekt als einen engeren PubNub-Client vorstellen; es enthält subscribe()- und unsubscribe() -Methoden, um das Abonnement der übergeordneten Entität zu aktivieren oder zu beenden. Es gibt zwei Möglichkeiten, Ereignisse auf einer Subscription zu empfangen:

1. Die on[Event]-Handler, wie im obigen Codeschnipsel für onMessage und onPresence gezeigt. Weitere Handler gibt es für Signale, Objekte, Dateien und Nachrichtenaktionen.

2. Die addListener-Methode empfängt alle Ereignisse innerhalb einer einzigen Funktion, und Sie werden diese Syntax vertrauter finden, wenn Sie von unseren früheren APIs aufrüsten. Der entsprechende Code in JavaScript, um mit der addListener-Methode auf Nachrichten und Präsenzereignisse zu warten, sieht wie folgt aus:

channelSubscription.addListener({
    //  Messages
    message: (message) => {console.log(message)},
    //  Presence event
    presence: (presenceEvent) => {console.log(presenceEvent)}, 
    //  Other event handlers for signals, objects, files, message actions
});

Was sind die Vorteile der neuen Event Listener?

Sie können mehrere Subscription-Objekte für eine beliebige Entität (z. B. einen Kanal) erstellen, und alle diese Subscription-Objekte sind unabhängig voneinander, auch wenn sie für dieselbe Entität erstellt wurden. Das bedeutet, dass jede Subscription aktiviert(subscribe()) oder gestoppt(unsubscribe()) werden kann, ohne dass dies Auswirkungen auf andere Subscriptions hat, und ermöglicht eine viel flexiblere Strukturierung von Client-Anwendungen, verglichen mit der Verwaltung des globalen Zustands durch das einzelne PubNub-Objekt.

Hinweis: Das Erstellen mehrerer Subscription-Objekte ist ressourcenschonend, da das SDK das Multiplexing all dieser Subscriptions über eine einzige Server-Verbindung für Sie übernimmt. Im Gegensatz zum 'alten' Ansatz, bei dem das Erstellen mehrerer PubNub-Objekte dazu führen würde, dass jedes eine eigene Server-Verbindung unterhalten müsste.

Schließlich unterstützen SDKs immer noch eine globale addListener() -Methode für das PubNub-Objekt, aber diese sollte nur verwendet werden, um auf Status-Ereignissewie Connected oder Disconnected.

pubnub.addListener({
    status: (s) => {console.log('Status', s.category) }
});

Betrachten wir eine einfache Anwendung, die die Werte verschiedener Aktien anzeigt. Wenn der Benutzer die Anwendung zum ersten Mal startet, werden ihm die Werte einiger beliebter Aktien angezeigt, aber wenn der Benutzer sich einloggt, kann er seine bevorzugten Aktiensymbole auswählen und erhält auch die aktuellen Preise dieser.

Um diese Anwendung in PubNub zu implementieren, könnten Sie sich für zwei Kanäle entscheiden, einen "commonStock"-Kanal und einen "favoriteStock"-Kanal.

Betrachten wir nun die User Journey und die Art und Weise, wie Sie herausfinden, auf welchen Kanälen Sie nach Aktienaktualisierungen suchen wollen:

Mit der bisherigen Architektur für Kanalabonnements, die von einem globalen Objekt abhängig war

1. Der Benutzer startet die Anwendung.

Die Anwendung abonniert den Kanal "commonStock".

2. Der Benutzer meldet sich an

Die Anwendung abonniert den Kanal "favoriteStock".

Die Anwendung ist nun bei zwei Channels abonniert: "commonStock" und "favoriteStock".

3. Der Benutzer meldet sich ab

Die Anwendung muss nun bestimmen, von welchem Kanal sie sich abmelden soll, in diesem Fall von "favoriteStock". Die Anwendung ist nun nur noch bei einem einzigen Kanal angemeldet: "commonStock"

Obwohl dies in diesem Beispiel trivial ist, können Sie sehen, wie die Verwaltung großer Anwendungen mit zunehmender Anzahl von Bildschirmen und Kanälen immer komplizierter wird. Sie benötigen eine Komponente in Ihrer Anwendung, die eine globale Übersicht über die Liste der abonnierten Kanäle hat und weiß, was mit dieser Liste geschehen soll, wenn die Benutzer durch Ihre Anwendung navigieren.

Lassen Sie uns nun dasselbe Szenario mit den neuen Event Listeners durchspielen

1. Der Benutzer startet die Anwendung.

Die Anwendung abonniert den Channel "commonStock", wie zuvor

2. Der Benutzer meldet sich an

Da wir allgemeine und bevorzugte Aktienkurse erhalten wollen, erstellen wir zwei Abonnements für den angemeldeten Benutzer. Wir brauchen kein Vorwissen, dass der Benutzer den Kanal "commonStock" abonniert hat.

stocksSub2 = PN.channel(“commonStock”).subscription() 
stocksSub2.subscribe()
favoritesSub = PN.channel(“favoriteStock”).subscription() 
favoritesSub.subscribe()

Die Anwendung ist nun bei zwei Kanälen abonniert: "Obwohl der Benutzer sowohl stocksSub1 als auch stocksSub2 abonniert hat, werden dadurch keine zusätzlichen Ressourcen verbraucht, und er erhält keine doppelten Nachrichten.

3. Der Benutzer meldet sich ab

Im Rahmen der Logik für die Abmeldung des Benutzers melden wir uns von den Kanälen "commonStock" und "favoriteStock" ab. Wir müssen nicht berücksichtigen, auf welche Kanäle ein abgemeldeter Benutzer Zugriff hat, da dies nicht in unseren Aufgabenbereich fällt.

stocksSub2.unsubscribe()
favoritesSub.unsubscribe()

Die Anwendung ist nun bei einem einzigen Kanal abonniert: "commonStockPrices", aufgrund des bestehenden stocksSub1-Abonnements.

Der Hauptunterschied besteht darin, dass sich die verschiedenen Bildschirme der Anwendung nur um das kümmern mussten, was in ihrem eigenen Bereich geschah, d. h. Sie müssen sich nicht mehr darum kümmern, ob "commonStock" noch abonniert werden sollte; das erledigen die neuen Ereignisbehandler für Sie.

Kombinieren von Abonnements zu einem Abonnement-Set

In den bisherigen Beispielen wurden nur einzelne Channels betrachtet. Das Subscription-Objekt ist jedoch nicht auf einen einzelnen Channel oder eine Channel-Gruppe beschränkt, sondern kann zu einem SubscriptionSet kombiniert werden, um die Ereignisse all dieser Channels gemeinsam zu behandeln.

Um das vorherige Beispiel zu erweitern, hätten wir beide eingeloggten Channels mit einem einzigen SubscriptionSet und einem einzigen Event-Handler behandeln können.

subscriptionSet = pubnub.subscriptionSet({channels: ['commonStock', 'favoriteStock’]})
subscriptionSet.onMessage = function (message) {console.log(message.channel)}
subscriptionSet.subscribe()

Beachten Sie, dass die Subscription zwar aus der Entitäterstellt wurde, wird das SubscriptionSet über das globale PubNub-Objekt aufgerufen.

Wann wird die PubNub-Scoped Subscription veraltet sein?

Mit der Einführung der neuen Architektur für Event-Listener werden die bisherigen APIs pro SDK veraltet sein, zum Beispiel die Javascript SDK, zum Beispiel, und beachten Sie, dass die "alte" pubnub.subscribe() und pubnub.unsubscribe() Methoden als veraltet markiert wurden. Wir möchten den Upgrade-Prozess für unsere Entwickler so reibungslos wie möglich gestalten, daher unterstützt jedes unserer SDKs eine lange End-of-Life (EOL)-Periode. Bitte sehen Sie sich die dokumentierte EOL-Periode für Ihr spezifisches SDK in den Dokumenten an, die Sie am Ende der Ende der SDK-Funktionsliste.

Änderung #2: Updates für unsere Event Engine

Das Herzstück unserer SDKs ist eine Logikschleife, die die Verbindung mit unserer PubNub-Infrastruktur herstellt, um Ereignisse wie Nachrichten oder Präsenz-Updates zu empfangen - dies bezeichnen wir als unsere Event-Engine. Im Allgemeinen ist dies nichts, was Sie konfigurieren müssen, wenn Sie unsere SDKs verwenden, und es wird bei 99 % unserer Kunden sofort funktionieren.Während alle unsere SDKs dem Benutzer eine konsistente Erfahrung bieten, gab es hinter den Kulissen bei verschiedenen SDKs Implementierungsfehler in der Ereignis-Engine, die es für uns schwierig machten, neue Funktionen hinzuzufügen und seltene Sonderfälle aufzuspüren.

Wir aktualisieren die Ereignis-Engine in jedem unserer SDKs, so dass sie alle Zustandsübergänge auf vorhersehbare und konsistente Weise handhaben. Dies wird uns ermöglichen, Verbesserungen hinzuzufügen, die zusätzliche Funktionen bieten, während wir die Anzahl der Randfälle, die unsere Kunden erleben werden, reduzieren.

Welche Codeänderungen sind für die neue Event Engine erforderlich?

Der SDK-Konfiguration wurde eine neue Konfigurationsoption hinzugefügt, enableEventEngine, die laut Dokumentation "die standardisierten Workflows für Subscription und Presence verwendet", was unsere Bemühungen widerspiegelt, die Implementierung der Engine in allen unseren SDKs zu standardisieren, wie im vorherigen Abschnitt beschrieben.

Es handelt sich um eine nicht-verändernde Änderung, d.h. wenn Sie diese Option auf true setzen, müssen Sie keine Änderungen an Ihrer Anwendung vornehmen , sofern nicht anders dokumentiert. Das einzige bisher dokumentierte Beispiel ist das Kotlin Statusereignisse für Subscribe wurden aktualisiert, um sie mit anderen SDKs konsistent zu machen (detailliert in unserer Anpassung des generischen Verbindungsworkflow). Diese aktualisierten Status werden in Kotlin vom Verbindungsstatus-Listener verwendet.Bitte konsultieren Sie die SDK-Dokumentation für zusätzliche Ausnahmen und erforderliche Änderungen bei der Aktivierung der neuen Event Engine.

Änderung #3: Updates für unser Presence State Management

Der Anwesenheitsstatus bezieht sich auf den benutzerdefinierten Benutzerstatus der eingestellt werden kann, aber nur so lange bestehen bleibt, wie der Benutzer den Kanal abonniert hat. Typische Anwendungsfälle für den Präsenzstatus sind die Aufrechterhaltung des Spielerstands, des Spielstatus oder des Standorts. Wenn Sie mit unserer Demo zur Zusammenarbeit (Whiteboard)kennen, verwendet diese Anwendung den Präsenzstatus, um die Cursorposition des Benutzers zu registrieren und zu aktualisieren.

Wir haben einige Sonderfälle mit bestimmten Kunden identifiziert, die von einer anderen Handhabung von Aktualisierungen des Präsenzstatus profitieren würden. Dies ist jedoch eine Einzelfallentscheidung, und die meisten Kunden können die bestehende Logik für den Anwesenheitsstatus ohne Änderungen weiter verwenden. Die "bestehende" Logik für den Anwesenheitsstatus lautet im Einzelnen setPresenceState, getPresenceStateund das Abhören der 'Zustandsänderung' Präsenz-Ereignis.

Welche Code-Änderungen sind für das neue Presence State Management erforderlich?

Der SDK-Konfiguration wurde eine neue Konfigurationsoption hinzugefügt, maintainPresenceState. Die meisten Kunden sollten, sofern nicht anders empfohlen, den Standardwert für diesen Parameter, 'true', beibehalten. Wenn Sie diesen Wert auf 'true' setzen, wird das aktuelle Verhalten, wie oben beschrieben, beibehalten.

Änderung Nr. 4: Harmonisierung unserer SDK-Wiederholungsrichtlinie

Im Falle einer Trennung des Clients von PubNub war die automatische Wiederverbindungspolitik in der Vergangenheit zwischen unseren verschiedenen SDKs inkonsistent.

Die meisten unserer SDKs bieten eine Möglichkeit, die Wiederherstellung nach einem Verbindungsproblem zu konfigurieren, in der Regel über eine "Wiederholungsrichtlinie", bei der der Entwickler zwischen "keine", "linear" und "exponentiell" wählen kann. Die Zeitüberschreitungswerte, die mit jeder Richtlinie verbunden sind, wären jedoch fest kodiert und spezifisch für das SDK.

Die Wiederholungsrichtlinie wird derzeit verbessert und anpassbarer gemacht, wie auf der Seite Seite zur Wiederverbindungsrichtlinie der VerbindungsverwaltungIm Zuge der weiteren Einführung dieser Änderungen in unseren SDKs wird die Wiederholungsrichtlinie harmonisiert. Sie können jetzt konfigurieren:

• Lineare Wiederholungsrichtliniemit einem anpassbaren Verzögerungsintervall und einer konfigurierbaren maximalen Anzahl von Wiederholungsversuchen.

• Exponentiale Wiederholungsrichtliniemit einer anpassbaren minimalen und maximalen Verzögerung sowie einer maximalen Anzahl von Wiederholungsversuchen.

• Endpunkte, die von der Wiederholungsrichtlinieausgenommenwerden sollen , z. B. wenn die Daten zeitkritisch sind und eine Wiederholung nicht sinnvoll ist, können Sie sie ausschließen. Denken Sie an eine Live-Veranstaltung, bei der ein großes Publikum auf viele Nachrichten reagiert; Sie könnten sich dafür entscheiden, den Ereignistyp "message_reaction" auszuschließen.

Die neue globale Option retryConfiguration und alle SDK-spezifischen Einschränkungen finden Sie im Konfigurationsabschnitt Ihres SDK.

Weitere Ressourcen:

Die in diesem Artikel beschriebenen Änderungen, insbesondere die Änderungen an den Event Listeners, stellen eine grundlegende Änderung der Art und Weise dar, wie Entwickler mit unseren APIs interagieren. Wir sind jedoch der festen Überzeugung, dass die langfristigen Vorteile die anfängliche Lernkurve überwiegen. Wir möchten Ihnen den Übergang zu den neuen Event Listener-APIs so einfach wie möglich machen. Wenn Sie also Hilfe oder Unterstützung benötigen, wenden Sie sich an unser engagierten Support-Team oder senden Sie eine E-Mail an unser Developer Relations Team unter devrel@pubnub.com.

Wir sind auch an Ihrem Feedback interessiert. Gibt es etwas, das wir tun oder anbieten könnten, um Ihnen das Upgrade zu erleichtern? Bitte lassen Sie es uns wissen.

Wie kann PubNub Ihnen helfen?

Dieser Artikel wurde ursprünglich auf PubNub.com veröffentlicht.

Unsere Plattform unterstützt Entwickler bei der Erstellung, Bereitstellung und Verwaltung von Echtzeit-Interaktivität für Webanwendungen, mobile Anwendungen und IoT-Geräte.

Die Grundlage unserer Plattform ist das größte und am besten skalierbare Echtzeit-Edge-Messaging-Netzwerk der Branche. Mit über 15 Points-of-Presence weltweit, die 800 Millionen monatlich aktive Nutzer unterstützen, und einer Zuverlässigkeit von 99,999 % müssen Sie sich keine Sorgen über Ausfälle, Gleichzeitigkeitsgrenzen oder Latenzprobleme aufgrund von Verkehrsspitzen machen.

PubNub erleben

Sehen Sie sich die Live Tour an, um in weniger als 5 Minuten die grundlegenden Konzepte hinter jeder PubNub-gestützten App zu verstehen

Einrichten

Melden Sie sich für einen PubNub-Account an und erhalten Sie sofort kostenlosen Zugang zu den PubNub-Schlüsseln

Beginnen Sie

Mit den PubNub-Dokumenten können Sie sofort loslegen, unabhängig von Ihrem Anwendungsfall oder SDK