私たちは、すべてのSDKが一貫して動作し、PubNub開発者に可能な限り最高のエクスペリエンスを提供できるように努めています。私たちは最近、"イベントエンジン "のアップデートとして知られている多くの変更と、PubNubイベントを受信する方法をよりコントロールできる新しい "イベントリスナー "APIのセットを導入しました。

この記事では、これらの異なるアップデートが何であるかを説明し、新しい "イベントリスナー "の概要を説明します。

SDKサポート

この記事を書いている時点では、最新リリースの Java, Swift, Javascript, コトリンそして RustSDKは新しいイベント・エンジンとイベント・リスナーをサポートしており、近日中に追加SDKでのサポートが予定されています。

何が変わるのか？

高レベルでは、SDKに以下の変更を加えています：

イベントリスナーAPIを再構築し、アプリケーション全体に単一のグローバルなPubNubオブジェクトを渡す必要がなくなります。このリストの4つの箇条書きのうち、新しいイベントリスナーAPIはPubNub開発者に最大の利益をもたらすので、この記事の大部分はこれらに捧げられています。
PubNubバックエンドとの通信を管理し、メッセージやプレゼンスなどのイベントを受信するロジックを更新し、調和させる。これが「イベントエンジン」である。
これは'Event Engine'の改善によって可能になりました。
リトライポリシーを調和させ、全てのSDKで一貫性を持たせました。これも'Event Engine'の改善によって可能になりました。

変更その1：イベントリスナーAPIの再構築

より詳細なイベントリスナーを提供するためにSDKを改良しています。

エンティティとは何ですか？エンティティは、'Channel'、'Channel Group'、'User Metadata'、'Channel metadata'のいずれかになります。

ここでいうイベントとは、'メッセージ'、'プレゼンス・イベント'、'シグナル'、'オブジェクト・イベント'、'メッセージ・アクション'、'ファイル'のどれかです。

これらの改善により、他の利点として、異なるチャネルに対して別々のメッセージハンドラを指定することができます。つまり、アプリケーションのグローバルな状態を追跡し、すべてのPubNubイベントに対して単一のリスナーを維持する必要がなくなります。

以下のセクションのコードサンプルではJavaScriptを使用していますが、この記事の冒頭に挙げた各SDKで同等の機能が実装されています。

イベント・リスナーで何が変わるのか？

最近まで、すべてのSDKは、通常PubNubと呼ばれる単一のモノリシック・オブジェクトをSDKの中心に含み、サブスクライブ、アンサブスクライブ、パブリッシュなど、すべての可能なインタラクションへのエントリー・ポイントを提供していました。アプリの特定の画面で特定のチャンネルをサブスクライブするなど、これらのアクションのいずれかを実行したい場合は、アプリ全体でこのグローバルPubNubオブジェクトへの参照を渡す必要があります。

アクションを開始するだけでなく、PubNubオブジェクトはaddListener()メソッドとremoveListener()メソッドを通して、メッセージ、シグナル、プレゼンスイベント、オブジェクト、ファイル、アクションなどのステータスアップデート（主にサブスクライブ接続状態に関連する）とPNネットワークから来るリアルタイムイベントをリッスンすることもできます。このaddListener()コードは、すべてのイベントタイプとソースを処理するために多数の条件ブロックがあるため、通常は肥大化します。をご覧ください。のコードを見てください。

さらに、すべてがPubNubオブジェクトのグローバルスコープで発生することを理解することが重要です：

チャンネル/チャンネルグループの購読リストはグローバル（つまりPubNubオブジェクトにスコープされる）であり、購読 /購読解除の呼び出しによってグローバルリストに影響が及ぶ。
ステータスとイベントリスナーはグローバルで、現在サブスクライブしているすべてのチャネル/チャネルグループに関連するイベントを発信します。

その結果、アプリケーションに複数の画面があり、それぞれが異なるPubNubチャネルへの接続を必要とする場合、ユーザーがアプリをナビゲートするときに、どの接続が必要かを手動で追跡する必要があります。このプロセスは、不要になったチャネルからサブスクライブを解除するとエラーが発生しやすくなります。

イベントリスナーの新しいアーキテクチャ

新しいアーキテクチャは、現在、SDKの範囲で展開されており、サブスクリプションとイベントをリッスンするための新しい、より狭い範囲の方法を導入しています。これらの更新されたSDKは、非推奨についてはこの記事の後半で説明しますが、現在のところ下位互換性があります。新しいアーキテクチャでは、'エンティティオブジェクトを作成するためのメソッドが追加されています：

チャンネル
チャンネル・グループ
ユーザー・メタデータ
チャンネルのメタデータ

これらのエンティティはSubscriptionオブジェクトを返すsubscription()メソッドを含んでいます。例えば、私たちのJavaScript APIは次のように呼び出すことができます：

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

返されたSubscriptionオブジェクトは、より狭いスコープのPubNubクライアントと考えることができます; それは、親エンティティへのサブスクリプションを有効または停止するsubscribe()とunsubscribe()メソッドを含んでいます。Subscriptionのイベントを受け取るには2つの方法があります：

1.1.onMessageと onPresenceのための上記のコードスニペットに示されているようなon[Event]ハンドラ。他のハンドラは、シグナル、オブジェクト、ファイル、およびメッセージアクションのために存在する。

2.addListenerメソッドは、1つの関数内ですべてのイベントを受け取るので、以前のAPIからアップグレードする場合、この構文がより馴染みやすいと感じるでしょう。addListenerメソッドを使用してメッセージとプレゼンスイベントをリッスンするJavaScriptの同等のコードは、次のようになります：

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

新しいイベントリスナーの利点は何ですか？

任意のエンティティ(チャネルなど)に対して複数のSubscriptionオブジェクトを作成することができ、これらのすべてのSubscriptionオブジェクトは、同じエンティティに対して作成されたものであっても、互いに独立しています。これは、各Subscriptionが他のSubscriptionに影響を与えることなくアクティブ化(subscribe())または停止(unsubscribe())できることを意味し、単一のPubNubオブジェクトを介してグローバルな状態を管理する場合と比較して、クライアントアプリケーションのはるかに柔軟な構造を可能にします。

注：複数のSubscriptionオブジェクトを作成することは、SDKがこれらのすべてのSubscriptionを単一のサーバー接続上で多重化することを代行してくれるため、リソースの点では安価です。複数のPubNubオブジェクトを作成すると、それぞれが個別のサーバー接続を維持することになる'古い'アプローチとは対照的です。

最後に、SDKはまだPubNubオブジェクトのグローバルaddListener()メソッドをサポートしますが、これは、ステータスイベントをリッスンするためにのみ使用する必要があります。ステータスイベントConnectedや Disconnectedのような。

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

ユーザーが最初にアプリケーションを起動すると、いくつかの人気銘柄の値が表示されますが、ユーザーがログインすると、好きな銘柄シンボルを選択できるようになり、これらの銘柄の現在の価格も表示されるようになります。

PubNubでこのアプリケーションを実装するには、"commonStock "チャネルと "favoriteStock "チャネルの2つのチャネルを持つことにします。

ここで、ユーザージャーニーと、どのチャンネルで株価の更新を聞くかを追跡する方法を考えてみましょう：

以前のチャンネル購読のアーキテクチャでは、グローバルオブジェクトに依存していました。

1.ユーザーはアプリケーションを起動する。

アプリケーションは "commonStock "チャネルを購読する。

2.ユーザがログインする。

アプリケーションが「favoriteStock」チャンネルを購読する。

これでアプリケーションは2つのチャンネルに登録されました：「commonStock" と "favoriteStock" です。

3.ユーザがログアウトする

この場合、"favoriteStock" チャネルから購読を解除する必要があります。この場合、アプリケーションは 1 つのチャネルにのみ購読することになります：「commonStock"

この例では些細なことですが、画面とチャネルの数が増えるにつれて、大規模なアプリケーションの管理がますます複雑になることがわかります。アプリケーションの中に、購読しているチャネルリストのグローバルビューを持ち、ユーザがアプリケーションをナビゲートするときにそのリストで何が起こるべきかを理解するコンポーネントが必要です。

それでは、同じシナリオを新しいイベント・リスナーを使って見ていきましょう。

1.ユーザがアプリケーションを起動します。

アプリケーションは、前と同じように "commonStock" チャネルを購読します。

2.ユーザーがログインする。

一般的な株価と好きな株価を受信したいので、ログインしたユーザのために 2 つの購読を作成します。ユーザが「commonStock」チャネルを購読しているという事前知識は必要ありません。

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

これでアプリケーションは2つのチャンネルに登録されたことになります：「ユーザが stocksSub1 と stocksSub2 の両方を購読していても、追加のリソースを使用せず、重複したメッセージを受信しないことに注意してください。

3.ユーザーのログアウト

ユーザーログアウトロジックの一部として、"commonStock "と "favoriteStock "の両方のチャンネルから購読を解除します。ログアウトしたユーザがどのチャンネルにアクセスできるかは、我々のスコープ外なので考慮する必要はありません。

stocksSub2.unsubscribe()
favoritesSub.unsubscribe()

現在、アプリケーションは単一のチャネルにサブスクライブしています：「commonStockPrices "である。

つまり、"commonStock "がまだサブスクライブされているかどうかのグローバルビューを維持する必要はありません。

サブスクリプションをサブスクリプションセットにまとめる

これまでの例では、個別のチャンネルだけを考えてきましたが、サブスクリプションオブジェクトは単一のチャンネルやチャンネルグループに限定されません。

前の例を拡張すると、1つのイベントハンドラで、1つのSubscriptionSetで両方のログインチャンネルを処理することができます。

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

サブスクリプションはエンティティSubscriptionはエンティティから作成されますが、SubscriptionSetはグローバルなPubNubオブジェクトで呼び出されることに注意してください。

PubNubスコープ付きSubscriptionはいつ廃止されますか？

イベントリスナーに新しいアーキテクチャを導入するため、以前のAPIはSDKごとに非推奨になります。イベントハンドラの JavascriptSDKを例にとると、"古い" pubnub.subscribe()と pubnub.unsubscribe()メソッドが非推奨としてマークされていることに注意してください。私たちは、開発者のためにできるだけ摩擦のないアップグレードプロセスを作ることを目指しているので、私たちのSDKのそれぞれは、長い使用終了（EOL）期間をサポートしています。あなたの特定のSDKのドキュメントに記載されているEOL期間を参照してください。 SDK機能リストの一番下にあります。.

変更その2：イベントエンジンの更新

私たちのSDKの中心には、メッセージやプレゼンスアップデートのようなイベントを受信するために私たちのPubNubインフラストラクチャとの接続を処理するためのロジックループがあります - これは私たちがイベントエンジンと呼んでいるものです。一般的に、これは私たちのSDKを使用するときに設定するものではありませんし、99.9％のお客様のために箱から出してすぐに "ちょうど動作 "します。しかし、長年にわたってSDKファミリーを開発するにつれ（ソフトウェア・エンジニアリング・プロジェクトと同様）、技術的な負債が蓄積されていきます。すべてのSDKがユーザーに一貫した体験を提供する一方で、舞台裏ではSDKごとにイベント・エンジンの実装に癖があり、新機能の追加や稀なエッジケースの追跡が困難になっていました。

私たちは、各SDKのイベントエンジンを更新し、すべてのSDKが予測可能で一貫性のある方法で状態遷移を処理するようにします。これにより、お客様が経験するエッジケースの数を減らしながら、追加機能を提供する機能拡張を追加できるようになります。

新しいイベントエンジンにはどのようなコード変更が必要ですか？

SDKコンフィギュレーションにenableEventEngineという新しいコンフィギュレーションオプションが追加され、ドキュメントには "サブスクライブとプレゼンスに標準化されたワークフローを使用する "と記載されています。

つまり、このオプションをtrueに設定しても、特に文書化されていない限り、アプリケーションに変更を加える必要はありません。今のところ文書化されている唯一の例は、Kotlinののステータスイベントが更新されました。のKotlinステータスイベントが更新され、他のSDKと整合性が取れるようになりました（詳細は汎用接続ワークフローこれらの更新されたステータスは、Kotlinの接続ステータスリスナー新しいイベントエンジンを有効にする際の例外や必要な変更については、SDKのドキュメントを参照してください。

変更その3: プレゼンス状態管理の更新

プレゼンス状態とはカスタムユーザー状態プレゼンス・ステートの典型的なユースケースは、プレイヤーのスコア、ゲームの状態、または場所を維持することです。もしあなたが私たちのコラボレーション（ホワイトボード）デモをご存知であれば、そのアプリは「プレゼンス・ステート」を使ってユーザーのカーソル位置を登録・更新しています。

私たちは、プレゼンス・ステートの更新を別の方法で処理することで恩恵を受ける特定の顧客とのエッジケースをいくつか特定しました。しかし、これはケースバイケースであり、ほとんどのお客様は既存のプレゼンス・ステート・ロジックを変更せずに使い続けることができます。具体的には、「既存の」プレゼンス・ステート・ロジックは setPresenceState, getPresenceStateそしてstate-change'プレゼンス・イベントをリッスンする。

新しいプレゼンス状態管理にはどのようなコード変更が必要ですか？

SDKコンフィギュレーションに新しいコンフィギュレーションオプション、mentainPresenceStateが追加されました。ほとんどのお客様は、特にアドバイスがない限り、このパラメータのデフォルト値である'true'を保持する必要があります。この値を'true'に設定すると、上記のように現在の動作が保持されます。

変更その4：SDK Retryポリシーの調和

PubNubからクライアントが切断された場合、自動再接続ポリシーは歴史的に私たちの異なるSDK間で一貫性がありませんでした。

私たちのSDKのほとんどは、接続性の問題から回復する方法を設定する何らかの方法を提供しており、ほとんどの場合、「再試行ポリシー」設定を公開し、開発者が「なし」、「線形」、または「指数関数」のいずれかを選択できるようになっています。しかし、各ポリシーに関連するタイムアウト値はハードコードされ、SDKに固有となる。

再試行ポリシーは改善され、よりカスタマイズできるようになっています。接続管理再接続ポリシーのページSDK全体にこれらの変更を展開し続けるにつれて、再試行ポリシーは調和されるようになります。現在、設定することができます：

リニア再試行ポリシーカスタマイズ可能な遅延間隔と設定可能な最大再試行回数を持ちます。
指数リトライポリシーカスタマイズ可能な最小遅延と最大遅延、および最大リトライ回数。
リトライ・ポリシーから除外すべきエンドポイント。たとえば、データが時間的に敏感で、リトライする意味がない場合は、それを除外できます。多くの聴衆が多くのメッセージに反応するライブ・イベントを考えてみましょう。「message_reaction」イベント・タイプを除外することを選択できるかもしれません。

新しいグローバルretryConfigurationオプションとSDK固有の制限については、SDKの設定セクションを参照してください。

その他のリソース

この記事で説明した変更、特にイベントリスナーへの変更は、開発者が私たちのAPIとどのように相互作用するかに対する根本的な変更を表しています。それでも、私たちは長期的な利点が最初の学習曲線を上回ると強く信じています。私たちは、新しいイベントリスナーAPIへの移行をできるだけ簡単にしたいと考えています。専任サポートチームまたは、開発者リレーションチーム devrel@pubnub.com.

また、皆様からのフィードバックもお待ちしております。アップグレードをより簡単にするために私たちができること、提供できることはありますか？ぜひお知らせください。

PubNubはあなたのお役に立ちますか？

この記事はPubNub.comに掲載されたものです。

私たちのプラットフォームは、開発者がWebアプリ、モバイルアプリ、およびIoTデバイスのためのリアルタイムのインタラクティブ性を構築、配信、管理するのに役立ちます。

私たちのプラットフォームの基盤は、業界最大かつ最もスケーラブルなリアルタイムエッジメッセージングネットワークです。世界15か所以上で8億人の月間アクティブユーザーをサポートし、99.999%の信頼性を誇るため、停電や同時実行数の制限、トラフィックの急増による遅延の問題を心配する必要はありません。

PubNubを体験

ライブツアーをチェックして、5分以内にすべてのPubNub搭載アプリの背後にある本質的な概念を理解する

セットアップ

PubNubアカウントにサインアップすると、PubNubキーに無料ですぐにアクセスできます。

始める

PubNubのドキュメントは、ユースケースやSDKに関係なく、あなたを立ち上げ、実行することができます。

Blog

イベントエンジンとイベントリスナーのアップデート

PubNub Developer Relations