Introduction

1. Basic Description

  Polyv Live Streaming originates from the company's years of video technology accumulation. Based on professional cross-platform video codec technology and large-scale video content distribution networks, it provides stable, smooth, low-latency, and high-concurrency real-time audio and video services.

  Polyv Live Java SDK allows you to easily access Polyv Live video cloud services without complex programming, enabling cloud live streaming related video services.

  Polyv Live Java SDK is implemented based on and wraps/optimizes the Polyv Live API. It liberates common tasks for B-end users. The API call logic and exception handling are encapsulated and optimized. B-end users only need to encapsulate the request parameters and hand them over to the Polyv Live Java SDK for processing. After the Polyv Live Java SDK completes processing, it returns the result, and the B-end continues its business logic based on the returned data. Currently, the Polyv Live Java SDK covers most frequently used API operations, including channel management, viewing management, live interaction, chat room, player, etc.

  If you encounter any problems while using the Polyv Live Java SDK, directly use the Online Customer Service to ask post-sales technical support questions. Please submit the problem's runtime environment, operation steps, error feedback information, and contact information simultaneously to facilitate quick problem identification and resolution.

2. Overall SDK Design

1. The B-end administrator creates basic channel information through the SDK, such as channel name, channel viewing password, channel live streaming scenario, etc.;
2. The B-end administrator performs basic information settings for the channel through the SDK, such as viewing condition settings, lecturer basic information settings, course basic information settings, sharing copy settings, etc.;
3. The B-end lecturer logs into the live channel via a web page, live assistant, or third-party push tool to start the live broadcast;
4. C-end viewers log into the live channel via a promoted sharing page link or QR code to watch the live content;
5. After the live broadcast ends, the B-end performs replay and transfer settings, obtains statistical analysis data, and completes the live broadcast business loop;

3. Detailed SDK Design

4. SDK Business Logic Analysis

• Prerequisite: SDK Global Initialization: Global parameters must be configured before calling the SDK. Configurable parameters include account information (appId, userId, appSecret) and HTTP connection pool parameters (timeout, maxClientNum). See Initialization for details.
• SDK Global Parameter Injection: The SDK injects globally configured parameters into the request object.
• Signature Generation: The SDK uses the MD5 algorithm signature rule to generate a signature.
• Parameter Legality Verification: The SDK uses a custom parameter verification tool to verify input parameters. If any parameter is invalid, a PloyvSdkException will be thrown. The exception's message includes the specific field information that failed verification. This exception is a runtime exception and must be caught to handle related business logic.
• Send HTTP Request, Get Return Data: The SDK initializes an HTTP connection pool during the initialization phase. All SDK requests are sent through this connection pool.
• Parse Return Data: Parse the return data. If the SDK call is successful, it will encapsulate the response object and return normally. If the server returns an error message, the SDK will throw a PloyvSdkException. The exception's message includes the specific server execution error information. This exception is a runtime exception and must be caught to handle related business logic.

5. Call Flow Template

  The above business flow diagram is parsed into the code level as follows. All calls to the Polyv Live Java SDK can refer to the following call template (Global initialization only needs to be called once globally).

6. Dependency Component Version Description

The common component information used by the latest version of the Polyv Java SDK is as follows.

Recommendations Regarding Jackson Component

If your project also uses the Jackson component, potential risks: When Jackson minor versions are inconsistent (e.g., jackson-databind differs from jackson-core/jackson-annotations minor versions, or conflicts with other dependencies in your business), it may trigger:

• NoSuchMethodError
• NoClassDefFoundError
• ClassCastException

Recommendations:

1. Unify the Jackson trio version in your project (jackson-bom or Spring Boot BOM). Ensure jackson-core / jackson-databind / jackson-annotations maintain the same minor version.
2. If your project must use a specific Jackson version (e.g., due to Spring Boot management), you can exclude Jackson when introducing the Polyv SDK, and let your project provide the Jackson version uniformly.

Example: Exclude Jackson transitively from the Polyv SDK

<dependency>
  <groupId>net.polyv</groupId>
  <artifactId>polyv-java-live-sdk</artifactId>
  <version>xxx</version>
  <exclusions>
    <exclusion>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-core</artifactId>
    </exclusion>
    <exclusion>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
    </exclusion>
    <exclusion>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-annotations</artifactId>
    </exclusion>
  </exclusions>
</dependency>

<!-- 再由你的项目统一指定 Jackson 版本（示意） -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson</groupId>
      <artifactId>jackson-bom</artifactId>
      <version>${jackson.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Recommendations Regarding Other Common Components

slf4j-api

• Spring Boot 2.x ecosystem typically remains on SLF4J 1.7.x
• Spring Boot 3.x ecosystem upgrades to SLF4J 2.0.x
• Recommendations:
  • When using Spring Boot, prioritize letting the Spring Boot BOM manage logging-related dependency versions; avoid explicitly fixing a version in your business project that is inconsistent with the BOM.
  • If your project explicitly introduces implementations like slf4j-simple, log4j-slf4j-impl, ensure only one implementation is retained (otherwise, "multiple bindings/providers" type issues may occur).

httpclient

• HttpClient 4.x (org.apache.http.*) and HttpClient 5.x (org.apache.hc.*) can coexist, generally without issues, but it is recommended to avoid mixing two versions in the same project.

Recommended Method for Resolving Dependency Conflicts

Execute in your project root directory (Maven):

1. View the final effective version (recommend adding -Dverbose):

mvn dependency:tree -Dverbose

2. Locate a specific component (Example: Jackson / HttpClient):

mvn dependency:tree -Dverbose -Dincludes=com.fasterxml.jackson.core:jackson-databind
mvn dependency:tree -Dverbose -Dincludes=org.apache.httpcomponents:httpclient

3. Determine who introduced a specific version (observe the "nearest-wins" path on the tree), then decide:

• Use dependencyManagement to unify the version
• Or perform exclusions at the point of introduction