Nous travaillons dur pour nous assurer que tous nos SDKs se comportent de manière cohérente et fournissent aux développeurs PubNub la meilleure expérience possible. Nous avons récemment introduit un certain nombre de changements, collectivement connus comme des mises à jour du "Event Engine", ainsi qu'un nouvel ensemble d'APIs "Event Listener" qui offrent un plus grand contrôle sur la façon dont vous recevez les événements PubNub.

Cet article vise à expliquer ce que sont ces différentes mises à jour ainsi qu'à donner un aperçu de nos nouveaux "Event Listeners".

Support SDK

Au moment de la rédaction de cet article, les dernières versions de notre SDK Java, Swift, Javascript, Kotlinet Rust Les SDK prennent en charge le nouveau moteur d'événements et les écouteurs d'événements, et d'autres SDK seront bientôt pris en charge.

Qu'est-ce qui change ?

À un niveau élevé, nous apportons les changements suivants à nos SDK :

• La refonte de nos API d'écoute d'événements afin que vous n'ayez plus à passer un seul objet PubNub global à travers toute votre application. Des quatre points de cette liste, les nouvelles API d'écoute d'événements apporteront le plus grand bénéfice aux développeurs PubNub, c'est pourquoi la plus grande partie de cet article leur est consacrée.

• Mise à jour et harmonisation de la logique qui gère la communication avec le backend PubNub, en recevant des événements tels que des messages ou des présences. Il s'agit du 'moteur d'événements'.

• Amélioration de la gestion de l'état de présence, rendue possible par les améliorations apportées au "moteur d'événements".

• Harmonisation de notre politique de relance pour la rendre cohérente dans tous les SDK, ce qui a également été rendu possible grâce aux améliorations apportées au "moteur d'événements".

Changement n° 1 : refonte des API d'écoute d'événements

Nous améliorons nos SDK afin de fournir des écouteurs d'événements plus granulaires, vous permettant d'étendre à l'entité spécifique le ou les événements que vous souhaitez recevoir.

Qu'est-ce qu'uneentité? Une entité peut être un "canal", un "groupe de canaux", des "métadonnées utilisateur" ou des "métadonnées de canal".

Qu'est-ce qu'un événement dans ce contexte ? Il peut s'agir d'un "message", d'un "événement de présence", d'un "signal", d'un "événement d'objet", d'une "action de message" ou d'un "fichier".

Ces améliorations vous permettent, entre autres, de spécifier des gestionnaires de messages distincts pour différents canaux, ce qui signifie que vous ne devez plus suivre l'état global de votre application et maintenir un seul auditeur pour tous les événements PubNub.

Au moment où j'écris ces lignes, nous sommes encore en train de déployer ces mises à jour dans notre gamme de SDK. J'ai utilisé JavaScript pour les exemples de code dans les sections suivantes, mais vous trouverez la fonctionnalité équivalente implémentée dans chacun des SDK que j'ai listés au début de cet article.

Qu'est-ce qui change avec les écouteurs d'événements ?

Jusqu'à récemment, tous nos SDK contenaient un seul objet monolithique, généralement appelé PubNub, au centre du SDK, fournissant des points d'entrée pour toutes les interactions possibles, par exemple, s'abonner, se désabonner, publier, etc. Si vous voulez effectuer l'une de ces actions, comme s'abonner à un canal spécifique dans un écran spécifique de votre application, vous devez passer une référence à cet objet PubNub global dans toute votre application.

En plus d'initier des actions, l'objet PubNub permet également à l'utilisateur d'écouter les mises à jour de statut (liées principalement à l'état de la connexion d'abonnement) et les événements en temps réel provenant du réseau PN, tels que les messages, les signaux, les événements de présence, les objets, les fichiers et les actions par le biais des méthodes addListener() et removeListener( ). Ce code addListener() devient généralement gonflé en raison du grand nombre de blocs de condition pour gérer tous les types d'événements et de sources - regardez simplement le code de l'une de nos applications de démonstration pour s'en convaincre( !)

En outre, il est important de comprendre que tout se passe dans la portée globale de l'objet PubNub, c'est-à-dire :

• La liste d'abonnement aucanal/groupe de canaux est globale (c'est-à-dire qu'elle est liée à l'objet PubNub ) et la liste globale est affectée par les appels d'abonnement/désabonnement.

• Les récepteurs d'état et d'événements sont globaux et émettent des événements liés à tous lescanaux/groupes de canaux actuellement souscrits.

Par conséquent, si vous avez plusieurs écrans dans votre application, chacun nécessitant une connexion à différents canaux PubNub, vous devez suivre manuellement les connexions requises au fur et à mesure que l'utilisateur navigue dans votre application. Ce processus est sujet à des erreurs lorsque vous vous désabonnez de canaux qui ne sont plus requis.

Nouvelle architecture pour les écouteurs d'événements

La nouvelle architecture, actuellement déployée dans notre gamme de SDK, introduit de nouvelles façons, plus restreintes, de traiter les abonnements et d'écouter les événements. Ces SDK mis à jour sont actuellement rétrocompatibles, bien que la dépréciation soit abordée plus loin dans cet article. La nouvelle architecture offre des méthodes supplémentaires pour créer ce que nous appelons des "entités".entité' :

• Canaux

• Groupes de canaux

• Métadonnées de l'utilisateur

• Métadonnées des canaux

Ces entités contiennent une méthode subscription() qui renvoie un objet Subscription. Par exemple, notre API JavaScript peut être appelée comme suit :

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);
}

Vous pouvez considérer l'objet Subscription renvoyé comme un client PubNub à portée plus étroite ; il contient des méthodes subscribe() et unsubscribe( ) pour activer ou arrêter l'abonnement à son entité parente. Il existe deux façons de recevoir des événements sur un abonnement:

1. Les gestionnaires on[Event], comme le montre l'extrait de code ci-dessus pour onMessage et onPresence. Il existe d'autres gestionnaires pour les signaux, les objets, les fichiers et les actions de message.

2. La méthode addListener reçoit tous les événements dans une seule fonction et cette syntaxe vous sera plus familière si vous passez de nos API précédentes. Le code équivalent en JavaScript pour écouter les messages et les événements de présence à l'aide de la méthode addListener se présente comme suit :

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

Quels sont les avantages des nouveaux écouteurs d'événements ?

Vous pouvez créer plusieurs objets Subscription pour n'importe quelle entité (par exemple, un canal), et tous ces objets Subscription seront indépendants les uns des autres, même ceux créés pour la même entité. Cela signifie que chaque Subscription peut être activé(subscribe()) ou arrêté(unsubscribe()) sans affecter les autres Subscriptions et permet une structuration beaucoup plus souple des applications clientes, par rapport à la gestion de l'état global à travers l'objet unique PubNub.

Remarque: la création de plusieurs objets Subscription est peu coûteuse en termes de ressources puisque le SDK se chargera de multiplexer tous ces abonnements sur une seule connexion serveur, contrairement à l'"ancienne" approche, où la création de plusieurs objets PubNub nécessitait une connexion serveur distincte pour chacun d'entre eux.

Enfin, les SDK prendront toujours en charge une méthode globale addListener() sur l'objet PubNub, mais celle-ci ne doit être utilisée que pour écouter les événements suivants événements d'étattels que Connecté ou Déconnecté.

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

Lorsque l'utilisateur lance l'application pour la première fois, il voit les valeurs de quelques actions populaires, mais lorsqu'il se connecte, il peut sélectionner ses symboles boursiers préférés et reçoit également les prix actuels de ces derniers.

Pour implémenter cette application dans PubNub, vous pouvez choisir d'avoir deux canaux, un canal "commonStock" et un canal "favoriteStock".

Examinons maintenant le parcours de l'utilisateur et la manière dont vous pouvez déterminer les canaux sur lesquels écouter les mises à jour des actions :

Avec l'architecture précédente pour les abonnements aux canaux, qui dépendait d'un objet global

1. L'utilisateur lance l'application.

L'application s'abonne au canal "commonStock".

2. L'utilisateur se connecte

L'application s'abonne au canal "favoriteStock".

L'application est maintenant abonnée à deux canaux : "commonStock" et "favoriteStock".

3. L'utilisateur se déconnecte

L'application doit maintenant déterminer de quels canaux elle doit se désabonner, en l'occurrence "favoriteStock". L'application n'est plus abonnée qu'à un seul canal : "commonStock"

Bien que cet exemple soit trivial, vous pouvez constater qu'à mesure que le nombre d'écrans et de canaux augmente, il devient de plus en plus compliqué de gérer les applications de grande taille. Vous devez disposer d'un composant dans votre application qui ait une vue globale de la liste des canaux auxquels vous êtes abonné et qui comprenne ce qui doit arriver à cette liste au fur et à mesure que les utilisateurs naviguent dans votre application.

Voyons maintenant le même scénario avec les nouveaux écouteurs d'événements.

1. L'utilisateur lance l'application.

L'application s'abonne au canal "commonStock", comme précédemment.

2. L'utilisateur se connecte

Puisque nous voulons recevoir les cours des actions communes et des actions favorites, nous créons deux abonnements pour l'utilisateur connecté. Nous n'avons pas besoin de savoir au préalable que l'utilisateur était abonné au canal "commonStock".

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

L'application est maintenant abonnée à deux canaux : "Notez que même si l'utilisateur est abonné à la fois à stocksSub1 et à stocksSub2, cela n'utilise pas de ressources supplémentaires et il ne recevra pas de messages en double.

3. L'utilisateur se déconnecte

Dans le cadre de la logique de déconnexion de l'utilisateur, nous nous désabonnons des canaux "commonStock" et "favoriteStock". Nous n'avons pas à nous préoccuper des canaux auxquels un utilisateur déconnecté a accès, car cela n'entre pas dans notre champ d'application.

stocksSub2.unsubscribe()
favoritesSub.unsubscribe()

L'application est maintenant abonnée à un seul canal : "commonStockPrices", en raison de l'abonnement existant à stocksSub1.

La principale différence réside dans le fait que les différents écrans de l'application ne doivent s'occuper que de ce qui se passe dans leur propre champ d'application, ce qui signifie que vous n'avez pas à maintenir une vue globale pour savoir si "commonStock" doit toujours être abonné ; les nouveaux gestionnaires d'événements s'en chargent pour vous.

Combiner des abonnements dans un ensemble d'abonnements

Les exemples précédents n'ont pris en compte que des canaux individuels, mais l'objet Abonnement n'est pas limité à un seul canal ou groupe de canaux, qui peuvent être combinés en un ensemble d'abonnements pour gérer les événements de tous ces canaux ensemble.

Pour prolonger l'exemple précédent, nous aurions pu gérer les deux canaux de connexion avec un seul SubscriptionSet, avec un seul gestionnaire d'événements.

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

Notez que si l'abonnement a été créé à partir de l'entité entitéle SubscriptionSet est appelé sur l'objet global PubNub.

Quand l'abonnement à l'échelle PubNub sera-t-il obsolète ?

Comme nous introduisons la nouvelle architecture pour les écouteurs d'événements, les API précédentes sont obsolètes sur la base d'un SDK particulier. Javascript par exemple, et remarquez que l'"ancienne" API pubnub.subscribe() et pubnub.unsubscribe() ont été marquées comme obsolètes. Nous souhaitons que le processus de mise à niveau soit le moins frictionnel possible pour nos développeurs, c'est pourquoi chacun de nos SDK prend en charge une longue période de fin de vie (EOL). Veuillez consulter la période EOL documentée pour votre SDK spécifique dans la documentation, qui se trouve vers le bas de la liste des fonctionnalités du SDK. vers le bas de la liste des fonctionnalités du SDK.

Changement n° 2 : Mises à jour de notre moteur d'événements

Au cœur de nos SDK, il y a une boucle logique pour gérer la connexion avec notre infrastructure PubNub afin de recevoir des événements tels que des messages ou des mises à jour de présence - c'est ce que nous appelons notre moteur d'événements. En général, ce n'est pas quelque chose que vous configurez lorsque vous utilisez nos SDK et cela fonctionnera tout simplement pour 99,9% de nos clients.9 % de nos clients, mais comme nous avons développé notre famille de SDK au fil des ans (comme pour tout projet d'ingénierie logicielle), vous accumulez de la dette technique. Alors que tous nos SDK fournissent une expérience cohérente à l'utilisateur, en coulisses, les différents SDK ont des bizarreries d'implémentation dans le moteur d'événements qui rendent difficile pour nous d'ajouter de nouvelles fonctionnalités et de traquer les rares cas de contournement.

Nous mettons à jour le moteur d'événements dans chacun de nos SDK afin qu'ils gèrent tous les transitions d'état de manière prévisible et cohérente ; cela nous permettra d'apporter des améliorations qui fourniront des fonctionnalités supplémentaires tout en réduisant le nombre de cas limites que nos clients rencontreront.

Quels changements de code sont nécessaires pour le nouveau moteur d'événements ?

Une nouvelle option de configuration a été ajoutée à la configuration du SDK, enableEventEngine, qui, selon la documentation, "utilisera les flux de travail normalisés pour l'abonnement et la présence", ce qui reflète nos efforts pour normaliser la mise en œuvre du moteur dans l'ensemble de nos SDK décrits dans la section précédente.

Il s'agit d'un changement irréversible, ce qui signifie que si vous attribuez la valeur "true" à cette option, vous n'aurez pas à apporter de modifications à votre application , à moins qu'il n'en soit stipulé autrement. Le seul exemple documenté jusqu'à présent est l'événement d'état Kotlin Les événements d'état pour Subscribe ont été mis à jour pour les rendre cohérents avec d'autres SDK (détaillés dans notre correspondance avec notre flux de travail de connexion générique). workflow de connexion génériqueCes statuts mis à jour sont utilisés en Kotlin par l'écouteur d'état de connexion auditeur d'état de connexionVeuillez consulter la documentation du SDK pour connaître les exceptions supplémentaires et les changements requis lors de l'activation du nouveau moteur d'événements.

Changement n° 3 : Mise à jour de notre gestion de l'état de présence

L'état de présence fait référence à l'état de l'utilisateur état personnalisé de l'utilisateur qui peut être défini mais qui ne persistera que tant que l'utilisateur sera abonné au canal. Les cas d'utilisation typiques de l'état de présence comprennent le maintien du score du joueur, de l'état du jeu ou de l'emplacement. Si vous êtes familier avec notre démo de démo de collaboration (tableau blanc)cette application utilise l'état de présence pour enregistrer et mettre à jour la position du curseur de l'utilisateur.

Nous avons identifié quelques cas particuliers avec des clients spécifiques qui bénéficieraient d'un traitement différent des mises à jour de l'état de présence. Cependant, il s'agit d'une question de cas par cas, et la plupart des clients peuvent continuer à utiliser la logique existante de l'état de présence sans changement. Plus précisément, la logique "existante" de l'état de présence est la suivante setPresenceState, getPresenceStateet l'écoute de la commandechangement d'état' (changement d'état).

Quelles modifications du code sont nécessaires pour la nouvelle gestion de l'état de présence ?

Une nouvelle option de configuration a été ajoutée à la configuration du SDK, maintainPresenceState. La plupart des clients, sauf avis contraire, devraient conserver la valeur par défaut de ce paramètre, 'true'. La définition de cette valeur à 'true' conservera le comportement actuel, tel que décrit ci-dessus.

Changement n° 4 : Harmonisation de notre politique de réessai du SDK

En cas de déconnexion d'un client de PubNub, la politique de reconnexion automatique a toujours été incohérente entre nos différents SDK.

La plupart de nos SDK offrent un moyen de configurer la façon de récupérer un problème de connectivité, le plus souvent en exposant une configuration de "politique de réessai" et en permettant au développeur de choisir entre "aucun", "linéaire" ou "exponentiel". Cependant, les valeurs de temporisation associées à chaque politique sont codées en dur et spécifiques au SDK.

La politique de réessai est en train d'être améliorée et rendue plus personnalisable, comme documenté sur la page Politique de reconnexion de la Politique de reconnexion de la gestion des connexionsAu fur et à mesure de la mise en œuvre de ces changements dans nos SDK, la politique de relance sera harmonisée. Vous pouvez désormais configurer la politique de relance linéaire :

• Une politique de relance linéaireavec un intervalle de temps personnalisable et un nombre maximum de tentatives configurable.

• Politique de relance exponentielleavec un délai minimum et maximum personnalisable, ainsi qu'un nombre maximum de tentatives.

• Points d'extrémité àexclure de la politique de réessai : par exemple, si les données sont sensibles au facteur temps et qu'il n'est pas utile de les réessayer, vous pouvez les exclure. Prenons l'exemple d'un événement en direct au cours duquel un large public réagit à de nombreux messages ; vous pouvez choisir d'exclure le type d'événement "message_reaction".

Veuillez consulter la section de configuration de votre SDK pour connaître la nouvelle option globale retryConfiguration et les éventuelles limitations spécifiques au SDK.

Plus de ressources :

Les changements décrits dans cet article, en particulier les changements apportés aux écouteurs d'événements, représentent un changement fondamental dans la manière dont les développeurs interagissent avec nos API. Cependant, nous sommes convaincus que les avantages à long terme l'emportent sur la courbe d'apprentissage initiale. Nous souhaitons que votre transition vers les nouvelles API d'écoute d'événements soit aussi facile que possible, alors si vous avez besoin d'aide ou d'assistance, n'hésitez pas à contacter notre équipe d'assistance dédiée ou envoyez un courriel à notre équipe chargée des relations avec les développeurs à l'adresse devrel@pubnub.com.

Nous sommes également intéressés par vos commentaires. S'il y a quelque chose que nous pourrions faire ou fournir pour faciliter votre mise à jour, n'hésitez pas à nous le faire savoir.

Comment PubNub peut-il vous aider ?

Cet article a été publié à l'origine sur PubNub.com

Notre plateforme aide les développeurs à construire, fournir et gérer l'interactivité en temps réel pour les applications web, les applications mobiles et les appareils IoT.

La base de notre plateforme est le réseau de messagerie en temps réel le plus grand et le plus évolutif de l'industrie. Avec plus de 15 points de présence dans le monde, 800 millions d'utilisateurs actifs mensuels et une fiabilité de 99,999 %, vous n'aurez jamais à vous soucier des pannes, des limites de concurrence ou des problèmes de latence causés par les pics de trafic.

Découvrez PubNub

Découvrez le Live Tour pour comprendre les concepts essentiels de chaque application alimentée par PubNub en moins de 5 minutes.

S'installer

Créez un compte PubNub pour un accès immédiat et gratuit aux clés PubNub.

Commencer

La documentation PubNub vous permettra de démarrer, quel que soit votre cas d'utilisation ou votre SDK.