Migration Guide: Updating Your Codebase
The external ExoPlayer is now deprecated. We strongly encourage you to switch to our custom player, NwPlayer. Please consult the migration section for detailed instructions on how to migrate from external ExoPlayer to NwPlayer.
We continuously strive to improve the developer experience and ensure our SDK remains flexible, efficient, and easy to integrate. We have updated the mechanism for integrating your custom ExoPlayer instance as part of this effort. Previously, we used a Channel to handle the communication between your application and the SDK. Now, we have transitioned to using CompletableDeferred, which offers a simpler and more robust solution for this use case.
Below, we will explain why this change was made, how it benefits you, and how to migrate your existing implementation.
When dealing with a single object (like an ExoPlayer instance) that needs to be passed temporarily between your code and the SDK, CompletableDeferred is a more suitable choice than Channel. Here’s why:
- Purpose
- Channel: Designed to stream multiple values over time.
- CompletableDeferred: Designed for a single value that needs to be produced asynchronously.
- Complexity
- Channel: Requires explicit closing after sending the value (close()).
- CompletableDeferred: Automatically resolves after a single value is provided (complete()).
- Resource Management
- Channel: Needs to be manually closed to avoid resource leaks.
- CompletableDeferred: No need for manual cleanup; it’s a lightweight, one-time operation.
- Error Handling
- Channel: Errors must be handled explicitly (e.g., trySend and checking for failures).
- CompletableDeferred: Errors are simpler to handle via the complete function’s return value.
- Use Case Fit
- Channel: Overkill for single-value communication.
- CompletableDeferred: Perfectly suited for single-value, one-time communication.
- Simplicity:
- CompletableDeferred is designed for one-time communication, making it easier to use and understand.
- No need to manage the lifecycle of a Channel (e.g., opening, closing, or handling backpressure).
- Safety:
- It ensures that only one value is sent, eliminating the risk of accidentally sending multiple values or forgetting to close the channel.
- The complete function provides a clear success/failure indication, making error handling straightforward.
- Performance:
- CompletableDeferred is lightweight and optimized for single-value communication, reducing unnecessary overhead.
If you are currently using the Channel-based approach, here is how to migrate to the new CompletableDeferred implementation:
- Replace Channel with CompletableDeferred.
- Use deferred.complete() instead of responseChannel.trySend().
- Remove the need to close the channel manually (responseChannel.close()).
- Optionally, add logging to track success or failure.
By migrating to CompletableDeferred, we have streamlined the integration process, making it easier for you to inject your custom ExoPlayer instance into the SDK. This change reduces boilerplate code, minimizes the risk of errors, and ensures a more efficient communication mechanism.