DEV Community

Cover image for Aktualizacje silnika zdarzeń i detektorów zdarzeń

Aktualizacje silnika zdarzeń i detektorów zdarzeń

Ciężko pracujemy, aby zapewnić, że wszystkie nasze zestawy SDK działają spójnie i zapewniają programistom PubNub najlepsze możliwe wrażenia. Niedawno wprowadziliśmy szereg zmian, zwanych łącznie aktualizacjami "Event Engine", a także nowy zestaw interfejsów API "Event Listener", które oferują większą kontrolę nad sposobem odbierania zdarzeń PubNub.

Ten artykuł ma na celu wyjaśnienie, czym są te różne aktualizacje, a także przegląd naszych nowych "Event Listeners".

Wsparcie SDK

W chwili pisania tego artykułu, najnowsze wersje naszych zestawów SDK Java, Swift, Javascript, Kotlini Rust Zestawy SDK obsługują nowy silnik zdarzeń i detektory zdarzeń, a wkrótce pojawią się dodatkowe zestawy SDK.

Co się zmienia?

Na wysokim poziomie wprowadzamy następujące zmiany w naszych zestawach SDK:

  • Przeprojektowanie naszych interfejsów API listenerów zdarzeń, dzięki czemu nie trzeba już przekazywać pojedynczego, globalnego obiektu PubNub w całej aplikacji. Spośród czterech punktów na tej liście, nowe interfejsy API listenerów zdarzeń przyniosą największe korzyści deweloperom PubNub, więc większość tego artykułu jest im poświęcona.

  • Aktualizacja i harmonizacja logiki, która zarządza komunikacją z zapleczem PubNub, odbierając zdarzenia, takie jak wiadomości lub obecność. To jest "silnik zdarzeń".

  • Ulepszono zarządzanie stanem obecności, co stało się możliwe dzięki usprawnieniom "Event Engine".

  • Ujednolicenie naszej polityki ponawiania prób, aby była spójna we wszystkich zestawach SDK. Było to również możliwe dzięki ulepszeniom "Event Engine".

Zmiana #1: Przeprojektowanie interfejsów API Event Listener

Ulepszamy nasze zestawy SDK, aby zapewnić bardziej szczegółowe detektory zdarzeń, umożliwiając określenie zakresu zdarzeń, które chcesz otrzymać.

Co to jestjednostka? Jednostka może być jednym z "kanałów", "grup kanałów", "metadanych użytkownika" i "metadanych kanału".

Co to jest*zdarzenie w tym* kontekście? Jest to jeden z "komunikatów", "zdarzeń obecności", "sygnałów", "zdarzeń obiektu", "akcji komunikatu" lub "pliku".

Ulepszenia te pozwalają między innymi na określenie oddzielnych programów obsługi komunikatów dla różnych kanałów, co oznacza, że nie trzeba już śledzić globalnego stanu aplikacji i utrzymywać jednego odbiornika dla wszystkich zdarzeń PubNub.

W chwili pisania tego tekstu wciąż wdrażamy te aktualizacje w całej gamie naszych zestawów SDK. W poniższych sekcjach użyłem JavaScript do przykładów kodu, ale znajdziesz równoważną funkcjonalność zaimplementowaną w każdym z zestawów SDK, które wymieniłem na początku tego artykułu.

Co się zmieniło w Event Listeners?

Do niedawna wszystkie nasze zestawy SDK zawierały pojedynczy monolityczny obiekt, zwykle nazywany PubNub, w centrum zestawu SDK, zapewniający punkty wejścia do wszystkich możliwych interakcji, np. subskrybowania, anulowania subskrypcji, publikowania itp. Jeśli chcesz wykonać dowolną z tych czynności, takich jak subskrybowanie określonego kanału na określonym ekranie aplikacji, musisz przekazać odniesienie do tego globalnego obiektu PubNub w całej aplikacji.

Oprócz inicjowania akcji, obiekt PubNub pozwala również użytkownikowi nasłuchiwać aktualizacji statusu (związanych głównie ze stanem połączenia subskrypcji) i zdarzeń w czasie rzeczywistym pochodzących z sieci PN, takich jak wiadomości, sygnały, zdarzenia obecności, obiekty, pliki i akcje za pomocą metod addListener() i removeListener(). Ten kod addListener() zwykle staje się rozdęty z powodu dużej liczby bloków warunków do obsługi wszystkich typów zdarzeń i źródeł - wystarczy spojrzeć na kod jednej z naszych aplikacji demonstracyjnych. kod jednej z naszych aplikacji demonstracyjnych jako przykład(!)

Ponadto ważne jest, aby zrozumieć, że wszystko dzieje się w globalnym zakresie obiektu PubNub, tj:

  • Lista subskrypcjikanału/grupy kanałów jest globalna (tj. przypisana do obiektu PubNub ), a na globalną listę mają wpływ wywołania subskrypcji/rezygnacji z subskrypcji.

  • Status i detektory zdarzeń są globalne i emitują zdarzenia związane ze wszystkimi aktualnie subskrybowanymikanałami/grupami kanałów.

W związku z tym, jeśli masz wiele ekranów w swojej aplikacji, z których każdy wymaga połączenia z różnymi kanałami PubNub, musisz ręcznie śledzić, które połączenia są wymagane, gdy użytkownik porusza się po aplikacji. Proces ten staje się podatny na błędy, ponieważ rezygnujesz z subskrypcji kanałów, które nie są już wymagane.

Nowa architektura dla detektorów zdarzeń

Nowa architektura, obecnie wdrażana w całej gamie naszych zestawów SDK, wprowadza nowe, węższe sposoby radzenia sobie z subskrypcjami i nasłuchiwaniem zdarzeń. Zaktualizowane zestawy SDK są obecnie wstecznie kompatybilne, choć w dalszej części tego artykułu omówiono ich wycofywanie. Nowa architektura oferuje dodatkowe metody tworzenia tzw.entity':

  • Kanały

  • Grupy kanałów

  • Metadane użytkownika

  • Metadane kanału

Jednostki te zawierają metodę subscription (), która zwraca obiekt Subscription. Na przykład nasz interfejs API JavaScript można wywołać w następujący sposób:

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);
}
Enter fullscreen mode Exit fullscreen mode

Możesz myśleć o zwróconym obiekcie Subscription jako o węższym kliencie PubNub; zawiera on metody subscribe() i unsubscribe() do aktywacji lub zatrzymania subskrypcji jego jednostki nadrzędnej. Istnieją dwa sposoby odbierania zdarzeń w Subskrypcji:

1. Programy obsługi on[Event], jak pokazano w powyższym fragmencie kodu dla onMessage i onPresence. Inne programy obsługi istnieją dla sygnałów, obiektów, plików i akcji wiadomości.

2. Metoda addListener będzie odbierać wszystkie zdarzenia w ramach jednej funkcji i ta składnia będzie bardziej znajoma, jeśli uaktualniasz z naszych poprzednich interfejsów API. Równoważny kod w JavaScript do nasłuchiwania wiadomości i zdarzeń obecności przy użyciu metody addListener będzie wyglądał następująco:

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

Jakie są zalety nowych Event Listeners?

Możesz utworzyć wiele obiektów Subskrypcji dla dowolnej jednostki (np. kanału), a wszystkie te obiekty Subskrypcji będą niezależne od siebie, nawet te utworzone dla tej samej jednostki. Oznacza to, że każda Subskrypcja może zostać aktywowana (subscribe()) lub zatrzymana(unsubscribe()) bez wpływu na inne Subskrypcje i pozwala na znacznie bardziej elastyczną strukturę aplikacji klienckich w porównaniu z zarządzaniem globalnym stanem za pośrednictwem pojedynczego obiektu PubNub.

Uwaga: Tworzenie wielu obiektów Subscription jest tanie pod względem zasobów, ponieważ SDK zajmie się multipleksowaniem wszystkich tych subskrypcji za pośrednictwem pojedynczego połączenia z serwerem. Porównaj to ze "starym" podejściem, w którym tworzenie wielu obiektów PubNub powodowałoby, że każdy z nich utrzymywałby osobne połączenie z serwerem.

Wreszcie, zestawy SDK nadal będą obsługiwać globalną metodę addListener() na obiekcie PubNub, ale powinna ona być używana tylko do nasłuchiwania zdarzeń stanutakich jak Connected lub Disconnected.

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

Rozważmy prostą aplikację, która pokazuje wartości różnych akcji. Gdy użytkownik po raz pierwszy uruchamia aplikację, wyświetlane są wartości niektórych popularnych akcji, ale gdy użytkownik się zaloguje, może wybrać swoje ulubione symbole giełdowe, a także otrzyma aktualne ceny tych akcji.

Aby zaimplementować tę aplikację w PubNub, można wybrać dwa kanały, kanał "commonStock" i kanał "favoriteStock".

Zastanówmy się teraz nad podróżą użytkownika i sposobem śledzenia, na których kanałach słuchać aktualizacji akcji:

W poprzedniej architekturze subskrypcji kanałów, która zależała od obiektu globalnego

1. Użytkownik uruchamia aplikację.

Aplikacja subskrybuje kanał "commonStock".

2. Użytkownik loguje się

Aplikacja subskrybuje kanał "favoriteStock".

Aplikacja jest teraz zasubskrybowana do dwóch kanałów: "commonStock" i "favoriteStock"

3. Użytkownik wylogowuje się

Aplikacja musi teraz określić, z których kanałów zrezygnować, w tym przypadku z "favoriteStock". Aplikacja jest teraz subskrybowana tylko do jednego kanału: "commonStock"

Chociaż w tym przykładzie jest to trywialne, można zauważyć, że wraz ze wzrostem liczby ekranów i kanałów, zarządzanie dużymi aplikacjami staje się coraz bardziej skomplikowane. Musisz mieć jakiś komponent w swojej aplikacji, który ma globalny widok listy subskrybowanych kanałów i rozumie, co powinno się stać z tą listą, gdy użytkownicy poruszają się po aplikacji.

Przejdźmy teraz przez ten sam scenariusz z nowymi Event Listeners

1. Użytkownik uruchamia aplikację.

Aplikacja subskrybuje kanał "commonStock", tak jak poprzednio

2. Użytkownik loguje się

Ponieważ chcemy otrzymywać ceny akcji zwykłych i ulubionych, tworzymy dwie subskrypcje dla zalogowanego użytkownika. Nie potrzebujemy żadnej wcześniejszej wiedzy o tym, że użytkownik był subskrybentem kanału "commonStock".

stocksSub2 = PN.channel(commonStock).subscription() 
stocksSub2.subscribe()
favoritesSub = PN.channel(favoriteStock).subscription() 
favoritesSub.subscribe()
Enter fullscreen mode Exit fullscreen mode

Aplikacja jest teraz subskrybowana do dwóch kanałów: "commonStock" i "favoriteStock". Zwróć uwagę, że nawet jeśli użytkownik jest subskrybentem zarówno stocksSub1, jak i stocksSub2, nie zużywa to żadnych dodatkowych zasobów i nie będzie otrzymywać zduplikowanych wiadomości.

3. Użytkownik wylogowuje się

W ramach logiki wylogowywania użytkownika, wypisujemy się zarówno z kanału "commonStock", jak i "favoriteStock". Nie musimy rozważać, do jakich kanałów ma dostęp wylogowany użytkownik, ponieważ jest to poza naszym zakresem.

stocksSub2.unsubscribe()
favoritesSub.unsubscribe()
Enter fullscreen mode Exit fullscreen mode

Aplikacja jest teraz subskrybowana do jednego kanału: "commonStockPrices", ze względu na istniejącą subskrypcję stocksSub1.

Kluczową różnicą jest to, że różne ekrany aplikacji muszą dbać tylko o to, co wydarzyło się w ich własnym zakresie, co oznacza, że nie musisz utrzymywać globalnego widoku tego, czy "commonStock" powinien być nadal subskrybowany; nowe programy obsługi zdarzeń robią to wszystko za Ciebie.

Łączenie subskrypcji w zestaw subskrypcji

Dotychczasowe przykłady dotyczyły tylko pojedynczych kanałów, ale obiekt subskrypcji nie jest ograniczony do pojedynczego kanału lub grupy kanałów, które można połączyć w zestaw subskrypcji, aby obsłużyć zdarzenia na wszystkich tych kanałach razem.

Aby rozszerzyć poprzedni przykład, moglibyśmy obsłużyć oba zalogowane kanały za pomocą jednego SubscriptionSet, z pojedynczą obsługą zdarzeń.

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

Zauważ, że podczas gdy Subskrypcja została utworzona z encji entityto SubscriptionSet jest wywoływany na globalnym obiekcie PubNub.

Kiedy subskrypcja PubNub-Scoped zostanie wycofana?

Ponieważ wprowadzamy nową architekturę dla detektorów zdarzeń, poprzednie interfejsy API są wycofywane w zależności od SDK. Weźmy przykład Javascript SDK i zauważ, że "stara" funkcja pubnub.subscribe() i pubnub.unsubscribe() Metody zostały oznaczone jako przestarzałe. Staramy się, aby proces aktualizacji był jak najmniej kłopotliwy dla naszych programistów, dlatego każdy z naszych zestawów SDK obsługuje długi okres wycofania z eksploatacji (EOL). Sprawdź udokumentowany okres EOL dla konkretnego zestawu SDK w dokumentacji, którą można znaleźć na dole listy funkcji SDK. na dole listy funkcji SDK.

Zmiana #2: Aktualizacje naszego silnika zdarzeń

W sercu naszych zestawów SDK znajduje się pętla logiczna do obsługi połączenia z naszą infrastrukturą PubNub w celu odbierania zdarzeń, takich jak wiadomości lub aktualizacje obecności - to jest to, co nazywamy naszym silnikiem zdarzeń. Ogólnie rzecz biorąc, nie jest to coś, co konfigurujesz podczas korzystania z naszych zestawów SDK i będzie "po prostu działać" po wyjęciu z pudełka dla 99% naszych klientów.Podczas gdy wszystkie nasze zestawy SDK zapewniały spójne wrażenia dla użytkownika, za kulisami różne zestawy SDK miały dziwactwa implementacyjne w silniku zdarzeń, które utrudniały nam dodawanie nowych funkcji i śledzenie rzadkich przypadków brzegowych.

Aktualizujemy silnik zdarzeń w każdym z naszych zestawów SDK, aby wszystkie obsługiwały przejścia stanów w przewidywalny i spójny sposób; pozwoli nam to dodać ulepszenia, które zapewnią dodatkową funkcjonalność, jednocześnie zmniejszając liczbę przypadków brzegowych, z którymi będą mieli do czynienia nasi klienci.

Jakie zmiany w kodzie są wymagane dla nowego Event Engine?

Do konfiguracji SDK dodano nową opcję konfiguracyjną, enableEventEngine, która zgodnie z dokumentacją będzie "wykorzystywać znormalizowane przepływy pracy dla subskrypcji i obecności." Przez "znormalizowane" odzwierciedla to nasze wysiłki na rzecz standaryzacji implementacji silnika we wszystkich naszych SDK opisanych w poprzedniej sekcji.

Jest to zmiana nierozerwalna, co oznacza, że jeśli ustawisz tę opcję na true, nie będziesz musiał wprowadzać żadnych zmian w swojej aplikacji, chyba że udokumentowano inaczej. Jak dotąd jedynym udokumentowanym przykładem jest Kotlin zdarzenia stanu dla Subscribe zostały zaktualizowane, aby były spójne z innymi zestawami SDK (szczegółowo opisane w naszym dopasowaniu naszego ogólny przepływ pracy połączeniaTe zaktualizowane statusy są używane w Kotlinie przez funkcję listener stanu połączenia.Prosimy o zapoznanie się z dokumentacją SDK dla dodatkowych wyjątków i wymaganych zmian podczas włączania nowego Event Engine.

Zmiana nr 3: Aktualizacje naszego zarządzania stanem obecności

Stan obecności odnosi się do niestandardowego stanu użytkownika który można ustawić, ale będzie on istniał tylko tak długo, jak długo użytkownik będzie subskrybował kanał. Typowe przypadki użycia stanu obecności obejmują utrzymywanie wyniku gracza, stanu gry lub lokalizacji. Jeśli znasz nasze demo demo współpracy (tablica)aplikacja ta wykorzystuje "stan obecności" do rejestrowania i aktualizowania pozycji kursora użytkownika.

Zidentyfikowaliśmy kilka skrajnych przypadków z konkretnymi klientami, którzy skorzystaliby z innej obsługi aktualizacji stanu obecności. Jest to jednak rozpatrywane indywidualnie, a większość klientów może nadal korzystać z istniejącej logiki stanu obecności bez zmian. W szczególności "istniejąca" logika stanu obecności to setPresenceState, getPresenceStatei nasłuchiwaniezmiana stanu'.

Jakie zmiany w kodzie są wymagane dla nowego zarządzania stanem obecności?

Do konfiguracji SDK dodano nową opcję konfiguracji, maintainPresenceState. Większość klientów, o ile nie zalecono inaczej, powinna zachować domyślną wartość tego parametru, "true". Ustawienie tej wartości na "true" zachowa obecne zachowanie, jak opisano powyżej.

Zmiana #4: Harmonizacja naszej polityki ponawiania SDK

W przypadku rozłączenia klienta z PubNub, zasady automatycznego ponownego połączenia były historycznie niespójne między naszymi różnymi zestawami SDK.

Większość naszych zestawów SDK oferuje pewien sposób konfiguracji sposobu odzyskiwania łączności, najczęściej poprzez udostępnienie konfiguracji "polityki ponawiania" i umożliwienie programiście wyboru między "brak", "liniowy" lub "wykładniczy". Jednak wartości limitu czasu powiązane z każdą polityką byłyby zakodowane na stałe i specyficzne dla zestawu SDK.

Zasady ponawiania prób są ulepszane i bardziej konfigurowalne, jak udokumentowano na stronie Polityka ponownego połączenia w zarządzaniu połączeniamiW miarę wprowadzania tych zmian we wszystkich naszych zestawach SDK, zasady ponawiania połączeń zostaną zharmonizowane. Można teraz skonfigurować:

  • Liniową politykę ponawiania połączeńz konfigurowalnym interwałem opóźnienia i konfigurowalną maksymalną liczbą ponownych prób.

  • Zasady ponawiania wykładniczegoz konfigurowalnym minimalnym i maksymalnym opóźnieniem oraz maksymalną liczbą ponowień.

  • Punkty końcowe, które powinny byćwykluczone z polityki ponawiania prób, na przykład, jeśli dane są wrażliwe na czas i nie ma sensu ich ponawiać, można je wykluczyć. Rozważmy wydarzenie na żywo, w którym duża publiczność reaguje na wiele wiadomości; możesz zdecydować się na wykluczenie typu zdarzenia "message_reaction".

Zapoznaj się z sekcją konfiguracji swojego zestawu SDK, aby uzyskać informacje na temat nowej globalnej opcji retryConfiguration i wszelkich ograniczeń specyficznych dla zestawu SDK.

Więcej zasobów:

Zmiany opisane w tym artykule, zwłaszcza zmiany w Event Listeners, stanowią fundamentalną zmianę w sposobie interakcji programistów z naszymi interfejsami API. Mimo to jesteśmy przekonani, że długoterminowe korzyści przewyższają początkową krzywą uczenia się. Chcemy, aby przejście na nowe interfejsy API Event Listener było jak najłatwiejsze, więc jeśli potrzebujesz pomocy lub wsparcia, skontaktuj się z naszym dedykowanym zespołem wsparcia. dedykowanym zespołem wsparcia lub napisz do naszego zespołu ds. relacji z deweloperami na adres devrel@pubnub.com.

Jesteśmy również zainteresowani opiniami użytkowników. Czy jest coś, co moglibyśmy zrobić lub zapewnić, aby ułatwić aktualizację? Daj nam znać.

Jak PubNub może ci pomóc?

Ten artykuł został pierwotnie opublikowany na PubNub.com

Nasza platforma pomaga programistom tworzyć, dostarczać i zarządzać interaktywnością w czasie rzeczywistym dla aplikacji internetowych, aplikacji mobilnych i urządzeń IoT.

Podstawą naszej platformy jest największa w branży i najbardziej skalowalna sieć komunikacyjna w czasie rzeczywistym. Dzięki ponad 15 punktom obecności na całym świecie obsługującym 800 milionów aktywnych użytkowników miesięcznie i niezawodności na poziomie 99,999%, nigdy nie będziesz musiał martwić się o przestoje, limity współbieżności lub jakiekolwiek opóźnienia spowodowane skokami ruchu.

Poznaj PubNub

Sprawdź Live Tour, aby zrozumieć podstawowe koncepcje każdej aplikacji opartej na PubNub w mniej niż 5 minut.

Rozpocznij konfigurację

Załóż konto PubNub, aby uzyskać natychmiastowy i bezpłatny dostęp do kluczy PubNub.

Rozpocznij

Dokumenty PubNub pozwolą Ci rozpocząć pracę, niezależnie od przypadku użycia lub zestawu SDK.

Top comments (0)