ツリー構造でRedPoint Systemを実装する

RedPointについて言えば，皆既になじみのないものではなくなっています。ゲームであれソフトウェアであれ、スマホシステムであれ、RedPointを通して、ユーザーやプレーヤーに「新しいメッセージが届きました。チャックしてください」と通知しています。 RedPoint Systemは、ゲーム開発者にとってはかなり厄介なシステムと言えます。関わるところが多く、レイヤーが深く、論理的な判断が複雑で、パフォーマンスが多様で、サーバーの判断が必要なものもあれば、クライアントの判断が必要なものもあり、扱いに面倒なところが多いです。 いくつかのプロジェクトでは、初期段階ではRedPointシステムの全体的な計画がないため、後期段階ではRedPointのニーズとプレゼンテーションに問題が発生しました。3〜4セットのRedPointシステムが共存されており、再構築しても根本的に解決できません。この記事では、RedPointの方法を共有します。 RedPoint Systemの概略 上図のように、RedPoint Systemを計画する際には、システム全体を構造層、駆動層、表示層の3つの独立した部分に分割しました。 構造層は、RedPoint Systemの階層構造を展開するために使用されます。RedPoint Systemの階層が深いため、ツリー構造でその階層を紹介しようと思います。 駆動層とは、ツリー構造を駆動して状態の変化を生成する方法、および状態の変化後に変更された動作を指定された表示層に通知して、データとプレゼンテーションをある程度分離する方法を指します。 表示層は、文字通りにプレゼンテーションの役割を担っています。例えば、単純な赤い点なのか、数字も表示するか、アイコンの揺れをするか、newというタグを表示するか、特殊効果を再生するか、などのような問題はこの表示層によって管理されています。 構造の設計 最初に一つの例から確認しましょう。UGUIによって設計されたが、一応これで説明させていただきます。 メインインターフェイスには、アライアンス、タスク、メールの3つのメインエントランスがあることがわかります。メールインターフェースでは、システム、チーム、アライアンスの3つのタブに分かれています。 ツリー構造に従って分析すると、次のようになります。 メインインターフェイスをルートノードとし、他のノードはすべてツリーの子ノードまたはリーフノードです。ここではメールモジュールだけが計画されているため、メールの下には3つのサブノードがあります。この章節も、この計画に基づき、Demoとコードを設計しようと思います。 コードのデザイン まずは、ツリー構造について見てみましょう。次のようになります。 constクラスを定義し、システムに従ってツリーの各ノードを分割します。たとえば、上記のRedPointツリー構造では、stringを使用してコードを完成させることができます。この定義は、構造を計画するためだけでなく、後でイベント駆動時のkeyを提供するためにも使用されます。 ツリー構造を表現した後、ノードがどのように表現されるかを見てみましょう。 いくつかのフィールドの意味は比較的明確なので、あまり説明しません。ノードも明確に定義されたら、RedPointSystemが何をする必要があるかを見てみましょう。 1つ目は、イベント駆動のDelegateタイプを定義すること、2つ目は、RedPointツリーのルートノードを持つこと、3つ目は、起動時の初期化を容易にするためにListに注意が必要なRedPointツリーを追加することです。 次は初期化です： コードは非常に単純です。つまり、各stringを配列に分割してから、配列をツリー構造に処理します。 ツリー構造が整ったので、イベント駆動を設定する必要があります。これは、このツリーにイベントコールバックをバインドするためのものです。 ここで、着信文字列はstringであるため、処理した最後のノードは、実際にコールバックをバインドする必要があるノードであることに注意してください。 ここまで、ツリー構造は完成、イベントモニタリングも設計し終わりました。では、駆動層についてはどうでしょうか。次のように： この関数は、コールバックを設定する上記の関数と非常によく似ています。実際のプロジェクトでは、2つの共通部分をパブリック関数として抽出することを検討する必要があります。すばやく表示するために、コードは簡潔ではありません。一般に、対応するノードを見つけて、それに特定の数のRedPointを設定します。 つまり、RedPointの数は、RedPointシステム全体とは関係ありません。サーバーからのプロトコル通知、クライアント自体によって送信されたデータ、またはファイルから読み取られたデータの場合があります。つまり、RedPointシステム自体は、RedPointの生成、管理、およびプレゼンテーションにのみ焦点を当てており、データのソースは考慮していません。 上記のコードは、RedPointNode構造で記述されたSetRedPointNumの関数に関連付けられています。この関数を見てください： ここでは特別な注意を払う必要があります。RedPointツリーは厳密に階層的に定義されています。つまり、すべての非リーフノードのRedPointは、その子ノードの統計から取得する必要があります。たとえば、メインインターフェイスに示したメールの数は、メールインターフェイス内の3つのタグの数の合計で、非リーフノードのRedPointの数を直接設定することはできません。関連するロジックが必要な場合は、表示層に独立に実行することをお勧めします（各ノードはのコールバックイベントに個別にバインドできます）。 内部の関数にも関わったので、次のように示します。 ここまで、RedPointシステムの設計は完了しました。 実際のプレゼンテーション 実際のパフォーマンスを見てみましょう！ デモコード： イベントハンドラー関数： インターフェイスのプレゼンテーション： ログエクスポート： 予想通り！ 後記： 冒頭で述べたように、RedPointシステムには3つのモジュールがありますが、現在のデモは構造層と駆動層のみを実装されており、表示層は一括的に計画されていないが、難しいことではありません。Listen関数に統一された処理クラスにつながり、スタイルを渡して分類すれば済みます。 デモであるため、アイデアと効果のみを示しています。コードはあまり簡潔ではなく、パフォーマンスも最高ではないため、使用する場合は、データ構造とパフォーマンスを考慮する必要があります。 また、これはRedPointシステムの実装ための一つの方法に過ぎず、すべての状況を解決できるわけではありませんが、現時点では、RedPoint面のニーズのほとんどはこのソリューションで解決できます。 UWA公式サイト：https://jp.uwa4d.com UWA公式ブログ：https://blog.jp.uwa4d.com UWA公式Q＆Aコミュニティ(中国語注意)：https://answer.uwa4d.com