WuKongEasySDK

WuKongEasySDK uses WebSocket JSON-RPC CONNECT for a lightweight connection and online-messaging API. It fits applications that already have a product backend and own their UI and product state.

Choose a platform and send the first message

After the platform tutorial, Alice and Bob will connect separately, exchange a text JSON payload in a person Channel, then remove listeners and connections on exit.

Check whether it fits

EasySDK is neither a chat UI nor a complete product backend. A successful send means the server returned a send result; it does not mean the peer received, displayed, or processed the message. If you need the broader feature set, return to SDK selection.

Before you begin: get connection material from your backend

The client must not create its own identity or call Product HTTP management routes. After product login, the trusted backend returns the minimum connection material over HTTPS:

{
  "uid": "alice",
  "token": "short-lived-token",
  "websocketUrl": "wss://im.example.com/ws"
}

Complete Authentication & Tokens first. Saving /user/token does not automatically add production-grade CONNECT validation to the default composition. Your deployment needs a trusted validator and evidence that invalid, expired, and revoked tokens are rejected.

Alice/Bob acceptance loop

All four platforms follow the same minimal path:

1. Obtain separate uid, short-lived token, and websocketUrl values for Alice and Bob.
2. Create the clients in two independent devices, processes, or browser contexts by following the platform quickstart.
3. After both sides report a successful connection, have Alice send a text JSON payload to the person Channel bob.
4. Retain Alice's send result; on Bob, verify fromUid, the Channel, and the payload in the realtime message event.
5. Send from Bob to Alice and prove the reverse direction.
6. Leave the page or sign out, remove listeners, and disconnect; confirm there is no duplicate event or background connection.

This loop verifies online messaging only. Send acknowledgement, realtime receipt, and product completion are three different states; model them with Messaging.

To validate the environment first, follow Run the Official Examples with the verified server and client revisions before moving tutorial code into your application.

Lifecycle differences across platforms

A view may subscribe to connection state, but rebuilding the view must not create a second connection. Each platform's complete minimal example shows the correct owner and cleanup point.

Complete before production

• Use WSS and verify certificates, reverse-proxy WebSocket Upgrade, and device-side reachability.
• Prove that expired, revoked, wrong-identity, and replayed tokens are rejected.
• Keep SDK diagnostics disabled in Release builds, then use non-production canaries to inspect device logs, the browser Console, crash reports, and collectors.
• Accept reconnect, offline recovery, deduplication, push, multi-device behavior, capacity, observability, upgrades, and rollback separately.
• Record the server revision, SDK version, platform, device, and network instead of treating one development loop as a production receipt.

Use Release Checks to close these gates.

Versions and evidence

Current released versions

Released-package runtime evidence

Application dependencies use only these exact versions—never latest or a broad version range. All four official releases include logging-security changes that leave diagnostics off by default and sanitize enabled output:

The task sequence was calibrated from the legacy EasySDK overview, iOS, Android, Flutter, and Web pages. The released source and distributions above remain authoritative for APIs, versions, and security boundaries.

Next

First run the official examples, then choose a platform for application integration. If you need offline messages, conversations, unread state, or broader platform APIs, switch to the full SDK.